This page describes the various element names which are built-into MUSHclient.
Open tags
"Open" tags can be used in either "open" or "secure" mode. They are intended for use in (amongst other places) chat lines, so that players can colour or emphasise their own chats.
Each of these has an opening and closing tag. In other words, after using
<b> you should have </b> to cancel the effect of the
<b>.
| Name | Arguments | Purpose |
|---|---|---|
| bold | none | Bold text.
Eg. |
| b | none | Same as <bold>.
Eg. |
| underline | none | Underline text.
Eg. |
| u | none | Same as <underline>.
Eg. |
| italic | none | Italic text.
Eg. |
| i | none | Same as <italic>.
Eg. |
| em | none | Emphasise text - same as <italic>
at present.
Eg. |
| color | FORE=text_colour BACK=background_colour |
Sets text and/or background colour.
eg. or, to achieve the same effect: You can specify just one or the other: <color fore=coral>Text colour is now coral.</color><color back=darkslateblue>Background colour is now darkslateblue</color>You can also use RGB codes: <color fore='#fff8dc' back='#0000ff'>This is cornsilk on blue</color>
The colour names and RGB use is described on MXP Colours. |
| c | FORE=text_colour BACK=background_colour |
Same as <color>. |
| s | none | Strikethrough. Not implemented. |
| strike | none | Strikethrough. Not implemented. |
| strong | none | Strong - same as <bold>. |
| small | none | Small text. Not implemented. |
| tt | none | Terminal text. Not implemented. |
| font | COLOR=text_colour,style BACK=background_color |
Change colour and style of text.
Colour names are the same as for <color> above. Style can be one of;
eg. The colour names and RGB use is described on MXP Colours. |
Secure tags
"Secure" tags can be used only in "secure" mode. They are intended for use by the MUD server to provide hyperlinks, and other useful features.
| Name | Arguments | Purpose |
|---|---|---|
| frame | n/a | Break screen into frames. Not implemented. |
| dest | n/a | Send text to a frame. Not implemented. |
| image | n/a | Display an image. Implemented by generating a hyperlink, which, if clicked on, opens the image in your default web browser. This is intended as a "fall back" for important images, like maps. |
| filter | n/a | See MXP spec. Not implemented. |
| a | HREF=link |
Creates an underlined hyperlink that the player can click on to either go to a web page, or send an email. The HREF argument must start with either "http://" or "mailto:". eg. |
| h1 | none | Heading level 1. Same as <bold>. |
| h2 | none | Heading level 2. Same as <bold>. |
| h3 | none | Heading level 3. Same as <bold>. |
| h4 | none | Heading level 4. Same as <bold>. |
| h5 | none | Heading level 5. Same as <bold>. |
| h6 | none | Heading level 6. Same as <bold>. |
| hr | n/a | Horizontal rule. Draws a horizontal line in the output window. |
| nobr | none | Non-breaking newline. Same as <br>. |
| p | n/a | Paragraph break. Starts a new line. Possibly in future versions might be used for automatic conversion of fixed-length lines into paragraphs. |
| script | n/a | Sends a script to the client. Not implemented
because of its dangerous nature, and difficulty of finding a script language
that would be compatible amongst various clients. However for compatibility
with other clients text between <script> and </script>
is discarded. |
| send | HREF=link HINT=hint PROMPT |
Creates an underlined hyperlink that the player can click on to carry out some action. The default behaviour is for the action to be sent to the MUD (eg. "go north"), however if PROMPT is specified the action is placed in the client's command window for modification before sending (eg. "tell Nick ..."). This is a very powerful feature, which allows MUDs to provide hyperlinks for clicking on, rather than players having to memorise lots of commands. Send without arguments In the simple case, <send> without arguments merely sends whatever is between <send> and </send> to the MUD. eg. In the above case, clicking on the hyperlink sends "West" to the MUD. Send with HREF You can send different text to what the player sees by using HREF. eg. In this case, the player sees "West - The Second Floor Landing" as a hyperlink, however if they click on it the word "West" is merely sent to the MUD. Send with HINT You can set up a "mouse-over" hint that appears if the player moves the mouse over the hyperlink. eg. In this case, the player sees "Go to the second floor landing" in a little popup window if they move the mouse over the hyperlink. Creating a popup menu You can also create a pop-up menu that appears if the player right -mouse clicks on the link. You do that by separating the various possible words to be sent to the MUD by the vertical bar character - "|". If the player left-mouse clicks the first item on the list (the default) is automatically sent. This will also appear in bold in the menu if you right-mouse click. By using HINT you can also specify the text of each item in the menu. If you also want a mouse-over hint then you need to provide that first. For all this to work properly, the number of hint items should be equal to, or one greater-than, the number of commands to be sent. eg.
There is currently a limit of 30 items that you can put into the menu. Additional ones will be ignored. Send with PROMPT By using the keyword PROMPT you can cause the text to be not sent immediately, but rather to be put into the client's command buffer. This would be useful for things like player names, where you might want to send them a "tell" or similar.
This example also illustrates use of the special entity "&text;". If you use that inside an element's arguments, the word "&text;" is replaced by the text between <send> and </send>. What this means is that if the player clicks on the menu link with the right-mouse button they would see (in this example):
Making your own elements with SEND in them Because the player's name is not inside the definition itself, then you can simplify life for yourself by defining your own element, like this:
The element definition only needs to be sent once, at the start of the session. Now, all you have to do (for example, in a WHO list), is use the newly defined tag "player" like this:
This is short and simple. You could do similar things with items in shops,
inventories, and so on. |
| sound | n/a | Play a sound. Not implemented. |
| music | n/a | Play some music. Not implemented. |
| br | none | Start a newline (break).
eg.
This is one line</br> This is a "command" tag, thus there is no </br> tag. |
| username | none |
Sends the current player's name to the MUD. The player name is defined in the "Connecting" configuration screen. This is a "command" tag, thus there is no </username> tag. This is intended for the MUD server to automatically find out your character's name at logon time. |
| user | none |
Same as |
| password | none |
Sends the current player's password to the MUD. The password is defined in the "Connecting" configuration screen. This is a "command" tag, thus there is no </password> tag. This is intended for the MUD server to automatically find out your character's password at logon time. The password must be sent in the first 10 lines of text sent to the MUD, otherwise this command is disabled as a security precaution. |
| pass | none |
Same as |
| relocate | n/a | Relocates to another MUD. Not implemented. |
| version | none | Sends the MUSHclient and MXP version
number to the MUD. This is to help servers work out which client and version
is connected.
This is a "command" tag, thus there is no </version> tag. |
| reset | none | Closes any open tags. Sets output colour
to white on black. Cancels underline, bold, italic, etc.
This is a "command" tag, thus there is no </reset> tag. |
Some tags not implemented
Tags marked as "not implemented" are recognised by MUSHclient, but no special processing takes place when they are found. Where the arguments are listed as "n/a" (not applicable) it is because the tag hasn't been implemented yet, so the argument list hasn't been finalised.
The reason some of them haven't been implemented is that, for speed reasons, MUSHclient only uses a single font. Tags like <h1>, <h2> and so on required different font sizes, and would be difficult to implement using the current design.