SAVE and RESTORE Commands

I have not been able to create a sequence in I7 that will implement the SAVE command. I find in reading most of the available texts that they all seem to gloss over the subject with some comment that is basically “If you don’t know how it works you don’t need to use it!”.
I tried this question one time previously and the answer I got was similar to that and was from one of I7’s progenitors, claiming that they use it and it works. :laughing: However than ain’t helping :exclamation:

Er, you are likely to get better responses if you actually explain what it is you’re trying to do…

Are you just trying to save the game? Saving is built into I7, so you just need to type SAVE (in the game) to save.

Are you trying to trigger a save from code other than the SAVE command? If so, check out the Standard Rules (File–>Open Extension–>Graham Nelson in the IDE), which offers these I7 names for constructs that are otherwise implemented in I6:

[code]Saving the game is an action out of world and applying to nothing.
The saving the game action translates into I6 as “Save”.

The save the game rule is listed in the carry out saving the game rulebook.[/code]

Are you trying to reimplement the save functionality entirely? If so, the folks warning you off probably have the right idea, but you can dig into the I6 template code to see how the built-in functionality is implemented.


Saving and restoring are interpreter features. You don’t have to add them to the game separately.

What may throw you off is that saving is disabled in the Inform’s IDE interpreter. If you release your game and try it with any interpreter outside the IDE you should have save/restore working normally.

I remember you asking this before. As Juhana stated, save is already implemented in I7. It is built - in. You don’t have to do anything.

You can verify this by typing “save” at the command prompt in a game running in the IDE. You’ll get this:

The reason save is disabled in the IDE is because the IDE is designed for creating a game and since saves are not compatible with different versions of the same game, implementing it here would be mostly useless. You can test save by using the “release” option to create a game file and then test save in the standalone interpreter of your choice.

If you want to alter the way save works, you’ll need to be more specific. (Edit: Oops, Erik already said that too.)

What they all said: saving and restoring is a standard feature that is put into your released game by default.

But that’s not true, is it? I certainly hope it’s not true, because being able to disable or change the save-command in my game is essential to my current project. Are there any interpreters that allow out-of-game saving?

This depends on the IDE, though. I believe saving does work in the Linux IDE (but I may be wrong and cannot test it right now).

It is true that the actual save is done by the interpreter/Glk library, but the Inform library provides an interface to that. I.e., it determines when the save will happen, the context (e.g., that the user will be prompted for a file, rather than the game creating one), and also monitors the interpreters response to provide feedback. That’s probably all you would want to mess with in any case.

This depends on the IDE, though. I believe saving does work in the Linux IDE (but I may be wrong and cannot test it right now).
Yeah, save is legal in the Mac IDE too.


Windows Frotz does, right? There are menu options for save/restore? Or do they fake typing “SAVE” on the command line? (I know there are menu options for undo that work out-of-game.)

iPhone Frotz does an out-of-game save whenever you quit the app, of course.

Windows Frotz fakes typing “SAVE”.

I’ve just added out-of-game saving and restoring to Bocfel, but doing so has an inherent problem: When @restore is successful, the program counter is set to the branch/store part of the @save instruction that originally created the save (and then a branch or store occurs). However, when doing an out-of-game save, the program counter is not at a @save, but rather at an @aread (or wherever you decide to hook in the saving); so a normal @restore of such a file would try to branch/store, which is of course problematic, because the program counter is at the beginning of @aread.

Thus the out-of-game save must be restored by the out-of-game restore, and not mixed with in-game stuff (and vice versa). Such out-of-game saves should consequently be used only in the direst of circumstances. I could have the restore functions detect what kind of save file it is and react accordingly so they could be mixed at will; but I’d rather not encourage such dastardly behavior, mainly because out-of-game saves are not Quetzal-compatible.

The buzzing of the hornets is more than I had hopped for :exclamation: But thanks all.

You were all right (correct) in your assessment of I7 and how the Save, etc commands work. My only question (a bit hypothetical) is why does no one explains that - or am I a bit thick in the head?

I bet it’s worth adding a flag to the Quetzal standard to support this, since it is a meaningfully common case.

I think that’s a good idea. As far as I can tell, though, the save file will have to have a new FORM type, because any interpreters that don’t understand out-of-game saves would not know how to check the new flag (or new chunk type) to see whether they can load the file. A new FORM type will automatically cause these interpreters to fail to load the save file.

How I’ve approached it is as follows: Quetzal 1.4 is used in its entirety with two changes:

  • The IFF format type is BFMS (modifies §2.1)
  • The PC must be set to the first byte of an instruction (modifies §5.8)

I’ve flagged my implementation as experimental, so I have no problems changing code to adapt to an actual standard, if one emerges. I’d be happy to hear any other interpreter authors’ thoughts on this.

The point they were trying to make is that no one explains it because it doesn’t need to be explained, except for those writing interpreters and development tools. This is something that is already provided for you. Unless you’re trying to do something “out of the ordinary” with the SAVE functionality, there’s no reason that you shouldn’t take advantage of the fact that it’s just there and it just works. (Usually.)

They digressed into a discussion that would be more appropriate over in the tools and addons forum.

Geeks and their toys, eh? :slight_smile: