Mudlet - Forum

Hello, i'm testing a code in my mudlib where i use \r character and certains escape sequences for up cursor any number of lines.

when i try write "test\ta" outputs in mudlet "testa" insted of "aest".

Mudlet don't support ANSI Escape sequences?

Thank you very much!

Yes, Mudlet doesn't support the fine terminal/vt control codes (http://www.mail-archive.com/mudlet-make ... 02869.html).

Humm, speaking as a player of a MUD (wotmud.org:2222) that uses the deleting backspace to erase and draw a single new character in the same place (to indicate a running action that takes time to complete: "bash"ing an opponent; using the "One Power" e.g. Magic; etc.) the mess that not handling THAT terminal/vt control code makes of the screen is unfortunate. It does work if one is using a Telnet client and given that MUDLET is supposed to be providing a considerable enhancement over using THAT, a fuller consideration of what codes should be supported might be worth a thought or two.

However, other clients also can fall down for this particular code anyhow - TinTin++ had issues with it the last time I used it...

First, I have to say I'm not 100% behind the decision to abandon original telnet functionality. However, given how things are, you guys have consistently given sub-standard answers to people looking for help in this regard, especially since these codes CAN be handled within Mudlet, the person simply has to catch these codes and provide the necessary instructions so as to handle them.

You can either capture the control code with a trigger, such as triggering off of \t or \a for tabs and bells. Some others are likely to be captured via the sysTelnetEvent. If you think your game is sending unsupported Telnet commands, but don't know what they are exactly, you can do this, to have them displayed when they occur, so then you can start figuring out what they should be and how to handle them. For tabs specifically, I have a trigger that I have been using for a while (and will use until tab support is implemented). Use this as the pattern: ^.*(\t).* and this as the code:

@ JorMox
Sorry, but you are confusing a few things here. VT100 control codes have nothing to do with the telnet protocol or ASCII characters like \t and \a.

@all
VT100 control codes are technically incompatible with modern MUD clients.

I'm not going to pretend that I know what I'm doing when it comes to VT100 anything, but the original post referenced \t and \r in conjunction with ANSI codes (which seem to be co-referenced when talking about VT100 when I looked it up). Regardless, the first poster looked like someone running a MUD, rather than someone playing one, so I don't know how I could have helped him anyway. But the second guy, SlySven, mentioned his MUD using a deleting backspace to write characters in the same space, and that seems like it would have to be something that, while you guys aren't handling it, would be caught by the sysTelnetEvent, allowing a script to be written to handle it instead. After all, deleting the last character in a line is really pretty simple code wise.

Heiko wrote: ↑

Tue Jun 11, 2013 7:15 am

@all
VT100 control codes are technically incompatible with modern MUD clients.

Uhm... I would love to hear some details here, as we're happily using VT100 control codes in our MUD and it works flawlessly - when using other clients that work happily with VT100 codes, including plain telnet.

I may be missing something about what do you mean with "modern MUD clients".

Telnet can't do triggers though... how would those work? Even going beyond the basic "see a line, do a thing" would be hard when any line on the screen can suddenly change under you.

Vadi wrote: ↑

Thu Feb 08, 2018 5:46 am

Telnet can't do triggers though... how would those work? Even going beyond the basic "see a line, do a thing" would be hard when any line on the screen can suddenly change under you.

I still don't really understand why this decision was made, especially given the specific examples of current games that use these control codes, making the game notably less functional in Mudlet than in any client that accommodates them. Yes, it is possible to use such codes to go back and change previous lines of text, and if you wanted to ensure that the trigger system accounted for such changes, it could be rather problematic. On the other hand, you could simply assert that triggers only work on text as it originally comes from the game, so the trigger engine processes each line one time, as it arrives, rather than going back and processing it again when a change is made to it. By doing that, you would have EXACTLY as much functionality with triggers as you have now in such games, but you would also have the inclusion of the features that those games take advantage of to create a more dynamic viewing experience, and pointedly, you don't run into the issue that SlySven pointed out where the control codes are ignored, but the new characters continue to be printed, creating a bunch of visual junk that no one wants to see, and that Mudlet has no method to process effectively.

I will always be of the opinion that any MUD client should be Telnet+, as that is what the core of these games were built around. Taking features away from Telnet is, in my view, nonsensical, even when it feels like some of the features of Telnet are outdated.

Sure, we should shift the problem later down the road ("Mudlet doesn't support it" to "triggers don't support it"). What you say makes sense - if someone wants to have a crack at this, I'd be interested to see how it looks.