After adding color to the entire game, colors are for some reason sometimes change the darker color, instead of what it should be, such as if I put &Ggreen in a room desc, it would show up as the darker green (&g). I think I have seen this question asked before, and I searched around for it, but could not find it. Could someone point me in the right direction, or help me?
Color reference problem
Posted by Zeno on Sat 05 Jul 2003 09:50 PM — 21 posts, 67,447 views.
I think it came up recently in the context of mixing a colour with bold. Is that is what is happening here?
I don't think so, I just use a normal &G and it then displays the darker green. No bold or anything else involved.
Although it doesn't happen all the time. For example, the MOTD has a few bright (&G &R) colors in it. When someone logs on and see's it, its all dark (&g &g) but when your on the mud, and read HELP MOTD, it displays the colors corretly.
Although it doesn't happen all the time. For example, the MOTD has a few bright (&G &R) colors in it. When someone logs on and see's it, its all dark (&g &g) but when your on the mud, and read HELP MOTD, it displays the colors corretly.
on smaug, colors like to bleed into other colors. try to put like &Y&Ggreen, that might make it the brightness, or end the line before it with &W or something of that nature.
They bleed into, if the next text isn't stated a color, but blending? I'm not sure, but I'll try it.
[EDIT] No, didn't work. &Y&Ggreen displayed the darker green, and the text before it ended with &W.
[EDIT] No, didn't work. &Y&Ggreen displayed the darker green, and the text before it ended with &W.
What client are you using? We need to establish if this is a server problem or a client problem.
MUSHclient of course. :P
I don't seem to be able to reproduce this. What version of MUSHclient are you using, and what version of SMAUG?
One possibility seems to be that it remembers what colour it last output, and if no change, doesn't send the same colour again. I see in new_descriptor is a line:
dnew->prevcolor = 0x07;
However it sounds in your case that you have somehow not got the bold version of green - for me dark green is unbold, whereas light green is bold green.
I suggest doing a packet debug. Quit your character, turn it on (edit menu) log on, see the MOTD, do your HELP MOTD, turn off packet debug, and compare the codes output.
I got this (amongst a heap of other stuff):
.[1;32m
The dot was the escape character. That represents bold green.
What we need to know is if you got that code. If you got it, and it isn't bold green on the screen it is a client problem. If you didn't it is a server problem.
One possibility seems to be that it remembers what colour it last output, and if no change, doesn't send the same colour again. I see in new_descriptor is a line:
dnew->prevcolor = 0x07;
However it sounds in your case that you have somehow not got the bold version of green - for me dark green is unbold, whereas light green is bold green.
I suggest doing a packet debug. Quit your character, turn it on (edit menu) log on, see the MOTD, do your HELP MOTD, turn off packet debug, and compare the codes output.
I got this (amongst a heap of other stuff):
.[1;32m
The dot was the escape character. That represents bold green.
What we need to know is if you got that code. If you got it, and it isn't bold green on the screen it is a client problem. If you didn't it is a server problem.
I'm using MUSHclient 3.32, Smaug 1.4a.
Although a question. What exactly is a bold text, is it with Smaug?
Logged on normally, MOTD darker color. Logged off, turned on debug packet, and logged on. I got stuff like .[m.[32m or ...[31m
Although a question. What exactly is a bold text, is it with Smaug?
Logged on normally, MOTD darker color. Logged off, turned on debug packet, and logged on. I got stuff like .[m.[32m or ...[31m
Bold (hilite really) is an ANSI code that says to use the stronger version of a colour. See:
http://www.gammon.com.au/scripts/doc.php?function=ansi
This lists common ANSI codes. You can see from that that bold is 1 and green is 32.
So, .[1;32m (where the dot is Escape) would be bold and green. It could also appear as: .[1m.[32m (ie bold and then green). However the fact that you got .[m.[32m is strange. It suggests the bold is not being sent. I think you would find that the first one (.[m) is just a "reset" to turn everything back to normal. That is, without a number it is assumed to be zero, and zero is reset.
The next test is to do "help motd" with packet debug and see if the code you get is different (ie. is the "1;" there?).
A bit of research shows that the MOTD shows up by simply doing a "help MOTD" like this:
The \033[2J is sending a "page clear" which will blank the page on ANSI emulators. After that it seems to be doing the same thing as HELP MOTD.
http://www.gammon.com.au/scripts/doc.php?function=ansi
This lists common ANSI codes. You can see from that that bold is 1 and green is 32.
So, .[1;32m (where the dot is Escape) would be bold and green. It could also appear as: .[1m.[32m (ie bold and then green). However the fact that you got .[m.[32m is strange. It suggests the bold is not being sent. I think you would find that the first one (.[m) is just a "reset" to turn everything back to normal. That is, without a number it is assumed to be zero, and zero is reset.
The next test is to do "help motd" with packet debug and see if the code you get is different (ie. is the "1;" there?).
A bit of research shows that the MOTD shows up by simply doing a "help MOTD" like this:
set_pager_color( AT_PLAIN, ch );
if ( xIS_SET(ch->act, PLR_RIP) )
send_rip_screen(ch);
if ( xIS_SET(ch->act, PLR_ANSI) )
send_to_pager( "\033[2J", ch );
else
send_to_pager( "\014", ch );
if ( IS_IMMORTAL(ch) )
do_help( ch, "imotd" );
if ( ch->level == 50)
do_help( ch, "amotd" );
if ( ch->level < 50 && ch->level > 0 )
do_help( ch, "motd" );
if ( ch->level == 0 )
do_help( ch, "nmotd" );
send_to_pager( "\n\rPress [ENTER] ", ch );
d->connected = CON_READ_MOTD;
The \033[2J is sending a "page clear" which will blank the page on ANSI emulators. After that it seems to be doing the same thing as HELP MOTD.
Did the test and got things like
.[m.[1;32m
...[33m
.[m.[1;32m
...[33m
Strange. So in the initial login you don't get the "1;" but later on you do? Can you confirm that the message is indeed the MOTD one, and that your code in comm.c looks like the stuff I posted further up?
If it matters, its actually the IMOTD. And the code isn't the same... I figured why bother with those ansi files, I just made a help file.
But it doesn't happen in IMOTD alone, it also happens in room desc's etc
set_pager_color( AT_PLAIN, ch );
if ( xIS_SET(ch->act, PLR_RIP) )
// send_rip_screen(ch);
if ( xIS_SET(ch->act, PLR_ANSI) )
do_help( ch, "_login_" );
//send_to_pager( "\033[2J", ch );
else
send_to_pager( "\014", ch );
if ( IS_IMMORTAL(ch) )
do_help( ch, "imotd" );
if ( ch->level == 50)
do_help( ch, "motd" );
if ( ch->level < 50 && ch->level > 0 )
do_help( ch, "motd" );
if ( ch->level == 0 )
do_help( ch, "motd" );
send_to_pager( "\n\rPress [ENTER] ", ch );
d->connected = CON_READ_MOTD;
But it doesn't happen in IMOTD alone, it also happens in room desc's etc
For a start, I'm a bit worried about these lines:
if ( xIS_SET(ch->act, PLR_RIP) )
// send_rip_screen(ch);
You have left the "if" in but taken out the line that it affects, this will change the logic.
However I don't think this is the problem, if it is affecting room descs as well you have some sort of problem in the way it translates colours.
if ( xIS_SET(ch->act, PLR_RIP) )
// send_rip_screen(ch);
You have left the "if" in but taken out the line that it affects, this will change the logic.
However I don't think this is the problem, if it is affecting room descs as well you have some sort of problem in the way it translates colours.
I'll provide an example of the room desc.
Room name- Test
Room desc-
&Rred
&Yyellow
&Ccyan
&Bblue
That would show up fine. But if I change...
Room name- >est
Room desc-
Same.
It would then convert all the room desc colors to the darker color.
Room name- Test
Room desc-
&Rred
&Yyellow
&Ccyan
&Bblue
That would show up fine. But if I change...
Room name- >est
Room desc-
Same.
It would then convert all the room desc colors to the darker color.
I've noticed a similar problem. I don't know if it's the MUD or the server either, but it seems that occasionally colors are darker than they're supposed to be. It also seems to have to do with setting a color on the line before. I haven't done a complete diagnosis, which I'll do and post here, but I'm wondering if it's MUSHclient, since other people I've spoken to don't seem to have the same problem. The problem seemed to be fairly sporadic, and was hard to obtain with regularity.
Personally I've never really trusted the SMAUG color code sending... then again, it's from SMAUG 1.0 and it has probably been improved since then. :)
Personally I've never really trusted the SMAUG color code sending... then again, it's from SMAUG 1.0 and it has probably been improved since then. :)
I don't think its MUSHclient, I've heard other people having this problem who use various other clients.
I suspect it is something to do with the optimization code at the server end. Somehow seeing the green first is making it think it doesn't need to send the bold code again the next time around.
Alright, I found a way to fix it. If you get this problem, do this. Lets say you use &G and it displays the darker. Use &w&G and it will work fine.
The problem you're having is because the Smaug 1.4a color parser is buggy as all hell. I spent months trying to wrestle it into submission and finally gave up and replaced it with the custom color code I have on my site. Ever since I did that, everything just works as expected. You may want to consider doing the same rather than relying on cheap fixes :P
Ah, a permanant fix. Just what I've been looking for. I'll look it over, thanks.
[EDIT] Would that be "Customizable ANSI Color v3.0 " ?
[EDIT] Would that be "Customizable ANSI Color v3.0 " ?