[Z-MACHINE] Use of @read and @read_char at the same time

Are there any circumstances under which @read and @read_char would both be called during the same turn? I’m trying to nail down when a turn ends and when one begins from the perspective of the Z-machine. Both of these opcodes seem to mark the beginning of a turn, but I’m unclear if both could happen in the same turn. That could cause some problems with the bot wrapper enhancements I’m working on for Dumb Frotz.

Do you mean like in A Mind Forever Voyaging, where you type a command and it presents you with a Yes/No prompt that uses read_char?

>GO TO INTERFACE MODE
You are now in Interface Mode.
Do you want to see the List of Active Ports? (y/n) >

As a player, I’d count that as one turn regardless of what I answer.

When thinking in terms of bot wrappers, the turn ends when input begins. @read and @read_char are both opcodes that stop processing and wait for input. They can’t both happen.

(Timed input is a separate question, but that’s effectively a case of “input has arrived, it’s a clock tick.”)

For the Glk API, I made this an explicit rule – the game calls glk_select(). At that time, the turn ends and all requested inputs begin. A window can’t request both line-read and character-read at the same time, so it’s clear how to set up the bot layer.

In theory you could request character input in the status window and line input in the story window at the same time. But the Z-machine has no way to express this, so you don’t have to worry about it. A Glulx-compatible bot would.

The z-machine itself has no concept of a ‘turn’ at all. The closest would be that a turn is whenever the relevant status global is updated (in V1-3) games. V4-V8 games don’t necessary follow this pattern. What do need to use this for?

Thanks. Knowing this will simplify things greatly. I’ll just ignore the complications of timed input because the fundamentals of a dumb interface prohibit timed input from working correctly if at all.

It’s to make it easier to run a forum bot. The idea is that Dumb Frotz will run for a single turn, then save and exit. When when someone posts to the game thread, Dumb Frotz starts up again, loads the save, runs one turn, prints the results, then saves and exits again. I’ve identified a point in the core code where this stopping can happen: right when @read and @read_char are called – because they block until they get input from the player.

Cool. Sounds similar to issues I had to work through to separate my z-machine implementation into a code library, divorcing it from any particular front-end interpreter.

Keep in mind that the input operation itself won’t be part of a normal save state, i.e. text buffer, parse buffer, etc.