Forged Alliance Forever

Re: Why is the _save.lua using different conventions for key

2018-02-07T20:02:45+02:00

Turns out the loading process is more robust than I'd expected. It can deal with "incorrect" formats. Pasting

Code:: ['UNIT_229'] = { ['Orientation'] = VECTOR3( 0.0, -8.822649, 0.0 ), ['platoon'] = STRING( '' ), ['orders'] = STRING( '' ), ['type'] = STRING( 'uel0201' ), ['Position'] = VECTOR3( 258.240875, 19.442125, 250.59201 )}

in the save.lua works just fine. Saving the map will then replace that part with the correct format and everything is well. Might not work the other way around (unit format -> marker format).

Statistics: Posted by Lionhardt — 07 Feb 2018, 20:02

Re: Why is the _save.lua using different conventions for key

2018-02-07T18:12:27+02:00

Ah I see, thanks.

Statistics: Posted by Lionhardt — 07 Feb 2018, 18:12

Re: Why is the _save.lua using different conventions for key

2018-02-07T17:59:24+02:00

Lionhardt wrote:
Btw., Ozon, I assume you had to write a function that produces string representations of tables for your editor, right? To dump the tables into a file like they did with the _save.lua.

Do you have a function that does that in your repository? Otherwise I would need to re=invent the wheel here, as I need a function like that for my transformation script.

Not sure what exactly do you have in mind about Tables.

What I do, is that I get lua file, add Header and Footer to it with functions (vector3 etc) and then i put it into Lua Parser. It gives me key/value pairs for everything in as LuaTables.
Then I convert that into C# classes that represent every object and from that is way easier to work with them in Unity.
After many months of search i decided to do everything by hand, so there are no clean conversion Lua > C# > Lua. Here are some classes that help me achieve that:

LuaParser_Read - Converts LuaTable values into C# structs (string, int, float, vector3, rect)
https://github.com/ozonexo3/FAForeverMa ... er_Read.cs

LuaParser_Write - Convert struct values into Lua strings
https://github.com/ozonexo3/FAForeverMa ... r_Write.cs

LuaParser_Create - Help manage structure of Lua file
https://github.com/ozonexo3/FAForeverMa ... Creator.cs

Then using that I can read scenario.lua and save.lua files:
Scenario.lua
Load - https://github.com/ozonexo3/FAForeverMa ... ua.cs#L324
Save - https://github.com/ozonexo3/FAForeverMa ... ua.cs#L460

Save.lua
Load - https://github.com/ozonexo3/FAForeverMa ... ua.cs#L108
Save - https://github.com/ozonexo3/FAForeverMa ... ua.cs#L248

Then I have easy access to all data from other scripts and I can do anything with them.

Statistics: Posted by ozonex — 07 Feb 2018, 17:59

Re: Why is the _save.lua using different conventions for key

2018-02-07T17:35:12+02:00

yea, I just wrote interface functions like this:

Code:: -- compensates for differing interfaces of units and markers -- keyword should be capitalized for this to make sense function access(container, keyword) ret = container[keyword] if ret == nil then ret = container[string.lower(keyword)] end if ret == nil then except("access error: unkown keys: "..keyword..", "..string.lower(keyword)) end return ret end -- compensates for differing interfaces of units and markers -- keyword should be capitalized for this to make sense function insert(container, keyword, value) if container[keyword] == nil then if container[string.lower(keyword)] == nil then except("access error: unkown keys: "..keyword..", "..string.lower(keyword)) else container[string.lower(keyword)] = value end else container[keyword] = value end return container end

gives me the creeps, but best solution I could think of.

Btw., Ozon, I assume you had to write a function that produces string representations of tables for your editor, right? To dump the tables into a file like they did with the _save.lua.

Do you have a function that does that in your repository? Otherwise I would need to re=invent the wheel here, as I need a function like that for my transformation script.

Statistics: Posted by Lionhardt — 07 Feb 2018, 17:35

Re: Why is the _save.lua using different conventions for key

2018-02-07T17:23:30+02:00

speed2 wrote:
There's a good reason why the keys are in the format ['Mass1'] etc. Since it uses the name, that you can change in the editor...

Its ok for marker/units/other names, but why marker keys, like ['position'] are also like that? They are defined and newer had spaces. Maybe because they were not sure what will be needed there.

Anyway, there is nothing to consider here. It's done like that, and changing it in lua files will just crash the game.

Statistics: Posted by ozonex — 07 Feb 2018, 17:23

Re: Why is the _save.lua using different conventions for key

2018-02-07T17:09:48+02:00

There's a good reason why the keys are in the format ['Mass1'] etc. Since it uses the name, that you can change in the editor, and this covers cases where you use spaces and other things.
So this will work

Code:: ['Mass 1'] = {},

but this is a syntax error

Code:: Mass 1 = {},

Those functions like VECTRO3 etc return the table but there's also at least one more key defining it's a verctor etc. Most probably needed for the engine as some engine functions require it. I know some that wanted position, didnt work with simgple table {x,y,z} but I had to use that function call to create it.

Statistics: Posted by speed2 — 07 Feb 2018, 17:09

Re: Why is the _save.lua using different conventions for key

2018-02-07T15:54:42+02:00

It's really annoying at least, because this way it's not possible to write functions that operate on units and markers without trying out both access keywords (capitalised and all lower case), because they have different interfaces.

Statistics: Posted by Lionhardt — 07 Feb 2018, 15:54

Re: Why is the _save.lua using different conventions for key

2018-02-07T15:41:49+02:00

Lionhardt wrote:
Better. Now consider the definition for `VECTOR3`:

Code:
function VECTOR3(x, y, z) return {x, y, z} end

It returns just a table so

Its not official definiton, it's my own definition to just read values it contains. We probably don't know what's official definition for that function, but maybe someone who knows LUA in this game better will confirm that. Maybe official one has some more stuff to control or to get data from them.

I will don't search for sensible reason why its made like that. At least my lua parser always read "position" and ['position'] as just a key "position".

For example reading position of marker:

Code:: public const string KEY_POSITION = "position"; position = LuaParser.Read.Vector3FromTable(Table, KEY_POSITION);

And position of unit:

Code:: public const string KEY_POSITION = "Position"; NewUnit.Position = LuaParser.Read.Vector3FromTable(UnitsTables[i], KEY_POSITION);

Why some are with upper case and other with lower case? Don't know, maybe someone was just lazy to check and to maintain constancy in names. But I'm not LUA master so maybe there is a reason somehow.

Statistics: Posted by ozonex — 07 Feb 2018, 15:41

Why is the _save.lua using different conventions for keys?

2018-02-07T15:07:27+02:00

Position, orientation etc. for markers and units are stored in the _save.lua files. In there you find a deeply nested lua table. An entry for a unit in that table looks like this:

Code:: ['UNIT_228'] = { type = 'urb2101', orders = '', platoon = '', Position = { 23.500000, 37.507813, 249.500000 }, Orientation = { 0.000000, -3.141593, 0.000000 } }

An entry for a marker like this:

Code:: ['Mass 16'] = { ['size'] = FLOAT( 1.000000 ), ['resource'] = BOOLEAN( true ), ['amount'] = FLOAT( 100.000000 ), ['color'] = STRING( 'ff808080' ), ['editorIcon'] = STRING( '/textures/editor/marker_mass.bmp' ), ['type'] = STRING( 'Mass' ), ['prop'] = STRING( '/env/common/props/markers/M_Mass_prop.bp' ), ['orientation'] = VECTOR3( 0, -0, 0 ), ['position'] = VECTOR3( 309.5, 28.2969, 347.5 ) }

Lets strip these down a bit:

Code:: ['UNIT_228'] = { Position = { 23.500000, 37.507813, 249.500000 }, Orientation = { 0.000000, -3.141593, 0.000000 } }

Code:: ['Mass 16'] = { ['orientation'] = VECTOR3( 0, -0, 0 ), ['position'] = VECTOR3( 309.5, 28.2969, 347.5 ) }

Better. Now consider the definition for `VECTOR3`:

Code:: function VECTOR3(x, y, z) return {x, y, z} end

It returns just a table so

Code:: ['position'] = VECTOR3( 309.5, 28.2969, 347.5 )

is in fact the same as

Code:: ['position'] = { 309.5, 28.2969, 347.5 }

which is the same format as in the table for the `UNIT_228`.

Also note that `{['key'] = 1}` is the same as `{key = 1}`. (In the context of the brace syntax undecorated tokens are interpreted as strings.)

Okay so when we combine these our entries for the unit and the marker actually turn out as:

Code:: ['UNIT_228'] = { Position = { 23.500000, 37.507813, 249.500000 }, Orientation = { 0.000000, -3.141593, 0.000000 } }

Code:: ['Mass 16'] = { orientation = { 0, -0, 0 }, position = { 309.5, 28.2969, 347.5 } }

So, why the hell use that unnecessary vector function and why use different syntaxes for defining keys. And primarily: Why use capitalised keys in the one case and all lower case keys in the other??

Is there any rational behind this?

Statistics: Posted by Lionhardt — 07 Feb 2018, 15:07