The MUD eXtension Protocol (MXP) is an open specification for enhancing the communication between MUD servers and clients. To contribute to this specification, email email@example.com or participate in the Developer's Forum on www.zuggsoft.com.
Version 0.5 (18-Oct-01)
- Overview of MXP
- MXP Line Tags
- MXP Reference
- Elements <!ELEMENT>
- Attributes <!ATT>
- Entities <!ENTITY> <VAR>
- User-defined Line Tags
- Tag Properties
- MXP Tags
- Text Formatting <B> <I> <U> <S> <H> <COLOR> <FONT>
- Line Spacing <NOBR> <P> <BR> <SBR>
- Links <SEND> <A> <EXPIRE>
- Version Control <VERSION> <SUPPORT>
- Optional Tags
- MSP Compatibility <SOUND> <MUSIC>
- Using Entities <GAUGE> <STAT>
- Frames <FRAME>
- Cursor Control <DEST>
- Cross-linking Multiple MUD Servers <RELOCATE> <USER> <PASSWORD>
- Images <IMAGE>
- File Filters <FILTER>
- Outdated Tags
- Server-side Scripting <SCRIPT>
- Implementation Details
- A Detailed Example
MUD Servers communicate with MUD Clients via the Telnet Protocol. While Telnet is the basis of most Internet protocols (FTP, HTML, SMTP, etc), most of these protocols enhance Telnet with their own higher-level protocol in order to provide more specific and directed features. For example, FTP adds a command language for transferring files via the Telnet socket connection.
Traditionally, MUDs have used raw Telnet. MUD sessions have been enhanced using standard terminal protocols, such as ANSI and VT100 to add color and cursor control. However, there is no higher-level command protocol used by MUDs to enhance the game session. The MUD eXtension Protocol (MXP) attempts to fill this gap by providing a markup language based loosely upon HTML and XML that allows better communication between the MUD Server and Client.
The design goals for MXP are:
NOTE: The copyright for the MXP protocol has been removed by Zugg Software as of MXP version 0.1. Zugg Software will still lead the development of MXP, but any MUD client or server is welcome to use and extend this specification as desired. Zugg Software will coordinate the documentation of MXP in the Developer's Forum at the web site: www.zuggsoft.com. Send all proposed changes to firstname.lastname@example.org to get them incorporated into this spec.
MXP is based loosely on the HTML and XML standards supported by modern web browsers. It is only "loosely" based upon these standards because MUDs require dynamic, streaming text, rather than the page-oriented view of web browsers. Also, the existing standards are needlessly verbose for use on a MUD where text efficiency is important.
In addition, there are additional security concerns to worry about with MXP. While support for HTML tags within a line is desired, players on a MUD can exploit this power and cause problems. Certain HTML functions need to be restricted so that MUD players cannot abuse them. For example, while it might be desirable to allow players to change the font or color of their chat messages, you would not want to allow them to display a large graphics image, or execute script commands on the client of other users. MXP handles this by grouping the various tags and commands into secure and open categories, and preventing the secure tags from being used by MUD players.
Two additional Client/Server protocols are not discussed in this document. The MUD Sound Protocol (MSP) is a separate specification, and while MXP provides compatibility with MSP, it does not add any additional sound support of its own.
The core of MXP involves tagging text lines sent by the MUD. Each MXP command is marked as either "Open" or "Secure". Lines sent from the MUD are also marked as "Open" or "Secure". On an "Open" MUD Line, only "Open" MXP commands are allowed. On a "Secure" MUD line, both "Open" and "Secure" MXP tags are allowed. Additional "open" tags can also be used to group lines from the MUD into channels that the user can easily control on the client.
MUD Server Implementation Note: Be very careful when sending Secure lines from the MUD. Be absolutely sure that MUD players cannot control the output of a secure line. If a MUD player is able to send a secure MXP command, he will be able to cause great damage to other MUD players using MXP.
To ensure that tags are difficult to send by MUD players, an escape sequence, similar to ANSI or VT100 is used:
<ESC> [ # z
where # is the tag number to use. Tag numbers are defined as:
The following additional modes were added to the v0.4 MXP spec:
The following modes are client-specific and were implemented in the v0.3 MXP spec by zMUD:
Note that the tag numbers from 10-19 are reserved for automapper usage. MUDs can easily support the automapper by simply tagging lines sent to the client using these codes. However, MUDs that fully support the MXP spec should mark the automapper information using the MXP tags described later rather than just tagging the line.
As with VT100 and ANSI sequences, the tag number is sent as decimal text. So, for example, to tag a line as "secure", the sequence: <ESC>[1z is sent from the MUD (where <ESC> is ascii character 27).
When the mode is changed from OPEN mode to any other mode, any unclosed OPEN tags (tags that were used while in open mode) are automatically closed. Also, when in OPEN mode, any unclosed OPEN tags are automatically closed when a newline is received from the MUD.
Note that secure tags are never automatically closed (this is a change from the 0.3 spec). Be sure to close your secure tags sent from the MUD, or use the Reset mode periodically.
The core of MXP involves "Elements." Elements are like normal HTML tags. For example <B> is an element called "B". It causes text to be bolded. To turn off the bold, the </B> element is used. Each element has a corresponding closing element that starts with a /. The exception are Commands. Commands are elements that do not require a closing tag. For example, the element <BR> causes a line break. No closing tag is needed.
Borrowing a feature from XML, MXP allows you to define your own elements. This is the true power of MXP. By defining your own elements and giving them short names, you can cause complex output formatting in only a few short characters.
In addition to Elements, you can also define "Entities." Entities are like macro string replacements. For example, in HTML, the entity < indicates the < or less-than symbol. Since a normal < symbol is interpreted as the start of an element tag, you must use < to refer to a less-than symbol directly. Entities are accessed by putting a & character in front of the entity name, and terminating the name with a ; character. All of the standard HTML entities are available in MXP, including the &#nnn; entity to insert character /nnn into the text stream. Note that nnn values less than 32 are ignored.
Of course, like in XML, you can define your own entities in MXP. MUD-defined entities work much like server variables. For example, you could store the player's hit-points in an entity called &hp;
Here is a list of each MXP command, along with it's purpose and abbreviation:
<!EL Command EMPTY>
specifies a tag called <Command> which does not require a closing </Command> since it has no content.
The 'Definition' is the optional macro expansion for this element. You can use a list of any text or other MXP commands in this definition. For example, to create a new element called "RED" which colors text red and makes it bold, you would define it as:<!ELEMENT red '<COLOR red><B>'>
And then you could use it in your MUD output like this:<red>This text is bold and red</red>
The 'Attribute-list' allows you to define arguments or attributes for your element. You can optionally specify the attributes using the <!ATTLIST> MXP command described later, or you can include them in the <!ELEMENT> definition for simplicity. To create an element that would allow you to change the text color, but would default to red, you would do:<!ELEMENT boldtext '<COLOR &col;><B>' ATT='col=red'>
Then you could use it on the MUD like this:<boldtext>This is bold red</boldtext> <boldtext col=blue>This is bold blue text</boldtext> <boldtext blue>This is also bold blue text</boldtext>
Note that you use an attribute in the element definition by referring to it as an entity. In this case, the temporary entity &col; refers to the color attribute that is passed. The 'col=red' defines the attribute, and gives the default value of 'red'. When the new element is used, the name of the attribute can be omitted if you give the arguments in the same order as the definition. That is how the third example is able to work.
The TAG=tag argument allows you to associate an element with a user-defined line tag. This is explained more in a later section.
The FLAG=flags argument allows you to assign an internal action to the element. This is explained more in a later section.
The OPEN argument sets the defined element to be an "Open" element. By default, elements are created as "Secure" elements.
The DELETE argument allows you to delete an element previously defined.
Security Note: Elements are marked as to whether they are created by the MUD or created interactively by the user. The user cannot override Secure elements sent from the MUD. The user is only allowed to override Open elements sent from the MUD.
Implementation Note (MXP v0.1): Attribute lists were changed from the earlier MXP spec. The data type of the attributes are no longer specified, since the type is not important to the MUD server of client.
- To define attributes, simply list the names of the attributes in the order that you want. To add an optional default, use the syntax =Default after the attribute name. For example the command:<!ATTLIST boldtext 'color=red background=white flags'>
Specifies the attribute list for the 'boldtext' element. The first argument is called 'color' and has a default value of 'red'. The second argument is called 'background' and has a default value of 'white'. The third argument is called 'flags' and has no default value.
Note that you can specify the attribute list using the ATT='list' argument in the <!ELEMENT> definition. Because of this, there is little use for the <!ATTLIST> command except for modifying the argument list on-the-fly without changing the original definition.
For example, here is the full MSP Sound command as defined in MXP:
<!ELEMENT Sound EMPTY> <!ATTLIST Sound FName V=100 L=1 P=50 T U>
The full usage of this element would normally be:
<SOUND FName="ouch.wav" V=50 L=2 P=80 T="combat" U="http://www.zuggsoft.com/sounds/">
But in MXP, the shorthand could be used:
<SOUND "ouch.wav" 50 2 80 "combat" "http://www.zuggsoft.com/sounds/">
You can omit some parameters using "" to specify the default, or mix attribute names in:
<SOUND "ouch.wav" "" 2 T="combat">
would be the same as
<SOUND FName="ouch.wav" V=100 L=2 T="combat">
Note the "" to specify the default for the V attribute. The P and U attributes also take their defaults since they are not specified at all. The T= overrides the parsing and tells MXP that the following value is for the T attribute instead of the P attribute that it was expecting at that position in the element.
<!ENTITY Version "6.15"> The current version of zMUD is &version;
The current version of zMUD is 6.15
Tags can be included within entities. Unlike in XML, tags can be broken across entities within MXP as long as when all entities on a line from the MUD are expanded, all of the tags are properly closed (or MXP will close the dangling tags for you). So, the following is valid in MXP:
<!ENTITY Start "<em>"> <!ENTITY End "</em>"> &Start;This text is emphasized&End;
Also note that as in XML, entities are case sensitive, so &Start; is different than &start;. Unlike XML, entities can be used anywhere in MXP, even within other tags. However, if an external entity has the same name as an attribute, the attribute within a tag takes precedence.
All of the default HTML entities are defined in MXP.
To delete an entity, use the DELETE argument. Setting an entity to a empty value does not delete it.
PRIVATE entities cannot be queried by the MUD client. They are completely hidden.
PUBLISH entities can be used by the client to produce a list of MUD Server variables to be access by the player
The DESC description is used to give your entity a longer description
The ADD argument causes the Value to be added as a new item in a string list. So, it is appended to the existing value of the variable. String lists are values separated by the | character.
The REMOVE argument causes the Value to be removed from the existing string list.
Security Note: Entities are marked as to whether they are created by the MUD or created interactively by the user. The user cannot override Entites sent from the MUD. The user is only allowed to override user-defined entities.
Hp: <VAR Hp>100</Var>
As mentioned near the beginning of this spec, a simple escape sequence can be used to tag a line. The tags 20-99 are defined by the MUD. The main purpose for user-defined line tags is to allow the user to customize how these lines are displayed. In particular, if the tag element is Open, the user can change the color, gag, or redirect the tagged line. This is useful for various chat channels on the MUD. Simply give them a name, and perhaps a default color, and make them open to allow the client user to gag them or redirect them to a different frame or window. Here is an example of an auction channel that can be controlled by the client user:
<!ELEMENT Auction '<FONT COLOR=red>' TAG=20 OPEN> <ESC>[20zA nice shiny sword is being auctioned. <Auction>Also, a gold ring is being auctioned.</Auction>
This also shows the two different ways the MUD server would then send text on this new auction channel. The use of the user-defined tag (<ESC>[20z) sends less text to the client, although the regular use of the tag name is easier to read and understand.
In both cases, the line is displayed to the user in red, by default. However, the user can change the attributes of this tag in the client, allowing them to change the color, gag the line, or redirect it to a different window.
Note that if the OPEN tag is left out, the user cannot change how the line is displayed.
MUD Clients can define properties tags to be used by the server in !ELEMENT definitions. The syntax is FLAG='value'. The following special flags are defined in zMUD:
<!ELEMENT Hp FLAG="Set hp"> <Hp>100</Hp>
would set the @hp variable in the user's session to 100.
NOTE: Only the tags described in this section are OPEN tags. All other MXP tags are SECURE tags.
Also, unlike HTML, normal spacing still applies to the MUD output in MXP. So, anywhere that there is a newline in the MUD output, a new line appears on the client. Multiple spaces are not absorbed, but are displayed as sent by the MUD. Tab characters can still be used for tab stops, and ANSI and VT100 codes can still be used as normal. This provides a very rich output environment for the MUD which has the best of both worlds between standard Telnet text and HTML tags.
The http:// URL will open the user's external web browser to the specified web page. The telnet:// URL will open another window for the specified telnet address and port. The mailto: URL will open your email client allowing you to send email to the specified address.
Example: <A "http://www.zuggsoft.com>Click here for zMUD</A>
The MUD client would display "buy bread" as a link (underlined). If the user clicks on this link, the text "buy bread" is sent to the MUD.
You can make the text sent by the link and the text displayed to the user different using the HREF attribute for the <send> command. You can refer to the text being displayed using the entity value of &text; For example, if displaying a list of items to be purchased from the store when the user clicks on the item, you could send:
<send href="buy bread">bread</send> <send href="buy water">water</send>
This would display the text "bread" and "water" and send the appropriate "buy" command when they are clicked. To minimize the text sent by the MUD in this case, it would be easier to set up your own Element for the store. For example:
<!ELEMENT Item '<send href="buy &text;">'> <Item>bread</Item> <Item>water</Item>
Would display the same list and still send the correct "buy" command to the MUD when the item is clicked on. In each case, the &text; entity is filled in with the text between the opening <Item> and closing </Item> tags.
Of course, you can omit the HREF= part since the first attribute of <send> is the command text. So, the real short form of this example would be:
<!EL Itm '<send "buy &text;">'> <Itm>bread</Itm> <Itm>water</Itm>
(MXP v0.2): You can change the mouse-over text of the link using the HINT="text" argument to the SEND tag.
<send "command1|command2|command3" hint="click to see menu|Item 1|Item 2|Item 2">this is a menu link</SEND>
will create a link on the text "this is a menu link". When the mouse is moved over this link, the text "click to see menu" will be displayed. If you click on the link, a menu with 3 items will be displayed. If you select "Item 1", the "Command1" is sent to the MUD.
<SEND EXPIRE="Exits">E</SEND> <EXPIRE Exits>
will remove all links that used the EXPIRE="Exits" option in either the <SEND> or <A> tags.
Using <EXPIRE> without any Name argument will expire any <SEND> or <A> tags no matter what Expire Name was given, as long as some name was given. <SEND> and <A> tags that never specified an Expire Name never expire.
<VERSION MXP=mxpversion STYLE=styleversion CLIENT=clientname VERSION=clientversion REGISTERED=yes/no>
The "mxpversion" is the version of the MXP spec implemented by the client. For example, MXP=0.4
The "styleversion" is the current version of the optional style sheet. A MUD sets a style-sheet version number by sending the <VERSION styleversion> tag to the client. The client caches this version information and returns it when requested by a plain <VERSION> request.
The "clientname" is the name of the MUD client. For example, CLIENT=zmud
The "clientversion" is the version of the MUD client. For example, VERSION=6.07
The REGISTERED argument is optional and can be used to detect if the player is using a registered version of the client.
Other arguments can be added to this TAG as needed without breaking older versions.
NOTE: The <VERSION> tag is sent back to the MUD as a SECURE-tagged line. This means that the MXP command is prefixed by <ESC>[1z and followed by a newline. This information makes it easy for the MUD to determine that this information was sent by the client and not by the player.
To determine all of the tags supported by the client, just send <SUPPORT> with no arguments. An example of the text returned to the MUD is:
<SUPPORTS +B +I +COLOR>
To show that the only MXP tags supported by the client are the <B>, <I>, and <COLOR> tags.
To determine if a specific tag is supported, use it as the argument to the <SUPPORT> tag. For example, to determine if the client supports the <IMAGE> tag, send <SUPPORT image> and the client will return <SUPPORTS +image> if the image tag is supported, or will return <SUPPORTS -image> if the tag is not supported.
You can query an entire list of tags at once by adding them to the tag. For example, to query both the IMAGE tag and the FRAME tag, you can send <SUPPORT image frame> and the client would return <SUPPORT +image -frame> if it supported image but did not support frame.
You can also query the arguments of a tag. For example, to determine the arguments for the <color> tag, use the syntax <SUPPORT "color.*"> The * asks for all arguments, and the client should send back: <SUPPORTS +color.fore +color.back> to indicate that the two arguments supported for the <color> tag are FORE and BACK. To query a specific argument, replace * with the argument name. For example: <SUPPORT color.fore> would return <SUPPORTS +color.fore>.
You can mix and match any of these in the list of arguments. For example:
<SUPPORT "color.*" send.expire image>
might return: <SUPPORTS +color.fore +color.back -send.expire -image>
It is very important to implement the <SUPPORT> tag in your MUD server. This is the only way to determine what tags are really supported by the client. The MXP version number isn't enough information to determine this, and using <SUPPORT> is easier and better defined than trying to decide based upon what MUD client is being used.
The tags given in this section may or may not be implemented by MXP clients. Use the <SUPPORT> tag to determine if the client implements the tag. In general, this section provides ideas for client developers interested in extending the MXP concepts, without describing tags that are required to be part of the implementation.
The following additional HTML tags might be supported within MXP:
For MSP Compatibility, the <SOUND> and <MUSIC> tags are available in MXP. They have the same keyword syntax and the equivalent !!SOUND and !!MUSIC MSP tags.
The MUD can instruct the client to automatically create a graphical Gauge or Status Bar text from MXP entities.
Creates a graphical gauge. The value of the first Entity is used as the gauge data. The Max= argument specifies the name of the entity to use for the maximum value of the gauge. The Caption= text is optionally displayed on the gauge by the client. The Color gives the color of the gauge bar.
Creates a new Status Bar text on the client. Text is appended to current status bar. The value of the entity given by the first EntityName is displayed. If the Max= argument is given and the entity named by the Max= argument is Published, then the client displays the text as nnn/mmm where nnn is the first entity value, and mmm is the Max entity value.
HTML allows you to define regions of your browser window called frames and can direct a separate HTML document to each frame. With MXP, everything needs to be specified from the single MUD text stream, so the normal syntax for frames in HTML does not work for MXP.
Defining a frame in MXP is similar to HTML, but different enough that you should note the syntax. First, the <FRAME> and <FRAMESET> tags are effectively combined. Then, instead of a SRC URL link for the frame, the frame is simply given a name.
The attributes for the <FRAME> tag are:
The frame borders are controlled by the client rather than the server. The server should assume that the frames do not have borders. The user can turn on borders in order to see the frames and resize them if allowed.
Overlapping frames are not supported and can cause undesired results (overlapping text that interferes with the text of the other frame). So, make sure your frames are properly located.
<FRAME Name="Status" Height="2c">
Creates a two-line high status bar at the top of the current MUD window.
<FRAME Name="Map" Left="-20c" Height="20c">
Creates a frame in the upper-right corner of the MUD window 20 characters wide by 20 characters high.
<FRAME "Chat" Height="10c" RESIZE>
Creates a resizable frame along the top 10 characters of the current MUD window.
To send text to a particular frame, you use the <DESTINATION> tag (or <DEST> for short). For example, to send a status message to the Status frame, you would use:
<DEST Status>This text is sent to the status window</DEST>
The <DEST> tag can also be used to position text at a certain position in a frame. So, instead of using VT100 or ANSI escape codes to move the cursor, you can just use the X and Y attributes of the <DEST> command. If no frame name is given, the text is sent to the position on the main MUD window. Note that when text in a frame or window scrolls, the text is no longer at the same X or Y position. So, for status windows, ensure that you set the frame to be unscrollable.
<DEST Status X=10 Y=2>100</DEST>
Would display the text "100" at the 10 column on the 2nd line of the Status frame.
To erase text already in the frame, you can output spaces, or you can use two of the erase attributes for the <DEST> tag. The EOL keyword causes the rest of the line to be erased after displaying the text. The EOF keyword causes the rest of the frame to be erased after displaying the text. You can erase an entire line using the Y= parameter with no text. You can erase the entire frame by just omitting any text and other keywords. So,
<DEST Status Y=2 EOL></DEST>
would erase the 2nd line in the status frame, while
<DEST Status EOF></DEST>
would erase the entire status frame.
Implementation Note (MXP v0.3): The function of the <RELOCATE> command has been changed, and the previous <LOGIN> tag has been replaced by <USER> and <PASSWORD>.
MXP also supports commands that allow multi-server MUD worlds to be built. The <RELOCATE> tag closes the current MUD connection and causes a new connect to open on a new server. The attributes for this tag are the hostname and port of the new connection:
<RELOCATE new.server.com 1000>
The optional keyword QUIET can be used to suppress further output from the MUD. When the closing </RELOCATE> tag is used, MUD output is resumed. When using the QUIET tag you'll normally put the </RELOCATE> tag after your login sequence to prevent the user from seeing the login text.
To automatically log the user into the other server, use the <USER> tag to cause the client to send the username, and the <PASSWORD> tag to cause the client to send the password.
You can also use <USER> and <PASSWORD> without using the <RELOCATE> command. Putting these two tags in your login sequence will cause MXP-enabled clients to automatically send the user's name and password, instead of relying on client-side scripting for autologin.
MXP supports an <IMAGE> tag to display inline graphics images. GIF or BMP images are supported. Additional image types or encrypted images can be supported with MUD-specific Filters as described in the next section.
This is similar to the <IMG> HTML tag but doesn't implement some of the HTML options. The <IMAGE> tag is very similar to the <SOUND> tag (or !!SOUND command) in MSP. The attributes of the <IMAGE> tag are:
Note that when using images, the act as large individual characters as far as the client is concern. Text cannot wrap on multiple lines next to an image...an image always takes up the entire height of the line. Text wrapping to the next line will wrap at the normal left margin of the screen until the graphics image. So, if inline graphics are used, you should make them similar in size to the surrounding text line. Also remember that the user might be using a different screen font.
The <IMAGE> command is intended to be used with graphic images already loaded to the client's disk. Using the URL attribute to download graphics on the fly can cause a severe burden to the MUD server. However, even if the URL attribute is used, the image file is not downloaded if it already exists on the disk. So, since the image is only downloaded once, the MUD server might be able to handle it. Also, as with MSP, the downloading will never overwrite an existing file with the same name as a security precaution, or allow any absolute path information. The file will be stored in a location determined by the client. To update an image to a new version, you need to specify a new filename.
It is likely that the MUD does not want all of the images stored on the clients disk to be viewable until the MUD server requests them. MXP allows the MUD to define it's own graphics format and to provide a client plugin module that converts the MUD-specific format to a standard GIF or BMP format. To define a filter, use the <FILTER> tag, with the SRC attribute to specify the file extension of the MUD-specific format, and the DEST attribute to specify the output file extension (default is BMP). The NAME attribute gives the name of the plugin to be called, and the optional PROC attribute is a numeric parameter that the plugin can use to support multiple conversions as needed. So, an example would be:
<FILTER SRC='gff' DEST='gif' NAME='MyPlugin'>
This would call the Filter function in the MYPLUGIN plugin module whenever the MUD tries to display a .gff file. The .gff file is read into memory and passed to the Filter function in the plugin (with PROC=0 in the above example) and expect a .gif format output to be returned by the function. Simply provide your plugin for users and you can then store proprietary files on the client that are decoded and displayed as needed. Note that this same Filter function can also be used to process sound files used by MSP.
The <SCRIPT> tag is no longer supported in version 0.4 MXP. There were too many client-specific security issues involved in this tag.
To implement MXP on a MUD server requires some attention. Most important, you need some way to activate the MXP text output on the MUD. You don't want to display the MXP tags to a user that doesn't have an MXP MUD client. One way to activate MXP on your MUD is to simply prompt the user and ask if they want to enable MXP, or provide an MXP command on the MUD that toggles MXP text on and off.
If you want to get more sophisticated, you can use the Telnet Option negotiation to determine if the client supports MXP. Simple query Telnet option 91 and an MXP client will respond that it will handle MXP. You can also use the Telnet option to determine if the client supports the MUD Sound Protocol (MXP) or the MUD Compression Protocol (MCP). The following Telnet Option numbers are used:
86 MUD Compression Protocol (see MCP
spec for details on the difference between option 85 and option 86)
90 MUD Sound Protocol (MSP)
91 MUD eXtension Protocol (MXP)
Although MXP does not support a separate style sheet, you would be best off in your implementation if you stored all of your !ELEMENT and !ENTITY definitions in a separate file and sent them to the client as part of your welcome message. This would give you one place to change your tags on the MUD. The MUD output itself would then use these elements. You should try to avoid using MXP commands within the specific room output of a MUD and instead encapsulate them into MUD-defined ELEMENTS so that you can easily change how your MUD looks and operates.
Want a more complete example of all of this? I thought so. Here is a basic MXP package the you can use on your MUD to handle the most common MUD functions. Go through this example line by line with the documentation above and you should be able to figure it out. Once you get the hang of it, it is pretty easy.
<!-- Elements to support the Automapper --> <!ELEMENT RName '<FONT COLOR=Red><B>' FLAG="RoomName"> <!ELEMENT RDesc FLAG='RoomDesc'> <!ELEMENT RExits '<FONT COLOR=Blue>' FLAG='RoomExit'> <!-- The next element is used to define a room exit link that sends the exit direction to the MUD if the user clicks on it --> <!ELEMENT Ex '<SEND>'> <!ELEMENT Chat '<FONT COLOR=Gray>' OPEN> <!ELEMENT Gossip '<FONT COLOR=Cyan>' OPEN> <!-- in addition to standard HTML Color specifications, you can use color attribute names such as blink --> <!ELEMENT ImmChan '<FONT COLOR=Red,Blink>'> <!ELEMENT Auction '<FONT COLOR=Purple>' OPEN> <!ELEMENT Group '<FONT COLOR=Blue>' OPEN> <!-- the next elements deal with the MUD prompt --> <!ELEMENT Prompt FLAG="Prompt"> <!ELEMENT Hp FLAG="Set hp"> <!ELEMENT MaxHp FLAG="Set maxhp"> <!ELEMENT Mana FLAG="Set mana"> <!ELEMENT MaxMana FLAG="Set maxmana"> <!-- now the MUD text --> <RName>The Main Temple</RName> <RDesc>This is the main hall of the MUD where everyone starts. Marble arches lead south into the town, and there is a <i>lovely</i> <send "drink &text;">fountain</send> in the center of the temple,</RDesc> <RExits>Exits: <Ex>N</Ex>, <Ex>S</Ex>, <Ex>E</Ex>, <Ex>W</Ex></RExits> <Prompt>[<Hp>100</Hp>/<MaxHp>120</MaxHp>hp <Mana>50</Mana>/<MaxMana>55</MaxMana>mana]</Prompt>
This would display the following:
The Main Temple This is the main hall of the MUD where everyone starts. Marble arches lead south into the town, and there is a lovely fountain in the center of the temple. Exits: N, S, E, W
and set the variables @hp, @maxhp, @mana, @maxmana appropriately. Clicking on the exit links would send the proper direction to the MUD to move you in that direction. It would send the "drink fountain" command if the user clicked on the underlined word "fountain".
Proper use of MXP can radically improve the normal text-only MUD experience. In addition to embedded graphics, you can now better control the font, color, and size of text. You can directly control the automapper, allowing it to work perfectly on your MUD without fancy parsing. You can define links for users that like to point and click with their mouse. You can add pull-down menus to text displayed by the MUD to give the user a list of possible commands. The use of MXP will make your MUD stand out among the hundreds of other MUDs on the Internet and help breath new life into MUDs and help them compete against the more graphical RPGs appearing on the Internet.