Gammon Forum : MUSHclient : MXP and Pueblo : !ELEMENT

Entire forum ➜ MUSHclient ➜ MXP and Pueblo ➜ !ELEMENT - define your own elements

!ELEMENT - define your own elements

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Tue 05 Jun 2001 03:58 AM (UTC)

Amended on Tue 24 Sep 2002 05:02 AM (UTC) by Nick Gammon

Message

You can create your own elements (tags) on-the-fly by sending an element definition from the server to the client.

The syntax is:



<!ELEMENT element-name [definition] [ATT=attribute-list] [FLAG=flags] [OPEN] [DELETE] [EMPTY]>

eg.



<!ELEMENT red '<COLOR red><B>'>



Then you can use the newly-defined element like this:



<red>This text is bold and red</red>

The entity name may not be the name of an existing built-in element (eg. "b" ) however you may redefine server-defined elements if you want to.

Rules for element names

The name must start with a letter, and then consist of:

* letters (A-Z, or a-z)
* numbers (0-9)
* underscore, hyphen or period characters

Case sensitivity

Entity names are not case-sensitive.

Entities inside elements

You are allowed to use entity names inside an element definition, for example:



<!ELEMENT exit "<send href='go &quot;&text;quot;'" >

The special name "&text;" is reserved and means "the text between the start and end tag of the element.

For example:



<exit>West</exit>

This would create a hyperlink (underlined link) for the word "West", which - if you clicked on it - would send:



go "West"

In this case the &text; in the element definition is the word "West" - the word between <exit> and </exit>.

Elements inside elements

You can not use user-defined elements inside an element definition. You must use inbuilt (predefined) elements only.

eg.

This is OK:



<!ELEMENT bold_red '<b><r>' >

This is NOT:



<!ELEMENT bold_red_italic '<boldred><i>' >

Attribute list

The ATT argument lets you specify "formal arguments" to an element definition. In other words, any word in the attribute list can be "passed down" to the element. Any word not in the attribute list may not be passed down to the element.

You can also use the <!ATTRIBUTE ... > tag to add attributes to an element later on.

The special keyword "&text;" is predefined and does not need to be included in the attribute list.

For example:



<!ELEMENT bold_color '<b><color &col;>' ATT="col=red">

In this example the attribute list specifies that there is one argument that can be passed to "bold_color" and its name is "col". In this case it also has a default value, "red".

You could use bold_color like this:



<bold_color col=blue> This is in blue </bold_color>

<bold_color green> This is in green </bold_color>

<bold_color> This is in red (the default) </bold_color>

The second example supplies "green" by position (the first argument) rather than by name.

Another example:



<!ELEMENT italic_color '<i><color fore=&fg; back=&bg;>' ATT="fg bg">

In this example the attribute list specifies that there are two arguments that can be passed to "italic_color" and their names are "fg" and "bg". There are no defaults, so if they are omitted then they become blank.

You could use italic_color like this:



<italic_color red green> Red text on green background </italic_color>

<italic_color bg=red fg=green> Green text on red background </italic_color>

<italic_color fg=green> Green text on existing background </italic_color>

<italic_color bg=red> Existing text on red background </italic_color>

The first example uses the colours "red" and "green" by position (ie. arguments one and two). The other examples show how you can pass down the arguments by name, in which case it doesn't matter what order they are in.

Flags

This argument lets you set variables in MUSHclient automatically.

eg.



<!ELEMENT rdesc flag=roomdesc>

The flag names can be:



roomname

roomdesc

roomexit

roomnum 

prompt

set xxxx

These are intended to help store room descriptions, exit lists etc. automatically as you move around. The final one, "set xxx", lets you set any arbitrary variable.

eg.



<!ELEMENT hp flag='set hp'>

Then when sending down the player's hit points, you would use:



<hp>120</hp>

The players "mxp_hp" variable will then automatically be updated (which they could then display on their status line, for example).

Variables set by MXP elements are preceded by the characters "mxp_", so that a server does not accidentally clobber variables you might be using for your own purposes in scripting.

Open

If you use this keyword the element is considered "open" and can be used on open lines, otherwise it is considered a secure tag.

Delete

If you use this keyword the named element is deleted.

eg.



<!ELEMENT rdesc delete>

Empty

If you use this keyword the element is considered to be a "command" element rather than one enclosing text. The word "empty" signifies that there is no text following it.

In other words, you don't use closing tags for empty elements.

eg.



<!ELEMENT new_level empty>

You might then send this to the client when the player reaches a new level.



<new_level>

Since it is empty you do not use the </new_level> tag.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Krenath USA (76 posts) Bio

Date

Reply #1 on Tue 01 Jan 2002 07:07 AM (UTC)

Amended on Tue 01 Jan 2002 07:09 AM (UTC) by Krenath

Message

Quote:

<!ELEMENT hp flag='set hp'>

Then when sending down the player's hit points, you would use:

<hp>120</hp>

Wow! This means that for those who are administrating such things as PSE-enabled MUSHes, it would be a very simple thing to configure the server to create such elements and pass ship status information to MUSHclient. This information could be used automatically by client-side script to update space 'macros' to adapt to the current ship status!

<!ELEMENT hull_points='set hull_points'>
<!ELEMENT reactor='set reactor'>

Then the PSE status commands would just pass the normal status display with the addition of the new tags:

<hull_points>85</hull_points>
<reactor>100</reactor>

The Tinyfugue-based macro sets I've seen since around 1993 for use by spacejocks can be easily converted tp MUSHclient aliases and scripts, allowing the scripts to calculate and allocate *precisely* the right power levels based on the current reactor settings, ship damage, etc.

(while you're at it, you could, with a little work, write a script that keeps shields facing your opponent no matter where he is. And a little modification could produce a script which could allocate multiple shields for defense against multiple targets!)

Now that we've got all these aliases and scripts defined, it should be a simple matter to create a compiled program (VB, C, whatever) that creates a reference to the MUSHclient world object and retrieves the variables set by the entities above. Why fly using a text interface when you could create a fully interactive graphical console? :)

I'd considered this graphical console many times in the past, but couldn't quite figure out how to accurately get the ship status information from the server. Now we have a way!

- Krenath from
bDv TrekMUSH
ATS TrekMUSH
TNG TrekMUSE
TOS TrekMUSE

Top

Posted by

Krenath USA (76 posts) Bio

Date

Reply #2 on Tue 01 Jan 2002 07:16 AM (UTC)

Message

If you want a quick test, try this:

@pem me=[html(!ELEMENT test flag="set test")][tagwrap(test,This is a test)]

You'll see "This is a test" looking as normal as ever, but if you hit shift+ctrl+7 and look at your Variables, MUSHclient now lists the variable "mxp_test" with the value "This is a test"

- Krenath from
bDv TrekMUSH
ATS TrekMUSH
TNG TrekMUSE
TOS TrekMUSE

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

16,289 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top