Currently there is no way to trace a screen ray that completely ignores units, i.e. only intersects with the ground, which would be very useful for many widgets (some of which are bugged without it i.e. the very popular custom formations)

As it stands, TraceScreenRay will always intersect with units and either return the unitID or the point of collision, both of which are useless when you are looking for intersection with the ground (if the unit hit is in the air then the collision point returned is also way up in the air...)

Requested Feature:
Optional boolean argument added to Spring.TraceScreenRay that determines whether units/features will be considered (by changing the usual ray trace used to one which only checks the ground)

http://springrts.com/wiki/Lua_UnsyncedRead#Screen_Trace

The optional argument "onlyCoords" already exist. I guess what you want to say is that when "onlyCoords" is set, then it returns the coordinates of the point of collision with any passing unit, instead of ignoring units.

It would say it is not a feature request, but a bug report.

We don't want an extra boolean. We want the already existing boolean to behave in a sensible way.

i found this:
http://github.com/spring/spring/blob/ma ... ead.h#L204

as stated in the comments, these are not implemented. i neither know why, nor why they are in synced instead of unsynced. i would be glad if some of the other engine devs could comment on this.

these 4 lines were added by trepan in June 2007:
http://github.com/spring/spring/commit/ ... 80e#L3R145

i would think, they should be in unsynced. implementing should mainly consist in mapping it to the respective functions in rts/Game/GameHelper.h. i could do that if it makes sense this way.

+1 to making it work consistently; I would really prefer to have it return coordinates by default, return Unit collisions if option = true, but whichever, so long as it works and allows for ignoring Units. The lack of this working in a consistent way has made me have to do some annoying hack-arounds for various things.

The synced ones aren't for screen space/mouse cursor raytracing, they were for weapon's line of fire checking etc. (they shouldn't interpolate the unit positions etc.)

ah..
so would it make sense to have these 3 implemented, and have an other 3 equal ones in unsynced, that use the inexact unit positions and other unsynced stuff, if any?

I would prefer 2 functions with one (or more) argument(s) for the collision types.

i see.. cram these 4 into a single one, and duplicate on the unsynced part, yeah?