DarkScythe
Hunkalicious Holo
- Joined
- May 6, 2014
- Messages
- 804
Hey guys,
Just in case not many wind up browsing the Mod Components subforum, I wanted to bring attention to an issue that LeeS discovered a couple days ago relating to TableSaverLoader, and a potential for data loss.
I've created an add-on script as a workaround for this issue, at least until Pazyryk can rectify it, and full details are available over in my thread in the Mod Components subforum.
The short version is that this may affect any mod which utilizes TableSaverLoader and its Lua-only savegame interception code. I don't believe it affects DLL-savegame hooks, and autosaves are completely unaffected in my testing.
The issue is basically that whenever the player executes a manual save (clicking on Save Game, or Quicksave, or pressing Ctrl+S or F11) only one mod's data winds up actually being written to the database; this mod being the very last one to load. Any other mods which have also been loaded and rely on TableSaverLoader for data persistence will be at the mercy of the player's autosave settings.
If a player's game has not autosaved in a while, and the player then executes a manual save and then exits or reloads the game, all data for all other mods since the last autosave will be lost.
My add-on uses a couple of LuaEvents in order to get around this issue, such that whenever a manual game save is detected, it automatically triggers all other mods immediately to execute their own TableSave().
As an example of this in action, here are the log entries for one of my tests:
As you can see, the active mod/context was FreeUnitsPerXTurns, and without this workaround, it would have been the only mod to save its data. However, this script, once loaded into all 5 mods being tested here, allowed the save game event to propagate into each mod in order to let them know to save their data.
The downside to this approach, though, is that it relies on mods to have this script active. Even if I were to rewrite TableSaverLoader to hijack the TableSave() function, it would still be dependent on mod authors including the new version.
This basically requires every mod which uses TableSaverLoader to include this add-on, unfortunately. Otherwise, if a mod which uses TableSaverLoader but does not include this loads last, every mod would revert to previous behavior -- at the mercy of autosave picking up their data.
Thoughts and comments welcome, though preferably in the other thread.
This is the first time I've worked with LuaEvents and such, so there could be some issues, but I've not run into any errors in testing prior to release.
Just in case not many wind up browsing the Mod Components subforum, I wanted to bring attention to an issue that LeeS discovered a couple days ago relating to TableSaverLoader, and a potential for data loss.
I've created an add-on script as a workaround for this issue, at least until Pazyryk can rectify it, and full details are available over in my thread in the Mod Components subforum.
The short version is that this may affect any mod which utilizes TableSaverLoader and its Lua-only savegame interception code. I don't believe it affects DLL-savegame hooks, and autosaves are completely unaffected in my testing.
The issue is basically that whenever the player executes a manual save (clicking on Save Game, or Quicksave, or pressing Ctrl+S or F11) only one mod's data winds up actually being written to the database; this mod being the very last one to load. Any other mods which have also been loaded and rely on TableSaverLoader for data persistence will be at the mercy of the player's autosave settings.
If a player's game has not autosaved in a while, and the player then executes a manual save and then exits or reloads the game, all data for all other mods since the last autosave will be lost.
My add-on uses a couple of LuaEvents in order to get around this issue, such that whenever a manual game save is detected, it automatically triggers all other mods immediately to execute their own TableSave().
As an example of this in action, here are the log entries for one of my tests:
Spoiler :
As you can see, the active mod/context was FreeUnitsPerXTurns, and without this workaround, it would have been the only mod to save its data. However, this script, once loaded into all 5 mods being tested here, allowed the save game event to propagate into each mod in order to let them know to save their data.
The downside to this approach, though, is that it relies on mods to have this script active. Even if I were to rewrite TableSaverLoader to hijack the TableSave() function, it would still be dependent on mod authors including the new version.
This basically requires every mod which uses TableSaverLoader to include this add-on, unfortunately. Otherwise, if a mod which uses TableSaverLoader but does not include this loads last, every mod would revert to previous behavior -- at the mercy of autosave picking up their data.
Thoughts and comments welcome, though preferably in the other thread.
This is the first time I've worked with LuaEvents and such, so there could be some issues, but I've not run into any errors in testing prior to release.
