![[de]](/mwf/flags/de.png "Germany")
I'd like to suggest a change in the saving of proplists and arrays, that they are always saved in-place (just like strings/ints/etc.) for the first time they occur. The enumeration number would still be saved, so if the same proplist or array occurs later during the save, it wouldn't be saved twice. Any references would be resolved during denumeration just like before.If I understand the code correctly, this would actually be a relatively trivial change. But it would be very helpful in making saved objects more readable. I often change small stuff directly in Game.txt without starting the engine, but whenever it's in a proplist or an array I have to search it in that huge, unsorted list of values.
It would also allow to use proplists and arrays in PlrExtraData and CrewExtraData.
>It would also allow to use proplists and arrays in PlrExtraData and CrewExtraData.
Hear, hear!
Yes, it would be relatively trivial - except for the code to load old game.txts. You'd have to retain the global list loading just for that. And the savegame code is already more complicated than I like. But well, if you feel strongly about this, I'd be willing to review a patch.The problem with arrays and proplists in *extradata are the static versions of them, like definitions. Supporting storing scenario-specific definitions would require major work. Not supporting them means that the script author doesn't always get immediate feedback that something can't be stored - for example, when they put a definition in an array after storing that array in the player file. Even just the fact that modifying an array/proplist after storing it means that the later version will get restored is surprising enough. Using Format("%v") + eval is an easier option.
>except for the code to load old game.txts
Do we really have that many game.txts at the moment? If "retaining" the code would be the minimal effort there (compared to maintaining it), we could as well have the next release WITH it so that developers can easily convert maps and then throw it out for the release after that?
Throwing out compat code for old savegames a few releases later is the standard procedure. My argument stands, though - bugs in the new code will have to be fixed while the compat code is still there. And modifying the whole thing twice is bad, too.
Well true, But I'd say we have max. 10 scenarios out there that utilize a Game.txt. So if we (/you) want to change that, we should do it sooner rather than later.Even if that means that I'll have to write a conversion script for the Game.txt. Should not be too much effort, I guess.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
