Maintaining backward Savedgame compatability

I think that 2 should be more like, "Updates should not break backward compatability if possible, but nothing should be held back because it breaks compatibility"
 
SimCutie I had a question conserning the ExtLoad code you added to enable backward compatability. I see this section of code

Code:
ExtLoadTypes load_acion =  getExtLoadAction();
	if ( load_acion == EXTLOAD_BASE )	// Firaxis vanilla
		return;
	if ( load_acion != EXTLOAD_EXTOK && load_acion != EXTLOAD_OLD )	// Error
		return;

will imediate exit when the save game being loaded is Firaxis Vanilla or the version is old. If I add additional data members below they will be read only when the versions match. But if I were loading a game saved under an older version of the CCP theirs no means of breaking up the loads and getting just what I want. Is their some means by which a series of if statments each checking for a version of CCP before loading. A new Enum for each version would be added and all the new data in that version placed under it. It would look something like...

Code:
if ( load_action >= EXTLOAD_1.61.01)
{
     load stuff added in version 1
}
else 
{ 
   return
}

if ( load_action >= EXTLOAD_1.61.02)
{
     load stuff added in version 2
}
else 
{ 
   return
}

I hope something like this could be done, but in the meantime I will place a markers in the Ext load function to seperate blocks which corespond to each version release, these can later be used to group the load-blocks.
 
Gurav has some concerns about save game compatability, specificly lack of backwards savegame compatibility was a deal-breaker for cerain mod makers. I hadn't though this would be the case but it seems I was wrong.

A method similar to what I described ealier would work but it might be possible to use a Global Define to control it. Civ4 already has a global define called SAVE_VERSION but I dont see it referenced anyware in the SDK so I think its being used in the .exe for some other purpose. A new Define called LOAD_VERSION could be created and as the game data loads it uses the value to keep everything syncked. When it saves it uses the SAVE_VERSION value it selectivly omits new data to creat a save which is backwards compatible and playable by someone who isn't using our DLL. The individual mod authors would be able to control when and if save compatability is broken.
 
Impaler[WrG];4995834 said:
Gurav has some concerns about save game compatability, specificly lack of backwards savegame compatibility was a deal-breaker for cerain mod makers. I hadn't though this would be the case but it seems I was wrong.

That was not exactly what I meant.

I think it would be obvious that those using mods that alter gameplay probably wouldn't be so interested in passing around their savegames to those not experienced with modding. But that is very common among unaltered gameplay players. Think of SGers, role players (story writers), tutorial writers, high scorers, and yes, unaltered gameplay mod makers. You should see the complaints of HOFers "being forced" to use a mod. Note that reverse compatibility (mod -> vanilla) is actually more important than the other way around. :cool: And I have reservations that reverse compatibility is even possible with any changes to the savegame part of the code.

Like I said, probably better off creating a separate dll for unaltered gameplay modders like me than trying to make it all work for a niche audience...
 
Well lets look at the differnt types of situations which can occur.

A) Playing CCCP and saving in Unmodified WL so the save is readable by non moded DLL.

b) Loading a Save from unmodified DLL with CCCP DLL.

In senario A the player needs to set the Save Version global define to 2.00 (thats what unmoded WL uses) then load Civ4 and save the game. The code will write only the original info an ommit all the extended information. An unmodified DLL can then load that save without any trouble.

In senario B the CCCP user sets the Load version global define and at the apropriate places the code just generates zeros for all the data missing in the save and then continues loading. Using the wrong loading number will crash the process. Idealy the value would be detected automaticaly from the save as SimCutie had planned but for now this plan sounds more feasable to use a global define.
 
Top Bottom