The following code in simworld.cc
// rdwr cityrules for networkgames
if(file->get_version()>102002) {
bool rdwr_city_rules = umgebung_t::networkmode;
file->rdwr_bool(rdwr_city_rules);
if (rdwr_city_rules) {
stadt_t::cityrules_rdwr(file);
}
}
Appears to have the wrong version number: should it not be 102003 not 102002? 102002, the current stable, does not have "file->rdwr_bool(rdwr_city_rules);", which line is called in every save game version >= 102002, such that a game saved in the current stable version will crash when loaded with the nightly.
I do not understand your report.
The current savegame version is 102002 (simversion.h), there should not happen anything bad. These information about cityrules as well as the bool in question will be saved as soon as the savegame version is increased.
The code for saving/loading is identical (checked karte_t::laden and speichern)
Edit: I realized, simutrans experimental has already increased the savegame version (102003), so the bug is related to this inconsistence.
Dwachs,
hmm, I'm not sure that I follow. The current stable version is 102002. If I remember correctly, the above code was added after the stable version was released. This code is called in loading as well as saving. If this code is called on a saved game saved with the current stable version, in which this code is not included, it will attempt to read the "rdwr_city_rules" value when no such value has been saved. This will, in turn, corrupt the remainder of the save, as the whole thing will be 8 bits off.
No: the condition
if(file->get_version()>102002) {
ensures that rdwr_city_rules is neither saved nor loaded with savegame version <=102002. The version is taken from simversion.h for saving, it is read from the savegame upon loading.
It will crash on savegames that were saved with savegame version>102002
before this piece of code was added.
Ahh - sorry: my mistake. The convention in Simutrans is to use >= rather than >, so I ****umed that this was the same. On closer inspection, it is just >. Perhaps, for clarity, this could be changed to >= 102003 to match other occurrences?
Unforutunately the code at that state is messy. There are at least one occasion <102003 must be used and >102002 and >=102003 are often both used. One should think of unifiying though.