Rich, suitability for MUDs?

[volundmush]

So I've been having a blast looking over the Rich package and trying out some things... and there is one use case which I am not sure if anyone has considered, but which I have been desperately seeking a solution like this one.

There is a genre of multiplayer games known as MUDs. These are RPG's played via a bastardized subset of the telnet protocol, and most such MUDs use ANSI standard colors or xterm256 colors to some extent.

This package is a GODSEND to almost any use-case one might want for sending colored, formatted fancy text to game clients, and even if the color features are turned off then the formatting tools like Table are still amazing.

There's only one area in which it doesn't quite handle the needs.

There is a MUD-specific telnet protocol known as MXP / Mud eXtension Protocol - this is a way for the server and client to send special commands and game-specific information back and forth by agreeing to send data in XML format instead of the normal stream. This DOESN'T look like the output generated by Console.export_html() mind you - it is, instead, a normal terminal/console byte stream with ANSI codes, where non-ANSI text has been html.escape()'d and XML elements can be present in the stream.

For instance:

ESC[31mThis text is red!ESC[0m And I say to &lt;thee&gt;: ESC[4z<send href="flee" hint="Run Away">&quot;Flee!&quot;</send>

I have been studying the guts of Rich, pondering the best way to add something like a Console.export_mxp() or Console.export_mud(). I think it may be quite doable, but would require some adjustments to the Style class to store the tag+attributes for a given style (which does not work the same way as a Link currently does) and another few methods to handle the alternate rendering.

What other difficulties might there be in enabling this approach?

[willmcgugan]

I had no idea people still played MUDs!

I think your assessment is correct. If you need to export custom xml tags you will need to extend the Style class. Bear in mind that Style is essentially immutable. If you modify a style after construction, it may break export. You will also need to define what happens when a style with an xml tag is combined with another style, so you will need to modify Style.__add__

Something to be aware of is that when the content is rendered, Rich will combine overlapping styles.

To illustrate this, if you print this string:

"[red]Hello [bold]world[/bold][/red]"

It is converted to a flat list of Segment instances without any nesting:

[Segment("Hello ", style="red"), Segment("world", style="bold red")]

So your xml tags may be duplicated if they contain style changes inside them. Not sure if that's a problem.

I can't think of any other potential gotchas...

[volundmush]

The 'overlapping' Styles only overlap for the purposes of markup when the string is being generated. I doubt very much that an MXP Style can be generated via text parsing this way so that isn't an issue. Also, technically that results in two different Style objects, each of which render() their text segments separately... in the event of MXP being 'split' this should result in two side-by-side links which do the same thing. That should be fine, as long as the XML remains properly formed.

[volundmush]

One more thing, but am writing from phone.

My project calla for the ability to parse different MU* player facing markups into Texts. This looks doable thanks to Text.assemble and .append, I just need to handle parsing and stare management to generate a stream of Tuple[str, Style]

The question is: is adding MXP support an acceptable addition to rich, if I make a PR? or am I better off using a fork or monkey patching?

Unsure if MUD features is within scope of Rich.

[willmcgugan]

Sounds like an interesting project, but it probably isn't something that belongs in Rich itself. But let me know if there is anything that would make it easier to extend.

[volundmush]

I will try a monkeypatch replacement of the Style and Console classes tonight to add MXP and see how it goes. Initial results this morning were pretty good.

The "mud markup" thing is external and requires no modifications to Rich - only the MXP data and rendering involve Rich's innards. Converting text like "&rthis&n text is red" into a Text just requires clever parsing and Text.assemble()

[volundmush]

Progress report for the night:

https://github.com/volundmush/mudstring-python
I was able to monkey-patch a MudStyle and MudConsole into place - check out the mudstring/init.py's install() method, and files under the patches folder!

Got some good results using the code in test.py

Tomorrow I will attempt to create a parser that can take a MUD/MUSH-style ANSI encoding and create a Text object with appropriate Styling sections. If THAT works? ... Then I win. -- assuming I can redirect the output of Console.print() while recording.

[volundmush]

I think you should take another look at https://github.com/volundmush/mudstring-python, @willmcgugan :)

This is kinda crude monkey-patching, but it's working pretty well for me.

Give it a look - see if it gives you any ideas about improvements that can be made to Rich!