Spring RTS Engine

I'm writing a LuaAI that uses Tobi's framework (from C.R.A.I.G) to run unsynced. A large portion of the "framework" code is dedicated to serialising and forwarding some synced callins to unsynced.

I'm thinking though that most, if not all, of these callins would also make sense as unsynced versions done engine-side and this would alleviate a lot of messy serialisation. The unit callins would require allyTeam and/or LOS filtering.

The forwarded callins are:
NOTE: The C.R.A.I.G code is kinda old, maybe some of these are already available unsynced?

Might even be the case that CRAIG purposefully forwards them to avoid ally / los filtering? (I don't know, can't remember if I even ever did know)

FLOZi wrote:Might even be the case that CRAIG purposefully forwards them to avoid ally / los filtering? (I don't know, can't remember if I even ever did know)

^this. It is easy enough to hack spring, please be careful about how much you open up spring to exploits. None of our games will ever be competive as it is due to the ability to easily alter spring(open source code after all)

FLOZi wrote:Might even be the case that CRAIG purposefully forwards them to avoid ally / los filtering? (I don't know, can't remember if I even ever did know)

No, there is no way to get those events in unsynced without forwarding them.

However, CRAIG purposefully does not do any ally / los filtering, as it has been moved into unsynced Lua code mostly to prevent having to deal with running synced.
(And not to make it behave like a human with scouts and stuff.)

This discussion is not relevant to cheating because we're talking about unsynced gadgets here, not widgets. The first 4 callins have no potential for cheating at all (how does knowing when the game started or a team died give you an advantage)? To open up cheating you'd need a gadget in your game forwarding data to widgets.

My proposal for the unit callins is simply that the data be made available to an unsynced gadget, preferably with an option to filter it by team and or LOS. The primary application for this would be non-cheating Lua AIs (which run synced and can cheat their hearts out anyway if they wanted to).

Tobi's code forwards data for unseen/enemy units via serialisation to string -> sendToUnsynced -> RecvFromSynced -> deserialisation which is expensive enough but then that data alsos need to be team/los filtered in Lua for a non-cheating AI. Given all this overhead a case exists for doing it in C++.

ah, I misunderstood, I thought you were talking about unsynced in general, sorry for the that.

The best way to prevent cheating btw is not by code, but by educating the playerbase that it's unsportsmanlike. There will always be ways to cheat, but that doesn't mean people will do it. Who wants to win that way anyway?

No, there will always be trolls.

SpliFF wrote:Tobi's code forwards data for unseen/enemy units via serialisation to string -> sendToUnsynced -> RecvFromSynced -> deserialisation which is expensive enough but then that data alsos need to be team/los filtered in Lua for a non-cheating AI. Given all this overhead a case exists for doing it in C++.

Wrong, no serialisation / deserialisation happens.

SendToUnsynced isn't more than a call-out in synced which synchronously calls the RecvFromSynced call-in in unsynced, only after checking that all the arguments are simple types (no tables, threads, functions).

So the overhead is a few extra function calls only: Spring, calls synced gadgetHandler, calls synced gadget, calls SendToUnsynced, calls unsynced gadgetHandler, calls unsynced gadget.

https://github.com/tvo/craig/blob/maste ... k.lua#L135
https://github.com/spring/spring/blob/d ... e.cpp#L252
https://github.com/spring/spring/blob/d ... e.cpp#L302

The serialisation you have seen in CRAIG is for the other way round: to send information from unsynced to synced. This needs to be serialised, because to send anything from unsynced to synced it must travel over the network so that all clients get the same message from unsynced at the same time.