Spring RTS Engine

I think maybe people are writing this off as an impossible idea without really giving it any consideration. Just because something is open-source doesn't mean it has to automatically have no reasonably-effective method of code verification. Firefox is regarded as a very safe browser but it's open-source, so everyone knows exactly how it will react to malicious code. Linux is open-source but its users spend all their off-hours making fun of how hackable windows is.

The security doesn't have to be flawless, and there's always going to be 1% of the population that will get away with whatever they want to.

you cannot police unsynced code.

"Sync it?" he asked, not even knowing the difference.

Not that practical.

spring has parts of memory that should be the same across all of the computers
this memory is hashed and compared against everyone else.
synced code is executed the same on all players' computers in a game.

if code isn't synced, it can be modified without breaking sync.
widgets are not synced.

if they were synced, it would require everyone's computer to run the widget.


it would be possible to implement the widgets you want in your mod as gadgets and totally disable the widget handler... but someone compiling spring with the widget handler hardcoded enabled still wouldn't break sync.

Caydr wrote:I think maybe people are writing this off as an impossible idea without really giving it any consideration. Just because something is open-source doesn't mean it has to automatically have no reasonably-effective method of code verification. Firefox is regarded as a very safe browser but it's open-source, so everyone knows exactly how it will react to malicious code. Linux is open-source but its users spend all their off-hours making fun of how hackable windows is.

It is because of one huge difference. Which side the user is on:
- FireFox-user are not trying to hack their firefox and to get infected. If they did they would. But they are wanting to stay safe.
- Video game players want to win. They want to hack their Spring if it means an advantage.

Caydr wrote:I see something like this as an eventuality... Developers can either choose to wait until that happens

Pendrokar wrote:Maybe in 2020...

There was no smiley in my post. I guess I have to port it to BA or else it doesn't exist.

caydr we are not dismissing it, we had large discussions about it prior to argh's widget blocker. The results were that if people want to write a cheat they can. It is just that you came in after all that was discussed and no one wants to talk about it again.

Still, this gadget would work for anyone with an official version of Spring...

but the gadget itself could be modified to do nothing without breaking sync.

smoth wrote:It is just that you came in after all that was discussed and no one wants to talk about it again.

this. applies to several other topics as well.

zwzsg wrote:

Pendrokar wrote:Maybe in 2020...

There was no smiley in my post. I guess I have to port it to BA or else it doesn't exist.

yeah because years might pass quickly.

it would be possible to implement the widgets you want in your mod as gadgets and totally disable the widget handler... but someone compiling spring with the widget handler hardcoded enabled still wouldn't break sync.

Actually, that's some of the problem. Certain things can still only be done in Widget unsynced code, whereas certain other things can only be done in Gadget unsynced code, IIRC. I'd have to dig to get an example, these were issues with callin / callout behaviors, and probably are ultimately tied into the Handlers.

That makes it currently impossible to go the all-Gadget route. Even if that wasn't something that could be fairly easily worked around. Adding a sync check to make sure that everybody is in Widget-less mode would be pointless, though, as ultimately that's something that can be hacked around fairly easily. The fact is that my Widget blocker is effective for all ordinary end-users, but is not "real security", and the game engine will never have "real security" due to the way that sync checks work.

The only way to even approach "real security" would require constant snooping, ala Steam, moderated through the Lobbies, and then it would remain fairly uneffective- hackers could see what was changed today and react... unless said changes occurred within a closed-source DLL, perhaps.

I don't know if I would agree with that statement argh, I am pretty sure gadgets can do all the widget stuff.

No. For once Argh isn't totally wrong.

The synced part of the gadget doesn't have access to the unsynced data (like MyTeam, CameraPosition, etc...). But this is normal.

The unsynced part of the gadget would in theory have all the capabilties of a widget. However, in reality, it misses a couple callins, namely all the UnitDestroyed, UnitCreated, UnitDamaged, etc... This is probably a bug or an overlook. You can workaround it by having the synced part of the gadget use those callins, and then send them back to unsynced via some SendToUnsynced and gadgetHandler:AddSyncAction. But this is unpleasant.

The unsynced part of the gadget would in theory have all the capabilties of a widget. However, in reality, it misses a couple callins, namely all the UnitDestroyed, UnitCreated, UnitDamaged, etc... This is probably a bug or an overlook. You can workaround it by having the synced part of the gadget use those callins, and then send them back to unsynced via some SendToUnsynced and gadgetHandler:AddSyncAction. But this is unpleasant.

Thank you, for putting in the details. It's probably stuff missing from the gadgetHandler, I just haven't had time to look into it in depth, and just worked around it.

so then it sounds like some of this can be fixed by correcting an oversight? Gadget unsynced should be able to do all a widget can.

so then it sounds like some of this can be fixed by correcting an oversight?

Yes, and it may be an oversight that can be fixed simply by moving certain things into gadgetHandler Lua code (i.e., no engine change required), although I don't know that, as I just haven't had time to look at this issue.

If anybody has time to look at this, it'd be great to see this get fixed.

All that widget-signing and other stuff would (maybe) be very, extremely important. In an imaginary world where anyone even bothers to play those mods - or, actually, an imaginary world where those mods get popularity far above BA, which is even more imaginary.

Seriously why won't you guys request signing gadget when you need it, as in, AFTER you get immense popularity and supposed cheating problems that come?

I am just saying we should address the missing functionality on the gadget side of things. It doesn't matter what they want to try and do, it is their business. I may not like argh or caydr, I might think that it is a wasted effort because cheaters will find a way. However, there was a constructive conversation going which was starting to actually make notes of a few actual issues with the lua implimentation.

Good job though, because insulting people's work on a grounds of popularity really makes a strong argument.Attacking anyone's work as a ground to denounce their arguement is low and frankly inappropriate. It is just weak.

This a bar of soap, clean your mouth.

is it clean now?

Now, wash the soap out your mouth and come back with something real or put the bar back in your mouth.

Seriously why won't you guys request signing gadget when you need it, as in, AFTER you get immense popularity and supposed cheating problems that come?

Because that's the worst-possible time to ask developers for a fairly major refactor of this kind of thing, if it's necessary, is why... duh.

Anyhow, I have a solution that works just fine for me at my game's current level of non-popularity online, so I don't really care all that much. I just brought up the issue of non-portability of Widgets to Gadget code because it was one of the routes I looked at, and it was closed because of those issues.