Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
Bug reports
MXP issue with Materia Magica

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	MXP issue with Materia Magica
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Worstje] 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. =) [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3

Posted by

Worstje Netherlands (867 posts)

bio

Date

Sat 04 Sep 2010 01:16 PM (UTC) [ quote ]

Message

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. =)

top

Posted by

forral USA (79 posts)

bio

Date

Fri 03 Sep 2010 01:51 PM (UTC) [ quote ]

Message

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!

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Thu 26 Aug 2010 09:12 PM (UTC) [ quote ]

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Zevious (6 posts)

bio

Date

Thu 26 Aug 2010 07:37 PM (UTC) [ quote ]

Message

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.

top

Posted by

Zevious (6 posts)

bio

Date

Thu 26 Aug 2010 07:26 PM (UTC) [ quote ]

Message

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.

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Wed 18 Aug 2010 07:46 AM (UTC) [ quote ]

Message

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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by Nick Gammon Australia (18,770 posts) bio Forum Administrator

Date Wed 18 Aug 2010 07:28 AM (UTC) [ quote ]

Message

Right, well this is partly why I added extra stuff into version 4.57.

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

The post below shows what you can get:

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

www.gammon.com.au, www.mushclient.com

top

Posted by

Zevious (6 posts)

bio

Date

Wed 18 Aug 2010 07:03 AM (UTC) [ quote ]

Message

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.

top

Posted by

Zevious (6 posts)

bio

Date

Wed 18 Aug 2010 06:54 AM (UTC) [ quote ]

Message

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.

top

Posted by

Zevious (6 posts)

bio

Date

Wed 18 Aug 2010 06:49 AM (UTC) [ quote ]

Message

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".

top

Posted by

Zevious (6 posts)

bio

Date

Wed 18 Aug 2010 06:47 AM (UTC) [ quote ]

Message

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.

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Tue 17 Aug 2010 11:20 AM (UTC) [ quote ]

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Deacla USA (42 posts)

bio

Date

Tue 17 Aug 2010 10:38 AM (UTC) [ quote ]

Amended on Tue 17 Aug 2010 10:55 AM (UTC) by Deacla

Message

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.

--

working way to hard to play

top

Posted by Nick Gammon Australia (18,770 posts) bio Forum Administrator

Date Tue 17 Aug 2010 09:59 AM (UTC) [ quote ]

Message

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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by Nick Gammon Australia (18,770 posts) bio Forum Administrator

Date

Tue 17 Aug 2010 09:41 AM (UTC) [ quote ]

Amended on Tue 17 Aug 2010 09:44 AM (UTC) by Nick Gammon

Message

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:

If MXP is enabled, things like <parchment name>
should be sent as <parchment name>.

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.
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

6,536 views.

This is page 1, subject is 3 pages long: 1 2 3

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )