Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ MXP bug
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1 2
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Sun 23 Jul 2006 10:07 PM (UTC) |
Message
| 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #1 on Sun 23 Jul 2006 11:43 PM (UTC) |
Message
| 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 < 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 |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Reply #2 on Mon 24 Jul 2006 12:02 PM (UTC) |
Message
| 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 < like you suggested...
Perhaps when in open mode if the mud sends < instead of < and it isn't followed by a recognized open tag the client should just pass it through? | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #3 on Mon 24 Jul 2006 06:46 PM (UTC) |
Message
|
Quote: Perhaps when in open mode if the mud sends < instead of < 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... | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #4 on Mon 24 Jul 2006 09:42 PM (UTC) |
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 <
- > should be rendered as >
- & should be rendered as &
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 <I> 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 = {
["<"] = "<",
[">"] = ">",
["&"] = "&",
}
-- 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: < > &
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 <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 | Top |
|
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Reply #5 on Mon 24 Jul 2006 10:52 PM (UTC) 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... | Top |
|
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Reply #6 on Mon 24 Jul 2006 11:01 PM (UTC) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #7 on Mon 24 Jul 2006 11:08 PM (UTC) |
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 = {
["<"] = "<",
["&"] = "&",
}
-- 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: < &
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>
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #8 on Mon 24 Jul 2006 11:19 PM (UTC) |
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 | Top |
|
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Reply #9 on Mon 24 Jul 2006 11:29 PM (UTC) 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>-<---- Vnum: 3700 ----------------------------->- -<---(*)--->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 | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #10 on Mon 24 Jul 2006 11:36 PM (UTC) |
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 | Top |
|
Posted by
| Greymouser69
(6 posts) Bio
|
Date
| Reply #11 on Mon 24 Jul 2006 11:56 PM (UTC) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #12 on Tue 25 Jul 2006 01:04 AM (UTC) |
Message
| Put <PRE> ... </PRE> around the whole thing. That preserves formatting. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #13 on Tue 25 Jul 2006 01:24 AM (UTC) |
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 < > to > and & to & 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 | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #14 on Tue 25 Jul 2006 06:52 PM (UTC) |
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. | 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.
64,138 views.
This is page 1, subject is 2 pages long: 1 2
It is now over 60 days since the last post. This thread is closed.
Refresh page
top