This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

MXP issue with Materia Magica

Posted by Deacla on Tue 17 Aug 2010 06:22 AM — 33 posts, 123,727 views.

Deacla USA #0
I'm getting MXP errors upon connection to Materia Magica ever since it's last reboot when it's 'MXP vX enabled!' message was slightly updated to now display after the connection sequence is complete. I'm posting this here because I've already had some communications with MM's coder's and they are unable to reproduce my error's using v4.56 of MUSHclient. I continue to get the same errors regardless of changing any combination of MUSH version, fresh install's, and fresh world files.
The error occur's whenever a lessthan symbol is received for output. Somehow the MXP parser is reading this as a command and removes the lessthan plus all characters following it to the next open space. It then outputs the rest of the line and sends an MXP error to the log. I've been assuming that possibly the MM coder's left out a > somewhere in their MXP code but not everyone is getting the errors. I can't seem to diagnose if it's a setting I'm using and how to get rid of it so that MXP works. here are some examples of the errors.
The prompt string is as follows:
<863hp 649sp 844st>

but becomes the following with the error:
863hp 649sp 844st>
E  1001: (16658) Unterminated MXP element:  (got <ESC>)

another example from a in-game help file:
NAME
 write - write something on a page of parchment using a quill pen

SYNOPSIS
 write <parchment name>
 write <parchment name> title <title of parchment>
 write <parchment name> title none

becomes:
NAME
 write - write something on a page of parchment using a quill pen

SYNOPSIS
 write 
 write  title 
 write  title none

with these error codes logged:
A 20000: (16778) MXP element: <parchment name>
E  1023: (16778) Unknown MXP element: <parchment>
A 20000: (16779) MXP element: <parchment name>
E  1023: (16779) Unknown MXP element: <parchment>
A 20000: (16779) MXP element: <title of parchment>
E  1024: (16779) Secure MXP tag ignored when not in secure mode: <title>
A 20000: (16780) MXP element: <parchment name>
E  1023: (16780) Unknown MXP element: <parchment>
A 20000: (16789) MXP element: <parchment name>
E  1023: (16789) Unknown MXP element: <parchment>
A 20000: (16789) MXP element: <title of parchment>
E  1024: (16789) Secure MXP tag ignored when not in secure mode: <title>
A 20000: (16795) MXP element: <parchment name>
E  1023: (16795) Unknown MXP element: <parchment>

thanks for your help in advance. and if you need more info just ask.
Twisol USA #1
< characters that are not part of MXP tags are supposed to be sent by the server as &lt; instead. If the MUD doesn't do this, you'll probably have the issues you're describing.

[EDIT] Alternatively, if MM lets you disable MXP, do so and disable it in MUSHclient too (in Game -> Configure -> MXP/Pueblo). You won't have any MXP benefits (because you've totally disabled it), but you won't have errors and your output will look right.
Amended on Tue 17 Aug 2010 06:26 AM by Twisol
Deacla USA #2
As of now, I do have MXP disabled to make the game playable. I could deal with this normally as I don't use any of the MXP features. My problem is I'm also using the 'convert IAC EOR/GA to newline' feature in the Output menu to have real-time tracking of the prompt. This seems to rely on MXP somehow as it's now disabled too. Without it my vital stat bars are always one round behind because the prompt does not have a newline to trigger from. If i could find a workaround for that i could forget MXP altogether.
Twisol USA #3
Deacla said:
My problem is I'm also using the 'convert IAC EOR/GA to newline' feature in the Output menu to have real-time tracking of the prompt. This seems to rely on MXP somehow as it's now disabled too.

Hmm, that shouldn't be. I use it with Achaea, and I have MXP disabled. I think it's just a side-effect of the update you said MM did. If it was working before, fixing it should be pretty trivial.
Deacla USA #4
Any other thoughts on if it's my fault somehow in a plugin I wrote or a variable i may have changed somehow? Am I able to effect the way MXP is parsed or wether IAC EOR/GA is available for conversion to newline? The same error is also occurring with other MUSH/MM players that I have distributed plugins to. But, it all started happening after MM's last update, which also may have coincided with my last MUSH update...
Twisol USA #5
Well, you said you tried earlier versions. If you were messing with the MXP input you'd have hit weird behavior a lot sooner. And the only other way to tinker with the raw incoming data is OnPluginPacketReceived, which I doubt you're using because it has very little general use.
Deacla USA #6
looking at packet debug i get this for the same example from above with the 'write' command help file:
.[1;34m[.[0m1382   1b 5b 31 3b 33 34 6d 5b 1b 5b 30 6d 31 33 38 32
 .[1;34m] .[33mW   20 1b 5b 31 3b 33 34 6d 5d 20 1b 5b 33 33 6d 57
RITE.[0m..NAME..   52 49 54 45 1b 5b 30 6d 0a 0d 4e 41 4d 45 0a 0d
 write - write s   20 77 72 69 74 65 20 2d 20 77 72 69 74 65 20 73
omething on a pa   6f 6d 65 74 68 69 6e 67 20 6f 6e 20 61 20 70 61
ge of parchment    67 65 20 6f 66 20 70 61 72 63 68 6d 65 6e 74 20
using a quill pe   75 73 69 6e 67 20 61 20 71 75 69 6c 6c 20 70 65
n....SYNOPSIS..    6e 0a 0d 0a 0d 53 59 4e 4f 50 53 49 53 0a 0d 20
write <parchment   77 72 69 74 65 20 3c 70 61 72 63 68 6d 65 6e 74
 name>.. write <   20 6e 61 6d 65 3e 0a 0d 20 77 72 69 74 65 20 3c
parchment name>    70 61 72 63 68 6d 65 6e 74 20 6e 61 6d 65 3e 20
title <title of    74 69 74 6c 65 20 3c 74 69 74 6c 65 20 6f 66 20
parchment>.. wri   70 61 72 63 68 6d 65 6e 74 3e 0a 0d 20 77 72 69
te <parchment na   74 65 20 3c 70 61 72 63 68 6d 65 6e 74 20 6e 61
me> title none..

does this mean that the is in fact sending leesthan symbols instead of &lt; ?
Twisol USA #7
Yes.
Nick Gammon Australia Forum Administrator #8
Every. Couple. Of. Months.

This question arises again and again, because Materia Magica (in this case) are not implementing the MXP spec correctly. From the spec here:

http://www.zuggsoft.com/zmud/mxp.htm

It says:

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.


(my emphasis on the "must").

The MUD has not implemented the MXP spec correctly, and thus you are getting undefined behaviour at the client end. In fact, if you set "MXP debugging" to some level other than "none" , you will see errors scrolling by about "Unknown tag: <parchment name>".

The situation is made worse because certain other clients (you know who you are) don't implement the spec also, and thus the MUD developers "get away" with not following the spec, if they only test using a certain client.

Search this forum <sigh> there are various plugins around that try to work around this behaviour.
Nick Gammon Australia Forum Administrator #9
Quote:

with these error codes logged:
A 20000: (16778) MXP element: <parchment name>
E 1023: (16778) Unknown MXP element: <parchment>
A 20000: (16779) MXP element: <parchment name>
E 1023: (16779) Unknown MXP element: <parchment>


Lol. I see you got those errors. I was so infuriated by the problem rearing its head again I skipped some of your post.

Well, you have something concrete to tell the devs at Materia Magica: "follow the MXP spec, please".
Nick Gammon Australia Forum Administrator #10
Deacla said:

As of now, I do have MXP disabled to make the game playable. I could deal with this normally as I don't use any of the MXP features. My problem is I'm also using the 'convert IAC EOR/GA to newline' feature in the Output menu to have real-time tracking of the prompt. This seems to rely on MXP somehow as it's now disabled too.


It shouldn't. In MUSHclient there is no connection.
Nick Gammon Australia Forum Administrator #11
Do a packet debug on when it is waiting for input. See if you get an IAC EOR (0xFF 0xEF) or IAC GA (0xFF 0xF9).

If not, you have, ah, another bug report to submit to the MUD.
Deacla USA #12
Thanks for your input guys. The one thing I don't understand is why it only recently started happening? I can only figure they left something open in the MXP change to trigger this.
Nick Gammon Australia Forum Administrator #13
Possibly. I haven't fiddled with MXP or the IAC/GA stuff, as far as I recall.

Especially if they claim 'MXP vX enabled!' (whatever that is). Sounds like they have been making changes. Not fully tested ones, perhaps.
Deacla USA #14
When you log on it displays a message in the output 'MXP v0.5 enabled!' or 'MXP v1.0 enabled!'. That message doesn't display anymore for me after the change.
And, here is an example of the prompt packet:
Incoming packet: 614 (74 bytes) at Tuesday, August 17, 2010, 4:10:55 AM

...[1;34m[*].[34   0a 0d 1b 5b 31 3b 33 34 6d 5b 2a 5d 1b 5b 33 34
m<.[0m863.[1;34m   6d 3c 1b 5b 30 6d 38 36 33 1b 5b 31 3b 33 34 6d
hp .[0m649.[1;34   68 70 20 1b 5b 30 6d 36 34 39 1b 5b 31 3b 33 34
msp .[0m839.[1;3   6d 73 70 20 1b 5b 30 6d 38 33 39 1b 5b 31 3b 33
4mst>.[0m          34 6d 73 74 3e 1b 5b 30 6d 20

Twisol USA #15
Deacla said:
When you log on it displays a message in the output 'MXP v0.5 enabled!' or 'MXP v1.0 enabled!'. That message doesn't display anymore for me after the change.

Possibly because you disabled MXP?
Deacla USA #16
Well yes that, but I mean when I'm testing different settings and install's and versions with MXP enabled it doesn't display. I'm mostly stating that for full disclosure as I've linked the MM devs to this topic to get a better idea of the discussion.
Twisol USA #17
Oh, I see. Got it.
Nick Gammon Australia Forum Administrator #18
In that packet you showed there was no IAC character at all.

I make it:


0x0a 0x0d 0x1b 0x5b 0x31 0x3b 0x33 0x34 0x6d 0x5b 0x2a 0x5d 0x1b 0x5b 0x33 0x34 0x6d 0x3c 0x1b 0x5b 0x30 0x6d 0x38 0x36 0x33 0x1b 0x5b 0x31 0x3b 0x33 0x34 0x6d 0x68 0x70 0x20 0x1b 0x5b 0x30 0x6d 0x36 0x34 0x39 0x1b 0x5b 0x31 0x3b 0x33 0x34 0x6d 0x73 0x70 0x20 0x1b 0x5b 0x30 0x6d 0x38 0x33 0x39 0x1b 0x5b 0x31 0x3b 0x33 0x34 0x6d 0x73 0x74 0x3e 0x1b 0x5b 0x30 0x6d 0x20


Now since IAC is 0xff and there is no 0xff there, you didn't get it.

Since you have the devs watching this thread I suggest there are two problems:

  1. If MXP is enabled, things like <parchment name>
    should be sent as &lt;parchment name&gt;.

    However since you can force MXP on at the client level, maybe the MUD doesn't think MXP is on.

    So you may need to check your client settings. However if MXP is enabled then my remarks hold.
  2. We don't see IAC GA or IAC EOR in that packet. If there is a MUD option to disable that, then maybe you should enable it.

    However if the client settings haven't changed, then the MUD may be behaving differently after the recent patch, and this could be something to look into.


Amended on Tue 17 Aug 2010 09:44 AM by Nick Gammon
Nick Gammon Australia Forum Administrator #19
Near the start of the session you should see something like this:


Incoming packet: 7 (3 bytes) at Tuesday, August 17, 2010, 7:56:23 PM

             ff fb 19   (IAC WILL EOR)

Sent  packet: 5 (3 bytes) at Tuesday, August 17, 2010, 7:56:23 PM

             ff fd 19   (IAC DO EOR)



If you don't get that, then MUSHclient won't activate the EOR processing (and neither will the MUD, probably).

Note that the request for EOR is 0x19 not 0xEF which is the IAC EOR you get later on (I got confused by this initially).
Deacla USA #20
After tracing it back in the packets i think that after the recent changes in MUSH that causes certain things to be fired before others and may have new errors show up has affected me in this case. It seems that having auto-login in MUSH world properties with %name%, and %password% being sent before anything, and also having Send ("") commands in an OnWorldConnect function can now lead to miscommunication in the protocols leading to all the above issues. I got MXP and everything to work by now manually logging in and installing my plugins after the world opens.

EDIT: I'm never quite knowledgeable enough to know what's actually causing my problems but i am tenacious enough to find a workaround eventually.
Amended on Tue 17 Aug 2010 10:55 AM by Deacla
Nick Gammon Australia Forum Administrator #21
It's interesting you should say that.

It sounds to me like you are describing a "race condition" - you can read more about them here:

http://en.wikipedia.org/wiki/Race_condition

Basically, the correct behaviour can become dependent on the exact timing or order of operations, which seems to be what you are describing.

Probably the server should be more immune to the exact order in which the client does things, but it sounds like if you are logging in automatically it may consider your username/password as declining to use things like IAC/EOR, whereas if you had not used the auto-login the acceptance of IAC/EOR negotiation would have occurred next.

I seem to recall something similar happening on another MUD a little while back (maybe a few months). There is no really "correct" order - if we sent the negotiations before the IAC/EOR stuff, then conceivably they might be mistaken for your player name.

If you are communicating with the MUD admins, you might want to suggest that the telnet negotiation not be so dependent on the exact order in which things happen.

Sure, it may work better with another client (which may do things in the reverse order) but there is no guarantee that every client will do things in a particular order.
Zevious #22
The spec isn't implemented incorrectly as far as I can tell. It works fine on my version of Mushclient. The game is sending greater than and less than because the problem is that Mushclient is not telling the game to send them by responding with the appropriate MXP telopt code, I think.

What happens on connect has not changed, except that the < VERSION > check does not occur until they are actually logged into the game. The telnet negotiation occurs as it did before, on connect, along with MCCP and the other ones.

When the < VERSION > check occurred, the game responds with a one-time (per connection) dump of settings for MXP. That's what was moved. The MXP 0.5 ENABLED message appears at that point. The reason this was moved was because of the telnet spec - previously it was generating a bunch of newlines, so people would get the login message multiple times before they could actually log in. This fixed that.

Now, on my Mushclient, the change I just described didn't work when I was using version 4.46. It did the same exact thing he's describing here. But when I reinstalled with the latest 4.56, it worked fine. I get the "MXP 0.5 ENABLED" message when I log into the game. So I thought that was because maybe there was a MXP bug in 4.46 that was fixed in 4.56.

However, Deacla has reinstalled with 4.56 and it's not working for him. So I don't know what the deal is. I don't have anything really customized in my Mushclient, it's basically out of the box. The only setting change I think I did was turn on MXP warnings.

So I don't understand why it's working fine for me, exactly as it should be, but for him it's doing the same thing that it did when I initially tried it with the 4.46 client.

I know CMUD/ZMUD allow some "cheat room" for things - it works fine in those clients - and I'm especially confused because it's not working there.

So the thing about the greater than or less than - the game uses the MXP SECURE and MXP LOCK settings, and uses the &gt and &lt etc. whenever it's sending an MXP SECURE string, and then calls MXP LOCK to disable that until the game sends MXP SECURE again. But it doesn't do this if it doesn't think MXP is enabled on the client end. Since the game will receive and negotiate the DO MXP telopt command whenever it's sent, it seems like Mushclient isn't sending it for some reason, yet it is receiving the MXP WILL and thinks it is ok, which is why it's getting messed up.

Zevious #23
To clarify the miswording above: "I'm especially confused because it's working in ZMUD/CMUD and in my version of mushclient, but not his".
Zevious #24
Oh, I don't have auto-login enabled, though. When I enable that, it does exactly what he's describing. The <VERSION> tag appears right after the password line, visibly.
Zevious #25
The MM game server isn't dependent on which order the telopt commands are sent in - they can be sent at any time to turn on/off features, before or after login. I think the issue is that Mushclient may not be sending the MXP DO or it's getting caught up somewhere and ignored, although I'm not sure how that would only happen in the auto login process.

It's possible this would have happened previously but the VERSION request caused it to somehow receive it properly? Not sure. Other telopt codes are accepted and received the same way, without incident as far as I can tell, so I'm not sure why this MXP has this particular issue.
Nick Gammon Australia Forum Administrator #26
Right, well this is partly why I added extra stuff into version 4.57.

Template:post=10509
Please see the forum thread: http://gammon.com.au/forum/?id=10509.


The post below shows what you can get:

Template:post=10444
Please see the forum thread: http://gammon.com.au/forum/?id=10444.


Please (in version 4.57) in the Immediate window (Ctrl+I) type in:


Debug "summary"


And then in the stuff that fills up the screen there should be a [Telnet] link which will dump out what things it responded to (eg. DO MXP, WILL MXP).

If you can paste all that in, that might help debug it.

I think there is some sort of race condition happening.
Nick Gammon Australia Forum Administrator #27
Zevious said:

Since the game will receive and negotiate the DO MXP telopt command whenever it's sent, it seems like Mushclient isn't sending it for some reason, yet it is receiving the MXP WILL and thinks it is ok, which is why it's getting messed up.


Well you have to check the client configuration here (which is why I wanted the debug dump).

There are two steps to negotiating:

http://www.gammon.com.au/mushclient/addingservermxp.htm

The server sends IAC WILL MXP and the client replies IAC DO MXP.

However if the client is set to "on command" (which is the default) then we have merely agreed to use MXP at some future time at this point.

Then the server, now it knows the client supports MXP, sends IAC SB MXP IAC SE which tells the client to turn MXP on now.

A packet debug will help at this point - you will see if the server actually sends the things it should (IAC WILL MXP and then IAC SB MXP IAC SE) and if the client replies as it should (IAC DO MXP).
Zevious #28
I think the problem is that the <VERSION> request isn't getting read by MUSHclient on connect when the autologin is used. It seems to ignore MXP commands during autologin. Don't think it's the telopt commands, those are working fine.

This is what happens:

CONNECT OK
Welcome to Materia Magica!
66.219.44.169
MATERIAMAGICA.COM

.-.-. '` .--- .--. .--. '` '`
|| | || ||-| || ||-. ||-.' || ||_|
`| |' || ; || `|__, `| ; || || |
' ' ' ' ' '
.-.-. '` .--. '` .--. '`
|| | || ||-| ||._' || || ||-|
`| |' |; | `|__| || \_, |; | v4.3

Online for over fourteen years, MATERIA MAGICA is one
of the longest-running, continually-developed games
available, with a vast game world, detailed environments,
intelligent monsters and other denizens, and many, many
thrilling quests - you'll never run out of things to do.

Copyright (c) 1995-2010 Ingenii Interactive Co., All
Rights Reserved. For game play information and more, visit
http://www.materiamagica.com

New players, please type NEW.
By what name shall we know thee? Password: <VERSION>

Reconnecting.
Welcome back to Materia Magica.

See the <VERSION> tag showing up above - it shouldn't be appearing there, MUSHClient isn't reading it in for some reason that only happens during the autologin process.

MUSHclient shows MXP as being on (
Telnet (IAC) received: DO: 0, DONT: 0, WILL: 7, WONT: 1, SB: 2)

-- MXP --
MXP active: yes, Pueblo mode: NO
MXP tags received: 0
MXP entities received: 0
MXP errors: 2

The game server is in a "MXP 0.3" mode on connect - what that means is that it knows MXP is out there and it's said it can do MXP and turned it on, but it won't send any MXP commands until it gets a proper <VERSION> response from the client. Since the VERSION request never gets responded to, the game knows the client can receive MXP but doesn't know if it's version 0.5 or not (less than 0.5 it doesn't bother with MXP), and there's no contingency to turn it back off after some duration if the MXP VERSION request is never received.

Yet somehow the MXP mode either isn't getting locked off - I'm guessing MXP starts with MXP mode locked on until explicitly told to lock it off - probably because the locking is initiated at the end of the VERSION string, which isn't being interpreted by MUSHclient as an MXP string - and so MUSHClient is reading in everything the client sends as potential MXP.
Zevious #29
I wonder if it's the password telopt string? This only happens on reconnect - it doesn't happen on the initial login - the VERSION request comes right after the telopt command to turn echoing back on.
Nick Gammon Australia Forum Administrator #30
Please turn on packet debugging (Edit menu -> Debug packets) and then connect and capture that stuff again. If your password is echoed then X that out (and also in the hex part as it is easy to work it out from the hex codes).

I suspect some sort of race condition. The fact that it shows <VERSION> seems to me to indicate that MXP is not turned on at that point.
forral USA #31
Wow, am I glad this issue finally saw some light.

Just wanted to post an update, one of the administrators of the mud took the liberty of posting the following update:

3277 08-26-2010 Vassago Fixed an issue with MXP support in MUSHclient not working properly on reconnect with auto-login enabled.

And I have tested it and it works fine now.

Glad to see everything resolved, and man was it cool to see collaboration between mud admin + mud client programmers. Finally some open-forum discussion to address the root issues!
Worstje Netherlands #32
Good to see it solved, although I must say I dislike the wording which makes it seems MUSHclient is 'buggy' or at fault in some way, which I am pretty sure it isn't.

Politics, ugh. =)