Home » MODDING HQ 1.13 » v1.13 Coding Talk » I'm putting an end to save-file compatibility breaks, if noone minds...
I'm putting an end to save-file compatibility breaks, if noone minds...[message #318648]
|
Sat, 04 May 2013 12:43
|
|
feynman |
|
Messages:38
Registered:October 2010 |
|
|
Hi,
to be honest, I'm pretty pissed off. I've tried to add the "AI index" used to "bind" an NPC to a certain AI behavior to the editor. It turned out that I'd have to modify SOLDIERCREATE_STRUCT (and probably _OLD_SOLDIERCREATE_STRUCT, _OLD_SOLDIERCREATE_STRUCT_101, what's with these variants, anyways?!), and I'm afraid that this breaks even more than the save file compatibility... more like, all maps?
This simply can't be allowed to continue. If the editor shall see any improvement whatsoever - and I think it deserves a little improvement - it must be comparatively easy to add new data. So I though: how can we introduce new variables without breaking compatibility (both in save games and maps) as long as we have a meaningful default? But the better question is: what stops us? I mean, we already handle file versions...
What stops us is the symmetry of saving and loading routines. When a new variable is introduced, it is added to a "POD" section of a struct, which will be saved and loaded using memcpy. Flugente added a nice workaround, some "Filler bytes", that can be decreased so this works. But the more permanent solution is to write different versions than we read. We simply don't continue to keep the functions symmetrical. So whenever we save, we save the newest version. Whenever we load, we check the version, and if it is < VARIABLE_X_INTRODUCED, then we don't read it from the file, but set a default value.
If anyone has an argument against that, please do tell. Otherwise, I'm going to unify this SOLDIERCREATE_FOO mess and change the save/load routines. NB: This will require that future variable additions are also added to the save/load routines manually, as opposed to the current automatic consideration through memcpy. But seeing that Flugente does that already with the filler bytes, I see no big deal here.
Report message to a moderator
|
Private 1st Class
|
|
|
|
Re: I'm putting an end to save-file compatibility breaks, if noone minds...[message #318658]
|
Sat, 04 May 2013 15:24
|
|
feynman |
|
Messages:38
Registered:October 2010 |
|
|
After some more digging through the code, it seems that the problem is specific to the SOLDIERCREATE_STRUCT and variants (with the 'variants' being part of the problem, the other two being that the data seems to go to both map and savegame file, didn't account for that, and finally the SOLDIERCREATE_STRUCT's creation invokes undefined behavior in C++, so it's kinda hard to figure out what's going on).
Together with the not-so-tidy save and load routines and the plain wrong comment "Keeps track of the saved game version. Increment the saved game version whenever you will invalidate the saved game file" I was thrown off.
Anyways, the "save the latest version and load whatever you get" approach seems to be implemented only for save games (not maps, which are saved in the version they were loaded?). And if data is added manually to the saving/loading routines, Flugente's filler doesn't seem to be required after all.
Also, implementing the loading twice - once for buffers and once for files - instead of reading the file to a buffer and use the same routine both times, seems to be more work and error-prone than really required.
So while my initial presumption was wrong, the saving/loading definitely could use some major cleanup.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
Goto Forum:
Current Time: Fri Mar 29 07:58:02 GMT+2 2024
Total time taken to generate the page: 0.01230 seconds
|