21 Mar, 2012, Deimos wrote in the 1st comment:
Votes: 0
I've reviewed the specs for several of the most popular protocols, but would like to know which ones are "worthwhile" these days? I haven't been keeping up with the whole MUD standards fiasco, ATCP/GMCP/whatever.

I've already got a working Q method Telnet implementation, MCCP support, TTYPE, NAWS, ECHO, EOR, GA support, etc.

MXP is my current pet project (speaking of which, anyone know of a console Linux client with MXP support? tt++ fails in this regard), but was wondering if any others are "must haves" and why (e.g. what do they offer that necessitates their use).
25 Mar, 2012, David Haley wrote in the 2nd comment:
Votes: 0
I don't have a great answer to this other than to say that a protocol is worth implementing if it gets you something you want, and more importantly, actually has client support (or you are willing to write plugins to provide such support, for clients that support plugins in the first place).
25 Mar, 2012, Runter wrote in the 3rd comment:
Votes: 0
The lack of good or universal support for most protocols makes them all questionable if your intent is only adding sugar for certain clients. My preference is to retire support for any client that won't support the features I think I need to make the experience good. It's not always possible to build out two or more separate interfaces for different clients that support different things. And even if you do, you usually limit yourself in such a way that it must be friendly for someone with the lowest common denominator in terms of features. It's not a good situation imo as the standard of technology gets higher and higher in the real world… in mudville we haven't made much progress or leveraged technology that is ready right now that could make muds far more interesting.
25 Mar, 2012, Deimos wrote in the 4th comment:
Votes: 0
I guess mostly I'd like to know what players are currently looking for in a MUD. I have an MSDP implementation now, and put MXP on hold for the moment, because it was the simplest and easiest to understand/implement protocol which allows me to pass variables OOB. I'm just worried that client support is going to net me less potential players than if I use certain other protocols.

Also, do lots of players use MUD sounds when offered? I always thought of MSP as a nice-in-theory type of protocol, but would be interested in seeing any kind of stats on usage.
25 Mar, 2012, Deimos wrote in the 5th comment:
Votes: 0
Is it common practice to support multiple similar protocols (e.g. MSDP and GMCP), and use one or the other depending on client support?

If so, how would it be handled from a negotiation point of view? Send WILLs until getting a DO reply (probably in order of most to least desired)?
25 Mar, 2012, Tyche wrote in the 6th comment:
Votes: 0
Deimos said:
If so, how would it be handled from a negotiation point of view? Send WILLs until getting a DO reply (probably in order of most to least desired)?

I would negotiate the protocols in the order that I thought the were best supported by my server, after attempting some Telnet commands to determine if it's even productive to do further negotiations.
For example, if I supported MCP, Pueblo, MXP, and VTxxx best in that order, I probably would skip all negotiations if the client was totally unresponsive to telnet (like GMud),
or just MCP if I determined through TTYPE that it was Mushclient. I might send a message and disconnect the client if I determined it was Zmud. And so on.
25 Mar, 2012, Deimos wrote in the 7th comment:
Votes: 0
Wow. I wasn't even aware that there were still clients in use that couldn't handle basic Telnet negotiation. Seems like that's a pretty severe deficiency. I'm inclined to just pretend that they don't exist and operate under the assumption that all clients are at least capable of negotiations, even if they support nothing I'm interested in negotiating…
25 Mar, 2012, Ssolvarain wrote in the 8th comment:
Votes: 0
GMUD will never die.
25 Mar, 2012, Runter wrote in the 9th comment:
Votes: 0
25 Mar, 2012, Scandum wrote in the 10th comment:
Votes: 0
Deimos said:
MXP is my current pet project (speaking of which, anyone know of a console Linux client with MXP support? tt++ fails in this regard), but was wondering if any others are "must haves" and why (e.g. what do they offer that necessitates their use).


None exist as you'd need to write a virtual terminal to handle clickable links in a console client, with clickable links appearing to be the main use of MXP nowadays.

Regarding what's hot, 256 color support is probably a recent 'must have' of sorts. One way to implement it is as a 32 color extension (to avoid using hard to distinguish colors) as documented/implemented here: http://www.mudbytes.net/file-2596 Negotiation is tricky with MTTS being one way to go about it, which tt++ supports, and some clients have adopted the reporting of the terminal type on the 2nd request.

256 color status as well as some newer protocols are listed here:

http://www.mudpedia.org/wiki/Comparison_...
25 Mar, 2012, Tyche wrote in the 11th comment:
Votes: 0
Deimos said:
Wow. I wasn't even aware that there were still clients in use that couldn't handle basic Telnet negotiation. Seems like that's a pretty severe deficiency. I'm inclined to just pretend that they don't exist and operate under the assumption that all clients are at least capable of negotiations, even if they support nothing I'm interested in negotiating…


Here's some links to GMUD discussion from this site or generated from discussions here.
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...
http://www.mudpedia.org/wiki/GMud
http://posted-stuff.blogspot.com/2010/03...

It looks that players using GMUD were anywhere from 1 in 6 to 1 in 5 as late as 3 years ago.
There's a clever way of dealing with it posted by Donky, so the GMUD user doesn't notice.
Or you can just as well ignore the client. Not a big deal.

Returning to your other question…
Deimos said:
Is it common practice to support multiple similar protocols (e.g. MSDP and GMCP), and use one or the other depending on client support?


I don't think there is a common practice. Existing mud games and even mud families will often continue supporting archaic clients their players are using,
because it's a cultural thing. I think old mudders are as reluctant to give up old clients as they are the style of games they play. :-)
And it depends on where you think your player population is going to come from. If your advertise it on certain fora, you might get SimpleMU, tkMOO, Pueblo
or Muckclient users. On other fora you might get TinTin, Zmud, and Mushclient users. If they come to it via your web page, they might be likely to use what
you recommend if they're newbies. If they come from facebook apps and phone apps, they'll be using whatever protocols are in those clients.

The views of what one should support vary from…
Backward compatibility supporting everything from dumb clients and basic telnet to the latest web apps and Mushclient/Cmud plugins.
to…
Just their own custom client or preferred client.
And everything in between.
YMMV
27 Mar, 2012, quixadhal wrote in the 12th comment:
Votes: 0
Deimos, once you've got MXP working, that's likely good enough for most people. I would also support XTERM256, as a few MUDs do offer that, but MXP is more common and a better solution for getting full color support, IMHO.

Scandum said:
None exist as you'd need to write a virtual terminal to handle clickable links in a console client, with clickable links appearing to be the main use of MXP nowadays.


Firstly, a "console" client just means a textmode client, and there are quite a few terminal emulators that can support mouse clicks in one way or another. And, even if you didn't directly support it as a mouse-driven feature, you could still allow selection of clickable items via some function key/escape sequence (IE: hit F1 and use the arrow keys to pick a link, then hit return).

Scandum said:
Regarding what's hot, 256 color support is probably a recent 'must have' of sorts. One way to implement it is as a 32 color extension


Another way to do it is the right way, of actually supporting the full 256 color palette, including the 24 greyscale intensities. If the MUD in question uses color in a way that makes it hard to distinguish one from another, that's the fault of the MUD, not the terminal or protocol. FWIW, MXP normally uses the same 24-bit palette that HTML uses, so if you want to map it down to any arbitrary granularity, the same code would work fine.

The simple way to do it is to just use code that finds the closest match (in color distance) from a 24-bit color to a reduced palette. For XTERM256, you can pre-generate those mappings and it'll be very fast. You can also pre-render the RGB names if MXP supports them (I don't remember if it does… the names are things like DarkOrchid3). For the full 24-bit palette though, you'll need to run the code and decide if it's worth caching the results or not. CPU vs memory and all that.
28 Mar, 2012, Joseph Locke wrote in the 13th comment:
Votes: 0
Tyche said:
I might send a message and disconnect the client if I determined it was Zmud.

Way to stick it to the man!
29 Mar, 2012, Deimos wrote in the 14th comment:
Votes: 0
I finished MSDP and am back working on MXP now. In the most respectful way I can possibly put this, whoever came up with this protocol obviously had access to and made liberal use of some fantastic drugs…
29 Mar, 2012, quixadhal wrote in the 15th comment:
Votes: 0
*chuckle*

Well, no argument there. MXP seems to be somebody looking at HTML and going "If only it would do MUD things too…. I'll hack it!"

However, it DOES work, and a fair number of muds actually make use of it.
30 Mar, 2012, Deimos wrote in the 16th comment:
Votes: 0
I've no idea how, though. The spec is ambiguous and lacking in so many ways it makes my head hurt. And that's even ignoring the not-quite-HTML syntax.

For example, here's an example of undefined behavior:
<!EL foo ATT=baz>
<!EL bar ATT=baz>
<!EL crap '<foo &baz;><bar &baz;>' ATT=baz>


And apparently names are case-sensitive (it makes special note of this) but attributes aren't (it uses "Fore" and "FORE" interchangeably).

I'm just glad I'm only implementing this server-side…
30 Mar, 2012, Runter wrote in the 17th comment:
Votes: 0
Lol, I wish I had written down all of the inconsistencies I found when implementing this. All I remember is there were more than a few. And even worse, different clients which implemented it didn't agree on how some of the finer points worked. Making it a difficult grind to find the best cross client compliant MXP for a few things.
30 Mar, 2012, David Haley wrote in the 18th comment:
Votes: 0
MXP is a terrible protocol with terrible maintenance. Just look into what Zugg (the protocol author) did in terms of supporting the protocol in his own client. He doesn't require strict escaping of < and > symbols (which the protocol spec seems to require). So, if a MUD sends out <exits> meaning just the literal string of characters, and it doesn't match a tag in Zugg's software, he lets it go through.

This creates all kinds of chaos with clients that actually respect the protocol, and wouldn't output that text verbatim.

So, well, yeah, it's not surprising that it was written with some of the same sloppiness as it was executed. :sad:

Sorry for ranting…
30 Mar, 2012, KaVir wrote in the 19th comment:
Votes: 0
Runter said:
Lol, I wish I had written down all of the inconsistencies I found when implementing this. All I remember is there were more than a few. And even worse, different clients which implemented it didn't agree on how some of the finer points worked. Making it a difficult grind to find the best cross client compliant MXP for a few things.

Support is so inconsistent across clients that I only bother using MXP for clickable links. The 24-bit colour could be useful too, but xterm 256 colours are more widely supported and sufficient for my purposes, so I stick with those (the only client I'm aware of that supports MXP and not 256 colours is zMUD).

If you're just using it for links and colour then it's not too bad, the only thing you really need to look out for is negotiation - the MXP specification doesn't define how it works, so some clients expect IAC DO MXP while others expect IAC WILL MXP (and some will accept either). You can't just negotiate both, because one will return WONT/DONT (and thus switch MXP off again), so you need to negotiate one, then if it fails negotiate the other.

Ironically enough, Zugg did clearly define how negotiation should work in his MUD Sound Protocol (MSP), despite the negotiation in that protocol serving no practical use.
06 May, 2012, Nathan wrote in the 20th comment:
Votes: 0
Ideally as many protocols as possible supported would be nice, for variety, but I would think it wise to stick to protocols you are willing to do a proper, full implementation of. I don't mean that people generally would have an incomplete implementation, but a poor implementation is probably worse than no implementation thereof.

I think MSP is a pretty cool idea, but I'd hate to get spammed constantly.
Random Picks
0.0/20