11 Apr, 2011, Chris Bailey wrote in the 1st comment:
Votes: 0
So I have been digging through the various documentation available for MXP, and I'm not sure how to get going. I know very little of telnet negotiation, so I am probably doing it wrong. Why do you have to convert the < > and &? Do you need to do anything special when sending telnet codes, or can I just send them as plain text to the client?
11 Apr, 2011, Runter wrote in the 2nd comment:
Votes: 0
I implemented MXP, and it wasn't that fun. So basically the reason you convert the < > and & is so that other normal characters in description or other output don't get interpreted or stripped out. Only the ones that were part of MXP tags specifically. The codes you are sending are just non-printed characters MXP decided to use. Basically you want to strip it all out if they aren't using MXP, if they are convert it. You should read up about the different "modes." There's a purpose to them, but if I recall, you really only will be using one mode most of the time. perm-secured, or something.

It's unfortunate that MXP isn't more powerful, well documented, or consistently supported. If you plan on using anything more than the basic hyperlinking for actions, get ready to have to test across multiple clients to just figure out what they accept and how they accept the tags. Even using the colors for the links is different between mushclient and zmud, for example.

Ideally, if I were going to use MXP in earnest, I'd support only cmud because of how much more advanced it is, but in reality because mushclient is free I probably target it. Mushclient doesn't do some of the more cool things, like inline graphics, and there's no interest from what I've read to have it added by Gammon.
11 Apr, 2011, Chris Bailey wrote in the 3rd comment:
Votes: 0
Blehg. It seems like it would be simpler to design a client that caters to your server, and use your own protocol. Am I missing something?
12 Apr, 2011, Runter wrote in the 4th comment:
Votes: 0
Chris Bailey said:
Blehg. It seems like it would be simpler to design a client that caters to your server, and use your own protocol. Am I missing something?


It works with existing clients out of the box with no extension needed installed…that being said, if you were already using a dedicated client that could make sense. Especially if you want more functionality than MXP offers.
12 Apr, 2011, Tyche wrote in the 5th comment:
Votes: 0
I thought MXP was difficult to implement on the client, although someone has released an MXP client library since then.
It used to be here.
MXP was pretty easy to implement on the mud server side.
12 Apr, 2011, Runter wrote in the 6th comment:
Votes: 0
Tyche said:
I thought MXP was difficult to implement on the client, although someone has released an MXP client library since then.
It used to be here.
MXP was pretty easy to implement on the mud server side.


No, the basics aren't difficult, what's difficult is determining what is supported and how on various clients. I finally made a decision to support especially mushclient's implementation (Even though I wasn't very happy with it.) because cmud was less accessible. The client developers seem to have different ideas about what parts of the protocol are useful. On Gammon's site, for example, he answers the question related to why mushclient doesn't support the image tags with : "MUSHclient is supposed to be a text-based MUD client, and as such, supporting images is a bit off-topic for it. " That was in 2004. Since then he's obviously decided to put graphical stuff in his client ala miniwindows. I wonder if he still feels that pizza is not for breakfast.
12 Apr, 2011, Twisol wrote in the 7th comment:
Votes: 0
Runter said:
Since then he's obviously decided to put graphical stuff in his client ala miniwindows. I wonder if he still feels that pizza is not for breakfast.

To be fair, MUSHclient's source is quite, um, rigid. It actually is easier to add miniwindows than to rewrite the output window.

EDIT: I speak from experience: I worked in the source for at least a few months and tried to clean things up.
12 Apr, 2011, Runter wrote in the 8th comment:
Votes: 0
Twisol said:
Runter said:
Since then he's obviously decided to put graphical stuff in his client ala miniwindows. I wonder if he still feels that pizza is not for breakfast.

To be fair, MUSHclient's source is quite, um, rigid. It actually is easier to add miniwindows than to rewrite the output window.

EDIT: I speak from experience: I worked in the source for at least a few months and tried to clean things up.


He never mentioned it as being too hard, or his source being too sloppy to facilitate major changes. His argument was the content doesn't belong in muds.
12 Apr, 2011, David Haley wrote in the 9th comment:
Votes: 0
Inline images are quite different architecturally than the miniwindows. He did argue that it wasn't appropriate for the client, but, well, that was in 2004, and this is 2011. :wink:
12 Apr, 2011, Runter wrote in the 10th comment:
Votes: 0
David Haley said:
Inline images are quite different architecturally than the miniwindows. He did argue that it wasn't appropriate for the client, but, well, that was in 2004, and this is 2011. :wink:


Yes, way back in 2004 games hadn't quite started being developed without CLI's yet. Forget about interfaces, the use of images at all isn't something that should be in muds.

In all seriousness, I dunno why the Gammonites are coming out of the woodworks and misrepresenting what I said. I never said anything about architectural details. He's the one who claimed it wasn't something muds were supposed to do (have images) and that was the end of the story. Where did I say anything about how hard/easy it is to do? It's in the spec, it's done in other clients. I don't get what you guys are even actually arguing, unless it's that Gammon was wrong. I agree with you there.

Oh, and I'll say it with a wink, too. :wink:
12 Apr, 2011, David Haley wrote in the 11th comment:
Votes: 0
I'm arguing that you're arguing with a position somebody gave seven years ago. Clearly, he has changed his mind. I'm not sure what there is to say at this point. :smile:
12 Apr, 2011, Scandum wrote in the 12th comment:
Votes: 0
If people only implement MXP to get clickable links it'd be easier to create a robust escape sequence for embedding clickable commands and links.

Would Mushclient allow parsing something like: \e:C\tn\tClick to go north\tNorth\a or \e:U\thttp://homepage.com\tClick to visit the homepage\tBubba's Homepage\a and turn it into a clickable link with the provided hint that either executes a command or visits an external webpage?

Negotiation would be fairly easy using MTTS, MSDP, or a variant.
12 Apr, 2011, David Haley wrote in the 13th comment:
Votes: 0
Yo dawg, I heard you like negotiation, so I put a protocol in your protocol so you could negotiate after negotiating.

Seriously: why are we negotiating something after we've negotiated a protocol through negotiation?

Anyhow, yes, you could parse something like that if you wanted to by using triggers or, for the more advanced, packet interception.
12 Apr, 2011, KaVir wrote in the 14th comment:
Votes: 0
Chris Bailey said:
So I have been digging through the various documentation available for MXP, and I'm not sure how to get going. I know very little of telnet negotiation, so I am probably doing it wrong.

You might want to take a look at my protocol snippet if you haven't already - it's public domain, and includes basic support for MXP.
12 Apr, 2011, Chris Bailey wrote in the 15th comment:
Votes: 0
KaVir said:
Chris Bailey said:
So I have been digging through the various documentation available for MXP, and I'm not sure how to get going. I know very little of telnet negotiation, so I am probably doing it wrong.

You might want to take a look at my protocol snippet if you haven't already - it's public domain, and includes basic support for MXP.


Well, that is a lot to look at. I'll check it out tonight for sure. Thanks!
12 Apr, 2011, Scandum wrote in the 16th comment:
Votes: 0
David Haley said:
Seriously: why are we negotiating something after we've negotiated a protocol through negotiation?

What else would you suggest?
12 Apr, 2011, David Haley wrote in the 17th comment:
Votes: 0
Scandum said:
David Haley said:
Seriously: why are we negotiating something after we've negotiated a protocol through negotiation?

What else would you suggest?

Use the negotiation mechanism directly rather than negotiate in a mechanism after having used a negotiation mechanism?
12 Apr, 2011, Kayle wrote in the 18th comment:
Votes: 0
And this is why I can't take anything Scandum says seriously.

I mean really. You want to negotiation MSDP on, and then INSIDE MSDP negotiate the clickable links on? Seriously? That sounds like an idea out of a fortune cookie.

CMUD automatically parses URLs into clickable links to open up in the browser, just FYI.
12 Apr, 2011, KaVir wrote in the 19th comment:
Votes: 0
Kayle said:
You want to negotiation MSDP on, and then INSIDE MSDP negotiate the clickable links on?

That's pretty much what I had to do in order to get MXP-style clickable links working in Mudlet.
12 Apr, 2011, Scandum wrote in the 20th comment:
Votes: 0
Kayle said:
I mean really. You want to negotiation MSDP on, and then INSIDE MSDP negotiate the clickable links on? Seriously? That sounds like an idea out of a fortune cookie.

You suggest assigning a TELOPT for ANSI, VT100, 256 COLOR, screen readers, color pallet, and clickable links?

We'd run out of TELOPTS fast if everyone and their mama started doing so, not to mention it'd be a glorious mess long before that.

So much for not ignoring the special people.
0.0/24