Converting from INI to JSON

[Per]

Feel free to make improvements

[crab_]

I found some wrong things in new research.json

if (filterparam ="ImpactClass")
{
filterparam = "weaponSubClass";
}

Fields in weapons.json as all lower case, but in research.json we see following:
"parameter": "Damage",

...var parameter = v['parameter'].toLowerCase();


per pls fix upper/lower case. "FirePause" != "firePause". This all broken this way.

btw. i like new format of Stats. It is very good compatible with Wz Guide.


[upd]
"results": [
{
"class": "Building",
"filterParameter": "Type",
"filterValue": "Structure",
"parameter": "Armour",
"value": 35
},

We have "Type" field in structure.json, but I do not see anything with type = "structure"

[Per]

Please understand that the results values refer directly to the Stats and Upgrades values set in src/qtscriptfuncs.cpp that can be introspected using "jsdebug". They do not necessarily correspond to values in other JSON files. The Stats Building's Type is currently hard-coded to one of Wall, Structure or Demolish.

The capitalization used for the Stats/Upgrades values are different than the capitalization used for JSON values interpreted by the stats loader.

Whether or not it would be a good idea to make the capitalization the same, I am not sure. On the one hand, it would make it easier to directly use JSON data together with Stats/Upgrades data. On the other hand, it might make people believe that they correspond 1:1 on some way, which they do not.

Also, I'm not sure which capitalization is better...

[crab_]

Ok. I just do not like to write code to change names of parameters and capitalization.

I'd like to remove all ugly logic. I do not understand why "damage" in .json is not correspond 1:1 to "Damage" in Stats/Upgrades.
Can you explan what diff between "damage" in .json and "Damage" in Stats/Upgrades?

Ok. I can accept you logic.

Per, can you say, did you test upgrades in new .json format? Upgrades were broken in master long time (in cause of partially wrong upgarde hint in old .ini format).

Seems I have to do careful testing of work of upgrades in my Wz Guide, before commit porting to json-stats.


btw. Each upgrade now can be have any number of results. Thats Great!
e.g. I can add research which increases both HP and damage.



in rules.js
in eventResearched

Code: Select all

		for (var cname in Upgrades[player][v['class']]) // iterate over all components of this type
		{
			var parameter = v['parameter'];
			var ctype = v['class'];
			var filterparam = v['filterParameter'];

parameter, ctype, filterparam should be initialized before loop of components

[Per]

In the case of "Damage", it is exactly the same value in both .json and Stats/Upgrades. Most things are the same. But there is no guarantee that they are.

It is possible to make them the same. It may be a lot of work. What needs to be done is to verify that nothing is changed when stats are loaded, if something is changed, move that change into the json, and rename changed names/capitalization. Feel free to do it

[crab_]

Ported Wz Guide to .json stats.
https://github.com/crab312/warzone2100- ... 90da3a358a

[Roland]

Is it only me or can git/HEAD not load it's own savegames since the format has been converted?

*** Program received signal SIGSEGV (Segmentation fault) ***
(gdb) backtrace
#0 0x00000000007d1c3c in eventNewContext (psCode=0x0, release=CR_RELEASE, ppsContext=0x7fffffffa350) at event.cpp:346
#1 0x00000000007d4de1 in eventLoadContext (ini=...) at eventsave.cpp:162
#2 0x00000000007d66c0 in eventLoadState (pFilename=0xff3ec0 <saveGameName> "savegames/skirmish/test/scriptstate.es") at eventsave.cpp:359
#3 0x00000000005ec2ca in loadScriptState (pFileName=0xff3ec0 <saveGameName> "savegames/skirmish/test/scriptstate.es") at game.cpp:6246
#4 0x0000000000632d8d in levLoadData (name=0xbeafc0 <aLevelName> "Sk-Rush", hash=0xbef4ab <saveGameData+16235>, pSaveName=0xff3ec0 <saveGameName> "savegames/skirmish/test/scriptstate.es", saveType=GTYPE_SAVE_MIDMISSION) at levels.cpp:1011
#5 0x00000000005d0e41 in gameLoadV (fileHandle=0x7829dc0, version=39) at game.cpp:3646
#6 0x00000000005cebd0 in gameLoad (fileName=0xff3ec0 <saveGameName> "savegames/skirmish/test/scriptstate.es") at game.cpp:2919
#7 0x00000000005c8f49 in loadGameInit (fileName=0xff3ec0 <saveGameName> "savegames/skirmish/test/scriptstate.es") at game.cpp:1494
#8 0x000000000063aea0 in initSaveGameLoad () at main.cpp:831
#9 0x000000000063b02a in runGameLoop () at main.cpp:881
#10 0x000000000063b2fc in mainLoop () at main.cpp:973
#11 0x0000000000887652 in wzMain3 () at main_sdl.cpp:1300
#12 0x000000000063be3e in realmain (argc=2, argv=0x7fffffffda38) at main.cpp:1297
#13 0x00000000008852be in main (argc=2, argv=0x7fffffffda38) at main_sdl.cpp:63

[NoQ]

Noticed something.

In struct.json (in multiplay/maps/*/), structure ID is not saved. It's possible to recover the ID from the dictionary key (eg. structure_0020 has id 20), but the game doesn't seem to be doing that. Same applies to feature.json.

In campaign maps (wrf/cam*/cam*/), there are no struct.json files or feature.json files, just droid.json.

Was any of the above intentional?

[Per]

struct.json doesn't need structure ID, but can specify it with "id" tag. For maps, it doesn't matter. For campaign, it does.

However, campaign has not yet been ported over to json. I don't exactly recall the reason(s) now, but lack of an easy way to test that the changes worked would be one, I guess.

[Per]

Is it only me or can git/HEAD not load it's own savegames since the format has been converted?

It wasn't just you. I just fixed a number of issues with saving / loading. There remains one issue with loading a savegame in campaign, but I'm not sure if that is a script fault or a save game system error. NoQ, think you could have a look?

[NoQ]

Will try!
_______________

Hmm, i guess we need "id=" iff we have the object labeled (itself or part of the group), regardless of whether it's a droid or a structure or a feature... right?

[NoQ]

Whoops, I accidentally pushed both the fix on the C++ side and the fix on the JavaScript side

Works anyway.

And, anyway, we need a better way to fix recursive references... Right now the problem was that the game serialized and loaded the __camGlobalContext variable by value, and then some functions in it were serialized into QVariant as objects, and i could no longer call them through the stored context by field name (the actual global context was fine though).