Well, it turns out that
/color background 90
is not a universal solution for dealing with nick colors that don't contrast with the background, because it can result in other colors losing their contrast
If you have
/color background 1
to make your background black, if someone sends text where they force the text to be back also:
//echo -a $chr(3) $+ 1 test
... then mIRC changes this text to show as white in order to prevent the background and foreground from being the same. However, it's doing this only to prevent them from being the same color INDEX not the same color shade. In the default color scheme, index 1 is black with RGB index 0, and that's the same index as for color 88, which users can verify like:
//echo -a $color(1).rgb same as $color(88).rgb
So, if you switch your background color to be index 90, the text forced to be index1=black is no longer flipped to white text, which means the foreground and background shades are almost identical and the text can't be read.
However, even if you've set your background to use the identical RGB shade as the text by using /color background 88 ... the black text is not flipped to white, because it's only checking if the foreground/background are using the same color index instead of whether they're using the same RGB shade.
I'm not so sure whether or not it would cause problems to have the color be flipped based on matching RGB rather than matching index, or whether it should flip the text color if the index is 'close enough', because that introduces the problem of how close is enough. If you set your color scheme to 'mIRC Classic', you'll see that there are duplicates between the original 16 colors and the newer colors.
//var %i 0 | while (%i isnum 0-98) { var %this $color(%i).rgb | var %j 0 | while (%j < %i) { if ($color(%i).rgb == $color(%j).rgb) echo -a dupe %i and %j index matching rgb $v1 | inc %j } | inc %i }
result:
dupe 52 and 4 index matching rgb 255
dupe 54 and 8 index matching rgb 65535
dupe 58 and 11 index matching rgb 16776960
dupe 62 and 13 index matching rgb 16711935
dupe 88 and 1 index matching rgb 0
dupe 98 and 0 index matching rgb 16777215
Another change that would work for both situations might not be backwards-compatible-enough. Currently the auto coloring of nicks is based on the color index of the channel window instead of the background color of listbox. If the auto-color of nicks were to depend on $color(listbox) instead of $color(background), then the background color of the nicklist could be changed to 90 to get a different auto-color palette, while still being able to have text color flipped if their color index matches the background color index.
