Allow for manual disabling and triggering of rewind points from Lua#617

in some heavily scripted mods its necessary to perform complex procedures over multiple frames, when doing so there’s a chance that an autosave/rewind point will trigger in the middle of the procedure, such that when the game is rolled back, it’s in an invalid state.

The current only solution to this (besides just accepting your game cant be rewound) is essentially to serialize everything possible, so that after the game is rolled back to the middle of the procedure, the script has to manually further roll back to the start of it, which is extremely tedious, error-prone, and possibly slow.

My solution would be some kind of setAutoRewindPointTrigger(false) and triggerManualRewindPoint(), which would allow script authors to manually create rewind points just before/just after a complex procedure, when the game is known to be in a valid state, and prevent any broken rewind points in the middle.

Since under the hood rewinding is really just saving, it might be a good idea for this to affect that as well, instead saving the last rewind point if things are disabled, ideally with some sort of dialog/notice that explains “This game has disabled saving at the current moment to ensure game state stability, would you like to save the game as it was X seconds ago?”. (possibly with a manual override for like “yes save the state now even if it might break”)

As an even simpler API, I would suggest “setAutoSaveEnabled(false)” and “setAutoSaveEnabled(true)”.

Clearly you need a transaction approach. We should be able to <Global>.startTransaction() and later either <Global>.commitTransaction () or <Global>.rollbackTransaction(). The engine would suspend load/save while a transaction is unresolved. A <Global>.isTransaction() Boolean function would complete the set. startTransaction would return false if a transaction is already active; conversely, commitTransaction and rollbackTransaction would return false if a transaction is not active.

I don’t think transactions are the way to go, rolling back in script would essentially be saving/loading, killing the current context and starting a new one, which could create a whole host of issues. I think without that it’s an abstraction that could be built on top of the above system by a user, but I don’t really see a benefit to it.

Someone brought up in discord that behaviour with multiple object trying to enable/disable saving could cause issues, or one object trying to trigger a save after another disabled it. My proposed solution would be: save enable/disable is stored per script. When a save is triggered (auto, or manually by script or player) it only succeeds if all scripts have saving enabled. If triggered by a player, a popup appears with a list of all objects currently disabling saving and an option to use the save from X seconds ago or override appears as described above.

By “per script” you mean the .ttslua of each object? You’d have TTS check each object to see if it has onLoad/onSave defined?

As for concurrent enabling/disabling or loading/saving issues, it’s beginning to sound like semaphores would be needed.