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:
- provide a switch to load the specified file and save it back immediately after the first move
- provide a switch to provide the first move ātextā
- provide a switch to perform the load and save silently so itās not included in any response
- 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
2 Likes
Thanks. This may not need to be touched. Iām looking at processing ansi ascii text in the plugin.
OK
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.
2 Likes
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. 
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.
Eg:
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]}
line.gsub!("\e[0;37m","\e[1;37m")
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:
- Thatās incorporating too much logic in my solution? (Whatās the point of having libraries again?)
- 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? 
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.
2 Likes