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 Go to next message
feynman is currently offline 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 #318652] Sat, 04 May 2013 13:34 Go to previous messageGo to next message
DepressivesBrot is currently offline DepressivesBrot

 
Messages:3658
Registered:July 2009
I was under the impression that we did that already? At least I did when I needed to change some map variables.

Report message to a moderator

Captain

Re: I'm putting an end to save-file compatibility breaks, if noone minds...[message #318658] Sat, 04 May 2013 15:24 Go to previous messageGo to next message
feynman is currently offline 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
Re: I'm putting an end to save-file compatibility breaks, if noone minds...[message #319354] Sat, 11 May 2013 12:53 Go to previous messageGo to next message
Taro_M is currently offline Taro_M

 
Messages:292
Registered:November 2008
I contacted him and Peter Noone does not mind you fixing save compatibility between versions.

http://www.utopiaartists.com/pics/bio_pNoone.jpg

Very Happy

Report message to a moderator

Master Sergeant
Re: I'm putting an end to save-file compatibility breaks, if noone minds...[message #319359] Sat, 11 May 2013 14:34 Go to previous message
lockie is currently offline lockie

 
Messages:3721
Registered:February 2006
Location: Scotland
Quote:
Poster: Taro
Subject: Re: I'm putting an end to save-file compatibility breaks, if noone minds...

I contacted him and Peter Noone does not mind you fixing save compatibility between versions.




oh dear ..... :/

Report message to a moderator

Captain

Previous Topic: Tactical AI: architectural redesign
Next Topic: Help with tweaking the sneaking
Goto Forum:
  


Current Time: Fri Mar 29 07:58:02 GMT+2 2024

Total time taken to generate the page: 0.01230 seconds