Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Bug reports ➜ MXP issue with Materia Magica
MXP issue with Materia Magica

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 3  

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #15 on Tue 17 Aug 2010 08:20 AM (UTC)
Message
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?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Deacla   USA  (42 posts)  Bio
Date Reply #16 on Tue 17 Aug 2010 08:30 AM (UTC)
Message
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.
--

working way to hard to play
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #17 on Tue 17 Aug 2010 08:31 AM (UTC)
Message
Oh, I see. Got it.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #18 on Tue 17 Aug 2010 09:41 AM (UTC)

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:


  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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #19 on Tue 17 Aug 2010 09:59 AM (UTC)
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 Deacla   USA  (42 posts)  Bio
Date Reply #20 on Tue 17 Aug 2010 10:38 AM (UTC)

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  (23,165 posts)  Bio   Forum Administrator
Date Reply #21 on Tue 17 Aug 2010 11:20 AM (UTC)
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 Zevious   (6 posts)  Bio
Date Reply #22 on Wed 18 Aug 2010 06:47 AM (UTC)
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 Zevious   (6 posts)  Bio
Date Reply #23 on Wed 18 Aug 2010 06:49 AM (UTC)
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 Reply #24 on Wed 18 Aug 2010 06:54 AM (UTC)
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 Reply #25 on Wed 18 Aug 2010 07:03 AM (UTC)
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 Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #26 on Wed 18 Aug 2010 07:28 AM (UTC)
Message
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

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #27 on Wed 18 Aug 2010 07:46 AM (UTC)
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 Zevious   (6 posts)  Bio
Date Reply #28 on Thu 26 Aug 2010 07:26 PM (UTC)
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 Zevious   (6 posts)  Bio
Date Reply #29 on Thu 26 Aug 2010 07:37 PM (UTC)
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

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.

111,452 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home