That’s me right there.
2 Likes
Clearly, you’re a spring chicken. Instead of a crusty geezer like myself. 
2 Likes
Just want to point out that Parchment has text completion (if your browser does), autosaves (for Zcode/Glulx), and you can upload a local file to play. Autosaves for the other formats would be nice, but it needs people with some more experience of how those interpreters work, it’s a different process than manual save/restore.
4 Likes
I feel like with TADS, it would be just a matter of the author implementing it for the game. Interpreter-based autosave runs the risk of breaking the game code, because a lot of it is handled on the game side of things.
ADRIFT and others might be different, though! 
Game based autosaves (probably) can’t capture the transcript, nor do they have access to all the interpreter variables. I don’t know what you mean by breaking the game code; if an autosave is done properly it will perfectly replicate the previous state. There’s a place for game based autosaves too, but they’re not comparable to interpreter autosaves.
2 Likes
I mean the game code is the place that opens the file browser, accepts a path string from the file browser, fetches the game state, and writes it to file. The interpreter just handled file I/O.
Also some parts of game state are not part of the save file by design, which is why modifying the save and load functions are sometimes necessary; the programmer must be able to account for this.
Ah, gotcha. Well that wouldn’t be involved for interpreter autosaves.
How would it handle transient data, which is explicitly not supposed to be in a save file or undo state? Save, Load, and Undo usually get modified in TADS to account for this.
An interpreter-managed autosave (or more detailed transcript, for that matter) does not have to look exactly like the save/restore functionality offered to the program running inside the virtual machine. If the latter intentionally omits some information, the former has to be different (more complete) to work. But this is just a difference in degree: the interpreter (and anything it relies on, e.g. Glk libraries) simply has to be programming in a way that it can gather all of its internal state, write it out to disk, and restore it later. The details are often fiddly and not standardized in the way “ordinary” saves usually are, but it’s not fundamentally different from “ordinary” save files, just more comprehensive and without handing the reigns to the game logic.
3 Likes
I don’t know the details of what state a TADS interpreter has, but in general an interpreter autosave will store everything. In theory the only way the game would be able to tell anything is different is by looking at the computer’s clock.
That’s why adding autosaves is a lot more complicated than just porting an interpreter, you really need to know all its innards.
1 Like
Oh okay so this works more like memory snapshots on the Nintendo Switch’s retro games…?
I suppose this all works without an HTML TADS implementation, as long as tracking saves and loads does not meaningfully contribute to game mechanics.
If/When audio gets implemented for TADS on parchment, I’ll be interested to know the autosave solution, because transient data often gets used to help the interpreter maintain a single background song/sound, or play the correct one according to the loaded game state. I suppose this could also be handled if the interpreter autosave also exported the current state of the interpreter’s audio buffer on its way to the audio-out pipe, so loading an autosave also loads the time position of all active audio tracks.
For graphics and audio there are different possibilities. Zarf’s GlkOte currently saves all the graphical operations and replays them, but when I add autosaves to AsyncGlk/RemGlk-Rs I’m intending to not store the operations, and instead just tell the game code to redraw the graphics. This could result in different graphics if there is randomness involved, which I think is an acceptable tradeoff. If the autorestored window was a different size the graphics would have to be redrawn anyway.
I don’t think there’s any online terp that currently supports both autosaves and audio, but my intention was that after an autosave it would hook into some of the same code that happens after a restore, and it would be up to the game code to detect that no audio is playing and start something if it wishes.
Edit: actually Glk doesn’t have any way to check if a sound is currently playing. Maybe it should store the currently playing sounds (with a timestamp?) and restart them? I haven’t thought about it much.
So it’s not strictly correct to say an autorestore will be completely indistinguishable to the game code. It’s more that the game state and interpreter state will be restored as identically as possible, and then the game will receive a window resize/redraw event.
2 Likes
This is usually done by comparing transient variables to those in the save file; if the transient data is also loaded, then I don’t think there’s a fallback for determining if something is wrong. Also, this method of loading is really non-standard for TADS, so there would be few (or no) games that are prepared to check for this.
Convoluted problem, for sure.
For TADS autosaving will have to store all the transient variables. But it will also store the interpreter’s own state which the game code can’t access. So for audio maybe it will need to store which audio files have been played.
That will be a problem for whoever implements TADS autosaves to work out!
1 Like
The funny part is I’m getting all the blow by blow updates on an in-depth interpreter discussion I don’t understand because Discourse treats this new topic as mine. No complaints, just amused. Please carry on.
4 Likes
This is the best you can do with the very detailed and stateful Glk display model, e.g., the game can (and must) query the size of graphics windows and do calculations with it to issue precise drawing commands, so it generally has to be prodded to re-do that after restoring. A game that just deals in (some approximation of) text in, text out really would be none the wiser. This doesn’t just matter for autosave/restore, it’s also why it’s hard to have a transcript that captures more than just player input and linear text output, and not (say) status line contents.
(You can change the notification status by clicking the bell icon. You could even mute it if you wanted!)
(Or we could split off these posts. Splits for everyone!)
2 Likes
Oh, I really don’t mind, just sincerely amused. Sorta makes me feel smarter than I really am to see this topic title listed in my profile summary.
3 Likes
This can be pulled from the transcript, I think. All audio and graphics operations are actually written to the transcript as text commands, but the styling just hides the textual parts of all that.
I think the only thing that isn’t sent to the transcript is creation of new output panes.
So if the transcript is replicated exactly how it was originally sent to the screen (and not just as the player sees it), then audio state and graphics come along for free.
The catch is the transcript that is saved to file (by players and testers) filters out this extra data (and I think this filtering is handled by game code).
From the other topic:
It couldn’t be easier now with the site generator! Parchment Site Generator
2 Likes