I'm working on a new client, which I hope will mark a significant step forward for muds when it's done. But I could do with a little feedback on the features people need - in particular, on open extensions to Telnet that some games are using.

Which of the following are in (common) use?

MXP - mud extension protocol
MCP - mud client protocol
MCCP - mud client compression protocol
ZMP - zenith mud protocol
MSP - mud sound protocol
... - any others I've missed?
... - anything useful these don't cover?

ZMP seems to have the best implementation, but MXP seems to be the most widely used. Any information or opinions appreciated.

If you implement MXP then you also want to implement MCCP to reduce amount of content that needs to be sent to client. Also MSP is supported by MXP.

To be honest I'm not that bothered about MCCP. Only when I had to use a 2400 baud modem have I ever found the amount of data sent by a mud to exceed my bandwidth.

Are you planning to market your client directly to the players, or are you hoping that muds will recommend your client to their players as well?

If the latter, you might want to consider that some muds pay based on the amount of bandwidth they use, and therefore might be less inclined to promote your client if it increases their hosting fees compared to other clients that do support MCCP. Even if the additional cost is neglegable, the very fact that it could increase their hosting costs at all may reduce their inclination to promote your product to their players.

I expect that even of the muds that do pay for bandwidth, few of them implement MCCP. If anybody has any evidence rather than conjecture to suggest otherwise, I'd like to see it. In an ideal world I'd implement each of these protocols, but this isn't an ideal world and I don't have infinite time.

TMC has a search option for 'MCCP', and lists 252 muds, including several of the larger ones.

Implementing MXP compared to MCCP is much tougher. Usually you just use an already made compression library like zLib. So for an experienced programmer it requires maybe 30-60 minutes to add support for MCCP.

Some MUDs like Aardwolf encourages people to use compression by giving bonus experience points if it is enabled. So few serious players there would use a client that doesn't support MCCP.

Ok, now we're getting somewhere. That seems to be about 1 in 6, more than MXP and MSP combined. Still, it's a low priority to me at the moment. Implementing MCCP (or indeed any such protocol) on the client side will actually be non-trivial for me, so given that it imparts little actual change to the user experience it's not going to take precedence. I'm biased more towards things that affect the interface at the moment.

Yeah. MXP implimentation has issues. Not the least of which being a) its hard to make a window that supports HTML type elements, like pictures, but still supports text positioning. The client I use didn't bother supporting *either*, since both where a pain to do. and b) if you follow specs, the muds might not, because sadly, zMud *doesn't* follow specs. At least with dealing with the translation of < and > to &lt and &gt. This causes a major pain if you decide to impliment error checking or capture of MXP tags. How do you tell if the stuff between < and > was *supposed* to be a tag, but something it wrong with it, or its just text, especially if the mud uses its own extensions to the protocol, which should logically be ignored, or its an element that is being sent in the tag? Simple, you can't. So you have two choices, a) delete the presumed tag and generate an error response through what ever system you have set up for that, or b) display it anyway, as though it was &ltblah&gt, which the specifications clearly indicate is actually wrong.

Nick Gammon, the creator of Mushclient and Zugg, who makes zMud have had a long conversation about this issue, which left off with Zugg saying, "Yeah, its probably a good idea to make sure everyone knows exactly what the standard behaviour *should* be in such cases.", then not doing anything at all to make the specifications clear about it, or changing zMud... The result is that *some* muds incorrectly impliment conversion, and in clients that treat bad or possible bad tags as errors, not plain text, those muds don't display right. Its just like HTML in IE vs. everyone else. Lets not follow a defined standard, lets just let the client *guess* what you really intended to have happen and hope the result isn't too screwed up in which ever browser you use... That worked so well for HTML after all that no browser in existence can or does display the test pages from the official specs properly. lol

Anyway. You need to be careful of these little annoyances. And in this case, doing it in a way that is technically correct will get you yelled at by mud developers, who are not following spec, but insist that just because everyone there uses zMud and zMud lets you funnel the bad parts into the box with the good ones, there is no good reason for "them" to fix the fact that you're being shipped a box of broken parts. Its quite annoying trying to talk to those people.

The rendering stuff shouldn't be too difficult for me, so that's ok.

Anybody got any stats, or even just vague observations, on which aspects of MXP are in common use? I'm probably going to try and cover the trivial text formatting and inline images first, followed by the sound and music tags (along with an MSP implementation).

VT100 support is always nice, though seemingly it's too difficult for most mud client developers to implement.

VT100, like most of the VT class protocols is simply ANSI with a few things stripped out (or rather ANSI is VT100 with things added). Technically, if a client supports ANSI, it should also, when asked, inform the server that yes, it does also support VT100. The problem is usually that ANSI support isn't always 100% complete in clients either, so neither actually works as its supposed to. However, unlike ANSI, VT100 users tend to "expect" all those codes to do something.

Believe me, I have been using clients with ANSI and VT100 in them since all the way back when BBSs where the rage. ANSI should simply extend VT100, not be completely different, but about 5%? of the codes in both are "never" used on most muds, so its become all too common for people to take their client specifications from the muds implimentation, not from the actual official specifications for the protocols, which is why people think that ANSI doesn't support VT100 functions. The later is usually taken from implimentations that do support those functions, but usually still not from the spec sheets. Over the last year or so the client I use has had to add in specifications for at least 4-5 things that where in the specs, but not supported, because they are not common to all muds and so the developer didn't think he "needed" them.

You might want to post to the zMUD Developers forum on and explain what you find to be problematic with MXP. Keep in mind that zMUD is no longer updated. Instead Zuggsoft is developing a new more modern MUD client, cMUD. So now is definitely a good time to post suggestions.

Some mud and client developers are trying to turn VT100 into a meaningless term as well. It's easier to redefine the meaning of a protocol and claiming you support it than actually implementing it.

The closest thing to a standard nowadays is the linux terminal emulation standard:



Compatibility is easiest to test with applications like Midnight commander.

Been there, done that. Like I said, this discussion has gone on between Zugg and Nick Gammon, over this already. Mushclient is Nick's client and while its designed to only support scrolled text (i.e., no text positioning) and doesn't allow things like inline images, it takes the literal interpretation of the MXP spec and assumes that something like <A Scary Road> **should** be an error, so won't display it, but instead attempts to generate an error response through the script systems callbacks for MXP tags. Nick's argument, and I tend to agree with him, is that a) without clearer specification, its entirely up to the developer if they fall through or not and display and b) it really doesn't make any sense to do it that way though, since something like <img="abc'> would also pass through, when it should, in a client that supports debug features, generate an error, instead of displaying the invalid data.

I tend to agree. How do you debug MXP tags using script callbacks if 90% of the "tags" are plain text? You can't, unless you either don't allow debugging, or you generate an error for "every" apparent case. If your mud used <> for room titles, but didn't escape them properly, then trying to debug MXP on it would produce an error **every** room. Its just absurd, even if the display behavour is useful. But adding my input to the argument isn't likely change things.

Yes, having looked into it tonight, MXP is just a completely unwieldy protocol to implement. MCCP simply wraps everything else, ZMP works with subnegotiation data, and both MSP and MCP only handle whole lines, all of which fit nicely alongside the telnet/ansi handling. Unfortunately MXP seems to want to work inline, across arbitrary amounts of data, with several different state combinations, and little guidance on how to handle tags that don't parse correctly.

I mean, parsing a line like "<!ELEMENT RName '<FONT COLOR=Red><B>' FLAG="RoomName">" is pretty horrific. That would be invalid XML, for good reason.

It's tempting to leave support for MXP out. At least it doesn't seem valid to stretch a tag across a new line so it might be ok to process it in the per-line handler.

Actually, this raises another interesting question. Sometimes you get sent data without a newline, such as a prompt. You need to display that verbatim on the screen before you receive a newline, because that newline may not be forthcoming. On the other hand, protocols like MSP and MXP work best when handled a whole line at a time, but that means withholding the display of the line until you get a newline. MSP you can at least spot by the "!!" prefix to the line, but with MXP, I suppose it's guesswork.

Obviously you can get around this by assuming that the MUD sends data in contiguous blocks and having some sort of hacky state that waits for a newline and, if it hasn't received it within a certain length of time, assumes it's a prompt. But that's just plain wrong, really.

Ouch. I wish people had given their extension protocols a bit more thought.

I think you can actually write out the text as soon as you have fully parsed it. What line tags are about is security. Usually you have a security level for the entire line, and as soon as a new line starts it reverts back to default security.

MUDs should really use </> entities for their prompts to make it clear that it isn't a tag. So it isn't really an issue with MXP, but an issue of poor implementation on MUDs.

Something that needs to be kept in mind here is that zMUD is quite good at error recovery. It will sometimes accept sloppy syntax of MXP and try, to its best efforts, make an acceptable parse of it. The bad thing about this is that MUDs who test their implementation towards zMUD might not detect obvious errors that dont quite follow the standard.

The problem is that 'fully parsed' is a non-trivial state to spot, especially given that the parsing has to be done on the same level as all the telnet and ANSI parsing. When I spot a '<' character in a mode that allows MXP tags, I need to enter a 'might be an MXP tag' state, start buffering text, and can only emit that text once I have parsed a complete tag, which is non-trivial.

The line modes aren't the issue here.

It's ok saying MUD's 'should' use those entitles, but it's quite clear from several MXP examples on the spec page that they don't have to - look at the 'start' and 'end' entity examples - and that open and closed brackets take on different meaning depending on their position, which makes parsing harder. Unfortunately this also no means that no complying client can assume that such brackets will be sent as entities. That's an issue with MXP. This means I can't just search for a closing bracket to terminate a tag, as I could in well-formed XML, hence the 'non-trivial' comment above.

And this means that if someone sends a prompt in open or secure mode like: "<hp 50 mv 150]" then your client has to make a guess as to whether that's an MXP tag that you have to wait to parse (as there is still a bit missing), or normal data to output to the MUD. Yes, while in your 'might be MXP' state you can keep checking the buffer and spot that 'hp' isn't a valid tag, but then do you emit the text, or do you report an invalid tag? And what if the user set part of a valid MXP tag in their prompt?

In fact, the whole protocol is a complete mess. Unclosed tags get closed at the end of the line... unless they were sent in secure mode... and who knows whether you close them or not when open mode is locked across multiple lines since one sentence suggests you do and one suggests you don't. It's almost a joke.

Umm.. ff f9, also known as IAC EOR/GA.

Its a go-ahead code sent by some muds, and apparently implimented in the TMI-2 mudmail editor, though not on prompts... Some muds support it, others don't. Mushclient has a feature you can turn on for, "Convert IAC EOR/GA to newline.", which allows prompts to function as though they actually had a /n in them, but it only works *if* the prompt has IAC EOR/GA at its end. In any case, if the mud sends and the client recognized this, then its trivial to determine if the line is a prompt or not.

But yeah, lots of screwy stuff has been added to Mushclient to get around this stuff, including the fact that while a line will "display" as its recieved (most never exceed the packet size), triggers that attempt to look at the line and figure out what is going on only fire "after" the newline, hence converting the IAC EOR/GA to a newline to make the prompt trigger immediately. If you can't, then you get something like this in script:

[code] OnPluginPacketRecieved () {
if stored packet then
retrieve packet
add new packet to old packet
onpluginpacketrecieved = false
exit function;

'do some regular expression checking.
if complete prompt then
do some stuff to it and put in changed_line
world.simulate changed_line
else if no newline
store packet
onpluginpacketrecieved = false
else
on pluginpacketrecieved = true ' Let the client handle it.
}[/quote]

You can do some crazy things with Mushclient, some of it just to work around silly BS like having no control over what the mud is actually sending you, substituting words and things into the packet (since you can't do that after a line already exists and a newline has scrolled it), etc. Substitution is a bit easier in some, but most of those use some other sort of system to handle triggers, like maybe keeping a list of triggers that it appears *may* match the line, and throwing out the ones that don't as more data arrives?? Who knows...

But yeah, the MXP spec is rather screwy in some places.. Though, in the case of that element thing, what is means is that a line containing the element will substitute the
[code] "<FONT COLOR=Red><B>"[/quote]

part for it, so the code you get is like:

[code] RName My Big Room<\b>

<FONT COLOR=Red><B>My Big Room<\b>[/quote]

XML includes a way to add element replacement like that as well, but what people forget is that this isn't XML, its HTML with some goofy things tacked on, and in the spirit of HTML the behaviour of when and if certain attributes get terminated differs based on *what* those things are. Something like a color, one would presume, would continue to be present until changed, other things are line by line based. Unfortunately, like HTML, zMud liked to try to guess what was intended when tags where mangled. A condition that has resulted, in the browser world, in 3-4 different clients, none of which actually correctly follow the W3C specs or can display their test page, and where the page design standards end up instead being set by the quircks and idiocies of the most popular browser.

I don't think anybody here is forgetting that MXP isn't XML, just lamenting the fact that Zugg knew of XML's existence and yet still chose to ignore some of the most important parts, before then writing an inconsistent spec to describe his creation.

My current plan is to buffer data as it comes in, and flush it after every new line, every ANSI sequence, and the end of every block of data read from the network. The last one isn't technically correct but is necessary since few muds I'm aware of will send a Go-Ahead for their prompts by default. I'll then attempt to process MXP tags in the buffer before committing the results to the output window.

Or maybe I'll just abandon MXP support altogether if that doesn't work out well enough! ZMP is easier to implement and to extend to cover everything that MXP does.

Yes, in fact one major aim of my client will be to showcase some new features in my own servers. However I will gain more traction with the client if it supports other MUDs and any of their advanced features, and if the new features in question are based on exploiting well-known standards that other games can implement. That way hopefully the whole genre can progress together.

It should be possible to create a special log syntax that adds a time stamp to each text and MSP message. That way you could play back a log file and edit it quite easily as well.

I ran a MMC (Mud Master Chat) server script for 3 months once and precisely zero people connected. I doubt it'll work unless you enable it by default, which in turn will annoy a lot of people who don't like phone home software.

How to negotiate character mode is a well kept secret =]

Not exactly what I was talking about. HTML logging sounds like a great idea, and isn't overly difficult to implement, but neither Firefox nor IE is capable of displaying log files of several megabytes.

The joys of over functionality =]

I brain stormed for a minute and wrote a 5 line script in tintin that creates a log file that plays back text in the order of appearance with milli second precision. As usual it's too difficult for most people to thinker up themselves, and once you start adding redundant functionality you end up with so much of it that nobody can find what they're looking for.

Posted a suggestion about a log intercept in Mushclient and got, "Well, you can just have a trigger and an alias that do a '*' match and uses 'keep evaluating'." Only problem is, the client has three text streams - 1. Server output, 2. User input, 3. Notes/Colornotes produced by script, the later which you can't "trap" that way. Haven't heard a response back about that later issue yet, but... as of last night there was also this announcement:



Mushclient is now freeware and as soon as Nick can rip out the code for user registration and the remains of the original proprietary code for spell checking, its going to also go open source. Any "missing" features at that point can be integrated into the client by anyone willing to spend the time to code it, including replacing the existing custom output window with one that supports correct inlining of MXP objects and text positioning commands (not sure how you really mix those though..), correct sound playback support (we have something, but its script run and flaky), parallel threads to download files (currently only available in the zChat protocol support, not for things like images/files), etc.

If its currently incomplete, partly broken or missing, it will now be possible to build a new version that does it.

I wouldn't get your hopes up. Talking about features is fun, but few people have the required skills to add a wide range of functionality. And those that do generally have better things to do with their time.

Bah.. We are talking about people that have coded mappers for Battletech based muds for it, do lots of complex stuff with the Lua scripting, done code work on path mapping for a mapper we don't have yet and even, in my case, experimented with docking windows with the main client window (and that was before you could "access" the main frame handle from the script or retrieve size/position data from it). I have every reason to believe that people "will" work on new features and changes for it from among the existing users.

But yeah. That is one potential problem.