Observations on the new random colors:
0. Once the list/count of valid colors is known, is the hash method being used to assign colors from the list going to be public?
1. Minor bug: Right now, the color choices seem to be be reset only by clicking OK to exit the Alt+K dialog. If using "/color background N" to change between white and black backgrounds, the nick colors don't reset. But if you open Alt+K and click OK without doing anything in there, the colors do get re-assigned based on the earlier /color command.
2. People using this feature will need to have the channel and listbox backgrounds be the same color, because the color choices are based on contrast against $color(background), so some nicks in the nicklist could be hard to read against a different $color(listbox). There's no way around this without greatly limiting the valid colors, and I assume very few users want to have their nicklist and channel have different backgrounds.
3. There may be a few color combos that need to have a ban override. In the default theme "mIRC Classic", a blackground doesn't assign nicks to the color 48, but will assign 12 and 60 - but all 3 are equally illegible against a blackground:
//echo $chr(3) $+ 48,1 test48 $chr(3) $+ 60,1 test60 $chr(3) $+ 12,1 test12
4. While most colors chosen can be seen against the background they're supposed to contrast against, there's also the issue of contrasting between nick colors themselves. For example, against a white background these contrast against white, but not against each other.
//echo -a $chr(3) $+ 45,0 test45 nick=les $chr(3) $+ 46,0 test46 nick=troy
It would be much more time consuming trying to have a color set where every color contrasts well against each other, and for the most part it would be pointless because, removing a color from each pair of too-similar colors would just result in twice as many nicks being assigned the identical half-the-number-of-colors.
However, one improvement which could be made is to eliminate colors in index 0-15 which have been assigned RGB colors too close to a color in the 16-98 range, as well as pruning some 16-98 colors very close to each other.
In the default "mIRC Classic" scheme, this shows there are 6 colors in the 0-15 range which are duplicated in the extra colors range:
//var %i 0 | while (%i isnum 0-15) { var %j 16 | while (%j isnum 16-98) { if ($color(%i) == $color(%j)) echo -a i: %i j: %j | inc %j } | inc %i }
result:
i: 0 j: 98
i: 1 j: 88
i: 4 j: 52
i: 8 j: 54
i: 11 j: 58
i: 13 j: 62
When the background is white, it looks like there's currently 67 colors chosen as nicks, so by assigning some nicks as color 1 and others as colors 88, it causes more black-ish nicks than there should be, because effectively 88 is used twice as often as every other RGB except for 62's.
There are other color pairs where the item in the 0-15 range could be dropped if it's too close to the color in 16-98. For example 14 vs 94 is rgb 127,127,127 vs 129,129,129
Among the extra colors, I don't know how slow this would make building the colors list, but something like this could identify colors very similar to each other, and whichever contrasts best against the background could be the one kept.
//var %i 16 | while (%i isnum 16-98) { var %j %i + 1 | while (%j isnum 16-98) { tokenize 44 $rgb($color(%i)) | var %r1 $1 , %g1 $2 , %b1 $3 | tokenize 44 $rgb($color(%j)) | var %r2 $1 , %g2 $2 , %b2 $3 | var %dist $calc( (%r1 - %r2)^2 + (%g1 - %g2)^2 + (%b1 - %b2)^2 ) | if (%dist isnum 1-1999) echo -a dist %i %j %dist | inc %j } | inc %i }
I assume a 'real' algorithm would assign different weights to RGB.
5. People with color-blindness, which google claims affects 8% of males, would probably be avoiding this feature. While they can adjust the RGB for index 0-15, they don't have control over the random choice of greenish vs reddish shades from the 16-98 range.
6. For those wanting to test the random colors, this is the alias I use to see which colors are chosen against various backgrounds, and to see who is assigned the same index as my nick. The color for each nick almost always changes when the background changes, because there's a different count of colors not-chosen. And reminder to forum users that the .color property of $nick() can be used to identify the color chosen.
//var %chan #freenode , %t $nick(%chan,0) , %i 0 , %a $str(0 $chr(32),99) | while (%i < %t) { inc %i | var %n $nick(%chan,%i) , %c $nick(%chan,%i).color , %c2 %c + 1 , %new.val $gettok(%a,%c2,32) + 1 , %a $puttok(%a,%new.val,%c2,32) | if (%c == $nick(%chan,$me).color) echo -s %n %c } | echo -s background: $color(background) zeroes: $wildtok(%a,0,0,32) of 99 total: %t : $regsubex(foo,%a,/(\S+)/g,$+($calc(\n -1),:,\t,$chr(32)))
