If you have been following this blog, you already know that we have been working on a custom version of Mushclient for Aardwolf with plugins pre-installed. As the work on the first version comes to a close, it has been a great learning experience on both sides - several improvements to both the MUD and the client itself were made as a result of this project. One of the problems we consistently faced was how to handle configuration. If the MUD needs a player to have specific options on for a plugin to work, we have to make sure they’re actively in the game and at a prompt to send the commands to activate them. The alternative is relying on players to manage numerous tag and config settings themselves. This is not practical for new users.
To try to solve this, we experimented with various tags but it was never quite right. Nick suggested we look into the possibility of telnet negotiation and after some research we settled on using telnet code 102.
The first phase was to make the mud accept telnet 102 codes because most clients can send them. The general structure of a telnet sequence of this type is: IAC,SB,102,data,data,…,IAC,SE. To send these in Mushclient you do:
SendPkt (string.char (255, 250, 102, 5, 1, 255, 240)
To send the same in zmud:
#sendprompt %char(255)%char(250)%char(102)%char(5)%char(1)
%char(255)%char(240)
This tells the MUD to do something, as if you had entered a command. However, the point of this is that it happens at a level of communication lower than anything to do with commands, timeouts in the game or player state. It works completely independently of where your character is at.
The particular sequence above turns on channel tags. This would work if you were afk or in note mode. If you were at a login prompt (no character loaded yet), it would remember those flags and attach them to your character when you logged in. The only time this wouldn’t work is if you were link dead as there is no socket to receive the options. As the mushclient plugins initialize themselves on connection, this is not an issue.
For enabling plugins and making sure the player has the right tags on in the mud this is extremely helpful. Any client that can send the above codes can use these sequences. The list so far is provided below. To use any of these, send IAC,SB,102,option,1 or 2 (on or off), IAC,SE:
Option Description
1 Statmon
2 Bigmap + Coordinates tags
3 Help tags
4 Map tags
5 Channel tags
6 Tell tags (see ‘help telltags’ in game)
7 Spellup tags (see ‘help spelltags’ in game)
8 Skillgains tags
9 Say tags
11 Score tags
12 Room names in mapper
14 Exits in mapper
15 Editor tags
16 Equip tags
17 Inventory tags
50 Quiet all tags (tags quiet on/off)
51 Turn autotick on/off
52 Turn prompts on/off
53 Turn output paging on/off (remembers pagesize)
So, this solved the problem of the client being able to affect player settings in the mud without needing to care if they’re at a prompt to receive the commands. As a bonus, it also cuts out a lot of “spam” the player would see as output from regular commands sent to turn tags on for each plugin.
What it did not solve is the problem of how can the client know for sure whether you’re active, in note mode, during a login sequence or otherwise paused and unable to receive game commands. By default, clients would be able to send these sequences but not receive them - the client would eat them as telnet sequences not negotiated.
Nick decided this whole setup had enough value to other muds to be worth implementing in the client itself, and did so somewhat extensively. Plugins can listen to telnet 102 sequences and even “wake” and do something on receiving one. You can see his own post about how this was integrated into Mushclient by reading the Mushclient 4.31 release notes.
Having the client capable of receiving these telnet negotiation sequences means that the same can happen in reverse - Aardwolf can send status back to the client without the client having to trigger on anything.
For example, the tick timer in use in the custom Mushclient plugin is always in sync - it receives a telnet message on every tick regardless of the player being in note mode etc. For controlling plugins such as spellups, whenever you go from note mode to active mode to afk to sleeping, the client knows about it.
The telnet sequences being sent from the mud to the client, once type 102 negotiation has been completed, are:
Option Description
100,1 At login screen, no player yet
100,2 Player at MOTD or other login sequence
100,3 Player fully active and able to receive MUD commands
100,4 Player AFK
100,5 Player in note mode
100,6 Player in Building/Edit mode
100,7 Player at paged output prompt
Whenever the player switches from one of these states to the other, the codes are sent. These are easily extendable. For example, it probably makes sense to have a 100,8 which means “Sleeping/Resting”, although this information is already available in statmon.
The only other notification being sent from the mud to client via this mechanism at the time of writing is 101,1 which means “the mud just ticked”.
Unfortunately, for this half of the project, most clients won’t be able to make use of the messages unless the clients themselves are changed to negotiate receiving telnet 102 sequences then make the data available to their scripting engine. CMUD can accept arbitary telnet SB sequences (see comments), but is the only one I’m aware of other than Mushclient. If you know of others, please post in the comments.
The ‘102′ protocol has the potential to be extremely useful for many things between the client and the MUD server. As there is no fixed protocol after the 102, MUD owners could provide many messages available for consumption by players of their games interested in creating their own scripts
This intel first appeared on: http://www.aardwolf.com/blog/2008/07/10/telnet-negotiation-control-...
