I’m new to parchment. I’m trying to locate documentation for it, and having a difficult time finding some. Specifically, I’d like to know what query parameters may be passed to parchment, when installed on a on a personal server. In addition to ‘story=’ for example.
Thank you for your help!
The only other query string options you can pass are defined here: parchment/src/common/launcher.ts at 5b53dc0a6ff729fdb50443dadf648045beee777f · curiousdannii/parchment · GitHub
Which is autoplay and do_vm_autosave.
More options can be defined in the HTML by setting parchment_options. parchment/src/common/options.ts at master · curiousdannii/parchment · GitHub
What are you wanting to change?
Hello sir. thank you for the help.
A couple of years ago I posted the following thread about creating a plex/netflix like front-end to an IF library:
Well, I’d finally got around to it, the core functionality is there and just adding some spit and polish.
Given an IF game file it’ll use babel to get the IFID, then query the IFDB to get any particulars on each game. The admin may override (or create) these details.
The user can then select one of these games (like you would a movie), and play it.
To play it then calls Parchment (single file edition), and that works great! But I thought to myself. How cool would be be to extract the save games from localStorage and store them to the DB so they can be loaded in from other browsers and locations? I put some stubbing in there (at the top), tried a few things, but haven’t had much luck just guessing so I thought I’d ask here.
Thank you for any advice.
Knowing very, very little about Parchment, and without yet trying anything significant. Since the Parchment wrapper I have knows what game is currently being played in the iFrame, I thought it could dip into localStorage and copy the game data from there into IndexedDB which would manage different save ‘slots’.
Then those slots would be replicated between the browser origin IndexedDB and the database I have. Then if the user would return either from the same origin or a new one the replicated copy would be compared and updated on the local IndexedDB.
Of course, my database would be aware of the times of each save (and which games), so a player could “resume” the most recent save, or load it from a different slot.
But I think this depends on a few things that I’d have to figure out, which may not be possible: I’d have be able to know the localStorage prefix and how they relate to each game (or be able to change the prefix). I’d have to be able to pre-load the requested save game into localStorage in the right place before Parchment executed. And I think I’d have to be able to block or usurp the current save process to not mix up where the save is going.
So there’s some experimenting I’d have to do and I thought I’d start out by looking what options are available via query parameter.
Well query strings are going to be totally useless for any of that! But you’re in luck in terms of general file system access, as the new version of Parchment from January makes that a lot easier. (Though I’m not sure if you’re using an up to date version of Parchment or not?)
The method Parchment uses to store files in localStorage is documented here; it’s up to version 2 now. There’s now a single source of truth for files in localStorage, the dialog_metadata key. Read that and you can know what all the files are as well as their dates.
But the ideal would be to make a new Dialog Provider. In the new Dialog system I’ve designed there can be multiple Providers to handle reading and writing files to different places. By default it uses one provider for downloaded files (the storyfile), one provider for persistent storage in localStorage, and another for temporary files in sessionStorage. In the future I’ll change persistent storage to use IndexedDB, and I also want to add the option to link to the player’s Dropbox, which would each be a new Provider. So you could write your own Provider to use your database. At the moment it’s not designed for plugins, so you’d just have to fork ProviderBasedBrowserDialog to include your new one.
That’s perfect! Thank you Dannii, that’ll be very helpful. That’s even better than query parameters! 
I really appreciate it.
Another question if you don’t mind. If version 1 autosaves are purged when using version 2, how does the version 2 autosave function behave now? I don’t see some equivalent landing in localStorage. Thanks again!
Parchment currently doesn’t have autosaves unfortunately.
I’m probably missing something conceptually. I may be confusing what ‘autosave’ is with the ability to just come back to the web page an pick up where you left off. I was running a copy of Parchment I think I’d downloaded probably about 2023, it could have been a fork that someone had added the ability to pick up where you left off.
Or perhaps it’s a feature of asyncglk that didn’t carry forward to Parchment?
I was just wondering how that worked because it seemed pretty slick for a web app. I just need to poke through the code more and get a better handle on it. Thanks again!
Oh. I think the light is coming on for me. There’s quite a few moving parts to Parchment and understanding what each of those parts does is key to the features.
So what I gather, just poking around the code, is that what I was referring to “pick up where you left off” is the ‘autosave’ feature, and it was lost in the most recent version because there was a technology switch that dropped Quixie, and Quixie had the autosave feature.
And at this point in development, the old Quixie-based autosave feature has not been redeveloped for the new architecture.
Autosaves require the cooperation of all layers of an IF interpreter: the virtual machine, the Glk library, and for web interpreters GlkOte as well. It was the change to RemGlk-rs that meant we don’t have autosaves yet. I’ll add support to RemGlk-rs in the future!
(And it’s Quixe not Quixie, though the latter does sound cuter!)
