08 Nov, 2013, KaVir wrote in the 2nd comment:
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.
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:
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.
Random Picks
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.