Gammon Forum : MUSHclient : Bug reports : Bleeding note colours onto basic text

Log on

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,985 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,985 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,837 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

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.