how to patch a map file (save file)
Community Forums/General Help/how to patch a map file (save file)
| ||
| Hello, (the longer number of characters allowed in the title is appreciated, thanks skidracer ! :) ) I am working on a map editor. There are different kinds (lists) of entities (entryexits, terrains, statics, interactables, lightsources, takables, turningmovings) (the names don't matter) I can create a new map, save a map, save a map as, close a map, load a map. The map is saved by writing, for each kind (list), the count of entities of this kind, for each entity, its properties (modelname, position, orientation, tag) The map is loaded by reading, for each kind (list), the count of entities of this kind, for each entity, its properties (modelname, position, orientation, tag) All works well, great ! Now, sometimes i decide to rename a model name, or to remove a model from the map editor, and if you work for several hours on a map but then you can't load it because you have renamed/removed a model, that's bad... So i decided to code a "map file patch program" where you can define which entities (identifiable by their model name) you want to rename/remove in the map (with for each, its kind (list), its model name, the operation wanted (rename or remove)), and then the program will analyze an existing map file (similar than loading a map), and rename or remove some entities from the map. I already know how to do it and it should work, i am just curious how you would do that ? The idea is to be able to load an old map file even if some models have been altered or removed from the map editor. Thanks, |
| ||
| I use bruceys TPersistence to serialize my object data into "savegames". I patched this mod to: - have a generic de/serializer which is called if the found "type" is no longer defined (eg. removed or renamded) - - the de/serializer handles incoming "data-arrays" and creates the new/renamed type instance by hand - each type could have a "serializedTypeNameToString()" and "deserializeTypeNameFromString:TypeName()" - which is called instead of bruceys TPersistence-de/serializer So I could - if really needed - make my savegames compatible to newer revisions. In your case: store them as json/xml and just skip whatever is no longer supported. For all supported ones you just need to have to register "synonyms": store a list of all known "ttypenames" (or even "ttypename->typenamehandler", "toldtypename->typenamehandler" ....). Then during loading of your map, you ask your registered handlers whether they are interested in the stored data or not. No patching needed - you just need to store in your code all these "renames" of types. removed types are just no longer handled by the savegame. And if a type got joined with another, then this new type just needs to register a handler for "old type" too. bye Ron |
| ||
| I did not understood everything that you wrote, but thanks for the tips. This made me realize again how important it is to backup your datas (progress) regularly, because i was able to debug the content of an old mapfile (since i have the old loading code to know how to read the file), and then i coded a procedure to modify some old models names into new models names, and apparently it worked ! (without a backup and the old loading code, i would have not managed to retrieve the old models names and the map would have stayed incompatible with the new version of my map editor (using a new saving/loading code and new models names) |
| ||
| If you write "readable" files (like XML, Json ...) then you could analyze the content while reading. <toldtype> -> load content but create "tnewtype" out of it, eg. create the newly introduced TVec2D out of toldtype.x and toldtype.y <tnewtype> -> load content too, without further "data updates". It is also good to store some kind of "version number" in your map file. So you could even write "loaders" for each version (or each "compatibility breaking change"). v1 -> LoadV1Map() v2 -> LoadV2Map() ... bye Ron |
| ||
| It is also good to store some kind of "version number" in your map file. So you could even write "loaders" for each version (or each "compatibility breaking change"). good idea, thanks |
   |