This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

MXP bug

Posted by Greymouser69 on Sun 23 Jul 2006 10:07 PM — 18 posts, 89,989 views.

Greymouser69 #0
MXP seems to be causing odd formatting errors, noticed this when playing with afkmud 1.77 + automap snippet as follows:

proper display without mxp enabled:
Entrance To Newbie Nursery School                          -     -     -
-<---- Vnum:   3700 ----------------------------->-        -<---(*)--->E
                                                           -     S     -

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


Garbled display with mxp enabled:

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

[Area Flags: none]
[Room Flags: indoors]
+-----------+ [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     | 
+-----------+


Let me know if you need further details.
Nick Gammon Australia Forum Administrator #1
It's hard to know exactly what is going wrong here. The absence of the < symbols in the minimap suggests it (the MUD) is not converting them correctly to &lt; when using MXP, however a quick test shows that MUSHclient displays even less than that if you simply push through the top display. So, it must be partially converting them or something. Try going to the MXP/Pueblo configuration tab for that world and set the debug level to Warnings, and see what messages appear in a separate window.

A packet dump of the problem packets would help. See this post for more discussion about MXP/Pueblo and line wrapping issues:

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


You can do a packet dump by going to the Edit menu -> Debug Packets, and then redisplay that part of the map. Turn packet debug off again, so the debug window does not get ridiculously large.

You can then use the notepad to "quote forum codes" and then paste the debug packets here surrounded by [code] and [/code] tag.s
Greymouser69 #2
Packet debug snippet:

Sent  packet: 9 (3 bytes)

l..                6c 0d 0a

Incoming packet: 8 (1024 bytes)

...[0;32m.[1z<RN   0a 0d 1b 5b 30 3b 33 32 6d 1b 5b 31 7a 3c 52 4e
ame>Entrance To    61 6d 65 3e 45 6e 74 72 61 6e 63 65 20 54 6f 20
Newbie Nursery S   4e 65 77 62 69 65 20 4e 75 72 73 65 72 79 20 53
chool              63 68 6f 6f 6c 20 20 20 20 20 20 20 20 20 20 20
      </RName>.[   20 20 20 20 20 20 3c 2f 52 4e 61 6d 65 3e 1b 5b
2z         .[0;3   32 7a 20 20 20 20 20 20 20 20 20 1b 5b 30 3b 33
7m-     .[0;37m-   37 6d 2d 20 20 20 20 20 1b 5b 30 3b 33 37 6d 2d
    .[0;37m -...   20 20 20 20 1b 5b 30 3b 33 37 6d 20 2d 0a 0d 1b
[0;37m-<---- .[1   5b 30 3b 33 37 6d 2d 3c 2d 2d 2d 2d 20 1b 5b 31
;33mVnum:   3700   3b 33 33 6d 56 6e 75 6d 3a 20 20 20 33 37 30 30
 .[0;37m--------   20 1b 5b 30 3b 33 37 6d 2d 2d 2d 2d 2d 2d 2d 2d
----------------   2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d
----->-        .   2d 2d 2d 2d 2d 3e 2d 20 20 20 20 20 20 20 20 1b
[0;37m-.[0;37m<-   5b 30 3b 33 37 6d 2d 1b 5b 30 3b 33 37 6d 3c 2d
.[0;37m-.[0;37m-   1b 5b 30 3b 33 37 6d 2d 1b 5b 30 3b 33 37 6d 2d
.[1;37m(*).[0;37   1b 5b 31 3b 33 37 6d 28 2a 29 1b 5b 30 3b 33 37
m-.[0;37m-.[0;37   6d 2d 1b 5b 30 3b 33 37 6d 2d 1b 5b 30 3b 33 37
m->.[1;33mE..      6d 2d 3e 1b 5b 31 3b 33 33 6d 45 0a 0d 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20


Debug log:

E  1001: ( 1927) Unterminated MXP element: ----  (got <ESC>)
E  1001: ( 1927) Unterminated MXP element: - (got <ESC>)


The whole packet debug was too large to fit, but this shows the main problem area. (The "compass" display)

Of course zmud (7.21) displays this properly with mxp on, but as you can see the mud isn't sending the &lt like you suggested...

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?
Shadowfyr USA #3
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...
Nick Gammon Australia Forum Administrator #4
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.
Greymouser69 #5
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...
Amended on Mon 24 Jul 2006 10:54 PM by Greymouser69
Greymouser69 #6
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.
Amended on Mon 24 Jul 2006 11:02 PM by Greymouser69
Nick Gammon Australia Forum Administrator #7
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 Australia Forum Administrator #8
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>
Greymouser69 #9
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
Amended on Mon 24 Jul 2006 11:38 PM by Greymouser69
Nick Gammon Australia Forum Administrator #10
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.
Greymouser69 #11
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.
Amended on Mon 24 Jul 2006 11:59 PM by Greymouser69
Nick Gammon Australia Forum Administrator #12
Put <PRE> ... </PRE> around the whole thing. That preserves formatting.
Nick Gammon Australia Forum Administrator #13
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".
Shadowfyr USA #14
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.
Nick Gammon Australia Forum Administrator #15
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.
Krae Netherlands #16
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.
Nick Gammon Australia Forum Administrator #17
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 &amp;) 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 &amp; so it should be sending "rock&amp;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 &lt; &gt; &amp; 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 &amp;
  • Converts 0x01, 0x02, 0x03 back into what they were to begin with.