The annoyance of save game incompatibility (RIP)

Koshling

Vorlon
Joined
Apr 11, 2011
Messages
9,254
Since I started contributing to the C2C modding efforts (and more recently AND) I have become increasingly frustrated by incompatibility of save games from one version into a slightly changed version as the XML assets evolve. Basically this means I never get beyond the middle ages before new assets render my games uncontinuable.

As a result I decided to do something about it.

This post is a slight pre-announcement, but I'm very excited about this change, so hopefully you'll foregive me for that. I am currently in the final stages of testing, but I expect to be pushing the changes to SVN in the next day or two. After I do I'll make a detailed technical post giving the details of how it all works for modders reference, but for now here's a brief summary in the form of a FAQ list:

What do I mean by saying the changes will enable save-game compatibility between mod releases?

An option will be provided on save, to save in an extended format, which will be loadable even after fairly radical changes to the mod XML, or future DLL changes. In particular you should be able to expect to continue existing games in updated versions of a mod, unless the changes to the mod are of an extremely radical nature.

What are some examples of mod changes that will NOT prevent save games from loading with the new format?

Most changes frankly. For example, adding buildings, units, civics, techs, improvements, resource types and so will no longer break saves. Removing these things will also not break saves, though in cases where removed entity is in use in the save it will be removed on load if no longer valid (and you'll get a visible warning that this has occurred). Obviously if the mod changes relationships between already-extant (in the save game) entities (e.g. - changes requirements for building something) then the save game will potentially contain things that you would not be able to create in the same conditions after the mod update (so if a building got a new required tech say, you would still have the building if you had already built it previously).

What will still make a save game unloadable?

Pretty much just DLL changes that don't stick to certain rules (which I'll clarify in a technical post after this gets pushed)

So should I continue old games just because I can?

Up to you. If the load gives you warnings that some of the types it needed could not be found (which implies units/buildings/resources or whatever it warns you about have been removed) then you need to weigh the loss of fidelity against the benefits of not losing your investment in time in that game.

What are the downsides?

Using the new format will result in larger save files (about 40%) and slightly slower loading and saving.

When will the new format be used, and when will the old format be used?

Auto saves will continue to always use the old format because it's smaller and faster. This means you can't assume autosaves will be loadable in future releases (so same as now). Explicit save requests from the main save menu will now pop up an additional question asking you which format to use.

When do I recommend using the new format?

Depends who's asking ;-) This new format should be considered beta functionality, so for most end users I would say from day to day continue to use the old format. When a new mod release or patch becomes available make a save in the new format so that you'll be able to load it again after updating the mod. Modders on the other hand might want to save in the new format all the time since they are likely to be making XML changes frequently (and because they want to be helpful and give it some additional testing!)

I hope everyone enjoys the ability to continue games even on mods that change very frequently (looking at you C2C), and I trust you'll forgive my excitement with this.
 
Wow, this is great! How will you choose between the old and the new format?

You get a popup that asks you which to use when you do an explicit save (auto and quick save use the old format for speed without asking)
 
After a few people requested it, I have just pushed to SVN (C2C and AND SVNs both) a small update to this to allow you to change to always using maximum compatibility saves for all saves without being asked (including autosaves). By default this is turned off (so you'll get the functionality you've had the last month or so, with autosaves being old format and a question as to what format to use on explicit saves), but it can be enabled in the global defines.

Go to assets/xml/A_New_Dawn_GlobalDefines.xml and add a global define as follows:

Code:
	<Define>
		<DefineName>ALWAYS_USE_MAX_COMPAT_SAVES</DefineName>
		<iDefineIntVal>1</iDefineIntVal>
	</Define>

(or, if you get it from SVN after this change, modify the one that's already there at the end of the file, but defines the value as 0)
 
This is fantastic news! It's so frustrating to either have to give up on a game that dozens of hours have been invested in, or have multiple copies of the game installed and try to keep track of all the differences. Big thumbs up - I'm excited about this!
 
After a few people requested it, I have just pushed to SVN (C2C and AND SVNs both) a small update to this to allow you to change to always using maximum compatibility saves for all saves without being asked (including autosaves). By default this is turned off (so you'll get the functionality you've had the last month or so, with autosaves being old format and a question as to what format to use on explicit saves), but it can be enabled in the global defines.

Go to assets/xml/A_New_Dawn_GlobalDefines.xml and add a global define as follows:

Code:
	<Define>
		<DefineName>ALWAYS_USE_MAX_COMPAT_SAVES</DefineName>
		<iDefineIntVal>1</iDefineIntVal>
	</Define>

(or, if you get it from SVN after this change, modify the one that's already there at the end of the file, but defines the value as 0)

I'm very tempted to turn this on to 1.
 
I most definitely agree here, thats all we deal with in our mods anyway, so let those that DONT want it, change it.

I leave that choice to the primary owners of the mods (Afforess and SO), but personally I run with it set to 1 also.
 
I leave that choice to the primary owners of the mods (Afforess and SO), but personally I run with it set to 1 also.

Yeah i tried it out, and the only thing i dont like about adding this to the normal savedgames is because of the 3-6 second delay on each turn now, so i am on the edge again on doing it this way??:sad:
 
Yeah i tried it out, and the only thing i dont like about adding this to the normal savedgames is because of the 3-6 second delay on each turn now, so i am on the edge again on doing it this way??:sad:

Well you autosave every turn don't you? Most of us only autosave every 4th
 
You get a popup that asks you which to use when you do an explicit save (auto and quick save use the old format for speed without asking)

I play AND in LAN with a friend. we can not reload a savegame due to a "cant uncompress" failure, even with explicit save after 5 turns.
Only the "client" gets this failure, the server loads correctly. Even if both save the game and change server-client side the client still cant load the savegame.

I use AND with 1.75C Patch and I never get an option about changing the format of the save file.
 
I play AND in LAN with a friend. we can not reload a savegame due to a "cant uncompress" failure, even with explicit save after 5 turns.
Only the "client" gets this failure, the server loads correctly. Even if both save the game and change server-client side the client still cant load the savegame.

I use AND with 1.75C Patch and I never get an option about changing the format of the save file.

That's because it's new in 1.76 beta 4 or so
 
ok i installed the 1.75C patch into the wrong folder.... shame to me ^^ now its working
 
Top Bottom