Z-machine interpreter that allows piping in and out?

I am working on an experiment where I would like to feed input to a z-machine interpreter from an external source, and likewise pipe the output back into that external source. From what I can tell, the popular interpreters don’t support this – they assume there’s a human looking at a screen.

I can manually copy–paste, but this takes a lot of effort. Do you happen to know of Linux interpreters that support this odd requirement?

(It should be fairly easy for them to – all it takes is that the interpreter not tries to do anything fancy, and just reads from/writes to standard in and standard out in a console.)

Actually, I solved my own problem. I found fweep which is just about as minimal as it needs to be. It did not compile on my system, but a few small fixes handled that.

However, it limited output to console size which is undesirable for my use-case and the flag to set console size was unimplemented, so I finished the implementation of that.

I also added a new flag to terminate lines before asking for user input, for easier use in line-buffered pipes.

The diff of my changes are linked downthread. (The diff previously embedded in this comment is outdated and contains a couple of new bugs I introduced.)

Good old command-line frotz (that is the interpreter I still prefer to use when playing any Z-machine games), probably available in most linux distributions, can do this. There is some flags you might want to add to improve the experience iirc.

Used it a long time ago to test my code using a perl-script that sent input to frotz and then looked for expected text in the output.

2 Likes

Thanks. I looked at frotz briefly but didn’t manage to get it to play in “dumb terminal” mode. I may have missed something.

Clever idea to test the game with Perl. I am also using a Perl script to drive the game, but for different purposes.

You can also link Bocfel to Cheapglk, or RemGlk if you want formatting or the status window.

1 Like

This is exactly the intended use case for dumbfrotz, a Z-machine interpreter that does everything through stdin and stdout and ignores any fancy formatting. We use it extensively for regression-testing the Dialog compiler: pipe a list of commands in, diff the output against what’s expected, and throw up an error if there are any changes.

1 Like

Yes, I keep both of these around. I use them constantly for various testing tasks. (Game testing, interpreter testing, and compiler testing.)

CheapGlk is the “as minimal as it needs to be” example. RemGlk is as minimal as it can while while encoding the entire screen state (including boldface, italics, fixed-width, and the status bar contents) into a JSON message. This was great for, say, the Discord bot I mentioned in a recent thread.

2 Likes

Nice. That sounds like it could have worked for my needs, too. I especially like the idea of autosaving – I currently issue an explicit save command every turn, and restore at startup if a save file exists.

I ended up making a couple more minor tweaks to fweep, as detailed in the draft of the article I’m writing.

1 Like

Curious now – what’s the difference between building Bocfel with GLK= (i.e. a non-glk build) and linking it to cheapglk?

(Fweep appears to not run all the z-machine 8 games I’m testing it on, so I’m starting to investigate alternatives.)

The non-Glk build uses terminal-window codes for boldface, etc.

1 Like

I vaguely remember having to find every occurrence of inline and change it to static inline before it would compile under Cygwin64.

1 Like