2021-01-18 05:35 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005880Spring engineGeneralpublic2021-01-01 20:25
Assigned To 
Product Version104.0 +git 
Target VersionFixed in Version 
Summary0005880: LOS issues on slopes/cliffs
DescriptionJust 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.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files




Doo (reporter)

Link to the replay:


hokomoko (developer)

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)

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)

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)

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)

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)

Last edited: 2018-02-02 11:01

View 2 revisions

Read 3 comments above you
And also my comment for that effect.


raaar (reporter)

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)

> 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)

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.


abma (administrator)

105.0 released: the maintenance branch is discontinued/obsolete.

-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
2021-01-01 20:25 abma Note Added: 0020569
2021-01-01 20:25 abma Status new => closed
+Issue History