First release

[The Great Apple]

Actually, by defailt experience is reduced to a maximum of 10 experience points when you upgrade. This is what I thought you may have changed.

Have finished updating the changelog, and have to go now. I've highlighted some bits in bold. I didn't have time to work out how to summerise the logging routines that you've added SimCutie, so I've left a placeholder there.

Could everybody please check I've got all the changes you've made in there.

 

[SimCutie]

Here is my code ready to merge, if any of the documentation is unclear please ask and I can in more detail describe the changes. As most effects require XML to activate and test I will prepare some content files that you can slip in Custom Assets, make shure your using the main assets pack here as your explicitly loaded mod as it contains the nessary Schemas to alow thouse content files to be read.

@'Impaler:
Have you checkcked compatibility with old savefile?
If you change NUM_PLAYER_OPTION_TYPES, It may or may not read old original save file. Please check out it. And it will make compatibility problem in future with more player options unless this is attacked and handled explicitely.

 

[The Great Apple]

As far as I am aware we're waiting on SC's little update so that the interface changes are configurable, and Impaler to look at NUM_PLAYER_OPTION_TYPES right?

 

[SimCutie]

This is updated files as TGA said. (Chnaged file only)

 

[Impaler[WrG]]

I put it under NUM_GAME_OPTIONS not PLAYER_OPTIONS. I dont see why we would be conserned about NUM_GAME_OPTIONS when I already made a bunch of other changes that break savegame compatability (new data members in CvCity and CvPlayer). I though we had desided it was ok to do this? Though the user cant currently use the custom game options screen to set the mod they can use the XML file to set it or they can use a python call at startup. It seems like the best place to put the controls as its incorporated in the game perminently, eventualy we can get that UI problem corrected and then it will be perfect.

 

[SimCutie]

I put it under NUM_GAME_OPTIONS not PLAYER_OPTIONS. I dont see why we would be conserned about NUM_GAME_OPTIONS when I already made a bunch of other changes that break savegame compatability (new data members in CvCity and CvPlayer). I though we had desided it was ok to do this? Though the user cant currently use the custom game options screen to set the mod they can use the XML file to set it or they can use a python call at startup. It seems like the best place to put the controls as its incorporated in the game perminently, eventualy we can get that UI problem corrected and then it will be perfect.

In that it may have backward compatiblility hazard, NUM_GAME_OPTIONS or PLAYER_OPTIONS are not much diffrent. Adding new data members in CvCity and CvPlayer is OK. Game saved in new format is sure to break the compatibility. it is inevitable.
But it should be able to *read* original old save file. This is backward compatibility I am talking about. But your current implementaion breaks this compatibility.
You should check the save file version and if it is save file of original unmodded game, skip reading additional variables from file and fill the new variables with default (reasonable) values.

 

[The Great Apple]

Given that this bit doesn't do anything anyway (right?) it wouldn't do any harm to remove it.

Does somebody want to do the final merge and compile? If you are going to do it post here so nobody else does it at the same time.

Oh - and SimCutie; could you please right a brief explaination about that logging function for me?

 

[SpoiledFruit]

Already started merging them. I'll post the finished dll on my FTP server when Its done.

 

[The Great Apple]

Great - ta!

 

[member66170]

can't wait to get my hands on it!

 

[Impaler[WrG]]

In that it may have backward compatiblility hazard, NUM_GAME_OPTIONS or PLAYER_OPTIONS are not much diffrent. Adding new data members in CvCity and CvPlayer is OK. Game saved in new format is sure to break the compatibility. it is inevitable.
But it should be able to *read* original old save file. This is backward compatibility I am talking about. But your current implementaion breaks this compatibility.
You should check the save file version and if it is save file of original unmodded game, skip reading additional variables from file and fill the new variables with default (reasonable) values.

Again I though we had desided this type of backward save game compatability was not nessary. End users routinly start new games when a new mods are released its not an issue for them. To impelement what your sugjesting every single read/write would need to have an if statment checking for the savegames DLL version and I dont know of any check we can make which will tell us that.

Given that this bit doesn't do anything anyway (right?) it wouldn't do any harm to remove it.

It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.

SpoiledFruit: I have some last minute bug fixes to include, also I put Chalids Slow Cultural Border Expantion in as another option and am working on merging in RogerBacons changes to City Work Radius, Cultural Borders on Ocean and the Flying Mod. The Work radius I am changing slightly to make in an Option rather then a hardcoded part of DLL. I can merge all these in if you put the source up at a place I can access it (I still can not access your server at the old or the new IP). I can also just post the altered files here for you to use if you like.

 

[The Great Apple]

It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.

Okies - I see what you mean. I thought it was just redundant.

The end result of the backward compatabilty discussion seemed to be that we should have most releases not breaking backward compatablilty, but there should be an amount that did.

 

[member66170]

When are we going to get this release?

 

[The Great Apple]

When are we going to get this release?

Already started merging them. I'll post the finished dll on my FTP server when Its done.

When it's done

 

[SpoiledFruit]

Should be ready somtime today or tommorow

 

[member66170]

Well, I'll do as much work/moding as I can now, so I'll be able to play this later. I'm really looking forward to having all of my GPP pooled together.

 

[SimCutie]

Again I though we had desided this type of backward save game compatability was not nessary. End users routinly start new games when a new mods are released its not an issue for them. To impelement what your sugjesting every single read/write would need to have an if statment checking for the savegames DLL version and I dont know of any check we can make which will tell us that.


It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.

SpoiledFruit: I have some last minute bug fixes to include, also I put Chalids Slow Cultural Border Expantion in as another option and am working on merging in RogerBacons changes to City Work Radius, Cultural Borders on Ocean and the Flying Mod. The Work radius I am changing slightly to make in an Option rather then a hardcoded part of DLL. I can merge all these in if you put the source up at a place I can access it (I still can not access your server at the old or the new IP). I can also just post the altered files here for you to use if you like.

I don't think so. When Piraxis issues new patch they maintains backward read compatibility with old savefile. Acutally they do check the savefile version everytime they read save file. They do great care to maintain read compatibility with old save file. Why can't we?
I am not argueing that the features should be removed or left out. It is OK to add new varibale or the features. But it should also be implemented in the way as it can read old save file.
Having new feature AND being able to read old save file too, is techincally feasible and strongly desirble.
I object to releasing any new version that will crashes on old original save file.
It will ruin credibility of our project.
At least, it should be able to read old original savefile when the feature is not selected by run-time cobnfigure or the new XML tags are not used.

 

[The Great Apple]

True, however seeing as the CCP will often be bundled with a new version of a mod, the mod is likely to break backward compatabilty as well.

Sometimes it won't be, and that is why I suggest we try to make as many releases as possible be backward compatable, but if we're not careful the whole code becomes a bundle of different version checks.

 

[12monkeys]

I don't think so. When Piraxis issues new patch they maintains backward read compatibility with old savefile. Acutally they do check the savefile version everytime they read save file. Why can't we?
I am not argueing that the features should be removed or left out. It is OK to add new varibale or the features. But it should also be implemented in the way as it can read old save file.
Having new feature AND being able to read old save file too, is techincally feasible and desirble.
I strongly object to releasing any new version that will crashes on old original save file.
It will ruin credibility of our project.

I agree. We shoud be able to read old save games without crashing the game. I'm sure there are people who want to load their current game and to proceeed with the new features.
Also, a lot of modders (me as well) have created their test scenarios to check certains aspects of the game with their mods. It will raise acceptance if they still can use them with our DLL/API.
After the game is save once, we may loose compatiblity, as long as we communicate it. Everybody who has a problem with this, can make a backup of the savegames.


12m

 

[Impaler[WrG]]

Read my post at the bottom of this thread for my arguments against backward compatability. If people had made their feelings know back then we could have possibly developed this feature but its definatly too late for the first release unless someone wants to A- drop nearly all the content I made or B- has the code for this ready right now.

http://forums.civfanatics.com/showthread.php?t=170670