Hey borg … maybe … can you give me a particularly egregious example (story with loads) and I will test it out as is?
I noticed the menu of etude completely fails a nice render.
Can you post a screenshot from etude?
1 Like
Do you mean the MORE? This is added when frotz thinks you have reached the end of the page, which of course doesn’t make sense in this context. You can start dfrotz with -m to disable this, but I saw a glitch just now that I tried it. An alternative is to use -h 99 (or some other large number) to print more lines in one go.
1 Like
Sorry, I actually have -m on the feature branch.
Running this with the bbcode branch currently produces this:
(You know i’m half tempted to set up a standalone Discourse instance for us to test this)
The period between items 5 and 6 is the glitch I mentioned earlier. I don’t understand what is happening at the bottom of the picture, is this the user input box?
1 Like
Correct, it would be good to defeat that.
Wild guess, this may have something to do with the period at the start of the first menu line. I pushed a commit that escapes all markdown special characters (as above, including period), maybe this will help.
1 Like
After trying and discarding a few different approaches, I figured out how to hijack Frotz’s input. Now with a single command line invocation it will load the game file, load the save file, process one command, save the game, and then exit. Return codes are not yet supported and output needs cleanup. If there is no save file found, this should tell Frotz to start a new game, but I’ve yet to implement that check.
Here’s some sample play with Zork 1:
$ ./dfrotz -B "look" -L zork1.qzl -R ./ zork1.z3
Using normal formatting.
Loading zork1.z3.
Ok.
command: look
>
West of House
You are standing in an open field west of a white house, with a boarded
front door.
There is a small mailbox here.
command: SAVE
>Ok.
$ ./dfrotz -B "open mailbox" -L zork1.qzl -R ./ zork1.z3
Using normal formatting.
Loading zork1.z3.
Ok.
command: open mailbox
>
Opening the small mailbox reveals a leaflet.
command: SAVE
>Ok.
$ ./dfrotz -B "take leaflet" -L zork1.qzl -R ./ zork1.z3
Using normal formatting.
Loading zork1.z3.
Ok.
command: take leaflet
>
Taken.
command: SAVE
>Ok.
$ ./dfrotz -B "north" -L zork1.qzl -R ./ zork1.z3
Using normal formatting.
Loading zork1.z3.
Ok.
command: north
>
North of House
You are facing the north side of a white house. There is no door here, and
all the windows are boarded up. To the north a narrow path winds through
the trees.
command: SAVE
>Ok.
3 Likes
Good work!! I’m right in the middle of some break-fix work but will return to this ASAP.
This was a side thread above, but I’ll update it anyway: RemGlk now has code to perform an autosave every turn.
Next I have to write the autorestore code, so that the autosave code is good for something…
1 Like
How did you get autosave to work? I tried initiating a save by calling z_save() and wound up with a corrupted Quetzal file (empty stack chunk among other abnormalities). I’m now doing a save by injecting a SAVE command after the player’s command is processed. Of course, this has the problem of not working with non-English games as you point out earlier (Discourse-Frotz).
Just a guess, but could this be due to the difference in encoding of the save and read instructions requiring an adjustment to the PC?
For ZVM I found that the regular save function would work for autosaving even though it would be at a non-@save opcode. I just had a quick look at Frotz’s code and didn’t see anything obvious that would explain why the saves weren’t correct. They don’t take many parameters, just using global state that must be correct or else it wouldn’t be able to play anything.
Though I did notice you’re not storing your stack in Quetzal’s format. Have you considered doing that? I found it made things quite a lot simpler.
I also tried quetzal_save() which gave the same broken file. I haven’t touched the Quetzal code since it first went into Frotz. Can you clarify?
Some interpreters store the call stack in the same format as Quetzal does, so that when it comes to saving and restoring all you have to do is duplicate the stack.
Huge update has gone live:
Thanks so much to @DavidG and @borg323 for their efforts here, especially @borg323 for his contribution adding a BBCode formatting mode to Frotz!! (NB don’t sweat him, this is an experimental feature specifically tailored to work with Discourse BBCode)
Thanks for the kind words, but calling me “one of the leading members of that community” is a bit of a stretch.
1 Like
Ok I’ll tone it down slightly. But really thanks a bunch !
1 Like
I’m revisiting the trouble with saves and started a new thread on it at Z-machine: parameters for @save
1 Like