Unit ID fix

[CarRepairer]

Unit ID lists can be used by widgets to get info on prevlos units, such as very bad soldier's widget. I have a suggestion to alleviate this problem.

Implement a system where local unsynced has its own set of unit IDs that map to the real set of unit IDs.

Functions run inside widgets would convert the local unit ID to the real ID behind the scenes.

In the case of sending unit IDs from unsynced to synced, a synced function can be provided to the gadget maker that takes the player ID and unit ID and gets the real unit ID. Some current gadgets would need updating, and a modrules flag could be useful in preventing existing mods from breaking until its gadgets are converted.

Just a thought, please let me know if there are any flaws in this logic. My desire is for Spring to be one step closer to bug-free.

Edit: I almost forgot to mention the most important part! Units entering radar range are assigned a random number and added to the local list, so that widget code can't keep tabs on an enemy unit that leaves and re-enters radar range.

[SpliFF]

The problem isn't with how unitIDs are stored, it's with the functions that don't check LOS before returning values on enemy/neutral units.

[CarRepairer]

The problem isn't with how unitIDs are stored, it's with the functions that don't check LOS before returning values on enemy/neutral units.

A widget can and should perform functions with an ID of an enemy unit even if it just appears as a radar blip. The problem is that knowing the unitID can be exploited, which is a known bug.

[Beherith]

How would a unit keep tracking another unit it was told to attack but lost radar/los for?

[SpliFF]

The problem isn't with how unitIDs are stored, it's with the functions that don't check LOS before returning values on enemy/neutral units.

A widget can and should perform functions with an ID of an enemy unit even if it just appears as a radar blip. The problem is that knowing the unitID can be exploited, which is a known bug.

I say it again, you are focusing on the wrong solution.

Who cares if I know a unitID of something I saw once? What matters is that if I query that id from a widget I should only get information I should be allowed to know. If its in radar then I should be able to get its position. If it's outside radar i shouldn't know anything, including whether it's still alive.

Your proposal does nothing to solve this, in fact I don't even need any ID's for exploits. I can just count from 1 to 10000 and query the engine about every id, store what I learn and exploit that.

I'm not saying there isn't a problem, what I'm saying is your solution is needlessly complicated AND doesn't solve the actual problem. The proper solution, as I just said, is that widget-side functions do not expose any knowledge about units beyond what's already known and allowable for the unitIDs current exposure. This includes any tracking code that persists beyond radar range.

If you want action on this issue perhaps specify exactly which functions are involved in the exploit and what they reveal so they can be looked at.

EDIT: Having re-read your post the issue I haven't addressed is that you can tell if a unit is the same unit you saw before (rather than another unit that looks like it). I'm not sure this is really exploitable, what issues exist with this? Also is this really a 'cheat', most humans could distinguish if a unit is the same as earlier just by proximity clues. Sophisticated sensors could probably determine if a tank was the same as an earlier one as well based on markings or damage to the unit.

[CarRepairer]

EDIT: Having re-read your post the issue I haven't addressed is that you can tell if a unit is the same unit you saw before (rather than another unit that looks like it). I'm not sure this is really exploitable, what issues exist with this?

Ah the joy of re-reading.

such as very bad soldier's widget

I was purposely vague here, ask around.

[SpliFF]

just spit it out, if I can find the widget then anyone can. i don't believe in security through obscurity, it doesn't work in open-source software.

Unit ID lists can be used by widgets to get info on prevlos units

Isn't this what we're talking about? If so it still comes down to fixing the functions. I can probably do that if you tell me which functions you're talking about.

[CarRepairer]

just spit it out, if I can find the widget then anyone can. i don't believe in security through obscurity, it doesn't work in open-source software.

Well I couldn't quite remember what it was called. Something along the lines of "ghostradar" I think.

Unit ID lists can be used by widgets to get info on prevlos units

Isn't this what we're talking about? If so it still comes down to fixing the functions. I can probably do that if you tell me which functions you're talking about.

I didn't state that well. A unit is in your sight, you record what type of unit it is, then it steps out of sight and radar range and then back in to just radar. You should only see a blip. But your EnteredRadar callin gives you the unit ID that you already have stored so you know what type of unit it is.

[SirMaverick]

Car, why a new thread? There have been some about this topic.

How would a unit keep tracking another unit it was told to attack but lost radar/los for?

Good point. Either the attack command changes the id (so you know the connection) or it keeps the old one and still attacks the new unit (you can't read the id in that case, or?, only see it via drawn unit commands).

just spit it out, if I can find the widget then anyone can. i don't believe in security through obscurity, it doesn't work in open-source software.

http://springrts.com/phpbb/viewtopic.php?f=23&t=15686

Unit ID lists can be used by widgets to get info on prevlos units

Isn't this what we're talking about? If so it still comes down to fixing the functions. I can probably do that if you tell me which functions you're talking about.

Car wants a second class of unit ids. This isn't done just by fixing some functions.
What do you do when the radar dot becomes visible -> new callins to tell the id change? Or use EnteredLos for the real ID and exitRadar for the fake one? etc.

[SpliFF]

Alright I understand the issue now. Supcom does this using a "blip" class for radar objects. This is also important for correctly implementing false or incomplete radar returns like seismic ping and spoofing.

A blip should have the following exposed (widgets and ai) properties:

position (can be inaccurate for seismic returns)
speed (how fast blip is moving)
vector (direction of travel)
size (based on seismic property or footprint)
unitID (if known, or nil)
detectedWith ('los', 'radar', 'sonar','seismic')
detectedBy (unitId)
detectedOn (frame num)

And the following hidden (gadgets only) properties:

realUnitID (Can be nil for spoofed blips)

Blips are lost when they leave radar. A new blip is always created when a unit reappears.

[Licho]

Blips sound like elegant solutions.

[Google_Frog]

How would a unit keep tracking another unit it was told to attack but lost radar/los for?

Good point. Either the attack command changes the id (so you know the connection) or it keeps the old one and still attacks the new unit (you can't read the id in that case, or?, only see it via drawn unit commands).

If an enemy unit leaves radar with commands queued on it the commands should not reappear on the unit when it enters radar. This is exactly the same kind of exploit as Ghost Radar only this one requires no widgets, just shift.

Local unsynced unit IDs might not be enough to fix this.

Your proposal does nothing to solve this, in fact I don't even need any ID's for exploits. I can just count from 1 to 10000 and query the engine about every id, store what I learn and exploit that.

I think the point of Car's suggestion is that widgets would not have access to engine side IDs. Well at least that's how I interpret it as otherwise it doesn't make sense, as you pointed out.

I think knowing if a unit is the same as a unit seen earlier even when it has left radar and los should be considered a cheat(bug). For example in FFA you would know whether someone has 2 krogs or they just repaired the krog that they sent at you earlier.

I like Car's idea. It also deals with knowing that a radar dot is the same radar dot as long as it has not left radar. Spiff's blimps do not seem to remember that a blimp is the same blimp as long as it hasn't left radar. Maybe a solution can be found with Spiffs blimps using Car's Unit ID fix for UnitID.

[SpliFF]

Spiff's blimps do not seem to remember that a blimp is the same blimp as long as it hasn't left radar. Maybe a solution can be found with Spiffs blimps using Car's Unit ID fix for UnitID.

Read it again, it remembers as long as you can still see the blip on radar, if it goes out of radar the blip is lost and a new blip created when it comes back (so blipId will change). Also it's 'blip', not 'blimp'.

I should point out that my solution (if i can call it mine, since i got it from Supcom) may be elegant but it won't be easy. Widgets may need updating too. Should be added as a GSOC proposal I think.

EDIT: Come to think of it it's pretty much this: http://springrts.com/phpbb/viewtopic.php?f=61&t=22027

[Google_Frog]

Then the solutions are the same. This bit confused me:

unitID (if known, or nil)

As It should not use engine unitID and blipID should always be known.

[SpliFF]

It's simple. You ALWAYS know the blipID but that doesn't mean the blip has a unitID (either you don't know it (radar only) or there isn't really a unit at all (false blip caused by interference/spoofing).

You're mixing the two concepts, a blip is NOT a unit, it's a radar dot, nothing more. That's why I don't like the original proposal, a fake/temporary unitID is too easily confused with a real unit leading to confusing code and documentation. The concept of a blip creates a clear distinction. Other than that yes, the concepts are basically the same.

There's a good reason why you'd want the engine id, because some gadgets have synced and unsynced parts and you want to pass the real unitID, not look it up each time.

[Beherith]

So, further issues: lets say you know the blip ID. How does your AA weapon know that it belongs to an aircraft, and fires at it? (as it currently does)

[SpliFF]

The targetting code would still be engine-side so that isn't an issue for existing stuff. The only thing is you'd know it was an aircraft when your stuff starts blasting. That shouldn't matter because a widget can identify aircraft blips from the blips elevation, meaning it shouldn't be a secret if a blip is airborne.

[Acidd_UK]

A simple blip->isAirbourne() would suffice, as I assume that could easily be provided by the engine...

I'm right in saying that this isn't a huge change to the main engine, just to the interfaces provided to user-side widgets, right (obviously it needs supporting code adding to the engine to track who can see which blips)? But it won't affect e.g. the automatic weapon targeting as that's part of the engine, not (primarily?) controlled by widgets...

[Beherith]

A simple blip->isAirbourne() would suffice, as I assume that could easily be provided by the engine...

Imo thats a very hackish solution thats doesnt adress the real issue. Air targets were just an example.
What about torps vs hovers, hovers vs subs, subs vs air etc...

The only real issue with ghostradar is not the fact that it remembers which kind of unit it was when the unit goes out of los. The real issue is that it remembers the unit type even after loss of radar on the unit. For example if a team runs an air scout over the enemy team at game start, then they will see all the enemy comms on the radar blips till the end of the game

[KDR_11k]

How would a unit keep tracking another unit it was told to attack but lost radar/los for?

Units are synced.