Author: Nick Gammon http://www.gammon.com.au/support/ .
This document is in the public domain. It is not copyright.
These notes are intended to complement the MXP specifications at http://www.zuggsoft.com/zmud/mxp.htm.
Comments or questions about this document should be forwarded to http://www.gammon.com.au/support/ or email@example.com .
The purpose of this document is to help MUD client developers implement MXP in a standard way, so that using an MXP-enabled MUD will result in the same gaming experience, regardless of client.
MXP stands for Mud Extension Protocol.
It is a method for MUD servers to specify formatting and content information which goes beyond the scope of what is available with ANSI escape codes. For instance, using MXP a server can designate a line as a room description, exit, hyperlink, and so on.For example:
This word is <b>bold</b>. <RoomDesc>This is a room description</RoomDesc>
Where reference is made to a newline (in C, the \n character) it is intended to encompass the various line endings that a MUD server might send:
In each case this document assumes that whatever line ending occurs, it is pre-processed by the client into a straight "newline" character (\n).
<!ELEMENT red '<color red>'>
<!-- this is a comment -->
<keyword [args]> </keyword> <!keyword [args]> eg. <font color=red>This is in red.</font> <b>This is in bold.</b> <!ELEMENT boldred '<font color=red><b>'>
&keyword; eg. &
By using escape sequences streams of output can be designated as open, secure or locked.
||Open||Only open commands (eg. <B>) will be interpreted.|
||Secure||All MXP tags are interpreted.|
||Locked||No MXP tags or entities will be interpreted.|
Following a newline (\n) the output stream is considered open, until another escape sequence arrives which changes the mode.
This is intended for output from the MUD that players may be able to influence, eg. chat, say, tell, whisper, player descriptions, and so on. Tags in this category are limited to those that are "harmless" like setting text to bold, italic and so on.
This is for the server to send the full range of tags, such as room descriptions, exits, player hit points, and so on.
This is to allow the server to send out "verbatim" text, to save having to "escape" out characters like "<" and ">".
Elements (such as <B>) can either be modal or command.
Modal elements temporarily change the mode of the text being displayed until the closing element.
This is plain text. <B>This is bold text.</B> This is plain text.
Command elements have an immediate effect. There is no corresponding closing tag.
<p> This is a new paragraph.
To guard against room designers (or people chatting) inadvertently forgetting to close their modal elements the client will automatically close outstanding open tags as follows:
All outstanding tags are closed at any of the following:
All outstanding tags are closed at:
<B>This is bold text. <I>This is bold italic text. </B></I>
The </I> should have been sent first. For simplicity of client implementation, the client should close all outstanding tags, up to and including the one requested. In the example above, the </B> would close both the outstanding <I> and the <B>.
To allow for nested font and colour changes, we suggest that clients "push" onto a temporary stack the tag name, and current text attributes (colour, bold, italic, font etc.).
Then when the closing tag is reached the outstanding tag is "popped" from the stack, with the saved text attributes being restored.
Also, in the case of tags like <SEND href=&text;> this would be an appropriate time to send the collected text.
Entities, such as "&", provide simple text substitution. For example, "&" is replaced by the "&" character.
You can define your own entities like this:
<!ENTITY version "version 5.5" >
You cannot nest entities, nor can you place elements inside entities. The text defined as the entity replacement text is simply displayed "as is".
Elements, such as "<B>", are one of:
These are predefined elements that have a well-known meaning to client programs, such as <B> for bold, <COLOR> for colour changes, and so on.
These cannot be defined by the server, because to add new atomic elements requires changes to the client program.
These are defined by the server by using the syntax:
<!ELEMENT element_name definition [ATT=attribute_list] [TAG=tag] [FLAG=flag] [OPEN] [DELETE] [EMPTY]>
Effectively these act as a 'macro expansion' much as a #define does in C. It lets server implementors combine elements, to simplify various situations.
<!ELEMENT bolditalic '<B><I>'>
This is plain text <bolditalic> this is bold italic </bolditalic> this is plain again.
eg. <!ELEMENT bolditalic '<B><I>'>
<bolditalic> now expands to <B><I>
eg. <!ELEMENT bolditalic '<B><I>'>
</bolditalic> now expands to </I></B>
Macro expansion elements can contain an attribute list, which effectively becomes "arguments" to the expanded elements.
<!ELEMENT colorbold '<COLOR &col;><B>' ATT='col=red'> <colorbold>This text is in bold red</colortext> <colorbold col=blue>This text is in bold blue</colortext> <colorbold blue>This text is in bold blue</colortext>
We suggest that for each macro-expansion element the client stores:
Then when the element is encountered in the text stream:
The closing tag (eg. </colorbold>) for an element will cause the element to be searched for in the 'outstanding elements' list, and if found, removed. Also at this time:
In the case of macro-expansion elements, the definition list will be walked in reverse order, and each definition in it will be closed. eg. <B> will be processed as </B>.
An element that is neither recognised as an atomic element, nor a macro, is silently discarded, with an optional debug message.
Note - the client may offer the option to display unknown elements, although this is not recommended, as it makes using older clients with MUDs that use newer tags display irritating unknown tags.
Comments to http://www.gammon.com.au/support/
Page updated on Sunday, 13th January 2001