17 Mar, 2010, KaVir wrote in the 21st comment:
Votes: 0
David Haley said:
My understanding is that it does exactly what happened here: it seems something that looks like an MXP tag, and turns on MXP and thereby hides the tag lookalike. I saw similar things happen with <n>, <s>, etc.

That makes sense, but surely that would be a huge problem for zMUD users? Using angled brackets for syntax is pretty common, while MXP support is relatively rare, so I could see many muds running into the same problem.

Perhaps it's just checking the login screen, but even that would cause problems with ASCII art and such. Unless it's checking the login screen for an alphanumeric sequence between angled brackets, or something wierd like that…

I'll have to try and find a player who uses zMUD and see if I can get them to repeat the problem.
17 Mar, 2010, Orrin wrote in the 22nd comment:
Votes: 0
David Haley said:
It's a MUSHclient "issue" in that MUSHclient does what the protocol says to do. Funny that!!

The behaviour Deimos described is exactly what happens with mushclient if you manually enable MXP and connect to a mud which doesn't support it (ie. it doesn't replace < with &lt;). I expect this is what Scandum was referring to, but I'm sure Deimos can end the suspense and tell us what client he was using.

KaVir said:
I'll have to try and find a player who uses zMUD and see if I can get them to repeat the problem.

Your login screen looks fine to me using zmud, but I can reproduce the problem using mushclient with MXP enabled.
17 Mar, 2010, Scandum wrote in the 23rd comment:
Votes: 0
Kayle said:
Uhm.. How? How exactly is something that zMUD does a MUSHClient issue?

What I mean is that Deimos most likely uses MUSHClient, not zMud.
17 Mar, 2010, Deimos wrote in the 24th comment:
Votes: 0
Yes, I was using MUSHclient, and I had MXP set to "always on" due to having played a MUD recently that didn't negotiate properly.

Personally, I would just prompt the player for it if negotiations fail, using some trickery like this:


//  If MXP negotiation failed, prompt the user:

MXP is <not>being parsed!

Is MXP being parsed (y/n)?

// If they answer yes at this point, turn MXP on.
17 Mar, 2010, Scandum wrote in the 25th comment:
Votes: 0
Oh joy, now MUD devs that don't even support MXP have to work around MUSHClient's issues, because the author is too stubborn to sensibly implement MXP.

I think it's safe to discard the zMud flames by MC fanboys, or the suggestion to add MXP detection that will work on MC, but not with ZM.
17 Mar, 2010, David Haley wrote in the 26th comment:
Votes: 0
Scandum, do you have any idea what's even going on? Like, did you actually bother to investigate the issue or are you just flaming/trolling? Perhaps you can tell us precisely what mistake MUSHclient is making.

Orrin said:
The behaviour Deimos described is exactly what happens with mushclient if you manually enable MXP and connect to a mud which doesn't support it (ie. it doesn't replace < with &lt;).

Yes. But this is 'user error' rather than 'client error'. MUSHclient is doing exactly what it's supposed to be doing given the circumstances.
17 Mar, 2010, Scandum wrote in the 27th comment:
Votes: 0
David Haley said:
Scandum, do you have any idea what's even going on? Like, did you actually bother to investigate the issue or are you just flaming/trolling? Perhaps you can tell us precisely what mistake MUSHclient is making.

I've heard the bitching and whining about ZM from MC fanboys for years now, it's hard "not" to know what's going on.

Where in the MXP protocol does it state that invalid MXP tags must be blanked out? Sounds like the same half-baked logic the author uses for not implementing VT100.
17 Mar, 2010, David Haley wrote in the 28th comment:
Votes: 0
The MXP spec said:
Since a normal < symbol is interpreted as the start of an element tag, you must use &lt; to refer to a less-than symbol directly.

It says that you must use &lt; to refer to a less-than symbol. Therefore, if you don't, you're trying to refer to a tag. Any sensible implementation would discard unknown tags: do you expect your HTML browser to display tags if it doesn't recognize them…?

Regardless it's pretty clear that zMUD is being lax with its own standard by working around MUDs that directly violate the standard by sending < when they mean &lt;.
17 Mar, 2010, KaVir wrote in the 29th comment:
Votes: 0
Deimos said:
Personally, I would just prompt the player for it if negotiations fail

Hrm, not sure that would look so great…

Welcome to the mud!

Automatically checking for MXP (this may permanently kill your local echo)…

MXP wasn't detected, so we'll ask instead. Does your client support MXP (y/n)? y

Sorry, the mud doesn't use MXP.

Enter your name:
17 Mar, 2010, Scandum wrote in the 30th comment:
Votes: 0
David Haley said:
The MXP spec said:
Since a normal < symbol is interpreted as the start of an element tag, you must use &lt; to refer to a less-than symbol directly.

Any sensible implementation would discard unknown tags: do you expect your HTML browser to display tags if it doesn't recognize them…?

The protocol doesn't say not to display them, and it's clearly an issue.
17 Mar, 2010, David Haley wrote in the 31st comment:
Votes: 0
It's fairly clearly inferior to display unknown tags, the reason being quite simply that if the tag later becomes known, output will mysteriously vanish from the screen. Worse yet, output will vanish depending on client version, if it supports it or not!

I'm not sure why there's even any contention that these MUDs are violating the protocol by sending < instead of &lt; and that zMUD lets them get away with it, just ensuring more brokenness as people test stuff on zMUD.
17 Mar, 2010, Deimos wrote in the 32nd comment:
Votes: 0
Why would MXP negotiations kill local echo? Anyway, if your game doesn't use MXP then this discussion is for naught. I'd still advise removing the angled brackets from your character creation process, though, since at least if a player makes it into the game, he/she can ask for help if things are mucked up.
17 Mar, 2010, KaVir wrote in the 33rd comment:
Votes: 0
Deimos said:
Why would MXP negotiations kill local echo?

I mentioned it in post #13 and also in this thread. Apparently it's an issue of windows telnet.

Deimos said:
Anyway, if your game doesn't use MXP then this discussion is for naught. I'd still advise removing the angled brackets from your character creation process, though, since at least if a player makes it into the game, he/she can ask for help if things are mucked up.

Not so struck on that, as it would make it inconsistent with the syntax I use throughout the rest of the mud, but I'll add an extra warning message if people type 'create' without any arguments.
17 Mar, 2010, flumpy wrote in the 34th comment:
Votes: 0
KaVir said:
Deimos said:
Personally, I would just prompt the player for it if negotiations fail

Hrm, not sure that would look so great…
Welcome to the mud!

Automatically checking for MXP (this may permanently kill your local echo)…

MXP wasn't detected, so we'll ask instead. Does your client support MXP (y/n)? y

Sorry, the mud doesn't use MXP.

Enter your name:


lawl funneh :grinning:
18 Mar, 2010, Scandum wrote in the 35th comment:
Votes: 0
I laughed.

Back on topic, I had a similar issue with veterans. On my mud exits are listed above the room description, opposed to under it, and some people seemed incapable of finding them (running into walls and trying to turn on autoexits), got frustrated, and quit, where as people new to muds didn't have much of an issue.

The big question is if those veterans would have stuck around to begin with. There are fundamentally flawed design issues that need addressing, but I don't think mud hoppers (I think that's the quasi official term for them) are something worth losing sleep over.
20.0/35