Talk:Plan for save states
TMC (talk) 02:13, 12 April 2015 (PDT) -- I've been intending this for a while. I see no reason not to use RSAV with extra data, especially since almost everything that's saved in a "complete" save state, we would also want to allow optionally saving in regular saves. In fact there's only a single piece of data that I can think of that should be omitted in regular saves: the state of the script interpreter. Because if the script data in the .rpg changes, the script interpreter state would become invalid and have to be thrown out. I really would love to be able to save interpreter state in regular saves, but it seems that it would require a complicated system where either the scripts are resumed if possible, or otherwise the 'load game' script is triggered instead so that you can restart everything manually. (In other words, distinguish between saved games and save states.) Clearly most users would get it wrong. Alternatively, we could allow saving script state only if you disable the ability to port your saves to newer versions of the game. Or just hide it as an advanced feature.
PS: Aside from fixing the Android port, I'm really keen to combine save states with input recording (.ohrkeys) for record-and-replay. Rewind to 8 seconds ago to try to figure out why a bug just happened. Edit the game to fix the problem, rewind before the bug occurs, and resume! A couple weeks ago I went to an awesome talk by O'Callahan of Mozilla on their miraculous rr tool (record-and-replay). Basically, you should already be able to do what I just described by using rr, with minimal overhead, though I haven't tried it yet, and live-previewing isn't going to work. rr only works on Linux.
I think there are many benefits of having save states, although also potentially some disadvantages such as if you want to upgrade save games to a new version of the RPG file which would make this more difficult to work (which is mentioned in the comment above, although I think script state is probably not the only reason for this). ZZT, MegaZeux, and Super ZZ Zero all do this already (although MegaZeux also allows you to implement your own formats by the file access functions), and ZZT uses the same format of world files for save games (which makes it much easier to implement). (In the case of Super ZZ Zero, the current implementation saves and restores everything (except the state of the random number generator) and refuses to load save games from older versions of the world file (ZZT and MegaZeux will just restore it as the older version instead, so that any changes to the newer version of the world file will be lost), but I also intend to add some way to allow upgrades to work properly if you do want to allow it, such as by a UPGRADE.DER lump which specifies what things should be changed when loading a older save game file (and might restrict it to certain locations; I think some Pokemon ROM hacks require you to save at the Pokemon Center if you want to upgrade your save game, for a similar reason) (this might also be necessary for OHRRPGCE if a value which is saved that might be changed at run time will nevertheless need to be upgraded, such as parts of the currently active map).) For input recording, you might also want to record random numbers, especially if you do not save the state of the random number generator (although it might be better not to save it anyways, in case the random number generator is changed later). --Zzo38 (talk) 21:38, 15 February 2026 (PST)