News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Compatible savegames with trunk

Started by isidoro, March 07, 2009, 06:29:35 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

isidoro

In the max load patch, http://forum.simutrans.com/index.php?topic=1648.0, one faces the problem that if you have to save something (in that case, the max loading percentage) the saved files will no longer be compatible with trunk and you cannot load old games to test new functionality too.

I think that also applies to James Pett's ST-experimental.  Here is my idea:

Make a patch-compatibility savegame layer:

  • All patches that require saving something will have a unique identification string.  For example: "author:name-of-patch:version"
  • There would be a method in savegame_t named bool is_patch_installed(char *id), that can be used inside the rdwr functions to know if the new features should be loaded/saved.
  • In the load/save window, a checkbox will give the option to "be compatible with trunk"
  • More advanced:  in the savegame a field can be added so that it says which patches should be on so that, if not, automatically abort loading

jamespetts

Isidoro,

this is a very interesting idea. Currently, Simutrans-Experimental save game files are compatible with the trunk, but only because I do not save any additional data in them. That causes some problems when loading saved games, so I am planning to create a new save game file version to work with Simutrans-Experimental, but would not allow Simutrans-Standard to read games saved with Simutrans-Experimental. This is definitely an interesting idea, but would only be of any use, of course, if it was implemented into the trunk. Certainly, if it was, I'd make the save game files of Simutrans-Experimental compatible with it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Patches are expedted to be not compatible with the trunk. Patches are for testing, not for playing. OpenTTD has this for a very long time. (For the nightlies I have added code to recover from missing information. In principle the current code can even save a 99.17 savegame before the introduction of the new vehicle movement system.)

The trunk would have to ignore this anyway or will information in the binary savegames interpret others. If you use XML savegames, then such incompatible games will be discovered easily. Other than that, you would have to add a lot of information to be able to load patched savegames in the trunk. Especially since they may have different functionality. (Imagine a patch for powerlinetunnel. The trunk encounters such a savegame but do not know about powerline tunnels. It would not have a matching besch and would abort anyway.)

Imho to much effort for very few cases.

isidoro

My idea doesn't involve the trunk.  I agree that trunk is for playing.  Nothing should be added to trunk.  The idea involves ST Experimental if James wants and patches that save info, if programmers want.  The use case would be:

  • I have an old game, load it in a patched binary, in compatible mode.
  • Play with it for some time to test the patches.  Meanwhile, the game is saved in patch's mode.
  • Once the patch has been tested.  The evolved game can be exported to a format compatible with trunk, to benefit from the infrastructure built while on the patch version.

The idea is to make a compatible specification to be reused.

jamespetts

Ahh, I see what you mean. Actually, the standard way in which Simutrans works for saved games is to detect the version number, and set default values for any data known not to be saved in versions below a certain number, so (1) and (2) will happen in any case. No. 3 is the extra bit that you are suggesting, I think, and it is an interesting idea. Would you like to code it, once I have reversioned the save files for Simutrans-Experimental? I'd gladly add it to the code :-)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

Trunk has its own versioning line and the patches should not interfere with it.  Points 1 and 2 apply too.  If my patch tries to load an old game and trusts trunk versioning it can be fooled.  The trunk can go on with versioning and fool it.

Regarding coding, now I have an overcrowding problem.  I have no patch slot free to occupy with it.  And merging it with one of the opened ones is no solution for reusing.  I would be very happy to work on the specification with you, though and coding when I free any of the slots.

The first problem I have is how to make the id string of the patch to be automatically recognized by the routine, no matter how many patches have been applied...

jamespetts

Ahh, as far as Simutrans-Experimental was concerned, I was not planning simply on incrementing the save game version by one, since that would then end up, as you suggested, with multiple inconsistent versions. Instead what I plan to do is, depending on the number of bits with which the number is stored (I have seen four digit decimal numbers used for the versions, so it must be at least a 16-bit number) is to have the version number calculated by adding together the base standard version (say, 4329) and the Simutrans-Experimental version (say 120000 - which would be Simutrans-Experimental revision 12), to make a total version number of 1204329), which would then be extracted into the separate standard and experimental versions. I am hoping that the version number is 32 bit to allow more headroom.

I have used a similar system (albeit, because of the way in which that system works, using hexadecimal numbering with some bitwise operations) for the file versioning of the various .pak files that are modified by Simutrans-Experimental (in the latest version - only the source code is available for that at present), which seems to work so far. The other atlernative, which I might have to use if the save game file format is a 16-bit number, is to add, say, 20,000 to the number to make it a Simutrans-Experimental version, and, if the number is higher than 20,000, it would then look for a further version number variable somewhere that will give the Simutrans-Experimental subversion.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

Now I understand you.  But a per-patch & experimental separate versioning would allow more interchange.  Apart from option 2) and 3), that should be implemented.  Your code could ask:

if (file->is_patch("experimental",100)) {

for experimental version above 100...


jamespetts

What do you mean here by, "per-patch and experimental separate versioning"?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

I mean a system in which you can ask the version of experimental, of replacing-patch, of trunk, etc. that is to be used.  That way,  you can be more accurate when saving and loading things.

For example, when saving in compatibility mode, all file->is_patch("...",x) would return false.  If done carefully, an info version could show the versions of the trunk, exp and/or patches in effect.


jamespetts

Hmm... I'm slightly confused. Could you elaborate a little on how you envisage it working?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

VS

I see it as a list of installed patches with unique names - so looking at the savegame, it can be decided what patches are needed and if they are present. Once the system is in place, you just add somewhere in  all patches something like patches->register("rocket transport"); to tell the program that it is using a patch...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

Interesting idea... does anyone care to code it? I'll gladly add it to Simutrans-Experimental if anyone does... :-)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

@VS:  That's it!  :)   Together with some versioning.  But I have a technical problem I cannot solve:
Whether you use a registration function or directly add the name of the patch to a variable-size array or to a file, I don't know how to do it in a format compatible with patch files, so that compatible patches could be added in any order.

If I do something like this:

// Please insert your patches registering functions
// below these two lines:
blah, blah, blah...


The first patch will place the correct function there, but that hunk of the second patch would fail, wouldn't it?  Any help?

Dwachs

Maybe at the very end of a trunk savegame add the patch data (that would be in karte_t::laden(loadsave_t *file) ): with this data specification:

int32 size  <- total size of patch data
byte len  <- length of patch identifier
char patchname[len]  <- patchname
char data[size-len] <- actual data


If the code (trunk) cant handle the patch data, then it will skip it.
Parsley, sage, rosemary, and maggikraut.