Unit ID fix

[CarRepairer]

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:

Your way sounds interesting but would require nearly every widget to be fixed. My proposal requires that virtually no widget and a small select few gadgets be changed.


So I'll restate my outline now that there's been some discussion:

Each allyteam has a local set of unit IDs. Every unit that enters radar range of an allyteam is for all intents and purposes a new unit given an incremented unique ID.

Nearly all widgets can remain unchanged. Widget callins and get-functions provide these local unit IDs instead of the real ones. Set-functions inside widgets take the local IDs as parameters and the engine will convert it to the real unit ID.

Gadgets that receive luarules messages from widgets where they expect a unitID will need to use a conversion function: GetRealUnitID(playerID, localUnitID) -> unitID. This is a quick and easy fix.

Have a modrule flag useLocalUnitIDs = true to apply the new rule so that existing gadgets won't break and give the modder time to convert them.

Some rare widgets might involve sending a unit ID from one player to another when they are on different ally teams. I don't know how to solve this case but I also don't know of any such widgets.

If a widget sends a unit ID and the receiving player is a spec, the widget should have access to the above gadget conversion function when used by a spec. These widgets would need quick modification. The only example I can think of is my widget SelectionSend.

[Licho]

Just imagine the confusion of real and fakeIDs and the manual conversions..
Its so clumsy and hacky.
Blips are nice and natural solution of this problem.

[Google_Frog]

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.

If at any stage you know a real unitID widgets can tell you whether a unit is the same as a unit you saw earlier or not.

Car's solution fixes everything if applied to synced but would require some targeting rewrite to support the current targeting and aiming cheats. Such as this:

If an enemy unit leaves radar with commands queued on it the commands 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.

I don't see much point in fixing ghost radar if exactly the same thing can be done with no widgets at all.

The new blimp system (maybe sensor system) would have to include tags for how much information a blip provides to both players and targetting AI. For example if a unit is air or ground or which team the unit is on.

[Licho]

You can have commands that target blip ID instead of unit ID.
You will only get unitID from blip if the unit is actually visible..

[Google_Frog]

You can have commands that target blip ID instead of unit ID.
You will only get unitID from blip if the unit is actually visible..

If at any stage you know a real unitID widgets can tell you whether a unit is the same as a unit you saw earlier or not.

[Licho]

Why is knowing whether its same unit a problem? If you know ID from blip - you know everything about that unit already.
Otherwise ID is not published.

[Google_Frog]

Why is knowing whether its same unit a problem? If you know ID from blip - you know everything about that unit already.
Otherwise ID is not published.

You don't know if the unit is the same unit that you saw earlier but left radar.

[SpliFF]

I agree that CarRepairers solution is easier to write and more compatible, but I prefer the advantages a new sensor system would provide. It matters quite a lot to me as my mod will be heavily into using advanced intel (spoofing and fake radar returns in particular).

Now it's clear you can tell if a unit is the same as before once you can see it. I just don't think it matters. I think the question is, assuming we had blips, "does knowing a visible unit is the same as before matter enough to justify the complexity of dealing with fake unitID's". I would say no. I can't even think of a useful cheat (a Krogoth counter?... hmmm). There might be some issues with missions but I haven't played any so I can't even speculate there.

Also, as I said before, at least for sci-fi mods it isn't that inconceivable that you could scan a visible unit to a high enough accuracy to provide a positive match to a previously seen one. So for most Spring mods it's hard to accept that exploiting this information is even a cheat. Even for Spring:1944 it's arguable that binoculars would be sufficient to make out an enemies platoon identification markings.

The ghostradar exploit is only possible due to radar returns leaking the unitID. I believe that fixing this directly is a better long-term goal and a better GSOC proposal if we were to go down that road.

Last thing. As far as compatibility goes I think it can be acheived just by rewriting the relevant selection/targetting code to handle blipIDs as well as unitIDs. At some point either solution will require rewritting for fixed sensors since the basic issue remains that the engine currently leaks unit details too early and any widget that takes that for granted is going to break either way.

[Argh]

I can't even think of a useful cheat

There are plenty of "track the Commander" widgets that allow you to keep tracking it after it leaves LOS and enters radar. One of the biggest reasons I think that blips shouldn't be able to be read by Lua widgets in any way. Gadgets, sure, ofc.

With the new sensor system as proposed, it should be possible to introduce blips as generic "sensed objects" that aren't in LOS, and then handle them accordingly, imo.

[SpliFF]

How is remembering something that moves from LOS to radar a "cheat"? It seems like a perfectly simple and logical thing for any radar operations. There's no reason why an object should become anonymous just because nobody has direct LOS anymore.

If you've seen it, you know what it is, and you'll keep knowing until its lost from radar. Armies have been able to do this since radar was invented so why would a future star-travelling race have difficulty?

[SeanHeron]

Plus it's something you as a player can do if you pay attention (okay, pretty cumbersome in this case I admit, but possible).
And I thought the usual stance has been: if a player can do it, then its okay for widgets to do it as well.

So concur with SpliFF on that point.

[JohannesH]

How is remembering something that moves from LOS to radar a "cheat"?

Of course its not cheat when everyone can do it and you cant enforce against it. Whether it is desirable functionality is totally up to the maker of any game.

Anyway a nice thing to have would be to be able to define what things you want user widgets allow to do. Besides just whether they can give orders to units or not.

[trepan]

LOS_CONTRADAR - look into it...

FWIW, unitID proxying should be done, regardless of
whatever sensor enhancements a "blipID" feature brings.
Look back into the #lua lobby logs from a few years ago,
it's not a new topic

[SirMaverick]

If you've seen it, you know what it is, and you'll keep knowing until its lost from radar. Armies have been able to do this since radar was invented so why would a future star-travelling race have difficulty?

Agreed.

LOS_CONTRADAR - look into it...

FWIW, unitID proxying should be done, regardless of
whatever sensor enhancements a "blipID" feature brings.
Look back into the #lua lobby logs from a few years ago,
it's not a new topic

LOS_CONTRADAR doesn't help as long as you know the unit id. And even if you have unit proxing i don't think we want to loose info when unit moves from los to radar.

Other point:
Why do people want anonymous radar dots but no one cares about the public team id? Whatever the implementation will be, I'd like the team id to be unknown as all other informations until you have los.

[trepan]

I'm not suggesting LOS_CONTRADAR is a fix to unitID proxying.
I'm saying that it's already built into the game, and as such is
not a "cheat" in any way. Proxied IDs would only be changed
after a unit leaves radar.

IIRC, I setup something where you could mask LOS_CONTRADAR

[SirMaverick]

I'm not suggesting LOS_CONTRADAR is a fix to unitID proxying.
I'm saying that it's already built into the game, and as such is
not a "cheat" in any way. Proxied IDs would only be changed
after a unit leaves radar.

Okay, misunderstood you there.

[CarRepairer]

Other point:
Why do people want anonymous radar dots but no one cares about the public team id? Whatever the implementation will be, I'd like the team id to be unknown as all other informations until you have los.

Good point too.

[Google_Frog]

I agree that CarRepairers solution is easier to write and more compatible, but I prefer the advantages a new sensor system would provide. It matters quite a lot to me as my mod will be heavily into using advanced intel (spoofing and fake radar returns in particular).

I don't see why a new sensor system and unitIDs per ally team cannot both be implemented. If the sensor system is completely redone see why you would want to leave in a difference between which information a player can access with and without widgets. There may not be any games which use the functionality but there's no point having an engine limitation.

If a game heavily used decoys the decoys would be rendered useless if the unitID is the same when they leave or enter radar. Once a unit reveals which unit type it is (for example in CA if a comm dguns) the unitID can be held and the unit's type will be known as soon as it is seen next time. If the unitID is not given to widgets there is no way to know what a decoy is once it leaves and enters radar.

Any Ghost Radar fix will have to use fake unit IDs. A widget will have to return some kind of ID when querying unknown radar blips so that the blip can be distinguished from other blips.

You're also missing the point that the same information that Ghost Radar provides can be gained with no widget use whatsoever. When you see an important enemy unit tell a turret to attack that enemy unit. Now any time the enemy unit appears on radar you will know what it is, even as an unknown unit. I think the whole business of fixing Ghost Radar is pointless unless the command IDs are fixed too. (and don't say blocking those commands from being drawn is a fix, with a mobile unit it could be momentarily un-waited to see which direction it travels in.)

Car's fix with fake unitIDs for allyteams seems to fix all these problems at once. If it was applied to command code it would fix the blip command cheat and I think it's cleaner than individually checking and blocking widgets from receiving IDs.

Other point:
Why do people want anonymous radar dots but no one cares about the public team id? Whatever the implementation will be, I'd like the team id to be unknown as all other informations until you have los.

This would also be good as an option.

[Argh]

If you've seen it, you know what it is, and you'll keep knowing until its lost from radar. Armies have been able to do this since radar was invented so why would a future star-travelling race have difficulty?

IRL, this is not the case. You now have a radar blip instead of a visual sighting- not the same thing at all. What you saw (a stealth fighter) becomes a blip as it passes over a hill... it may be a reflection from a bird or another object, a transient effect, a reflection from the fighter that's bouncing back to the receiver from another source, etc.- iow, the data's not the object, it's merely data. Which is why radar systems IRL aren't perfectly accurate, and especially the type that Spring emulates, which IRL are mainly for long-distance fixes and early warning, not precise targeting data.

In games, it makes a lot more explicit sense to treat it this way- if it's definite target position, but you do not know the actual type of unit, then it should be a non-random blip that doesn't screw up targeting (one of the hard-coded things about Spring's current sensor system I hate, btw, is how we have no control over this) or if you know the ID, then you should see a ghosted version of the Unit, imo.

In OTA, for example, blips were real locations, no inaccuracy- which is why the Targeting Facility was worth buying sometimes. If you blind-fired artillery at blips, you were going to hit things a lot more often than in Spring.

But that's a per-game-design choice, basically. We may want it to be definite, as in the above example; we may want it to have a wide error-radius, and any shots directed towards that blip may be considerably inaccurate, we may want to forbid shooting at it at all, other than users giving an explicit Attack command, etc.

Basically, I would like to see a system where there is more than one way to interpret that state; I do not think it's appropriate for Widgets to ever have more information than Gadgets are willing to provide them in re: the gamestate value of the sensor state; and I'd like to see a system without the hardcoded behaviors of the current one, where Gadgets make the determination as to what happens to a Unit when it leaves LOS but is within a given Sensor's radius.

[Pxtl]

Well, in the extreme case you could hack the radar-wobble system to occaisionally make nearby radar dots swap their underlying unit. They just migrate from following unit X to unit Y. Then radar dots would get lost in the crowd, even to widgets.