Intermud-2 Services


Here is a list of all services used by the Intermud-2 protocol. Well, I didn't really know that it was called Intermud-2, as it came with our mudlib. And I don't have a clue what whould be Intermud-1 then, but anyway, this is it! The CD protocol has been ported by Pinkfish@Discworld and in August '93 by Grendel@TMI-2 even later (April '96) from here on by Annihilator@ES2 (Eastern Stories)

Features that were included in the original (CD) implementation are marked with a [*]. All other commands are only supported by certain mudlibs and are not standard.

Note that it is common practice to send the "NAME" and "PORTUDP" with all outgoing messages. However they must be send only with messages for which a reply is requested. Some muds even completely ignore messages when no "NAME" parameter is suplied. These two paramaters will not be mentioned every time in the description below.

"gfinger_q"
Retreive information about a player or creator on a remote mud.

"ASKWIZ"
The real name of the person who asks the information

"PLAYER"
The name of the player about who info is asked

"gfinger_a"
The answer to a "gfinger_q"-request: finger information about a player.

"ASKWIZ"
This value must be the same as in the query

"MSG"
The available finger information

"gtell"
This was one of the first extensions and is supported by practically every mud which uses this protocol. You use it to tell something to a person on another mud.
The confirmation of a tell, should come in a "affirmation_a" packet; however many muds simply send a "gtell" message back from a non-existant user (e.g. "root" or "udp-daemon") telling you whether the message was shown to the remote user, or not.

"WIZFROM"
The name of the person who says something

"WIZTO"
The name of the person to whom is spoken

"MSG"
The actual message

"affirmation_a"
This is the affirmation of a "gtell" message.

"TYPE"
This value always is "gtell"

"WIZFROM"
The name of the person who received the tell message

"WIZTO"
The name of the person to send the confirmation to

"MSG"
The actual affirmation message

"gwizmsg" [*]
This is sent from one mud to another holding a message to present on the 'global wizline'.

"WIZNAME"
Name of the wizard sending the message

"GWIZ"
The actual message text as given by the wizard

"EMOTE"
The integer 1 if this message is to be interpreted (shown) as an emote (like Koresh smiles), or 0 otherwise. EMOTE is part of the original protocol implementation

"CHANNEL"
This option was added later to support several channels. Currently known are 'CREATOR' and 'HUNGARY'

"gchannel"
This is sent from one mud to another holding a message to present on yet another 'global wizline'. It is an extension to the default wizline and was probably introduced by the Eastern Stories mudlib (based on TMI-2). The 'es' channel is supposed to be restricted to MUDs with this mudlib; and the 'twiz' (taiwanese wizards) channel to IP-numbers starting with 140. I say "supposed", because they all show up in my logfiles ;-)

"USRNAME"
Name of the wizard sending the message in ASCII

"CNAME"
Name of the wizard sending the message in Big5 character set

"CHANNEL"
The channel this wizards uses: known channels are 'es', 'gwiz', 'twiz' and 'jy'

"MSG"
The actual message text as given by the wizard (usually in Big5 characters)

"EMOTE"
The integer 1 if this message is to be interpreted (shown) as an emote (like Koresh smiles), or 0 otherwise

"locate_q"
Check whether a certain player is logged on (or exists) in this mud. This request is usually send to all known muds at once.

"ASKWIZ"
The real name of the person who asks the information

"TARGET"
The name of the player we are looking for

"locate_a"
The answer to a locate-request. Some muds only send a reply when the person was actually located (and leave out the "LOCATE" parameter).

"ASKWIZ"
This value must be the same as in the query

"TARGET"
This value must be the same as in the query

"LOCATE"
"yes" or "no", depending on success

"mail_q"
This extension was first added in August 1993 by Inspiral@Tabor. Use this to send an intermud mail message to somebody at another mud. Note that mail messages are usually longer than the maximum size of an UDP packet, so they will be split up in several packets. Some MUDs only support these messages over TCP connections.

"WIZTO"
The mail recipient

"WIZFROM"
The mail sender

"DATE"
A timestamp for the mail (usually in seconds since 1-1-1970)

"SUBJECT"
A subject for the mail message

"CC"
Optional adresses for extra recipients

"ENDMSG"
The value is "1" iff this is the last packet of a message, it is usually omitted for preceding messages This should always be 1 if the message fits in a single packet

"MSG"
The contents of the mail: this may be a multi-line string

"mail_a"
Confirmation for a received intermud mail message.

"ENDMSG"
Present with value "1" iff the mail_q had this set as well

"RESEND"
Optional: ask the originator MUD to resend a message that could not be processed. I've never seen this option actually being used...

"mudlist_q" [*]
Request info about all muds known by the remote host.

"mudlist_a" [*]
This is the answer to a mudlist query.

"0" (a numeric index, one for each mud)
This is the only standard service which uses subindices. The subindices are the same for each index:

"NAME"
The name of the mud (case-sensitive!)

"HOST"
The fully qualified hostname running the mud

"HOSTADDRESS"
The IP adress used to talk with the mud

"PORT"
The portnumber for players to connect to

"PORTUDP"
The portnumber to receive udp messages on

"ping_q" [*]
This command is sent from one mud to another to request information.

"ping_a" [*]
This command is sent as an answer to a ping query. The parameters are the same as in the startup command.

"rwho_q"
This extensions is used very often as well. It will list the users on the remote mud.
Only one parameter is used:

"ASKWIZ"
The real name of the person who asks the information

"rwho_a"
The reply to a rwho query. There is no standard layout for the reply; it should be shown directly to the player who requested the info. Admins are free to include as little or as much information as they like (titles, levels, etcetera).

"ASKWIZ"
This value must be the same as in the query

"RWHO"
The string listing all users on the remote mud

"shutdown" [*]
This command is sent when the mud shuts down. Parameters are the same as used by the "startup" message.

"startup" [*]
This command is sent when the mud starts. It is supposed to be sent to a 'mud server', however some muds send it to all known hosts, but mosts don't send it at all...

"VERSION"
The version of the GameDriver, e.g. "CD.04.05.Sky"

"MUDLIB"
The version of the mudlib, e.g. "CD.00.25.OS"

"HOST"
The fully qualified hostname running the mud

"PORT"
The portnumber for players to connect to

"TIME"
The localtime of startup, UNIX ctime-format

"TCP"
The supported TCP service level, this is one of the following values:
none
No TCP support. Assumed when the TCP paramater is missing.
some
Limited TCP support: TCP is only used for mail.
all
Full TCP support: hopefully the default. This implies that TCP is preferably used for mail and finger commands with optional support for long tell-messages. Wizlines and rwho messages are still supposed to use UDP.
only
No UDP support. If this is the case, I strongly suggest you don't bother implementing this protocol as you will not be able to communicate with many others.
The default port for TCP connections seems to be (don't ask me why) one portnumber above the UDP listening port.

"supported_q"
Check whether a remote mud supports a certain intermud service.

"CMD"
Any intermud command (e.g. "ping_q")

"ANSWERID"
An unique id for recognizing the answer (this can be the name of a player when the message is initiated by one).

"supported_a"
In the original protocol, this (undocumented) command returns the "SUPPORTED" parameter with value "yes" when the command is supported and "NOTSUPPORTED" with value "yes" otherwise. However some implementations appear to be using the "no" value for "SUPPORTED" in the latter case. Either way: a mud should not really depend on the answer to this query.

"CMD"
This value must be the same as in the query

"ANSWERID"
This value must be the same as in the query

"SUPPORTED"
The only defined value is "yes"

"NOTSUPPORTED"
The only defined value is "yes" (To avoid confusion, SUPPORTED and NOTSUPPORTED should never be used in combination!)

"warning" [*]
This is sent as to warn another mud that someone is trying to send messages using the same mudname but from another host. The standard way to handle warnings is to simple ignore those.

"MSG"
A message containing the warning

"FAKEHOST"
IP address of the falsifier

Return to the OuterSpace index
Last modified Thu Oct 7 22:24:04 2004, by Dyorion