Savegame versions

[TrueBrain]

Currently, we are to naggy about new savegame version. Some things I want like to see different.

First, MINOR version is NEVER used. It is saved, but never loaded. My suggestion is to get ride of it.

Second, the savegames are ready for 65536 MAJOR versions. Why don't we change the savegame more often. Now we are waiting and putting it all together, having some known bugs in the nightly builds, because we don't want to update the savegame version yet. Who cares if we hit 200 versions. So my suggestion is, that every time someone wants to change something in the savegame, let him do it, bump the version, make sure it keeps backwards compatible, and we are all happy

So.. let me know what you devs think of it

[Celestar]

100% agree.

Celestar

[Bernhard]

100 % agree

[dominik81]

version is a uint. 256 values for major version, 256 values for minor version. And the minor version is being used a few times, e.g. for correct town owner handling and for compatibility with new airports. The minor version can be increased whenever something is added to a savegame without breaking the old savegames. The major version is used to ensure downward compatibility.

[TrueBrain]

version is a uint. 256 values for major version, 256 values for minor version. And the minor version is being used a few times, e.g. for correct town owner handling and for compatibility with new airports. The minor version can be increased whenever something is added to a savegame without breaking the old savegames. The major version is used to ensure downward compatibility.

Excuse me? Version is an uint indeed.. this is 32-bit... this means that there are 65536 major and 65536 minor versions.. check stdafx.h for the define of uint.. you will see it is an unsigned int, and an int is 32-bit.. even more: it is saved as a raw 32-bit integer.. so we have a _lot_ of versions to go

And as you point out yourself, minors are used very little. They are set back to 0 after a major, so they don't really have a purpose... but we can keep it, it does not really matter

[dominik81]

Sorry, I was wrong there of course. But in SaverLoader struct the variable version is a byte. I didn't examine the save/load code close enough yet to say which way it is stored in the game. But internally bytes are used in most places for the version number (e.g. struct SaveLoadGlobVarList as well).
Anyway, I think that minor versions are underused. And in many cases you do not have to store extra variables to implement a new feature. So even though the savegame version of course shouldn't hinder the implementation of a new feature, it shouldn't necessarily be raised for every new patch.

[TrueBrain]

Sorry, I was wrong there of course. But in SaverLoader struct the variable version is a byte. I didn't examine the save/load code close enough yet to say which way it is stored in the game. But internally bytes are used in most places for the version number (e.g. struct SaveLoadGlobVarList as well).
Anyway, I think that minor versions are underused. And in many cases you do not have to store extra variables to implement a new feature. So even though the savegame version of course shouldn't hinder the implementation of a new feature, it shouldn't necessarily be raised for every new patch.

A byte is easly changed in an uint16, even more because it is not saved

[Celestar]

Truelight:

change it to uint16 please

Celestar