Gammon Forum
Entire forum
MUSHclient
Bug reports
Bleeding note colours onto basic text
Bleeding note colours onto basic text
|
It is now over 60 days since the last post. This thread is closed.
  Refresh page
Posted by
| Vaejor
(120 posts) bio
|
Date
| Sat 09 Nov 2002 01:25 PM (UTC) |
Message
| I've noticed it before at times, but it seems to have gotten a little worse with this update.
When you do a world.note, or even a world.send that outputs in (?almost any) colour, the next line can have it's colors altered slightly.
The hilite code seems to go missing or turned on inappropriately at times, and if the basic text is non-ansified, then it changes into the color of the prior client output.
I know one of the times I've always seen it happening is when I have client output, then gag the next line. The one following that(the first one appearing) will show up with it's ansi altered.
I'm pretty sure the mud I'm connected to sends it's ansi data at the beginning and end(or across lines where appropriate), so there's nothing strange going on there that could affect it.
If anyone else has noticed this, please drop a post.
| top |
|
Posted by
| Shadowfyr
USA (1,786 posts) bio
|
Date
| Reply #1 on Sat 09 Nov 2002 06:38 PM (UTC) |
Message
| Yes.. Common problem. I fixed it where I was bothered by using a last colourtell or note that sent a space with the attributes set to the clients ansi settings for low-white on black. (This means reading these settings, since in a plugin the client's settings for 'normal' background and white may be changed by the user). I was not aware of the hi-color/lo-color glitch though.. :p The problem seems to be that mud designers often get lazy and make some lines send without leading ansi, assuming that the prior line 'must' have ended with ESC[38;40m. The problem is that world.note and the like commands do not terminate what they send with such a sequence to return to the 'normal' colors as mud sent lines do, so the next line 'inherits' any color settings, including the 'bold' attribute that sets the colors to the hi-color mode.
Perhaps world.note and world.colournote should act as though they where sent by the mud and set the current color to the NormalColour(8) on NormalColour(0) settings of the client? It imho makes no sense for the client to handle such things by ignoring the 'standard' method of terminating lines with such a return to the basic colors. Of course this 'could' cause side effects on muds where they cheat in the 'middle' of a paragraph, so maybe a 'reset to last color attributes' would be better, since then even if they set things to green on yellow the next line after the note would end up being the right color. In any case, the fact that it doesn't correctly terminate with a reset of the attributes is an inconvenience at the very least and 'non-standard' behaviour with respect to how ansi is normally handled. | top |
|
Posted by
| Nick Gammon
Australia (22,975 posts) bio
Forum Administrator |
Date
| Reply #2 on Sat 09 Nov 2002 11:32 PM (UTC) |
Message
|
Quote:
The problem seems to be that mud designers often get lazy and make some lines send without leading ansi, assuming that the prior line 'must' have ended with ESC[38;40m. The problem is that world.note and the like commands do not terminate what they send with such a sequence to return to the 'normal' colors as mud sent lines do, so the next line 'inherits' any color settings, including the 'bold' attribute that sets the colors to the hi-color mode.
Well, not really. I had a bug report a while back because I was resetting colours to defaults on a new line, when the MUD had set (say) green on black, and expected it to stay that way while it drew a nice big ASCII picture.
MUSHclient is supposed to remember what the current colours are, however I will admit that in situations where you sprinkle in world.notes, and then add to the confusion by omitting lines, perhaps it gets a little lost.
Strictly speaking, in a sequence like this:
blah blah - ends in blue on grey (from the MUD) <-- not omitted
blah blah - ends in red on green (from the MUD) <-- omitted
A world.note here in some strange colours
xxxx new line - should still be in red on green
However having said that, I can now reproduce a problem where in that situation above the last line (without ANSI codes) is actually carrying forward the world.note colour, not the last output colour. I will investigate this forthwith.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | top |
|
Posted by
| Shadowfyr
USA (1,786 posts) bio
|
Date
| Reply #3 on Sun 10 Nov 2002 04:58 AM (UTC) |
Message
| Thanks.. This one has been around for some time now and was mildly annoying. ;) | top |
|
Posted by
| Nick Gammon
Australia (22,975 posts) bio
Forum Administrator |
Date
| Reply #4 on Sun 10 Nov 2002 08:34 PM (UTC) |
Message
| I think I found it at last. It was another instance of where there was a newline (\n) inside a single packet, the code did not correctly restore the line colour after a world.note. However it would work if the line was in a new packet.
I have moved the code which is done at the start of a packet, to a separate spot, and do it in both cases now.
This should hopefully fix up those annoying and occasional problems. Please let me know if it doesn't.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | top |
|
Posted by
| Vaejor
(120 posts) bio
|
Date
| Reply #5 on Mon 11 Nov 2002 01:48 PM (UTC) |
Message
| I've been able to replicate the instances in which I've seen the bleeding colors previously and I'm happy to say that no more bleeding is occuring at this time.
Thanks Nick. As usual, great job. :)
| 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.
15,741 views.
It is now over 60 days since the last post. This thread is closed.
  Refresh page
top
Quick links:
MUSHclient.
MUSHclient help.
Forum shortcuts.
Posting templates.
Lua modules.
Lua documentation.
Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.