These two things seem fairly easy. The second one already has an avenue for support. The -f option is for picking a scheme for marking up the output. It currently has ansi and irc modes. Adding more is very straightforward.

1 Like

So I can look at what is currently possible with existing formatting support but a nice first improvement on the Frotz side would be to provide option on command line to accept a load file and a next move string and return just the story text response whilst silently saving state back to the specified file aka ‘autosave’

The command then won’t vary time after time except for the user move text.

There will be no need to send any additional characters to perform load or save as that will be taken care of by the command line options.

And the silent option would hide the housekeeping status reporting.

In this mode the command can return to the command prompt as there is no need for session continuity beyond that provided by the save file. That might be behaviour also controlled by a switch.

So boiling this down:

  1. provide a switch to load the specified file and save it back immediately after the first move
  2. provide a switch to provide the first move ‘text’
  3. provide a switch to perform the load and save silently so it’s not included in any response
  4. provide switch to cause the command to end after one move if not already implemented by 1.

That should be fairly easy to unit test too?

I think only one new switch would be required to run Dumb Frotz like this. Testing would require a dummy wrapper script to present output and collect input at a terminal.

1 Like

That would clean up the code tremendously and could be leveraged by the restful-Frotz project too.

I will try to look at formatting over the next few days.

It isn’t very hard. Here is the merge request for the ansi mode: https://gitlab.com/DavidGriffith/frotz/-/merge_requests/148/diffs


Thanks. This may not need to be touched. I’m looking at processing ansi ascii text in the plugin.


I’ve pushed some improvements to a feature branch:

This does away with the silly suppression settings, introduces translation to BBCode to support formatting and colour, leverages the Dumb Frotz command line options better, obviates the need to write to a text stream and squashes a vulnerability.

This branch requires the official Discourse BBCode plugin to be installed.

I’m still experimenting with it.

I’ll probably merge after some significant trials.


Did you end up needing to alter Dumb Frotz itself?

Specifying an autosave, silencing the housekeeping, providing a first move and returning to the command prompt after one move all from command line would still be great.

I’ve only tested so far on two games and what I fear is supporting more variety. The way I’m suppressing the housekeeping feedback whilst not inadvertently deleting the content may get more tricky.

Doing as much of the housekeeping from the command line instead of the within a session avoids unnecessary output and streaming commands. Lack of streaming improves security too.

I’ll post an example.

Also FYI converting ANSI to BBCode isn’t as trivial as you might think but so far so good.

ANSI, not ASCII. :wink:

Actually is that true? ANSI should be a standard, right? But the codes coming from the terminal are actually for lower bit rate screens and a smaller set of colours.

I tried a Ruby library called ansi to handle the codes but it kept falling over. On inspection this because neither the output nor the library followed fully the same convention. Hence why I’m referring to the terminal output as something different. Is the terminal really true ANSI?

As a result of this I’m having to convert those codes to the higher bit version and making a judgement eg turning grey into white.

ASCII has some control characters but it’s extremely unlikely any of them are being used other than \n or \r, and ^[ or ESC. ANSI escape codes start with ^[. There is a formal standard and most of it is probably supported by most terminals, though some have limitations.

1 Like

Ok we can call it ANSI but it’s not a very good standard imho. The codes from terminal are not universal it appears and doesn’t seem to be much standard software library support to upscale. That said the terminal makers are clearly coping. Are they reinventing the wheel every time?

Worse BBCode isn’t really a standard at all.

We’ll have to see how well we can achieve a generalised scheme that works nicely across a broad range of games.

You see here’s another problem. I’m interpreting \e

A quote from your link:

“There are several encoding schemes, and unfortunately most terminals mix sequences from different schemes, so host software has to be able to deal with input sequences using any scheme”

Not the best.

^[ and \e are the same, just different representations for an 0x1B byte. Sorry.

1 Like

Those are clearly different haha. :). Different representations is the problem (plus 8-bit upscaling)

I’m not sure why you’re saying different representations is a problem, you just have to be aware people might describe them differently. What do you mean by upscaling?

Absolutely they are a problem. It leads to solutions that are unnecessarily complex.

Upscaling is converting the low res colour scheme to eg HTML.

And in my case two different ‘ANSI’ representations.


This kind of thing:

\e[37m —> \e[1;37m

The only (Ruby) ansi library I could find supports the latter scheme.

If you feed it the former codes it will fall over.

Requiring something like:

line.gsub!(/\e\[3.m/) {|substring| substring[0..1] + "0;" + substring [2..4]}


As a pre-process.

A solution is to extract the code and mappings from the library and put it into my code. That will allow me to simplify it considerably except:

  1. That’s incorporating too much logic in my solution? (What’s the point of having libraries again?)
  2. Demonstrates the issue with this not being a strong de facto standard (the only library called ‘ansi’ doesn’t seem to support some ‘ansi’ codes!)

I guess part of the problem here is that the standard has changed over time and didn’t consider the future. The games were written to these old standards and that hasn’t aged perfectly?

I don’t think I’m being too facetious? :slight_smile:

In any case it’s not worth dwelling on too much as this is fairly trivial. Mapping to BBCode successfully for a broad range of games might not be so simple though …

The ANSI mode is for emitting terminal control sequences. ANSI as a terminal protocol is sort of a mishmash of DEC VTxxx series terminals starting with VT100. It’s not intended to be parsed or manipulated by a wrapper script. I think what you want is some sort of interim markup that the wrapper can easily detect and replace with whatever is needed. That sort of thing can be easily added to Dumb Frotz as another parameter for the -f flag

1 Like

Those are not the same - the first one is normal white (usually a very light grey), the second one is high intensity white. Seems the library is very limited if it can’t handle the first.

I still think it will be a lot easier to add a new display mode to dumb frotz to output the formatting codes you need.