[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  MXP bug
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: MXP bug
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Sun 06 Dec 2009 07:44 PM (UTC)  [ quote  ]
Message
It's because it doesn't find a ; before the newline. The 2nd plugin on page 1 of this thread should help. However it tries to tell the difference between a real entity (like &) and something that should be converted (like "rock & roll") by checking for NO letter after the & sign.

Now if the MUD sends "rock&roll" then it fails that test. This is really frustrating because the MUD operators are being lazy by not changing the & in "rock&roll" to & so it should be sending "rock&roll" in the first place.

What you could do is analyze the incoming text (using packet debug might help) and work out what entities they are using, probably < > & and maybe one or two more appear frequently. Then you could make a similar plugin that:


  • First converts known ones like the 3 above into something else, like 0x01, 0x02, 0x03.

  • Then converts every remaining & into &

  • Converts 0x01, 0x02, 0x03 back into what they were to begin with.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Krae   Netherlands  (16 posts)  [Biography] bio
Date Sun 06 Dec 2009 02:15 PM (UTC)  [ quote  ]
Message
First off, sorry for bumping up an ancient topic, but it saved me part of the problem and I hate opening new ones for nothing.

So my problem is this:

Some characters in my MUD suddenly no longer started displaying, such as the '<' and '&' Now I -finally- found this topic and the plugin helped me restore use of '<' (which helps me tremendously) I rarely stumble upon the '&' sign but it does features a few times and disallows me to see the rest of the line.

E 1003: ( 4991) Unterminated MXP entity: I. (got <NEWLINE>)

Is what the Debug Warning reads, after the I and ampersand would follow with some more text. Though I am unsure how it can be fixed and it is not so dire to me but it is a nuisance. I gather the newline thing is because ';' starts a newline.
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Tue 25 Jul 2006 09:57 PM (UTC)  [ quote  ]
Message
Actually I think zMUD looks for the </I>, so it *would* work.

However it is not supposed to do that. The MXP spec (http://www.zuggsoft.com/zmud/mxp.htm) says:

"Also, when in OPEN mode, any unclosed OPEN tags are automatically closed when a newline is received from the MUD.".

So, you are allowed to leave off the closing tags and have the client close them for you - which is what MUSHclient does.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Tue 25 Jul 2006 06:52 PM (UTC)  [ quote  ]
Message
Quote:
I know it is tempting to suggest that MUSHclient do "what everyone else does", but that does not handle situations like this:

Exits: <I>nn, <B>ank


And somehow I **suspect** zMuds behaviour wouldn't be any different than Mushclients in those cases. Not sure mind you, but I suspect it would be. I am not sure its a valid point. Still, I didn't expect a change of heart, nor do I think drop through, without making it obvious that its an error of some kind (which is one reason zMud doing it is so bad) is necessarilly a good thing.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Tue 25 Jul 2006 01:24 AM (UTC)  [ quote  ]
Message
I didn't initially realise that you are making changes to the MUD yourself. In that case you should definitely fix up the problems at the server end, not by installing plugins.

When drawing the map, change < to &lt; > to &gt; and & to &amp; if the player has MXP mode on.

Also, if MXP is on, surround the map by <PRE> and </PRE> codes (preformatted) which will make the clients display the thing "as is".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Tue 25 Jul 2006 01:04 AM (UTC)  [ quote  ]
Message
Put <PRE> ... </PRE> around the whole thing. That preserves formatting.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greymouser69   (6 posts)  [Biography] bio
Date Mon 24 Jul 2006 11:56 PM (UTC)  [ quote  ]

Amended on Mon 24 Jul 2006 11:59 PM (UTC) by Greymouser69

Message
Well I figured out why the second script was doing what it did... The mud's mxp was set to send a mxp lock code right after closing some elements, I have since changed that to send mxp reset code instead. That let the script work as intended, but somehow the spacing in the "mini-map" area is all gone:

+-----------+ [Exits: East South->(Closed)]
|           | This is the entranceway to the Newbie Nursery 
| | School here at AnonyMUD.  Walking through the school will help 
| O | to prepare you for the real world.  Our world is probably 
| | | different than any world you've ever been to, so even if you 
| X-O | consider yourself "experienced", humor us and read all the 
| | | signs.  There is a big sign on the wall which says, "to read me, 
| O-O-O | type LOOK sign".  A door leads south into the playground but you 
| | | have to go to school before you play...  

|     O     | 
+-----------+



Ok so I looked back and noticed the spacing was always getting munged along with the \n\r... It was just harder for me to see without the proper line breaks.
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Mon 24 Jul 2006 11:36 PM (UTC)  [ quote  ]
Message
I think you can easily make a trigger in MUSHclient to simply discard blank lines, that might neaten things up.

Make sure you go to Global Preferences -> General and check "Regular expressions can match an empty string".

Then make a trigger that:


Match: ^$
Omit from output: yes
Regexp: yes


Of course, that gets rid of all blank lines, it depends which annoys you more, no blank lines or too many.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greymouser69   (6 posts)  [Biography] bio
Date Mon 24 Jul 2006 11:29 PM (UTC)  [ quote  ]

Amended on Mon 24 Jul 2006 11:38 PM (UTC) by Greymouser69

Message
Super, that fixed it!

On the strange line formatting, I double checked and the mud is sending \n (0a) and \r (0d) so something odd is happening there for sure. And it only happens with MXP enabled, also double checked that one.

This is happening within an open <RDesc> tag set, and when I was experimenting (read compiling & re-compiling) with the mud if I closed the tag with </RDesc>(esc)[3z on each line I ended up with an extra crlf thrown in from Mushclient so I got blank lines between each line. Sorry but I'm too lazy to recompile at the moment so I can post a packet dump on that one, but I'm reasonably sure from code I was playing with that it was coming from the client.

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

Oops, we cross posted there hehe. The first script was working great except I found that we also forgot the <! LOL, fixed that one by adding it to the pattern.

As for the second, I don't think it quite worked as intended hehe.
Entrance To Newbie Nursery School                          -     -     -<br>-&lt;---- Vnum:   3700 ----------------------------->-        -&lt;---(*)--->E<br>                                                           -     S     -<br><br>[Area Flags: none]<br>[Room Flags: indoors]<br>+-----------+ [Exits: East South->(Closed)]<br>|           | This is the entranceway to the Newbie Nursery 
| | School here at AnonyMUD.  Walking through the school will help 
| O | to prepare you for the real world.  Our world is probably 
| | | different than any world you've ever been to, so even if you 
| X-O | consider yourself "experienced", humor us and read all the 
| | | signs.  There is a big sign on the wall which says, "to read me, 
| O-O-O | type LOOK sign".  A door leads south into the playground but you 
| | | have to go to school before you play...  
<br>|     O     | <br>+-----------+ <br><br><br><br>"A professor is one who talks in someone else's sleep."<br>[522hp 882m 150mv]  [8265625exp]


somehow it kicked it out of mxp mode or something
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Mon 24 Jul 2006 11:19 PM (UTC)  [ quote  ]
Message
Quote:

according to the code it SHOULD be sending \n\r as near as I can see...


Yes you are right, however I think it has put the client into "wrap" mode, similar to real HTML where linebreaks in HTML code do not translate into linebreaks on the page, unless inside a <PRE> tag (see other post again).

This different plugin may or may not fix that for you. It converts newlines into <BR> if MXP is active, however it may well spam too many newlines, it depends on what the MUD is sending.

The code is pretty straightforward, it is all done in this line:


return (string.gsub (s, "\n", "<br>"))


That is converting the newline to <br>.




<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, July 25, 2006, 9:11 AM -->
<!-- MuClient version 3.75 -->

<!-- Plugin "Convert_newline_to_BR" generated by Plugin Wizard -->

<muclient>
<plugin
   name="Convert_newline_to_BR"
   author="Nick Gammon"
   id="b4959257712f089b871acc88"
   language="Lua"
   purpose="Converts newlines to BR when in MXP mode"
   date_written="2006-07-25 09:09:55"
   requires="3.67"
   version="1.0"
   >

</plugin>


<!--  Script  -->


<script>
<![CDATA[
function OnPluginPacketReceived (s)
  if GetInfo (104) or GetInfo (105) then  -- MXP or Pueblo active
    return (string.gsub (s, "\n", "<br>"))
  else
    return s
  end -- if
end -- OnPluginPacketReceived 
]]>
</script>


</muclient>
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Mon 24 Jul 2006 11:08 PM (UTC)  [ quote  ]
Message
Oops. :)

OK, try this:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, July 25, 2006, 7:31 AM -->
<!-- MuClient version 3.75 -->

<!-- Plugin "MXP_Tag_Fixer" generated by Plugin Wizard -->

<muclient>
<plugin
   name="MXP_Tag_Fixer"
   author="Nick Gammon"
   id="2cad9c303fac53bb0a186ef4"
   language="Lua"
   purpose="Attempts to display incorrect MXP tags"
   date_written="2006-07-25 07:24:35"
   requires="3.67"
   version="1.0"
   >

</plugin>


<!--  Script  -->


<script>
<![CDATA[
-- conversion table

t = {
    ["<"] = "&lt;",
    ["&"] = "&amp;",
    }

-- find 1st character in table, append 2nd character

function converter (what)
  return (t [string.sub (what, 1, 1)] .. string.sub (what, 2)) or what
end -- converter 

-- convert < > & to: &lt; &amp;

function OnPluginPacketReceived (s)
  if GetInfo (104) or GetInfo (105) then  -- MXP or Pueblo active
    return (string.gsub (s, "[<&][^A-Za-z/]", converter))
  else
    return s
  end -- if
end -- OnPluginPacketReceived 

]]>
</script>


</muclient>


I took out the conversion of the > because I don't think it matters to MUSHclient if it has a solitary > in the text (your initial post shows them, for instance) and with the > left in I got something like this:


</code> becomes </code&gt;
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greymouser69   (6 posts)  [Biography] bio
Date Mon 24 Jul 2006 11:01 PM (UTC)  [ quote  ]

Amended on Mon 24 Jul 2006 11:02 PM (UTC) by Greymouser69

Message
Love the script but I think you may have forgotten to account for </ in the tags to terminate a tag... Here's a snippet of what I get with it:

Entrance To Newbie Nursery School                 </RName>         -     -     -
-<---- Vnum:   3700 ----------------------------->-        -<---(*)--->E
                                                           -     S     -


If I knew LUA at all I'd fix it myself since I'm sure its a simple fix. :) And yes it happens to all the </ tags.
[Go to top] top
Posted by Greymouser69   (6 posts)  [Biography] bio
Date Mon 24 Jul 2006 10:52 PM (UTC)  [ quote  ]

Amended on Mon 24 Jul 2006 10:54 PM (UTC) by Greymouser69

Message
Ok, first off, sorry for opening that particular can of worms. It seems that Zugg is taking a page from Micro$oft's book and writing a standard that they propmtly ignore as they see fit. Also thanks for the script to emulate somewhat their broken behavior!

now to the packet dump, hope this fits here:

oors]...[0;32m.[   6f 6f 72 73 5d 0a 0d 1b 5b 30 3b 33 32 6d 1b 5b
1z<RExits>.[1;35   31 7a 3c 52 45 78 69 74 73 3e 1b 5b 31 3b 33 35
m.[1;30m+-------   6d 1b 5b 31 3b 33 30 6d 2b 2d 2d 2d 2d 2d 2d 2d
----+.[0;37m .[1   2d 2d 2d 2d 2b 1b 5b 30 3b 33 37 6d 20 1b 5b 31
;35m[Exits: <Ex>   3b 33 35 6d 5b 45 78 69 74 73 3a 20 3c 45 78 3e
East</Ex> <Ex>So   45 61 73 74 3c 2f 45 78 3e 20 3c 45 78 3e 53 6f
uth</Ex>->(Close   75 74 68 3c 2f 45 78 3e 2d 3e 28 43 6c 6f 73 65
d)]</RExits>.[2z   64 29 5d 3c 2f 52 45 78 69 74 73 3e 1b 5b 32 7a
...[1;30m|.[0m.[   0a 0d 1b 5b 31 3b 33 30 6d 7c 1b 5b 30 6d 1b 5b
1;35m              31 3b 33 35 6d 20 20 20 20 20 20 20 20 20 20 20
.[1;30m|.[0m.[1;   1b 5b 31 3b 33 30 6d 7c 1b 5b 30 6d 1b 5b 31 3b
35m .[0;32m.[0;3   33 35 6d 20 1b 5b 30 3b 33 32 6d 1b 5b 30 3b 33
2m.[1z<RDesc>Thi   32 6d 1b 5b 31 7a 3c 52 44 65 73 63 3e 54 68 69
s is the entranc   73 20 69 73 20 74 68 65 20 65 6e 74 72 61 6e 63
eway to the Newb   65 77 61 79 20 74 6f 20 74 68 65 20 4e 65 77 62
ie Nursery ...[1   69 65 20 4e 75 72 73 65 72 79 20 0a 0d 1b 5b 31
;30m|.[0m.[1;35m   3b 33 30 6d 7c 1b 5b 30 6d 1b 5b 31 3b 33 35 6d
           .[1;3   20 20 20 20 20 20 20 20 20 20 20 1b 5b 31 3b 33
0m|.[0m.[1;35m .   30 6d 7c 1b 5b 30 6d 1b 5b 31 3b 33 35 6d 20 1b
[0;32mSchool her   5b 30 3b 33 32 6d 53 63 68 6f 6f 6c 20 68 65 72
e at AnonyMUD. W   65 20 61 74 20 41 6e 6f 6e 79 4d 55 44 2e 20 57
alking through t   61 6c 6b 69 6e 67 20 74 68 72 6f 75 67 68 20 74
he school will h   68 65 20 73 63 68 6f 6f 6c 20 77 69 6c 6c 20 68
elp ...[1;30m|.[   65 6c 70 20 0a 0d 1b 5b 31 3b 33 30 6d 7c 1b 5b
0m.[1;35m          30 6d 1b 5b 31 3b 33 35 6d 20 20 20 20 20 20 20
.[0;37mO.[0m   .   1b 5b 30 3b 33 37 6d 4f 1b 5b 30 6d 20 20 20 1b
[1;30m|.[0m.[1;3   5b 31 3b 33 30 6d 7c 1b 5b 30 6d 1b 5b 31 3b 33
5m .[0;32mto pre   35 6d 20 1b 5b 30 3b 33 32 6d 74 6f 20 70 72 65
pare you for the   70 61 72 65 20 79 6f 75 20 66 6f 72 20 74 68 65
 real world. Our   20 72 65 61 6c 20 77 6f 72 6c 64 2e 20 4f 75 72
 world is probab   20 77 6f 72 6c 64 20 69 73 20 70 72 6f 62 61 62
ly ...[1;30m|.[0   6c 79 20 0a 0d 1b 5b 31 3b 33 30 6d 7c 1b 5b 30
m.[1;35m       .   6d 1b 5b 31 3b 33 35 6d 20 20 20 20 20 20 20 1b
[0;33m|.[0m.[1;3   5b 30 3b 33 33 6d 7c 1b 5b 30 6d 1b 5b 31 3b 33
5m   .[1;30m|.[0   35 6d 20 20 20 1b 5b 31 3b 33 30 6d 7c 1b 5b 30
m.[1;35m .[0;32m   6d 1b 5b 31 3b 33 35 6d 20 1b 5b 30 3b 33 32 6d
different than a   64 69 66 66 65 72 65 6e 74 20 74 68 61 6e 20 61

Incoming packet: 7 (972 bytes)

ny world you've    6e 79 20 77 6f 72 6c 64 20 79 6f 75 27 76 65 20
ever been to, so   65 76 65 72 20 62 65 65 6e 20 74 6f 2c 20 73 6f
 even if you ...   20 65 76 65 6e 20 69 66 20 79 6f 75 20 0a 0d 1b
[1;30m|.[0m.[1;3   5b 31 3b 33 30 6d 7c 1b 5b 30 6d 1b 5b 31 3b 33
5m     .[1;31mX.   35 6d 20 20 20 20 20 1b 5b 31 3b 33 31 6d 58 1b


that should be enough to show what's going on I hope.

according to the code it SHOULD be sending \n\r as near as I can see...
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Mon 24 Jul 2006 09:42 PM (UTC)  [ quote  ]
Message
Sigh.

Please read this thread:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6247

Let's be clear about this - this is not a MUSHclient bug. The spec for MXP says that when in MXP mode:


  • < should be rendered as &lt;
  • > should be rendered as &gt;
  • & should be rendered as &amp;


Your packet dump shows the server is not doing this, thus the server has the bug.

Unfortunately, zMUD has tried hard to be helpful to MUD developers, and thus you will find zMUD will render things like "<-----" literally without complaining about the fact that it is an unknown tag. However MUSHclient follows the spec (that the zMUD developer, Zugg, wrote), and does not accept it.

Because of zMUD's behaviour, MUD developers who test their servers with zMUD get acceptable displays (eg. with that map) and think their job is done, whereas they should be translating the <, > and & characters.

If you ask nicely the developers of afkmud (Samson I think) to fix up the way they draw their map, the problem may be solved.

I know it is tempting to suggest that MUSHclient do "what everyone else does", but that does not handle situations like this:


Exits: <I>nn, <B>ank


In this case the <I> and <B> look like valid tags, and MUSHclient will render them in italic and bold. In this case you simply have to use the &lt;I&gt; method.

Meanwhile, to try to work around this problem, you can try this plugin. Copy between the lines, save to disk as MXP_Tag_Fixer.xml, and install into MUSHclient as a plugin (File menu -> Plugins).


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, July 25, 2006, 7:31 AM -->
<!-- MuClient version 3.75 -->

<!-- Plugin "MXP_Tag_Fixer" generated by Plugin Wizard -->

<muclient>
<plugin
   name="MXP_Tag_Fixer"
   author="Nick Gammon"
   id="2cad9c303fac53bb0a186ef4"
   language="Lua"
   purpose="Attempts to display incorrect MXP tags"
   date_written="2006-07-25 07:24:35"
   requires="3.67"
   version="1.0"
   >

</plugin>


<!--  Script  -->


<script>
<![CDATA[
-- conversion table

t = {
    ["<"] = "&lt;",
    [">"] = "&gt;",
    ["&"] = "&amp;",
    }

-- find 1st character in table, append 2nd character

function converter (what)
  return (t [string.sub (what, 1, 1)] .. string.sub (what, 2)) or what
end -- converter 

-- convert < > & to: &lt; &gt; &amp;

function OnPluginPacketReceived (s)
  if GetInfo (104) or GetInfo (105) then  -- MXP or Pueblo active
    return (string.gsub (s, "[<>&]%A", converter))
  else
    return s
  end -- if
end -- OnPluginPacketReceived 
]]>
</script>


</muclient>


What this will do is convert <x where x is not an alphabetic character into &lt;x, which (in my test) made your map come out alright. This will catch *some* of the problems with MXP where the server does not convert the < symbols correctly.

Your other problem is with the strange line wrapping near the bottom of your original post. Can you please post a packet dump of that so we can see what is going on? Thanks.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Mon 24 Jul 2006 06:46 PM (UTC)  [ quote  ]
Message
Quote:
Perhaps when in open mode if the mud sends < instead of &lt and it isn't followed by a recognized open tag the client should just pass it through?


Long argument about this, both between players and Nick, as well as Nick and Zugg. Basically, the specifications say "very clearly" that < "must" be converted. zMud fails to follow this specification, which produces a disasterous mess. Frankly, I wouldn't mind much having a, "Emulate Zmud behaviour for '<'.", flag someplace, at least until/if this ever gets resolved, but that might end up resulting in it "never" being resolved. :( Then again, I don't see Zugg doing anything to fix it any time soon anyway.

But, this is a bit like an IE vs. Mozilla bug. Where one tries its best to follow the spec, the other doesn't, and thus any page made for IE specifically won't work right in Mozilla based browsers. And, just as with that case, the problem isn't the specification, which is clear on how it must work, but the fact that everyone "testing" muds ends up using zMud to run the tests.

That said, I would "still" prefer the option of letting bad tags drop through, while still generating errors, just so long as its clear that "isn't" correct behaviour in cases where its not actually a "tag". Why? Because "seeing" a tag fail is easier than scripting a whole error system. But that's just my view on the matter, it still ends up making it too easy for people to ignore the specifications. Maybe if there was some way to make it obvious that the text "was" processed as a tag, but fell through, so that it displays, but is like double overstriked or something... Something that the normal "font" tag can't do. Hmm. Upside down? lol

Anyway...
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] 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.

11,049 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]