Configurable Player Colors - how to deal with other colors?

[Leartin]

I played around with the source code for a bit and found out that it's pretty easy to write a patch that allows player colors to be defined externally.



However, since player colors are used in all kinds of places, simply changing them is not the way to go.



I'm not certain how to deal with this. From my perspective, every instance of a color index in the code is pretty much meant to be a hardcoded color, so I'd just replace them by the actual rgb values they want to have, or make them setable via theme were that makes sense. Is there something I'm overlooking for why this wouldn't be possible?

Factories and Goods reference the same list. I'd just ignore that though, since it's impossible to accomodate for that unless a second array with the original values is created - which seems rather dumb. Would that be okay, or is a solution for old factories and goods to keep their original color absolutely required?

[prissi]

Since about 4 years one could use RGB colors for factories and other things. Also one could use a second array only for player colors, since there is no 8 bit driver support any more.

One could also change simcolor to return only rgb. Not sure if this is possible in all cases.

[Leartin]

Since about 4 years one could use RGB colors for factories and other things.

I doubt anyone went and changed that. Anyway, I was questioning wether it's acceptable for paks with the old color definition to lose the original color.

Also one could use a second array only for player colors, since there is no 8 bit driver support any more.

But would that be useful for anything but factory/good colors? I suppose if I just want my setable player colors, it COULD be nice to just create "special_pal_players" and search&replace every instance where it's player colors rather than gui. But would that be an improvement?
Changing all colors, while certainly harder, seems like an improvement overall. Especially if the color-index-system is just a relic rather than actually better for performance.

One could also change simcolor to return only rgb. Not sure if this is possible in all cases.

I'd duplicate them. That is, "COL_BLACK" is an index, I'd create "RGB_BLACK" in simucolor defining "color_idx_to_rgb(COL_BLACK)", then slowly walk through all other files and change the references. Eventually, COL_BLACK is no longer needed, and can be removed simply by hardcoding "RGB_BLACK" to "0xFFFF". I don't think it's possible to make COL_BLACK a PIXVAL and then change all the files referencing it, since there are surely too many to do it reasonably in one go. If I start now and be done in half a year, I'd have a massive incompatible patch, plus I couldn't even test if I made mistakes before I'm done. Since that method means I don't actually get playercolors until I'm done, I'm  more likely motivated to see it through.

I think the largest chunk of this undertaking is simply copypasting and removing "idx_to_rgb" functions left and right, which is something I can do.

If I come across a collection of colors not yet in simcolor or simgraph, should I outsource them? I see that the financial window already references colors defined in simcolor rather than hardcoded colors, so would it make sense to do the same for mapcolors? [Though I'd rather place them in simgraph, since I'd make them to be set via config rather than theme]


Oh yeah - might be a silly question, but the game still operates with PIXVAL - that is, RGB555, with no intention to change? Just double checking, since it would be awkward to change everything, but do it wrong.

[prissi]

In principle "color_idx_to_rgb(COL_" to "(RGB_COL_" replacing (with some allowance for spaces over all files is quite straight forward. I think there are very few places of using direct color indices. (Most notable the minimaps.)

The factory colors are broken since about 12 years, when I made the 8 bit driver and introduced changable player colors for networkmode. This needed the 8 shades, which the old plaette did not have (it was rather random). I do not think pak128 ever updated factory colors since then.

[Leartin]

Yes, most replacements are straightforward. There are some I'm uncertain about.

=> In bauer/goods_manager.cc, there is a spot where the colors of pax and mail are defined. (Line 93)

Code Select Expand


// passenger and mail colors
if(goods[0]->color==255) {
goods[0]->color = COL_GREY3;
}
if(goods[1]->color==255) {
goods[1]->color = COL_YELLOW;


My guess is that this bit of code (as well as the one right before it) assigns colors to goods that don't define any in the dat. Since those colors are somewhat random and will be even more random if special_pal can be edited, is it fine to just replace the COLs with the numbers they represent?


In dataobj/environment.cc are instances of some colors:

Code Select Expand

file->rdwr_bool( show_tooltips );
if (  file->is_version_less(120, 5)  ) {
uint8 color = COL_SOFT_BLUE;
file->rdwr_byte( color );
env_t::tooltip_color_rgb = get_color_rgb(color);

color = COL_BLACK;
file->rdwr_byte( color );
env_t::tooltip_textcolor_rgb = get_color_rgb(color);
}

Seems to be about backwards compatibility stuff, I'm not sure what to do with those (if they are just stored as indizes, the stored color might be lost anyway if player colors change?)

Other than that, I need to adjust the minimap colors and the factory charts - and of course search for any wild instance of a color referenced via index rather than a COL-name.


EDIT:
Another question: I can set all player colors except for the second set. Are they overwritten somewhere else?

[prissi]

Sorry, what do you mean by second set?

The colors behind color 224 are fixed, because these are the special night colors and thus handled differently during bringhten and darkening.

[Ranran(retired)]

If the player color is the same as before, this orange color has overlapping gradations.
Also I want to use pink, but there is not, and there are many similar greens. IMO, those greens don't help much to distinguish them from other players...
In many places it uses dark colors, so they look more similar.

[jamespetts]

This is an interesting discussion: if the player colours could be de-linked from the hardcoded world colours, it would be much easier to increase the number of player slots. I have attempted to do this for Extended in the past, but have been unable to make progress on this in light of the impenetrable player/special colour code: even adding one or two players ended up causing various random pixels on ways, buildings, grounds, etc., to show up as whatever colour had been selected for that player.

[Leartin]

Sorry, what do you mean by second set?

I mean the second set of 8, for the second player (public hand).
I set all player colors to the same set of colors in an attempt to see in the game where player colors are used. The public hand is still grey, so I think there must be something special about those 8 shades of grey.

The lightcolors are not fixed though - they can be set in the simuconf.tab. In fact, the very first thing I did was look up the patch that allowed custom lightcolors and copypasted the code for playercolors.
(Plus, the entries "MN_GREYX" refer to lightcolors, but only for their shades, not for their ability to change at night - perhaps from a time where the menu actually had to use those colors so it wouldn't darken. Hence I replaced those)

If the player color is the same as before, this orange color has overlapping gradations. Also I want to use pink, but there is not, and there are many similar greens. IMO, those greens don't help much to distinguish them from other players...

The idea is to make them setable via Simuconfig. From my perspective, the colors the game comes with won't change, especially since the colors I'd choose (and will use for p192.comic) are quite saturated and might not fit well with more moody paksets.
Bit of a preview:

Like the pink? There are two oranges, the right one to somewhat reflect a historic livery in my country. And my favorite of the bunch since it didn't exist at all: Beige.

This is an interesting discussion: if the player colours could be de-linked from the hardcoded world colours, it would be much easier to increase the number of player slots. I have attempted to do this for Extended in the past, but have been unable to make progress on this in light of the impenetrable player/special colour code: even adding one or two players ended up causing various random pixels on ways, buildings, grounds, etc., to show up as whatever colour had been selected for that player.

What I'm doing it de-linking colors in the gui that currently refer to the "special palette", to instead use color values provided seperately in simcolor.h. This allows for player colors to change without changing the look of the gui, and probably makes it easier to turn gui-colors into theme-set colors by replacing the color value with the theme reference.
It changes nothing about image processing, so I doubt it will solve your issues.

[Ranran(retired)]

The idea is to make them setable via Simuconfig. From my perspective, the colors the game comes with won't change

I expected a differentiated player color, so it's a bit disappointing not to.
However, I support what you are trying to do. Because the current auto-fixed player color gradient is not suitable for drawing 3D objects.
And current player color gradation is fixed though the way of expressing light is different depending on the pakset.
I mean, depending on the pakset, the brightness balance of the roof, the surface on the south side, and the surface on the east side is different, but it is not possible to handle it. Even if there is a pakset that makes the eastern wall darker, there is a player color that does not be so dark.
In addition, the current fixed color gradation may not change much depending on the color. (It may not change as I shown above.) It creates an unwanted discrepancy with other player colors.

Bit of a preview:

I think the reason why your vehicle sample looks so good is that that issue is solved.

Like the pink?

As for vehicle color, I prefer a color close to salmon pink, but I wanted such a vivid color for the name color and plate color.
In the network game, the player color is one identity, so I wanted a color that stands out while avoiding competition with other companies. Currently, red, blue, yellow-green, yellow, and orange are often noticeable. I wanted pink as an option that wouldn't overlap with them.

[Vladki]

The public hand is still grey, so I think there must be something special about those 8 shades of grey.

Aren't they the same as special "menu button background colors" that are not affected by day/night cycle?

[Leartin]

Aren't they the same as special "menu button background colors" that are not affected by day/night cycle?

No, there are only 5 menu greys, special_pal[8-15] are the 8 gray shades used for the public hand.

[prissi]

If I sent any player color in simgraph_init to the desired value, it stays. SO I think there is an error with zou code. Show me zou patch and then I can comment.

[Leartin]

What sets the player colors is pretty much just this bit in settings.cc:

Code Select Expand

void settings_t::parse_simuconf(tabfile_t& simuconf, sint16& disp_width, sint16& disp_height, sint16 &fullscreen, std::string& objfilename)
[...]
// player colors
for(  int i=0;  i<28;  i++  ) {
char str[256];
sprintf( str, "player_color[%i]", i );
int *c = contents.get_ints( str );
if(  c[0]>=24  ) {
extern uint8 special_pal[SPECIAL_COLOR_COUNT*3];
// now update RGB values
for(  int j=0;  j<24;  j++  ) {
special_pal[i*24+j] = c[j+1];
}
}
delete [] c;
}

Which, as I have now noticed, only works if the colors are defined in simutrans' simuconf tab, if they are defined in the paksets simuconf.tab the colors of images change, but not the gui. Gnarf :( Chances are grey has the same problem, so maybe not overwritten, but instead initialized before the colors in simuconf.tab are read?

The entry in the simuconf is supposed to look like this:

Code Select Expand

player_color[0]=  68,71,73, 94,97,98, 117,119,119, 133,133,133, 165,165,165, 196,196,196, 236,236,236, 255,255,255 //Weiß
player_color[1]=  41,41,41, 61,61,61, 83,83,83, 99,99,99, 127,127,127, 160,160,160, 187,187,187, 211,211,211 //Grau
player_color[2]=  14,15,19, 24,26,31, 41,43,48, 55,57,62, 76,78,83, 102,103,108, 127,129,133, 170,171,175 //Schwarz
player_color[3]=  66,0,14, 105,4,20, 135,7,7, 182,13,13, 214,34,34, 221,72,48, 235,105,80, 245,138,116 //Verkehrsrot
player_color[4]=  111,38,31, 140,43,28, 169,47,25, 232,64,17, 222,81,23, 235,99,44, 241,129,69, 249,146,91 //Blutorange
player_color[5]=  109,37,5, 142,55,5, 170,70,5, 200,100,5, 235,130,5, 255,165,15, 255,190,45, 255,205,80 //Orange
player_color[6]=  120,77,7, 179,120,21, 205,146,38, 214,171,55, 224,199,83, 231,209,105, 232,223,136, 244,238,181 //Sonnengelb
player_color[7]=  95,125,9, 136,152,12, 169,182,22, 182,210,39, 173,225,54, 198,244,92, 221,250,134, 240,255,194 //Zitronengelb
player_color[8]=  15,96,0, 30,117,0, 62,142,0, 91,163,0 119,181,15, 143,201,30, 175,213,45, 199,225,76 //Gelbgrün
player_color[9]=  2,44,22, 3,82,19, 9,132,9, 19,189,19, 42,226,42, 109,229,72, 165,240,104, 206,244,157 //Grün
player_color[10]= 8,52,0, 16,65,0, 33,81,0, 49,97,0, 66,113,8, 82,134,16, 107,150,24, 132,170,41 //Chromoxid
player_color[11]= 15,21,19, 31,41,32, 41,56,35, 57,77,52, 77,104,73, 96,119,91, 120,140,111, 142,160,138 //Tannengrün
player_color[12]= 28,55,46, 14,68,58, 31,90,79, 26,128,109, 31,164,114, 51,204,153, 90,210,166, 148,219,184 //Türkis
player_color[13]= 0,52,85, 0,81,103, 4,109,118, 22,146,155, 38,168,175, 56,188,198, 89,197,182, 125,212,190 //Aquamarin
player_color[14]= 36,75,103, 57,94,124, 76,113,145, 96,132,167, 116,151,189, 136,171,211, 156,190,233, 176,210,255 //Hellblau
player_color[15]= 8,22,53, 19,39,72, 38,59,97, 67,87,122, 106,122,151, 146,159,184, 180,191,210, 226,232,241 //Azurblau
player_color[16]= 1,11,52, 2,21,99, 20,47,158, 53,56,181, 85,73,196, 129,108,226, 160,144,234, 193,182,244 //Blau
player_color[17]= 29,14,68, 53,19,95, 80,27,133, 117,34,166, 145,57,199, 181,84,220, 201,112,219, 235,160,224 //Violett
player_color[18]= 76,2,27, 92,1,31, 117,2,40, 152,3,48, 184,2,50, 216,20,78, 244,43,97, 255,70,93 //Weinrot
player_color[19]= 82,0,41, 107,8,66, 132,28,90, 156,44,115, 181,60,140, 231,73,173, 247,121,198, 255,158,214 //Magenta
player_color[20]= 108,0,130, 150,0,181, 202,24,196, 232,49,223, 234,91,227, 235,122,229, 221,147,217, 220,181,218 //Pink
player_color[21]= 108,99,57, 129,119,73, 160,144,90, 189,170,107, 213,193,130, 225,206,141, 245,221,161, 252,234,188 //Beige
player_color[22]= 79,45,25, 104,62,37, 118,76,53, 138,98,67, 157,123,86, 177,146,110, 206,181,151, 240,216,188 //Brown
player_color[23]= 46,23,20, 66,33,30, 88,41,39, 118,57,53, 148,71,65 168,99,93, 201,138,133, 234,183,179 //Rotbraun
player_color[24]= 38,32,28, 55,46,41, 73,60,54, 98,81,73, 123,102,91, 145,126,116, 175,162,155, 210,206,204 //Choco


Full patch (All color-index references in simcolor.h are replaced by colors, all places that used these references are changed to use rgb references instead, minimap and factory-chart colors were moved to simcolor.h as well so they may be easier set by theme later):
https://simutrans-germany.com/files/upload/setable_player_colors.zip

[Yona-TYT]

Wow this is very interesting  .

[ceeac]

Some comments about the patch ( in no particular order):

• The colours in the minimap have changed, is this intended? (see attached images)
• There is an inconsistency wrt. the name of the factory colours for electricity: In your patch, the colours have the "_ELE" suffix, but other parts of the code use "_ELECTRIC" (e.g. FAB_BOOST_ELECTRIC)
• Please do not introduce magic numbers for the colours (for example in bauer/goods_manager.cc, dataobj/environment.cc etc). What about renaming COL_* to COL_IDX_* so the indices can still be used where required (for loading old saves)?
• Nitpick: There is trailing whitespace, for example at the definition of minimap_t::severity_color. You can use cleanup_code.sh to remove it.

[Leartin]

The colours in the minimap have changed, is this intended? (see attached images)

The rivers and shores are not intentional, might just by a typo.
EDIT: Yep. Typo in the shore, the river got a completely wrong value. Thanks for pointing it out.

Some colors did change slightly for convenience. (They were not named and I picked a named color that's close enough) The only major change should be in the factory production statistics, were each goods chart is represented by that goods color rather than a prefixed color set.

There is an inconsistency wrt. the name of the factory colours for electricity: In your patch, the colours have the "_ELE" suffix, but other parts of the code use "_ELECTRIC" (e.g. FAB_BOOST_ELECTRIC)

Sure, that's solved by some search&replace.

Please do not introduce magic numbers for the colours (for example in bauer/goods_manager.cc, dataobj/environment.cc etc). What about renaming COL_* to COL_IDX_* so the indices can still be used where required (for loading old saves)?

It just makes no sense to have "COL_YELLOW" as an index reference, since it won't actually be yellow. I understand that magic numbers should be avoided and speaking names used instead, but an accurate description would be "PROBABLY_YELLOW_MAYBE?"
It's a bit absurd to have code intended to set something to a specific color if you cant be certain what color that would be.

For goods, the proper way to deal with this would be to change them to store their color as the color value rather than an index. This means that the magic numbers could be replaced by named RGB values. Additionally, makeobj could hold the original special_pal and convert indexed colors in dats to the rgb value they were meant to be.
Unfortunately, I don't feel confident touching the reader/writer stuff. Seems like you should know C for that... though if factories were changed to accept rgb, I might be able to copy that.

In environment.cc, it's worse. I'm not even sure what the code does exactly, but given it deals with various game versions it probably can't be changed to use rgb values.

It's 5 instances in total. Even if the magic numbers were to be removed, I'd suggest defining them on location, just to make sure they won't be reused later on and are easy to remove if a better solution is found.

Nitpick: There is trailing whitespace, for example at the definition of minimap_t::severity_color. You can use cleanup_code.sh to remove it.

I'm not sure I know how to do that, but I can give it a try.


Another thing I noticed: I tried making those colors that are not named after a color setable via theme. The way it works for text does not work for buttons and chart lines. Any quick idea why that is, before I spend too much time investigating?

[prissi]

Since the index colors never darken, one can have still the old indexed array as static in env_t or theme_t the use a lookup makro for indexed colors to PIXVAL for those which are not player colors. That way minimap colors and old good colors would stay the same.

[Leartin]

Since the index colors never darken, one can have still the old indexed array as static in env_t or theme_t the use a lookup makro for indexed colors to PIXVAL for those which are not player colors. That way minimap colors and old good colors would stay the same.

...yes.
Minimap colors stay the same either way (at least if I don't make typos), and I strongly suggest good colors should become RGB. Once that happens, any pakset that cares about good colors AND wants to change player colors can choose new good colors. Any old pakset won't have changed player colors, so the good colors won't change either. If a player changes player colors, good colors are affected - but let's be happy that same player didn't change lightcolors instead, right?
I really don't see why you'd want to keep indexed colors anywhere.


The player colors don't work properly (gray stays gray, issues from pak directory), but I'm personally happy with the rest. What would you have me do to commit that (besides _ELE, minimap colors and such, which are already done locally)?

[prissi]

I will look at the full patch, correct it so that there are no hidden bugs I find and then submit it. I assume the zip is still current then?

[Flemmbrav]

Hey hey, did looking into this work out fine?
Would be such a waste not to make use of that patch.

[Leartin]

Nope, there were issues I was simply unable to fix. The idea was to have the colors configurable via pakset setting, and that never really worked, only via game settings. Then life happened.

That's not to say it will never work - I just couldn't deliver something good enough back then. I'm sure I'll look into this again at some point and provide a patch that actually can be included.

[Ranran(retired)]

if the player colours could be de-linked from the hardcoded world colours, it would be much easier to increase the number of player slots. I have attempted to do this for Extended in the past, but have been unable to make progress on this in light of the impenetrable player/special colour code: even adding one or two players ended up causing various random pixels on ways, buildings, grounds, etc., to show up as whatever colour had been selected for that player.

https://github.com/jamespetts/simutrans-extended/commit/01d3f77449de0c5c2a03b4f658b1941c4391375e#diff-075e38bc25047b1dcf421b030aabb972d80fb130ed9060ab5a434dd5c0302ce3L1209
In simgraph16.cc, you replaced the magic number "16" with MAX_PLAYER_COUNT, which I think is a mistake. I think "16" was a color-related number, not a player-related number.
I think that's what caused the problem with the image rendering.

[jamespetts]

https://github.com/jamespetts/simutrans-extended/commit/01d3f77449de0c5c2a03b4f658b1941c4391375e#diff-075e38bc25047b1dcf421b030aabb972d80fb130ed9060ab5a434dd5c0302ce3L1209
In simgraph16.cc, you replaced the magic number "16" with MAX_PLAYER_COUNT, which I think is a mistake. I think "16" was a color-related number, not a player-related number.
I think that's what caused the problem with the image rendering.

That is very interesting, thank you. Were you able to get it to work when reverting this change?

[Ranran(retired)]

Were you able to get it to work when reverting this change?

I wasn't trying to test the max players extension, I just came across this thread again in trying to change the player color gradient system. Then I remembered that Leartin had tried to change the color gradient, so I thought I would find a clue here.
Unfortunately, the patch file was not already available.
I mean I was looking for a place to control it. And I saw James' post in this thread, so I checked the commit for reference, and I guessed that your changes caused the symptoms you mentioned in your comment, since there is no direct relationship between the color palette and the number of players.
Therefore I have not tested your max players expansion branch.

EDIT:
I tested only changing this magic number, but it didn't change any image pixel, so it may be irrelevant.