[Kylotan]

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.

[Aeran]

Originally Posted by (Kylotan @ Mar. 19 2007,09:51) 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.

[Kylotan]

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.

[KaVir]

Originally Posted by (Kylotan @ Mar. 19 2007,9:15) 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.

[Kylotan]

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.

[KaVir]

Originally Posted by (Kylotan @ Mar. 20 2007,11:33) 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.

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

[Aeran]

Originally Posted by (Kylotan @ Mar. 20 2007,05:33) 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.

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.

[Kylotan]

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.

[shadowfyr]

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.

[Kylotan]

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).

[scandum]

Originally Posted by (Kylotan @ Mar. 19 2007,09:51) 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.

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

[shadowfyr]

Well, I am hardly an expert on what is in common use. The first few places I tried that had MXP used only one feature - the ability to set up clickable links for commands. They didn't even use the extended colors, but stuck with ANSI. It looked ugly with all the underlines for the links, the color scheme was horrible for the rooms, they had silly things like coloring a flower red, when the description said it was violet, since of course it wouldn't make sense to.... I don't know, *use* the MXP color code for violet? Not sure if they used the image support, since I ran away screaming after about five minutes. lol

But seriously, I get the sense that most of the stuff that gets supported is the simpler, but fundamentally lamer, features, like text links. The rest is either completely ignored to maintain general compatibility with older ANSI clients (why I have no clue...). Some do specifically use sound and images though. Its going to vary a lot from mud to mud. Some will use images and sound, some will only support text links, a very few probably use what I would have thought to be the most useful and least visually invasive (and I mean even *in comparison* to the high contrast ANSI they use instead) color system. I mean, which would you rather look at, a set of soft, well blended, colors, like 2-3 shades of forest green for the details in a druid guild, or some combination of clashing colors in ANSI that will burn your eyeballs out at 2 AM and do nothing to enhance the sense of where you are? Just saying...

Still, as I said, I am hardly an expert on what people "are" using. But I have been told by more than a few people that there is a fear, hatred or just plain disinterest in even trying to use color support.

[shadowfyr]

Originally Posted by (scandum @ Mar. 21 2007,6:17) 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.

[Aeran]

Originally Posted by (shadowfyr @ Mar. 21 2007,4:17) 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.

You might want to post to the zMUD Developers forum on www.zuggsoft.com 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.

[scandum]

Originally Posted by (shadowfyr @ Mar. 22 2007,2:57) 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.

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:

http://www.squarebox.co.uk/cgi-squar...onsole_codes.4

Compatibility is easiest to test with applications like Midnight commander.

[shadowfyr]

Originally Posted by (Aeran @ Mar. 23 2007,8:03) Originally Posted by (shadowfyr @ Mar. 21 2007,4:17) 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. You might want to post to the zMUD Developers forum on www.zuggsoft.com 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.

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.

[Kylotan]

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.

[Kylotan]

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.