Color change discussion thread.

[John]

Like all new features of this magnitude, we can expect there to be issues.  I'll just knock them out one wrong color at a time!

I'll give it a chance from time to time. I'm fairly happy with the Mushclient colours I've got. It's mainly the iPad client I wanted to get colourised. However that's where I'm getting the most issues (and given some of them are only happening on that, I'm guessing it's an iPad client issue, not a server issue).

[Nathvaan]

Okay, I figured out how to get the colors to work, after a fair amount of experimenting with settings.

I now have another weird problem in CMUD:  whenever I click on the text in the active mud window, it sends the command:  "Number: 99 Number:100 Number:101 Number:102."

Very strange.  It should only issue any output that looks like that in 'change color palette'.  Can anyone else verify their experience in CMUD?  This will let us know if it is client side or not.

[Sedora]

Just a heads up to other people, in case someone else is running into my crazy problem.

While troubleshooting with the creator of the InfoBar plugin, I discovered that I had the in-game infobar enabled on accident. This built-in bar option is what was causing my stam stat to continually post in my game when I was logged in. Now that I disabled that, I'm able to run the plugin InfoBar and have my colors.

[Synthesis]

Okay, I figured out how to get the colors to work, after a fair amount of experimenting with settings.

I now have another weird problem in CMUD:  whenever I click on the text in the active mud window, it sends the command:  "Number: 99 Number:100 Number:101 Number:102."

Very strange.  It should only issue any output that looks like that in 'change color palette'.  Can anyone else verify their experience in CMUD?  This will let us know if it is client side or not.

It stopped doing it.  Absolutely no idea why it was doing it, but when I opened a new session, it just stopped.

D'oh, nevermind.

As soon as I typed "change color palette" and got that number output, it started doing the click-command thing again.  There must be some kind of automatic script running in CMUD that interprets the 'change color palette' output as a command.  I have all scripts, triggers, aliases, and macros turned off.  I have all "extra" bullshit turned off.

It stops again when I close the session and open a new one.  Oh well.

[nauta]

Nice!  I did notice a few strange things show up in red -- I was spam putting arrows on a bench and one of them turned red for some reason.  I'll see if it happens again, and send in a bug report.

Two itsy bitsy things:

1. Staff Echoes.

- Staff using the echo command will now color as an emote.

I posted a bit ago about how the staff echoes can get lost in RPTs with all the other noise.  If it's easy, perhaps we could make this its own category so we could highlight them in bright on our clients, e.g., fg_staff_echo.

2. I noticed that with the new release sometimes my opponent is highlighted bright white (sometimes not) -- so it's sort of shifting between the old / new color system at the moment.  For instance (it also lowercases 'a' -- imagine the bold bit as bright white on the output):

a whip-tailed turaal claws at you, but you dodge out of the way.
You slash a whip-tailed turaal's body.

[Nathvaan]

Nice!  I did notice a few strange things show up in red -- I was spam putting arrows on a bench and one of them turned red for some reason.  I'll see if it happens again, and send in a bug report.

Two itsy bitsy things:

1. Staff Echoes.

- Staff using the echo command will now color as an emote.

I posted a bit ago about how the staff echoes can get lost in RPTs with all the other noise.  If it's easy, perhaps we could make this its own category so we could highlight them in bright on our clients, e.g., fg_staff_echo.

2. I noticed that with the new release sometimes my opponent is highlighted bright white (sometimes not) -- so it's sort of shifting between the old / new color system at the moment.  For instance (it also lowercases 'a' -- imagine the bold bit as bright white on the output):

a whip-tailed turaal claws at you, but you dodge out of the way.
You slash a whip-tailed turaal's body.

1) Sounds like a fine idea.  I'll toss around the implications and see if this is feasible.
2) Hmm.  Yeah.  About that..... That would be a bug that I introduced when testing something and forgot to remove.  Whoops!  I know exactly what it is and it will be removed when I have a chance to update the code, push the changes and reboot.  For the record it only happens when you 'dodge out of the way' in combat.

[Samoa]

Nath, this is really cool. Thank you for all your hard work on this.

A few suggestions:

When listing, the NPC name is highlighted in the same colour as the items, perhaps it could be 'n/pc coloured'.
Likewise in shops, I don't know that the WHOLE line should be coloured; perhaps just the object name? Maybe this is just a matter of preference.

As an addition, it would be nice to have access to colour code in the prompt; while ideally we could have a dynamic shifting range that could colour as it gets lower, it'd be nice just to have a bit of colour in general for those who want it. I am FIRMLY against players EVER having the ability to 'generate' colour in-game, but it'd be nice to have access to it for things only they see, ESPECIALLY if it's dynamic (colour 'invisible' in the prompt, or 'armed' vs 'unarmed', and I think we'd all be a lot better off). Maybe this could be done with fg_warning/bg_warning (sneaking, moderate hp, armed), and fg_danger/bg_danger for higher impact (invisibility, low hp, other things).

Again, a great quality of life change and I think you 100% made the right decision on how it's designed. Great work.

[TroopSharp]

I've got a few problems all showing up.

#1 If I make a color profile, all colors are also in italicized text.  When I type 'change color palette', all options are italicized.  If I type change color default, all text output becomes italicized regardless of whether it is colored or not.  When I copy paste it from my window to here it's non italicized.  If I type change color off everything goes back to how it was, except for #2.

#2 I still have the old highlight from combat showing up but in reverse.  If I successfully hit something or get hit the line is all in flat grey.  Every time I miss or it shows the short desc of someone in combat missing or not hitting it gets highlighted the way old hits used to be brighter white.  This part in tests has made it incredibly hard for me to follow combat, and if I try to fix it via change color options, it italicizes all text in combat and makes it even harder to read while the same problem continues.

#3 Why say that the use of it is optional if you took away the way it was before where things were comfortable?  I really just wanted the flat default color with only highlights on sdescs of who's hit in combat to remain.  This is in response to the post that said

After looking I remembered why it isn't set to work that way currently. The new methods that give colored text to the players is not compatible, as is, with the old method.  It will take a pretty significant refactor to get that kind of thing working.

Also, information that might help.  I'm using Mushclient.  When I type color palette and it's all italicized, there are also only a few numbers on that list that show any color, but there's 255 numbered entries.  Does that mean this is somehow client side even though I'm not having issues before this or in any of the other muds I play?

[Hauwke]

I have an issue with:
Change color fg_emote green
It comes out changing the background color rather than the foreground, and since all my says and such of that stuff is all green no seeing emotes in green is a little wierd. Doing change color bg_emote does the exact same thing sadly.
Little help anyone?

[Nathvaan]

I've got a few problems all showing up.

#1 If I make a color profile, all colors are also in italicized text.  When I type 'change color palette', all options are italicized.  If I type change color default, all text output becomes italicized regardless of whether it is colored or not.  When I copy paste it from my window to here it's non italicized.  If I type change color off everything goes back to how it was, except for #2.

#2 I still have the old highlight from combat showing up but in reverse.  If I successfully hit something or get hit the line is all in flat grey.  Every time I miss or it shows the short desc of someone in combat missing or not hitting it gets highlighted the way old hits used to be brighter white.  This part in tests has made it incredibly hard for me to follow combat, and if I try to fix it via change color options, it italicizes all text in combat and makes it even harder to read while the same problem continues.

#3 Why say that the use of it is optional if you took away the way it was before where things were comfortable?  I really just wanted the flat default color with only highlights on sdescs of who's hit in combat to remain.  This is in response to the post that said

After looking I remembered why it isn't set to work that way currently. The new methods that give colored text to the players is not compatible, as is, with the old method.  It will take a pretty significant refactor to get that kind of thing working.

Also, information that might help.  I'm using Mushclient.  When I type color palette and it's all italicized, there are also only a few numbers on that list that show any color, but there's 255 numbered entries.  Does that mean this is somehow client side even though I'm not having issues before this or in any of the other muds I play?

This is unusable behavior that I haven't seen any of my testing using MUSHclient.  What version of MUSHclient are you using?

1) No where in the code currently do we issue the ANSI escape code for italics so by definition something must be going on on the client side.  I looked briefly to see if there were any bugs like this listed in any MUSHclient versions but didn't find anything specific.  Copying and pasting text from one application to another won't actually include the ANSI escape codes.

2) This is a bug I accidentally introduced on Monday morning.  This is resolved in my testing and will be deployed to production at the latest of this coming Monday. It is issuing escape codes for bold (brighter white in your case) and was a test to once again try and reintroduce the old functionality but was unsuccessful.

3) I totally understand the concern and I have, on multiple occasions over the last couple months, attempted to merge the two features.  In this case it is complicated by the way that colors are created and nesting the statements.  Getting deep into the weeds here but basically in testing when I fully nest ANSI escape codes it seems to significantly misbehave as you are seeing in point 2 above. I fully intend to try and reintroduce this bold feature in the future if I can manage a way to work through the technical issues.

As with any feature as large as this there will be some growing pains.  Please bear with us as we get through these issue.  I am not done implementing features for colors and things will get better.

Specifically to your client side issue I would first make sure you are on a reasonably new version of MUSHclient (I use 4.94 for instance).  Second, as a test I would create a new world file and see if with 100% default settings you have the issue.  If you do not, you should look through your setting 'game -> configure' to see what is set in your current world profile.  Specifically I would check 'ANSI colour' settings and 'Printing' options.  For instance, does Printing show any checkboxes with italics enabled?

You will see another release notes post on the staff announcements board when I have deployed the fix for #2 above.

[Nathvaan]

I have an issue with:
Change color fg_emote green
It comes out changing the background color rather than the foreground, and since all my says and such of that stuff is all green no seeing emotes in green is a little wierd. Doing change color bg_emote does the exact same thing sadly.
Little help anyone?

Interesting.  I'll be glad to help if I can!

First, what client and version of the client are you using?

Second, can you share your 'change color export' settings for both scenarios described above as well as a description (of screen shot) of what you are seeing?  This will let me understand the actual settings you have and reproduce those on my account as well.

Lastly, if you wish up while online and I am available I would be glad to see if I am seeing the same thing with your exact setting by watching your connection.  If we see different things then is clearly points to an odd client side issue.

[Iiyola]

I'm actually switching between these two on the fly. They deal only with foreground combat:

cute set:
change color fg_combat_charhit 174
change color fg_combat_victhit 178
change color fg_combat_room 229
-------------------
practical set
change color fg_combat_charhit 196
change color fg_combat_victhit 34
change color fg_combat_room 229

I like it. Do you have any other adjustments? For thinks, feels, psi's perhaps?

[TroopSharp]

2) This is a bug I accidentally introduced on Monday morning.  This is resolved in my testing and will be deployed to production at the latest of this coming Monday. It is issuing escape codes for bold (brighter white in your case) and was a test to once again try and reintroduce the old functionality but was unsuccessful.

Good news!  From the effect it seems you are on the right trrack.

[quote="Nathvaan]3) I totally understand the concern and I have, on multiple occasions over the last couple months, attempted to merge the two features.  In this case it is complicated by the way that colors are created and nesting the statements.  Getting deep into the weeds here but basically in testing when I fully nest ANSI escape codes it seems to significantly misbehave as you are seeing in point 2 above. I fully intend to try and reintroduce this bold feature in the future if I can manage a way to work through the technical issues. [/quote]

Cool.  I hope this wasn't too snark.  When it comes to code I think keeping old functionality maintains priority before any injection happens so this miffed me a bit.  The only exception in that model for me is when the old functionality is actively being replaced to no longer be available.  Maybe in the future run things solely on a test port until you can demonstrate consistently that the old functionality is not unaffected, then expand to bugs from there.  That allows for a continue as usual approach with expanded features instead of lots of problems you have to deal with until we fix it approach.

I'm using Mushclient 4.94, and for now have managed to fix the italicized problem that is only happening in Arm by making my client completely unable to display italics.  I look forward to things returning to normal for me.

[Miradus]

Turned on color. Tested it.



Turned color off.

I've just grown too accustomed to no color.

[Hauwke]

Im using blowtorch Test version. And here is the color export.
change color export
change color none
change color fg_say 2
change color fg_shout 2
change color fg_psionics 93
change color fg_room_name 11
change color fg_room_exits 208
change color fg_tell 2
change color fg_whisper 244
change color fg_ooc 182
change color fg_sing 2
change color fg_talk 2
change color fg_wish 163
change color fg_object 14
change color fg_char 142
change color fg_combat_charhit 196
change color fg_combat_charmiss 118
change color fg_combat_victhit 88
change color fg_combat_victmiss 106
change color fg_combat_room 220
change color bg_emote 0

That is before change

.> change color fg_emote green
Setting emote foreground text to green


> change color export
change color none
change color fg_say 2
change color fg_shout 2
change color fg_psionics 93
change color fg_room_name 11
change color fg_room_exits 208
change color fg_tell 2
change color fg_whisper 244
change color fg_ooc 182
change color fg_sing 2
change color fg_talk 2
change color fg_wish 163
change color fg_object 14
change color fg_char 142
change color fg_combat_charhit 196
change color fg_combat_charmiss 118
change color fg_combat_victhit 88
change color fg_combat_victmiss 106
change color fg_combat_room 220
change color fg_emote 2
change color bg_emote 0

I will send  a screen shot via email or something I guess? Otherwise its basically just like it is setting the bg_emote to a bright green. Having looked at the color export it may be a client issue, however my says and sings and talks are the same and have 0 issue.

Edited to add: Fg_emote changes the background color no matter what color I put in except one of the blacks to match my background.

[Nathvaan]

<snip>
I will send  a screen shot via email or something I guess? Otherwise its basically just like it is setting the bg_emote to a bright green. Having looked at the color export it may be a client issue, however my says and sings and talks are the same and have 0 issue.

Edited to add: Fg_emote changes the background color no matter what color I put in except one of the blacks to match my background.

As far as fg_emote changing bg_emote I am starting to think this may be a bug as well.  I will try and get this looked at and fixed soon. 

Can you try pasting in this and see what your experience is like?  Also, feel free to email me screenshots at nathvaan@armageddon.org.  Thanks.

change color none
change color fg_say 2
change color fg_shout 2
change color fg_psionics 93
change color fg_room_name 11
change color fg_room_exits 208
change color fg_tell 2
change color fg_whisper 244
change color fg_ooc 182
change color fg_sing 2
change color fg_talk 2
change color fg_wish 163
change color fg_object 14
change color fg_char 142
change color fg_combat_charhit 196
change color fg_combat_charmiss 118
change color fg_combat_victhit 88
change color fg_combat_victmiss 106
change color fg_combat_room 220
change color fg_emote 2

[Hauwke]

Done and it seems to be fixed.

[azuriolinist]

Yeah. There seems to be a bug with bg_emote in that when you log off and log back in, bg_emote automatically sets to 0--which may or may not be black/green depending on the client settings. I've seen this when typing 'change color export' immediately after logging in.

[Nathvaan]

Yeah. There seems to be a bug with bg_emote in that when you log off and log back in, bg_emote automatically sets to 0--which may or may not be black/green depending on the client settings. I've seen this when typing 'change color export' immediately after logging in.

I am looking into this one. Thanks for letting me know.

[Hauwke]

Thanks for your help Nath, I enjoy the color. Wasnt sure I would but it brightens it up a bit.

[Nathvaan]

Yeah. There seems to be a bug with bg_emote in that when you log off and log back in, bg_emote automatically sets to 0--which may or may not be black/green depending on the client settings. I've seen this when typing 'change color export' immediately after logging in.

I am looking into this one. Thanks for letting me know.

Looks like I just needed to sleep on this.  I found the issue.  I typoed EMOTE as EMTOE in the place where it saves the bg_emote data.  This will be fixed on the next code push.  Thanks.

[Hauwke]

Rofl, that seems like one of the easiest to make mistakes ever.

[Armaddict]

The joys of coding.

Semicolons, typos, and out of bounds errors. 

[Nathvaan]

This is now resolved on the main game.  Also a number of other coloring issues were resolved.  Hopefully this will button up the current list of bugs.  Thanks.

[Delirium]

Looking good. Just wish there was an OOC area I could sit and fiddle with this.

No apologies for random semi-odd behavior and zombie sitting...!