I've been toying with the notion of adding in MXP to my source. It would seem that the features provided by MXP would add a different kind of interaction between the player and the MUD itself, but are they worth it?
I was wondering what were the (other) benefits of adding such a protocol, how much work would it take, and how easy/difficult is it to work with?
Mmm, I wouldn't really recommend it. The MXP protocol is unfinished and the specifications aren't really followed. Zugg helped design MXP, but I don't think Zugg's client (ZMUD) even follows it correctly.
I"ve gone back and forth on the idea of adding it to my mud many times myself, I think in theory it looks really cool, but it takes quite a bit to add and means some changes to the way builders do things, and it's got very limited (and spotty) support in a very select few clients, which is why I usually end up deciding to put it off again to see if anyone ever decides to make a client that actually supports it fully before I bother installing it into my mud. *shrug* Just my two cents, your milage may vary.
which is why I usually end up deciding to put it off again to see if anyone ever decides to make a client that actually supports it fully before I bother installing it into my mud. *shrug* Just my two cents, your milage may vary.
I think even if they make a client that supports it fully, you'll only get people using that client who can use it. An update to MXP would have to be done on most of the major clients in order for it to be 'worth it' IMO.
I would have to agree with the assessment. IF you don't have MXP now, don't bother. It's not worth the hassle. You'll be in for the same kind of crap us webmasters deal with. Zmud is the IE of MUD clients. Outlines a standard and then breaks it, leaving the other clients that follow it to be the Firefoxes of MUD clients :)
Mmm, I wouldn't really recommend it. The MXP protocol is unfinished and the specifications aren't really followed. Zugg helped design MXP, but I don't think Zugg's client (ZMUD) even follows it correctly.
I read through that post. As that post went on, I couldn't help but notice that several posts point out that zMUD always has MXP on. I've used zMUD for nearly 10 years now and as far as I can remember, which may not extend all the way back to 10 years, there has been an option to disable MXP completely.
I've spent a good deal of time looking at those specs in the past which was what lead me to wonder about adding it to our mud. I was hoping to use MXP to add a little extra stuff such as help balloons or clickable links to get/drop items, kill mobs, send tells, room exits, etc… However, if this is indeed too much trouble, or more trouble than it's worth, then perhaps I'll go a different route.
It is a lot of hassle, but whether it's worth it or not is up to you to decide, the biggest drawback is that few clients support it, and most of them don't support it fully, including zmud.
I haven't used ZMUD in years, and I never really used MXP. Perhaps try asking on Gammon why they think it's always on.
I thought of doing that, but that thread's been dead for over a year.
08 Sep, 2007, David Haley wrote in the 11th comment:
Votes: 0
I use MXP only for adding hyperlinks. Adding it was a breeze for me, contrary to other people apparently. Being able to add hyperlinks makes things like builder interfaces a lot easier to work with, since you can have something very close to a GUI to do your OLC work, instead of having to remember potentially arcane command syntax.
That said, I don't like MXP as a protocol for several reasons many of which are outlined by myself and others on Nick Gammon's forums. One of my more recent problems with it is that it is too prescriptive instead of descriptive: I think it should be a client-side decision to put things into frames or not. Well, anyhow, I've been advocating the creation of a new protocol to go along with Nick's ideas of a new client, but obviously any protocol will suffer from the problem of adoption (both for servers and clients). That said, being able to influence a new client's support of a new protocol at the same time as designing a new code base opens up very many and very interesting possibilities…
The concept of MXP is great, I loved it enough at the time to pursue adding it to Alsherok, and later releasing the work as part of AFKMud. But as has been mentioned, the protocol is disobeyed by its creator which causes problems when the coders on the mud are trying to make it work in what few clients actually support it. Very often what works for Zmud fails in others. And as I said before, it becomes an IE vs The Standards situation. In this case though it's an IE vs Standards situation that's not worth the hassle.
I use MXP, but in such a way that I really don't care that much about it. Granted, I don't use many of its capabilities… it's used mainly to link help files (that I have lots of).
MXP normal usage is to be always on, and escaping stuff you don't want to be interpreted (open mode). I use the opposite approach: as soon as MXP is negotiated, I turn it off (locked mode), and turn it on for each tag (temp secure mode) each time I need it. Sadly, this means that I only support MXP 0.4 or higher… is there any non-obscure mud client that supports MXP, but doesn't support this version?
On contrary to popular belief, zugg didn't disobey his own standards. He added version based support to it, and made a ton of stuff outcasted, and then didn't update his docs on how to implement properly.
Which was the biggest issue I had when I implemented MXP on sandstorm. I use it for all sorts of stuff, and I am even adding in options now for builders to add in their own phrases to manipulate things within the olc editors.
With all that being said.
If you implement the latest/greatest docs from zugg, you'll find that you maintain about 80% of the actual support that mxp has.
After talking with afew mud admins that deal directly with zugg, it came to my attention that they have 100% support, because he likes to keep the people who give him money, up to date.
Anyways, thats just my little banter.
But MXP is worth it if you have big dreams for making your mud mouse-driven, have images, inline sounds/music, add frames, popup-windows/chat-style windows (for tells, ie, PM's) you can do lots with it, its just the matter of you getting past his original V1 crap, because his v2 support is limited, and unless your mud tells the mudclient to use V1 support, it defaults to V2 (or greater) in the client. (especialy in zmud/cmud) which is why I recommend learning the V1 standards, implement them, in generic easy-to-update functions, to ease the pain of a massive update when you move to his V2 settings, which requires afew syntax changes for the basics.
If his docs are not in sync with what the client actually supports, how does that serve anyone? I don't think those of us trying to follow the standards and wondering why only zmud fails to process things properly are all delusional :P
Tomas Mecir of Kmuddy fame has been through this. Kmuddy adheres to the published standard. MUDs following that standard behave properly with Kmuddy, but break when zmud users log on. If zmud can't talk to a MUD using the published standards then what good is it?
10 Sep, 2007, David Haley wrote in the 18th comment:
Votes: 0
I agree with Samson. If Zugg publishes a standard, and implements his standard, but then changes his implementation without updating the standard's documentation, then he is effectively not following his own standard. Well, he's doing his own thing, certainly, but he's not following the published standard.
It sounds to me like Zugg's gone and done great things with MXP but decided to not share the improvements unless you're willing to pay for them. Considering it's the users of his client (who are paying him for that client) that suffer as a direct result since muds who impliment MXP as published fully support other clients that support MXP as published and only his client doesn't get supported this way, that sounds like a very bad idea. That clearly shows that he's not adhering to the standards he's set, but it also indicates that he doesn't want his client used except by those who also play the muds who pay him so he can get paid both coming and going. If that's the case, that's a real shame that he'd ruin his reputation over greed like that, if that's not the case, I'll bet he'd not appreciate you (Darien) putting it out there in a way that gives that impression. :sad:
Mmm, I wouldn't really recommend it. The MXP protocol is unfinished and the specifications aren't really followed. Zugg helped design MXP, but I don't think Zugg's client (ZMUD) even follows it correctly.
I read through that post. As that post went on, I couldn't help but notice that several posts point out that zMUD always has MXP on. I've used zMUD for nearly 10 years now and as far as I can remember, which may not extend all the way back to 10 years, there has been an option to disable MXP completely.
I've spent a good deal of time looking at those specs in the past which was what lead me to wonder about adding it to our mud. I was hoping to use MXP to add a little extra stuff such as help balloons or clickable links to get/drop items, kill mobs, send tells, room exits, etc… However, if this is indeed too much trouble, or more trouble than it's worth, then perhaps I'll go a different route.
Any suggestions?
Since they explained it (but haven't used ZMUD recently), did Zugg fix it so MXP is not always on? Or is it still like that?
I was wondering what were the (other) benefits of adding such a protocol, how much work would it take, and how easy/difficult is it to work with?