08 Nov, 2013, plamzi wrote in the 1st comment:
Votes: 0
I've been doing a lot of tinkering to negotiate a long list of protocols as cleanly as possible with everyone listing on mudportal.com. But I'm hitting an issue with at least one game where, if I initiate an MXP handshake from the client, the server doesn't absorb the binary characters, and the next input attempt from the user is deemed invalid.

The issue: snapshot

biyg.org:1801
Bleached InuYasha Galaxy

The server knows to ignore and absorb IAC WILL GMCP. But if I send IAC WILL MXP on connect, it seems to keep those characters in its input buffer.

You can see the issue in action at the two URL's below. The first one disables the IAC WILL MXP on connect.

(works) http://www.mudportal.com/play?host=biyg....
(no go) http://www.mudportal.com/play?host=biyg....

As far as I can see, every server listed on the Portal that supports MXP is waiting to get IAC WILL MXP (rather than sending it and expecting IAC DO MXP). This includes my server, which is using KaVir's protocol snippet v8. Without sending IAC WILL MXP pro-actively, negotiation doesn't work.

Has anyone else encountered this issue and, if so, what can be done about it other than workarounds? I'd rather not have to ask game admins to do extra stuff, etc.
08 Nov, 2013, KaVir wrote in the 2nd comment:
Votes: 0
The mud isn't explicitly ignoring "IAC WILL GMCP", it's just ignoring non-printable characters (fairly standard behaviour for many muds). The problem is that the value of MXP is 91, which is the "The mud isn't explicitly ignoring "IAC WILL GMCP", it's just ignoring non-printable characters (fairly standard behaviour for many muds). The problem is that the value of MXP is 91, which is the "[" character - it's printable, so it gets parsed, but it's not valid for a name. You'll have similar problems with certain other telnet options as well.

You could try sending backspaces after the negotiation. But you'd be better off doing what most clients do, and waiting for the server to initiate negotiation - that's what most muds expect (some basic/broken implementations may not even work if the client initiatiates negotiation), and it avoids problems like you've described here.

If you're using my snippet, your mud should initiate MXP on its own. You can test it easily enough with TinTin++, just type "#config {debug} on" before you connect and you'll see the negotiation.
08 Nov, 2013, plamzi wrote in the 3rd comment:
Votes: 0
KaVir said:
If you're using my snippet, your mud should initiate MXP on its own. You can test it easily enough with TinTin++, just type "#config {debug} on" before you connect and you'll see the negotiation.


The TinTin++ trace helped a lot, thank you. It's all sorted out now.

Apparently, due to a silly typo, I was missing out on some of the "DO" messages your snippet was sending, so I was under the mistaken belief that the client needed to initiate. Everything is being initiated by the server now, so I hope this is the last negotiation issue for a while.

Thanks again.
0.0/3