| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0005880 | Spring engine | General | public | 2018-02-01 23:11 | 2019-07-23 13:45 | ||||||||
| Reporter | Doo | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | major | Reproducibility | sometimes | ||||||||
| Status | new | Resolution | open | ||||||||||
| Product Version | 104.0 +git | ||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0005880: LOS issues on slopes/cliffs | ||||||||||||
| Description | Just as you can see in the screenshots: Building LLTs near that cliff makes them both cloaked and stealthy. Both radar and los won't find them, which results in obvious exploits. (the two llts actually destroyed that pitbul) I also uploaded the replay, on 104.0.1-104-g2135e2e maintenance. This issue isn't actually new and could be seen on 103 aswell. I believe this is because the exact position of the unit is used to check for visibility. Since this position might have a tiny slope (from the terraforming that happened) in front of it, midway between los emmitter and unit position, while the unit is entirely inside LOS, it causes some glitchy LOS. (See ugly image showing this) What i propose is to either use x, y + losemitheight, z position rather than x, y, z as the key position to decide wether a unit is visible or not. That's meaningful since if two units have the same los, they should be able to see each other (always). (See the 2nd ugly image) In the meantime (before any fix or work is done to fix this glitch), i'd like to find a workaround. Do you have any idea how to ? I was thinking of checking units position and forcing them visible to certain teams depending on wether or not the x,y+losemitheight,z position was already visible to the said team, but i am not sure if it's possible to force a unit as "inside" x team's los. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Checked infolog.txt for Errors | |||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Doo (reporter) 2018-02-01 23:13 |
Link to the replay: http://replays.springrts.com/replay/597d735ac3f4a76c63cd0ed484b850f3/ |
|
hokomoko (developer) 2018-02-01 23:25 |
there's no real solution for this, we're already using y+some number and this number cannot be different for different units. re: workaround, IIRC, in ZK a unit makes itself visible to airlos for a short while when it fires, so you can't be too stealthy. |
|
Kloot (developer) 2018-02-02 00:32 |
it could be semi-solved by splatting unit model heights onto the map per footprint square and adding those instead of LOS_BONUS_HEIGHT, but the cost/benefit ratio doesn't seem favorable. |
|
hokomoko (developer) 2018-02-02 00:38 |
the issue is not only performance, but the inability to convey this information to the player. How does the player know that a map square has enough los to show a peewee but not enough to show a flea? (or any other two units) |
|
Google_Frog (reporter) 2018-02-02 01:08 |
Technically, units have no fancy checks for whether they are visible. The underlying terrain is visible/invisible and that state determines whether the unit is visible. I have thought on this a bit when dealing with the issue you state here and I have decided that I do not want any major changes to this system. I don't want changes because the current system has good simplicity. If whether a unit were visible depended on the properties of the unit we wouldn't be able to draw LOS in a useful way. A change I would support is configurability for the constant in "y+some number" because Spring should support games of different scales and requirements. The ZK workaround is that units in ALOS are forced to be visible for a second or two whenever they fire. |
|
Google_Frog (reporter) 2018-02-02 01:12 |
In my experience the visibility problems are most apparent for turrets. What if Spring had a callin to modify the +constant of each LOS map square? This would allow game devs to make the visibility of the square higher when the turret is built and lower it back to the default when it is destroyed. |
|
hokomoko (developer) 2018-02-02 11:00 Last edited: 2018-02-02 11:01 |
Read 3 comments above you And also my comment for that effect. |
|
raaar (reporter) 2019-07-22 21:37 |
This is a nice idea. It could use the unit model's height itself instead of the los emit height. ground units not seeing tall towers near edge of sharp cliffs that should be within LOS is a major issue. having a patch of ground drawn as "within los" but where a peewee is visible but a flea is not would be a minor issue. Another way to fix this would be to just make LOS_BONUS_HEIGHT configurable as a mod rule. (which I suggested on https://springrts.com/mantis/view.php?id=6260) That one would be visually consistent for all units and have "no" performance penalty. |
|
hokomoko (developer) 2019-07-23 11:16 |
> That one would be visually consistent for all units and have "no" performance penalty. Incorrect, I believe it will have a small (although probably insignificant) performance penalty. |
|
raaar (reporter) 2019-07-23 13:45 |
maybe there's a way to use a gadget to make units visible by sampling 8 points around them (distance = unit height) to check if the corresponding ground is within los, and make the unit visible in that case. That would make tall units visible near cliff edges that are within los, but not short ones. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-02-01 23:11 | Doo | New Issue | |
| 2018-02-01 23:11 | Doo | File Added: LOS issues and possible fix.png | |
| 2018-02-01 23:11 | Doo | File Added: screen02056.jpg | |
| 2018-02-01 23:11 | Doo | File Added: screen02057.jpg | |
| 2018-02-01 23:11 | Doo | File Added: screen02058.jpg | |
| 2018-02-01 23:11 | Doo | File Added: screen02059.jpg | |
| 2018-02-01 23:12 | Doo | File Added: screen02060.jpg | |
| 2018-02-01 23:13 | Doo | Note Added: 0018766 | |
| 2018-02-01 23:25 | hokomoko | Note Added: 0018767 | |
| 2018-02-02 00:32 | Kloot | Note Added: 0018768 | |
| 2018-02-02 00:38 | hokomoko | Note Added: 0018769 | |
| 2018-02-02 01:08 | Google_Frog | Note Added: 0018770 | |
| 2018-02-02 01:12 | Google_Frog | Note Added: 0018771 | |
| 2018-02-02 11:00 | hokomoko | Note Added: 0018775 | |
| 2018-02-02 11:01 | hokomoko | Note Edited: 0018775 | View Revisions |
| 2019-07-22 21:37 | raaar | Note Added: 0020051 | |
| 2019-07-23 11:16 | hokomoko | Note Added: 0020054 | |
| 2019-07-23 13:45 | raaar | Note Added: 0020055 | |
| Issue History |