Okay, this is going to sound weird. Please just trust me.
Let’s say I am running a terminal-based interpreter on a Linux.
Now, let’s say (for some strange reason), that I need to receive commands and send the current terminal screen from/to another system. A user is not directly interacting with the terminal.
Is there a way to pipe in commands, and receive the output (hopefully with any banners) so this other system can effectively play the parser game?
If you’re trying to pipe commands in and text out, there are “dumb” or “cheap” versions of a lot of interpreters (dumbfrotz, cheapglulxe) designed for exactly this purpose; a lot of interpreters nowadays use Glk as a standard for cross-platform text I/O, and there’s a very basic Glk library called “cheapglk” which ignores all fancy windows and formatting and such and just uses stdin and stdout. For example, I hooked cheapglulxe up to Facebook Messenger at one point to play The Wand with people on another continent. You just send commands to stdin and see results on stdout and pipe it to whatever you want.
If you want to capture things like status bars and formatting, you’ll have to do a bit more work, since then the “send plain text in, get plain text out” model of Unix pipes stops working. But RemGlk/GlkOte is another Glk library which makes an interpreter input and output everything in JSON, which you can then parse and present however you like.
I’m running Frotz through a child_process module in Node.js right now, but the output has a bunch of control characters. I’m finding myself pouring over documentation for ECMA standards, and having a rough time.
I am absolutely checking this out next. Right now, I’m giving it the ol’ college try to see if I could somehow convert these control characters into a series of HTML tags, but it’s really rough.
If this absolutely destroys me, then I might skip the whole tags thing, and just use a terp that is “cheap”, as you propose.
emglken is published as a Node package and runs Z-Code (and other formats) in a “cheapglk” style mode. If you switched to it you’d probably solve the control characters issue. It also has a RemGlk mode. And you can load it as a module in order to directly receive its RemGlk output if that’s what you’d want.
Excellent!! I’m still learning about Glk, and couldn’t figure out from previous docs what game file types were supported, but I will happily change out my terminal-reader for this module!
Hey, uh… I feel like I’m completely missing something here, but are there docs available for this, or for similar systems that this might be based on…?
I’m looking through the source code on the repo (and the connected/related modules/repos) and there are explanations of what these modules are, but not a whole lot on how they can be used.
I could probably figure it out after a week of studying the source code, but there’s a chance that I poke the wrong stuff and destabilize it without realizing what’s off-limits and what’s meant to be exposed to rest of the node server.
EDIT: I’m mostly trying to figure out how something like this could be done:
const emglken = require("emglken");
const gameProcess = emglken.run("game/path/here");
gameProcess.on('output', (data) => {
// Do stuff with the JSON output
});
gameProcess.sendPlayerInput('get lamp');
Assuming this is a node module, as it’s on npm.
If it’s run-from-terminal-only, then I’ll incorporate it with the process wrapper I’ve made during my previous experiment.
If you make any progress with this I would be interested in using it. I am also willing to help. I have some js code working that spawns a glulxe process and provides an API. I know that creating a version of GlkOte would be so much more elegant.