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.