Fri 31 May 2013 11:55:48 PM UTC, comment #4:
Introduction: As far as I understand, SlotUsage assigns all units being build to unit-producing buildings, so that a savegame does not load with suddenly canceling all in-progress unit build orders.
Grep-ing the repository for "SlotUsage" leads me to believe that the following tasks need to be done:
1. Change the savegame file format (engine/unit/unit_manager.cpp) and increase the savegame version number. The new format needs to save
SlotUsage(MaxSlot, [{{Slot = Slot1, FreeCycle = Freecycle1}, ..}])
rather than the old, buggy
SlotUsage(MaxSlot, [{Slot = Slot1, FreeCycle = Freecycle1}, ..])
(all parameters after the first get saved inside a table).
2. SlotUsage (engine/unit/script_unit.cpp) needs to be adapted to handle a table as the second argument and process its entries the way it processed all arguments but the first.
3. Update documentation (doc/scripts/savegame.html).
4. Create a handler for old format savegames. Here is some pseudo code that might do the trick, if possible:
savegame_code = import(savegamefile)
for line in lines_that_contain(savegame_code, "SlotUsage")
tmp = savegame_code.replace_first_occurence("{", "{{")
fixed_savegame_code = tmp.replace_last_occurence("}", "}}")
execute(fixed_savegame_code)
In any case I recommend to never overwrite savegames while loading them. It would also be acceptable to not provide backwards-compatibility. Perhaps some decision on that havs been made in the past.
Unfortunately I have no C programming experience. Hopefully this summary is correct and will make it easier to get into the
|