idea/rant: gadgets that alter what widget sees

[knorke]

This came to my mind but I have forgotten the login password to my blog so I post here.

Imagine a world where gadgets can alter what the widgets see:

1) event happens
2) gadget sees event (gets callin)
3) gadget alters (or blocks) the event
4) the altered event is passed to widget (if it was not blocked)
5) the widget sees the altered event

Sometimes one does not want widgets to know too much about what is happening.

Potential uses:
widgets like "ghost radar" can atm cheat:
When a unit leaves radar coverage and comes back into radar, the same unitID gets reported. See http://springrts.com/mantis/view.php?id=1002
Now what if there was a callin whatWidgetWillSeeUnitEnteredRadar (unitID, team) that returns the unitID that the widget will see? One could make something like:

Code: Select all

gadget:whatWidgetWillSeeUnitEnteredRadar (unitID, team)
  return unique_random_number
end

to fix the unitID exploit.
Or could always return the same number to completly make radar-widgets unuseable, if that is wanted.


Different use:
Units that transform/morph into different unit types. Generally that is done by destroying the unit then spawning a new unit. (of different type)
This triggers UnitDestroyed and UnitCreated callins and widgets could potentially use this information.
But maybe one does not want widgets to know whenever a Commander has upgraded or a terran Viking has switched to airmode?
So one would return nil which means this event never reaches the widget:

Code: Select all

gadget:whatWidgetWillSeeUnitDestroyed (unitID,...)
  if isCommander (unitID) return nil end
end

gadget:whatWidgetWillSeeUnitCreated (unitID,...)
  if isCommander (unitID) return nil end
end

Anyway that is just idea..or maybe it is already possible somehow?

[jK]

gadgets can already send faked events to widgets (Script.LuaUI), but not alter engine ones.
It would also be very complicated to implement in the current system, no idea either how it may make multithreading Lua more complicated (yes, that's still a goal).

[CarRepairer]

http://springrts.com/phpbb/viewtopic.php?f=21&t=22029

[Jools]

I think the underlying issue would be important to fix, but I don't really understand the mechanics of the proposed solutions.

But making unitID:s part of a local scope (specific to the team that looks at the radar) instead of globally available sounds like a logical solution.

But I think the issues we have are twofold:

1) Radar blips leak unitID, which can be used to retrieve unitDefID in widgets such as ghostradar. Of course, if an unit has been withing LOS and then continues to be withing radar, the player should know the unitID.

2) Once you have an unitID, you can store it for tracking purposes á la Mossad.

So how have other RTS games solved this issue? In OTA, I think an unit that is attacked receives the unitID of the attacker, which is why you could set a bertha to guard a peeper and send it towards the enemy base. I also think that the unitID is persistant in OTA.

[knorke]

gadgets can already send faked events to widgets (Script.LuaUI)

So if a gadget does Script.LuaUI.UnitDestroyed (unitID,...) the widget will really think a unit died, with no way to tell it was faked?

, but not alter engine ones.

But maybe it is possible to disable the callins from widget, for example by modified widgethandler in mod? Then one could simply disable all relevant callins. So instead of the engine calling the callins, now a gadget would do it. (with its own rules)

http://springrts.com/phpbb/viewtopic.php?f=21&t=22029

As I understand the thread is about how engine should give random IDs to radarblobs, or a new "type" of units: radarblip. My idea is to leave this ID randomization to gadgets.
---

I don't really understand the mechanics of the proposed solutions.

Before any event is passed to widget, gadget get the chance to block or alter it.
Something a bit similiar exists in the form of UnitPreDamaged() and UnitDamaged()
First UnitPreDamaged() gets called, afterwards UnitDamaged()
UnitPreDamaged() can return a number to alter the damage and UnitDamaged() will only ever see this altered number.
Now think if there was the same thing for all events, ie UnitPreEnteredRadar etc.

[Silentwings]

I can see the applications but this could make for really impenetrable code when the interaction is split across multiple files!

[Jools]

Revisiting the UnitID exploit: why not just remove the widget:UnitEnteredLos callin from widgetmanager, or blacklist widgets that contain this callin.

At the moment, only widgets to use it are the commander name tags one, the defenserange one, the ghost site/radar and for ba commcounter and adv. unit marker.

Wouldn't be hard to even blacklist this for not included widgets. Problem solved.

I think there are other ways to get the unitID:s, but I think they are more expensive to fps than the widget:UnitEnteredLos one. As a matter of fact, ghost radar/site widgets are already quite expensive in widget profiler.

[CarRepairer]

I think there are other ways to get the unitID:s, but I think they are more expensive to fps than the widget:UnitEnteredLos one. As a matter of fact, ghost radar/site widgets are already quite expensive in widget profiler.

So instead of everyone being able to cheat on even ground, only people with expensive computers can. Pay to win. That's much better.

[Jools]

Well, the aim should be that nobody wants to cheat but win with fair play. I don't see the sporting world making anabolic stereoids legal just it's possible to evade detection with an own stab of knowledgeable doctors, like Lance Armstrong.

[zwzsg]

So how have other RTS games solved this issue

Which other RTS allow users to run their own script?

[Jools]

So how have other RTS games solved this issue

Which other RTS allow users to run their own script?

That's an old quote, I was much more older then, I'm younger than that now.

But yes, that's the problem to begin with.

[Google_Frog]

Revisiting the UnitID exploit: why not just remove the widget:UnitEnteredLos callin from widgetmanager, or blacklist widgets that contain this callin.

This would not really affect anything. You can check whether a unitID is in radar by asking for something such as it's position and checking to see whether you get a result. This can be done every second or so for little cost.

[Jools]

It's also quite easy to detect a faked unitDied callin: you just check if the unitID that died is changing position or not.

But would it be possible to have a gadget that changes unitID when the unit leaves the radar coverage of some allyteam? You could maybe do it with morph gadget, but maybe that's too expensive...

But wouldn't that work?

[Anarchid]

But would it be possible to have a gadget that changes unitID when the unit leaves the radar coverage of some allyteam? You could maybe do it with morph gadget, but maybe that's too expensive...

Not expensive, but fragile, and would require you to rewrite every gadget that ever touches units.

Every other gadget that relies on unitID would have to be told about the unitID change and update its internal information accordingly.

Any gadget that doesn't... would be broken.

The ugliest bit yet is that you'd probably have to do the "morph" thing to substitute unitID's - i don't think you can just change them at will - and that'll cause quite a lot of animation breakage.

Eventually people would start using this to subvert enemy aiming scripts by triggering the los-swap on purpose

[100Gbps]

This came to my mind but I have forgotten the login password to my blog so I post here.

I like your blog, Sarah

[CarRepairer]

Is that a person or a starchy vegetable?

[100Gbps]

idk but she definitely has the whole periodic table on her face. Probably in a duck language it's called cosmetics, but again - I don't know