Example:
Server> IAC WILL TELOPT_TERMINAL_TYPE
MushClient> IAC WONT TELOPT_TERMINAL_TYPE
in Configuration>Appearance>Output there is an option called "Telnet Terminal Type", which defaults to "mushclient". So, I figure the fact that MC refuses to negotiate term type is a bug.
If you check RCC 1091:
http://www.faqs.org/rfcs/rfc1091.html
Part way down the document, this example appears:
8. Examples
In this example, the server finds the first type acceptable.
Server: IAC DO TERMINAL-TYPE
Client: IAC WILL TERMINAL-TYPE
(Server may now request a terminal type at any time.)
You will notice that the server should send "IAC DO TERMINAL-TYPE" and the client responds "IAC WILL TERMINAL-TYPE".
MUSHclient does this.
Further up the page it also says:
2. Command Meanings
IAC WILL TERMINAL-TYPE
Sender is willing to send terminal type information in a
subsequent sub-negotiation.
This is not appropriate for the server (the MUD) to send, because it wants to receive terminal type information, not send it.
I am working on a MUD Client and am making sure that my server detects the clients color system. I send the IAC DO when the socket first accepts:
byte[] cmd = new byte[] { 0xFF, 0xFA, 0x18, 0x01, 0xFF, 0xf0 };
And I recieve a bunch of bytes from the client which has the color system label inside it. I tested this on the windows client and got ANSI, and putty, which I got XTerm, but when I tested this with MUSH Client I received no reply. Am I going about this wrong?
Nevermind, I just made it loop a few times and the client sent me mush client.
Cheers.
Communications are asynchronous. The next thing you receive won't necessarily be the one you asked about. For example in a MUD you might type:
But because of time differences (server queues) you might get:
The sun sets in the west.
... before the response to "look".