Spring RTS Engine

So I want some custom variables in my lua unitdefs files, that will have a form of a nested lua tables. Then I will read them in unitdefs_post.lua to check if they are correct etc. Then I want to somewhat make them available in a gadget which will trigger appropriate game logic. How to do it?

The problem is that unitDef.customParams only takes strings and ignores tables. While Spring.SetGameRulesParam() only takes number values so it is even worse.

So the question is:
Is there any part of lua environment which stays untouched between unitdefs_post.lua and gadget initialization? I know Spring loads all defs and then exports them back during that time, but does it overwrite whole lua state or is there some part where i could safely store my data in a variables?
Perhaps any other easy way?

If all of the above is not possible then I will probably have to butcher (serialize) the nested tables into string(s) stored in unitDef.customParams and then later read them in the gadget which will be another source of problems in itself...

Lua objects like tables aren't c++-like structures that can be constructor and handled separately from a Lua State/Context. So when the LuaState gets destructed the table is also. So the engine can't internally `save` Lua objects (except creating its own uber-complexe containers for them).
So it is quite unlikely that there will be a functionality as this in the engine in the near future.

Some options to workaround this:
* serialization of customParams (unserialization doesn't have to happen in the gadget itself, it can also be moved into the gadgetHandler etc.)
* running defs.lua in LuaRules again and using its output instead

Ok, so the whole loading-time LuaState gets destructed, that explains a lot. Thought that maybe a part of it is preserved.

jK wrote:Some options to workaround this:
* serialization of customParams (unserialization doesn't have to happen in the gadget itself, it can also be moved into the gadgetHandler etc.)
* running defs.lua in LuaRules again and using its output instead

I am not sure what to choose. Running same code and parsing same stuff two times seems bad to me, but would be easier and probably more flexible solution.

I could probably use Gadgets\Configs\definemystuffhere.lua instead but I prefer the possibility of having all unit related data in one place. I am even going to move script contants like turret turning speeds to unitdef file.

I will think more about the possibilities. Thanks for help!

Would it be totally insane to write a parser to parse string custom params into tables?

FLOZi wrote:Would it be totally insane to write a parser to parse string custom params into tables?

http://lua-users.org/wiki/TableSerialization

Regret wrote:

FLOZi wrote:Would it be totally insane to write a parser to parse string custom params into tables?

http://lua-users.org/wiki/TableSerialization

Ah, +nowisee.

Regret wrote:http://lua-users.org/wiki/TableSerialization

I have looked there for examples earlier, but eventually I wrote my own simple serializer and deserializer.
It handles just the simple cases, won't work with duplicated / circular / recursive tables but these will not happen in my unitDefs anyway.
The deserialization happens in a file included in gadgets.lua.

I have run into a problem that in Spring-exported UnitDefs original variables can't be modified in any way, but luckily you can add new variales. This means you can't modify UnitDefs.customParams and can't even add variables to it, but you can add new variables to the UnitDef itself, so I made myCustomParams table containing deserialized customParams and then added it to the UnitDefs.

Rafal99 wrote:

Regret wrote:http://lua-users.org/wiki/TableSerialization

I have looked there for examples earlier, but eventually I wrote my own simple serializer and deserializer.
It handles just the simple cases, won't work with duplicated / circular / recursive tables but these will not happen in my unitDefs anyway.
The deserialization happens in a file included in gadgets.lua.

I have run into a problem that in Spring-exported UnitDefs original variables can't be modified in any way, but luckily you can add new variales. This means you can't modify UnitDefs.customParams and can't even add variables to it, but you can add new variables to the UnitDef itself, so I made myCustomParams table containing deserialized customParams and then added it to the UnitDefs.

Could I get a look at your simple serializer/deserializer?

By the sounds of it, I'm doing some of the same stuff you are ("I am even going to move script contants like turret turning speeds to unitdef file."), I guess the end aim is to have just one or two general unit scripts which are controlled via custom params of unitdefs?

I want (eventually) for all S44 tanks to share a script for example, and, perhaps more ambitiously, all mechs in Spiked's new BattleTech mod.