Handling of improper MXP tags

Unexpected control characters or end-of-line

If MUSHclient receives one of the following characters inside an element or entity, collection of that element/entity is terminated with a debug message.


\n - newline
\r - carriage return
0x1B - "escape" character - shown as (esc) below
0xFF - IAC telnet sequence initiation


However version 3.27 onwards will accept the sequence IAC IAC (0xFF 0xFF) as being a single IAC (that is, the character ÿ).

Thus the following sequences would be invalid:


<color \n red>
<send (esc) "go north" >
<!-- This comment has colours in it (esc)[310m -->
<!-- This is a multi-line comment \r\n -->


The purpose of this is to stop MUSHclient going into a lengthy "element collection" phase, possibly discarding hundreds of lines of MUD output, because someone accidentally started a comment and didn't finish it.

If such a sequence is received a message will be written to the debug window, providing the MXP debug level is not "none".

If some of the MUD output seems to go missing you are advised to set the debug level to "Errors" or "Warnings" and check the debug window periodically for messages.

Each message is prefixed with the line number in the output window which caused the error. You can use Ctrl+Alt+L to go to that line number.

---

Unknown/improper elements/entities

In MXP mode, MUSHclient will never display on the screen text received between:


< ..... and ..... >
& ..... and ..... ;


Thus MUD implementors always need to use the following substitutions for those characters:


< becomes: &lt;
& becomes: &amp;


For example, a seemingly harmless line like:


Written by John & Peter


... would result in everything after the & being discarded (with an error message).

---

Handling of unrecognised names

If an element or entity name is not recognised, then an error message will written to the debug window, if the MXP debug level is not "none". The element or entity in question will not be displayed in the output window.


<blah> - unknown element "blah"
&fish; - unknown entity "fish"


The purpose of these rules is to give a consistent way of processing MXP tags, and allow for future expansion. For example, if a new tag <status line> is invented, but you are using an older version of MUSHclient that doesn't support it, at least you won't see annoying tag names sprinkled throughout the output window.

I am using ver 3.25 and I love it so far, I am connecting to a moo, and they extensively use < and > all over the place. The do not use tags in any fashion though, but do use Pueblo, is there a way I can turn pueblo on, and have it not try to access tags? or mxp? I tried asking them to alter they display method, but despite my reasons, they didn't find it funny, or worth their time.

I do not understand this statement. To use Pueblo you must use tags, eg <b> for bold, <u> for underline and so on.

Pueblo, like HTML and XML, specifies that if you want to use "<" and ">" characters inside your text, but not as a tag, then you must represent them as &lt; and &gt; otherwise obvious confusion will arise where things look like tags but are not.

Some Pueblo and MXP implementations don't appear to do this properly, I suggest you advise them that they need to fix up their "<" and ">" signs if this is the case. However your statement that "they do not use tags" makes me wonder just what is going on.

If they need help fixing up the tags, I suggest taking a look at the web page I wrote about how to do that. It is at:


http://www.gammon.com.au/mushclient/addingservermxp.htm


They only use pueblo for sound types and images, they dont seem to be using it for anything else, for one when the pueblo/mxp is off, the moo looks no different, except that urls are no longer highlighted, instead they use < and > for ansi art, and extensively. I am coming to the conclusion they probably would of been more effective trying to use MSP instead of pueblo, but I just play there I don't make any decisions.

Sounds too me like they decided to be sloppy about things and assumed that most clients (like zMud) would be sloppy about implimentation as well.

For instance this is straight out of the docs for Pueblo 2.0 and is used to play a sound:

<img xch_sound=play href="http://www.chaco.com/music/explosion.wav" event="complete" action="_on_explosion" md5="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">

There does not appear to be any other commands that do so. They are expecting the client to recognize 'if' a command is valid and simply ignore it if not. As Nick has said, one decision in implimenting mushclient's design was to avoid buggy tags or, especially with MXP, unknown elements by hiding them instead of assuming that they are supposed to be displayed solely do to not being a valid command.

However if Pueblo itself is doing this then the designers are not reading their own documentation and neither are the people working on the moo you play, since it says very clearly in the docs that:

Upon receiving thisPUEBLOCLIENT command, the World may send the following sequence, to tell the Pueblo client to begin interpreting the World's output as HTML:

</xch_mudtext><img xch_mode=html>
...

and

...
3. Add HTML escaping. HTML has a few special characters that require escaping. You should convert these characters to the corresponding HTML sequence, as described in the following table. (Note: those trailing semicolons inside the strings are important.)
It then shows a list of HTML tags you that are used, 'including' the one for playing a sound. It would seem to me that Nick has it right, but your admin don't. Note: If they used zMud to test and design the moo, then this is not a big surprise, since its implimentation does assume that invalid tags should be displayed. For debugging purposes this may have even been intentional, but it complete ignores the reason they tell you to use &lt, &gt, &amp and &quot in the specification. The normal characters are reserved specifically for tags and the fact that they happen to display correctly in zMud is a side effect of the way it handles errors in the tags, not imho what 'should' happen.

I do not think your understanding the situation, all tags are invisible to the player, we never see a tag executed, they are not improperly using tags, and pueblo and zmud do not have an issue with this, what it is, is thus, MUSHclient tries to convert every < or > no matter where they are in the output as a tag, unless I have the MXP PUEBLO features turned off, they are using < and > as ascii art in the display screens, such as the ic display of the who list.
it is like this:
who
|C| Submitting query...
|C| Generating results from WHODATA.DB ...
|W|----------------------------------------------------------------------------+
|W| <<<<<<<<<<<<<<<< WITHMORE SECURE IDENTIFICATION NETWORK >>>>>>>>>>>>>>>> |
|W|----------------------------------------------------------------------------+
|W| ID | ALIAS | BROADCAST MESSAGE (ct) [54] |
|W|------+----------+----------------------------------------------------------+
|W| | Warren | ... we are about to embark upon a most unprecedented exp |
|W| | Sergiusz | My name is Sergiusz, brother of. I got me some c |
|W| | Sheen | and then the serpent struck.. |
|W| | Abdnago | If rubbin' frozen dirt in ya crotch is wrong, hey, I don |
|W| | Ono | Cutting edge designs for a up planet. |
|W| | eA011qzr | |
|W| | Mims | Hey, you know what might be a hoot? |
|W| | Flatline | You really don't want me to do that. |
|W| | WJF-Ops | Obey The Law - Dial 911 to request help |
|W| | Aurora | |
|W| | Xee | NLM StreetTerm Official Advertiser -=- Call 383-3745 |
|W| | Max | If I'm goin' out, I'm goin' out in style! (tm) |
|W| | Boo | Your worst ' nightmare |
|W| | Powers | There it is, the near-death star. |
|W|------+----------+----------------------------------------------------------+
|W| 31,000 flavors, Baskin Robbins, try some |
|W|----------------------------------------------------------------------------+

What I am trying to get around to, is there a way I can get the debugger to not cut out what it does not like from the text

I know exactly what you are saying. I wanted to be able to use MXP to color tells, etc., but on a non-MXP mud and ran into the same problem. I also argued with Nick about this before and while I wouldn't mind some way to make invalid tags visible, I do understand why mushclient doesn't.

As I said, the fact that they are visible in zMud and Pueblo is not stated in the specs for them as being the 'normal' behavour, the issue is instead completely ignored. But neither of those clients have complex error handling for dealing with such bad tags and as Nick has tried to say, it does not make sense for them to work that way. For instance:

Lets say a mud has a hotel in it and the rooms are labelled -
<Room 1>
<Room 2>
<Room 3>

and some where along the line it is decided by to extend the specification, when used on mud where the rooms are stored in a database, so that the index number assigned to that room in the database is returned in a tag. Oops.. Now the room names are going to be incorrectly interpreted as ID tags for the new zMud mapper or whatever it was intended to be used for and not displayed. It is not a good idea for designer to ignore what the specification tells them they are supposed to be doing.

Pueblo and zMud allow invalid tags to be shown for 'debugging' purposes, the specification does not say that this must be the behavior, but it does imply that using < and > anyplace else, except in a tag, is wrong. Otherwise they wouldn't tell you to use the &lt, &gt replacements.

That said... You could try using a script to deal with this by going into the script settings and clicking the MXP tag. You would then place a sub name in Opening Tag: and use world.tell in the script to display the missing stuff. I didn't have much luck with my own experiments to do this, but then I tried to use the Error event, on the assumption that I didn't want to process 'all' tags for redisplay, just the ones I knew where wrong.

Note to you Nick: I told you this was going to come up. People that design things will look for the easiest way to do stuff, even if the method they use is completely wrong, and since neither the Pueblo or zMud spec force complience with the &lt and &gt requirement, guess what... :p

I quote from the MXP spec at:


http://www.zuggsoft.com/zmud/mxp.htm




Note the use of the word "must" (my emphasis). The MXP spec requires that < symbols to be represented as &lt; and a MUD that does not do that is not implementing it correctly.

Also in the Pueblo spec at:


http://pueblo.sourceforge.net/doc/manual/




I suppose the word "should" isn't as strong as "must" but for me it is strong enough. "Should convert" means to me that you should do this (if you want it to work), not you might if you feel like it.

In fact the sentence "HTML has a few special characters that require escaping" is pretty strong. "Require" means to me that you need to do it.

As both specs require that the "<" be converted to &lt; I believe MUSHclient's implementation is correct, and I do not wish to encourage sloppy implementation by MUD writers by allowing incorrect tags to "slip through".



Both Shadowfyr  and I understand the problem - it is that the moo is not implementing Pueblo correctly. There are plenty of examples of it being done right, for instance my own implementation I referred to before, Dawn Of Time, PennMUSH, and others. I suggest you do one of:

• Turn off Pueblo and do without the sound effects
• Play another MUD
• Convince the admins that they should fix up their < signs as per the spec

If they are only using Pueblo for sound effects and images (ie. in 2 places) it is simple enough to fix. All their output to players should automatically convert "<" to &lt; and "&" to &amp; and in those 2 places where they are actually using Pueblo tags they simply use a different output routine that doesn't do the conversion.

Well I guess that means I have to get one of the other clients, I love this client, but their moo is one of a kind, so I can't get a replacement for it, and they adamantly refuse to change their display output, because it works with other clients, they feel the fault is with this program, and no matter what I try to tell them, its "not their problem"

Sorry to hear that, but you can always turn off Pueblo. After all, people played MUDs for ages before Pueblo came along, and you can probably manage without the occasional sound effect.

Couldn't they do a work around by putting the client into lock locked mode (ESC[7z) when coming out of secure mode (ESC[1z) after sending the sound tag?

I'm using something like this to handle cat'ing files to players.

I defined:
MXP_BEG as ESC[1z (secure mode)
MXP_LOCK as ESC[7z (lock locked mode)
MXP_END as ESC[0z (open mode)

then send MXP_LOCK before cat'ing the file to the player and then MXP_END when I'm finished. It seems to work ok so far.

Is there a problem with doing it this way?

~Ettercap

I play Achaea and I am about to write an auto walker using the Achaea server MXP tags, using room number and room names. But this is where the shit hit the fan, let me explain:

I switch MXP OFF in Mushclient to see the tags and
CONFIG MXP ON in the mud Achaea, and this is what I see an init string with tags, then I look around.

<VERSION><SUPPORT><!ELEMENT RNum ATT="id" FLAG="RoomNum" EMPTY><!ELEMENT RName FLAG="RoomName"><!ELEMENT RDesc FLAG="RoomDesc"><!ELEMENT RExits FLAG="RoomExit"><!ELEMENT Prompt FLAG="Prompt">You have turned MXP on and will now be sent MXP tags.

LOOK

<PROMPT>4220h, 2420m exkdb-</PROMPT>

<RNum 24137><RName>River around Delos</RName>.
<RDesc>The River Zaphar flows steadily to the southwest at a quick pace, corralled by highly angled banks. Cattails and grasses wave in the wind on the northwestern bank, while the tall reeds on the southeastern bank have been trampled flat by a careless wanderer. The clan registry of Delos is visible above the river, a constant flow of traffic travelling to and from the building. The riverbed is dark and muddy, the swift current constantly stirring up sediment and clouding the water.</RDesc> A large silver salmon flicks through the water.
<RExits>You see exits leading <COLOR #00FF00><SEND HREF="northeast">northeast</SEND></COLOR> and <COLOR #00FF00><SEND HREF="southwest">southwest</SEND></COLOR>.</RExits>

<PROMPT>4220h, 2420m exkdb-</PROMPT>

----------------------------------

I have a serious issue about MXP variables. Mush creates 4 variables properly mxp_roomname; mxp_roomdesc; mxp_roomexit; mxp_prompt. The mxp_roomnumber (or rnum) is missing.

As we can see in the above/below example the <RNum> tag is not followed by </RNum> closing tag:

<RNum 24137><RName>River around Delos</RName>.

Proper line should be this:

<RNum> 24137</Rnum><RName>River around Delos</RName>.

Am I right?

I think I am.

So I SWITCH MXP YES ALWAYS back in Mushclient, and begin to look or walk, and the MXP warning window keep saying (obviously) one-line warning messages whenewer I look or walk. Example:

W 5015: ( 9996) Unused argument (1) for <rnum>: 24137 :-P

Yeah there is the failed rnum damnit, in an error message in the MXP Messages window.

So this is broken, I cannot build a database using room numbers and room descs.

(Filed a BUG ingame about the unclosed RNum tag, but god knows when will they fix it.)

1.) How can I fetch/copy/packet-hack/whatever that damn broken rnum tag into a standard Mushclient variable, like mxp_roomnumber?

2.) How can I use GetEntity() for the working tags? print(GetEntity("Rname")) gives an empty line only.

3.) How can I list all the existing Entities with GetEntity()?

Regards.

Whoever did this hasn't been paying attention to the spec, which clearly said that an "empty" tag should be rendered as:



(Note the trailing "/>").

Or maybe as:



All I can really suggest is to leave MXP turned off, and parse the "rnum" yourself in triggers. With luck they will always be at the start of a line.

Or, leave it turned on (to get stuff like RDesc) but in the OnPluginPacketReceived, detect the RNum tags, save the room number, and then remove them from the packet.

You could try sending a message to Achaea, with luck they will fix it up.

Leaving mxp off in Mush is a big no-no. Substituting multi-coloured block of text is a pain.

OnPluginPacketReceived?

I never use plugins, only standard triggers and aliases...
... I foresee sweating and painful mistakes here. :-P

So, I have to write a plugin from scratch and place an OnPluginReceived("<RNum *><RName>*</RName>.") function and do a SetVariable("rnum","%1") inside?

Edit: deleted a plugin, I am too stupid at the moment and know nearly nothing about plugins. Let me read docs.

Here is the output of the MPX window when I swith on the mxp of the mud:

I 10000: ( 35) Sent version response: <VERSION MXP="0.5" CLIENT=MUSHclient VERSION="4.51" REGISTERED=YES>

I 10009: ( 35) Sent supports response: <SUPPORTS +head +body +afk +title +username +pass +samp +h +high +i +option +bold +xch_page +reset +strong +recommend_option +support +ul +em +send +send.href +send.hint +send.xch_cmd +send.xch_hint +send.prompt +p +hr +html +user +password +a +a.href +a.xch_cmd +a.xch_hint +underline +b +img +img.src +img.xch_mode +pre +li +ol +c +c.fore +c.back +color +color.fore +color.back +font +font.color +font.back +font.fgcolor +font.bgcolor +u +mxp +mxp.off +version +br +v +var +italic >

I 20002: ( 35) Got Definition: !element RNum ATT="id" FLAG="RoomNum" EMPTY
I 20002: ( 35) Got Definition: !element RName FLAG="RoomName"
I 20002: ( 35) Got Definition: !element RDesc FLAG="RoomDesc"
I 20002: ( 35) Got Definition: !element RExits FLAG="RoomExit"
I 20002: ( 35) Got Definition: !element Prompt FLAG="Prompt"
I 10000: ( 35) Sent version response: <VERSION MXP="0.5" CLIENT=MUSHclient VERSION="4.51" REGISTERED=YES>

I 10009: ( 35) Sent supports response: <SUPPORTS +head +body +afk +title +username +pass +samp +h +high +i +option +bold +xch_page +reset +strong +recommend_option +support +ul +em +send +send.href +send.hint +send.xch_cmd +send.xch_hint +send.prompt +p +hr +html +user +password +a +a.href +a.xch_cmd +a.xch_hint +underline +b +img +img.src +img.xch_mode +pre +li +ol +c +c.fore +c.back +color +color.fore +color.back +font +font.color +font.back +font.fgcolor +font.bgcolor +u +mxp +mxp.off +version +br +v +var +italic >

I 20002: ( 35) Got Definition: !element RNum ATT="id" FLAG="RoomNum" EMPTY
W 5000: ( 35) Replacing previously-defined MXP element: <rnum>
I 20002: ( 35) Got Definition: !element RName FLAG="RoomName"
W 5000: ( 35) Replacing previously-defined MXP element: <rname>
I 20002: ( 35) Got Definition: !element RDesc FLAG="RoomDesc"
W 5000: ( 35) Replacing previously-defined MXP element: <rdesc>
I 20002: ( 35) Got Definition: !element RExits FLAG="RoomExit"
W 5000: ( 35) Replacing previously-defined MXP element: <rexits>
I 20002: ( 35) Got Definition: !element Prompt FLAG="Prompt"
W 5000: ( 35) Replacing previously-defined MXP element: <prompt>

And this happens when I walk around:
W 5015: ( 163) Unused argument (1) for <rnum>: 707
W 5015: ( 179) Unused argument (1) for <rnum>: 708
W 5015: ( 186) Unused argument (1) for <rnum>: 707
W 5015: ( 190) Unused argument (1) for <rnum>: 700
W 5015: ( 201) Unused argument (1) for <rnum>: 707
W 5015: ( 226) Unused argument (1) for <rnum>: 699
W 5015: ( 235) Unused argument (1) for <rnum>: 698
W 5015: ( 245) Unused argument (1) for <rnum>: 697
W 5015: ( 255) Unused argument (1) for <rnum>: 698
W 5015: ( 278) Unused argument (1) for <rnum>: 699
W 5015: ( 283) Unused argument (1) for <rnum>: 707

OK, I made a plugin to fix this.

I think Achaea is mis-using the roomnum tag. The spec for an element definition (here: http://www.zuggsoft.com/zmud/mxp.htm) says:

---


Tag Properties

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:

RoomName

The text for the element is parsed by the automapper as the name of a room.

RoomDesc

The text for the element is parsed by the automapper as the description of a room.

RoomExit

The text for the element is parsed by the automapper as exits for the room

RoomNum

The text for the element is parsed by the automapper as a room number

Prompt

The text for the element is parsed by as a MUD Prompt

Set

The text for the element is stored into the named local variable within the client. For example:

<!ELEMENT Hp FLAG="Set hp">
<Hp>100</Hp>

would set the @hp variable in the user's session to 100.



---

Notice it says "the text for the element is parsed". That is it should be:



instead of:



(See his example for Hp).

Rather than getting into a lengthy argument about whether or I followed, or understood, the spec, the plugin below should work around it. It detects the problematic RNum tags, calls an alias to save the room number, and removes it from the input stream.






I could have just set a variable, but that would be a plugin variable, not a variable you can easily use elsewhere.

Now you just need an alias in your world file, which picks up the room number change:





That detects "got_room_number 707" being sent from the plugin, and just saves it as the "room_number" variable.

Nick! Thanks for your help! You are amazing.

Let me add a last word about mxp and Achaea, here is a chapter from the HELP MXP copy/pasted from the Achaea mud.

19.20 MXP - MUD eXtension Protocol
MXP is a MUD communication protocol that allows us to send enhanced information within the normal text stream. Examples of this enhanced information are:
formatted text, clickable commands, and even images.
To enable MXP for your character in Achaea, type:
CONFIG MXP ON
You can read more about what MXP offers at:
http://www.zuggsoft.com/zmud/mxp.htm
You may also have to enable MXP in your MUD client. Instructions for various popular MUD clients that do not automatically enable MXP follow:
CMUD v3.12 (Beta version)
---------------------------
- Click on "Options" in the top toolbar, then click on "General".
- Click on the "MXP" tab in the "Preferences" window that opens.
- Click on the button "Force remote MXP" if it is not already enabled.
MUSHclient v4.40
------------------
- Click on "Game" in the top toolbar.
- Mouse over to the "Configure" menu option.
- Click on the "MXP / Pueblo" menu option.
- Click on "Use MXP/Pueblo" drop-down menu and choose "Yes - always".
- MUSHclient supports an outdated version of the MXP specification, and therefore does not allow for all of the features used by zMUD and CMUD.
....

Regards!

Edit: I keep bugging the Achaean admins (mostly Tecton) about this issue until they change this very help file and they fix that mxp room number tag.

Hmmm. The default behaviour in MUSHclient is to accept an MXP-enabled MUD if the telnet negotiation sequences are sent to it (as documented in the official MXP spec).

Thus it shouldn't be necessary to set it to "choose "Yes - always". I wonder if Achaea is following the spec itself?

Further grumbles deleted.

Well, I should quote this bit from the same help file:



I imagine they won't send the negotiation if you don't have CONFIG MXP ON set. I imagine you just need to set CONFIG MXP ON, then reconnect.

I have heard of a bug where people who have CONFIG MXP OFF set will still receive MXP, even though it says its off when you check. I think they're aware of it though.

They probably do that because zMUD processes MXP regardless of the negotiation. In other words, it is always on. So to avoid confusion, you have to explicitly enable it.

Hmm, that makes sense.

Hi Nick,

To activate MXP in mushclient in its factory default (on command) the MUD has to send a (IAC, SE, MXP, IAC, SE) after the negotiation. Other clients don't need this step and activate after the negotiation with DO/WILL, so maybe the IRE staff didn't know this about Mushclient and it's just a matter of somebody telling them.

At the beginning of the year there was a change in CMUD concerning the RNUM-tag. I found this in the changelog:



There was also a corresponding thread on the cmud forums, that I didn't find now.

Maybe this helps,
xtian

This seems suspicious. Did you mean (IAC, SB, MXP, IAC, SE) (note the SB)?

Thanks for the clarification, assuming you mean IAC SB MXP IAC SE. It is strange the cMUD activates MXP on a query rather than a command (it is like asking someone if they can play the piano, and rather than just replying "yes" they sit down and actually play it, which you might not want them to do if you have a baby asleep in the next room).

The confusion probably arises because, as far as I know, cMud and zMud parse MXP whether or not it is actually activated, and thus when IRE did their testing it appeared to work. A pity they didn't try it with other clients, but there you are.

MUSHclient does have an option to activate MXP "on query", which is not the factory default because I don't think it is sensible to turn an option on just because you have been asked if you support it or not.

Well I don't browse the cMUD change logs (and no doubt Zugg doesn't browse the MUSHclient ones either). It would be nice to hear about changes that affect MXP, but ... oh well.