|
Joined: Aug 2019
Posts: 16
Pikka bird
|
OP
Pikka bird
Joined: Aug 2019
Posts: 16 |
Consider the following screenshot: How easy is to follow a conversation? /rhetorical/Now, with colours: ...Can we please have automatic "colourization" of the nick-names in the chat and (maybe) in the user list as well?
|
|
|
|
Joined: Oct 2018
Posts: 2
Bowl of petunias
|
Bowl of petunias
Joined: Oct 2018
Posts: 2 |
You mean like this? https://imgur.com/a/9yOSW7CPress alt-b to get the address book or right-click any name. It's also in the tools menu. This is not new; I've been using it for years. This particular chat room also give permission to certain users to post in colour as well!
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
This can already be done. In mIRC type /abook -l Here is mine.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
This thread deals with that topic, and it doesn't look as cut and dried as you make it seem. How many colors should be assigned? How should they be assigned to the different nicks? Depending on the background color, there can be different number of different colors you'd want to use. If your background is black, you could use 3-green 4-red 8-yellow 9-neon-green 11-sky-blue. But 2-blue would be bad. On the other hand, with a white background, 8/9/11 are bad, but 2 and 12 are good. Other colors start to become marginal, so how to decide when enough is enough. Should the color be calculated based on the 'nick'? or their address so they stay the same color when they change nick? If the address, which mask should be used? Right now, your example looks like 3 nicks are using green, and a 4th uses a shade of blue that looks almost the same. It took me a while to figure out that bold meant that $1 was someone's nick.
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
How many colors should be assigned? How should they be assigned to the different nicks?
Depending on the background color, there can be different number of different colors you'd want to use. If your background is black, you could use 3-green 4-red 8-yellow 9-neon-green 11-sky-blue. But 2-blue would be bad. On the other hand, with a white background, 8/9/11 are bad, but 2 and 12 are good. Other colors start to become marginal, so how to decide when enough is enough.
Should the color be calculated based on the 'nick'? or their address so they stay the same color when they change nick? I tested several different algorithms that measure relative perceived luminance, contrast, etc. to determine if a foreground color is readable on a particular background color. It's not clear-cut but I found some algorithms that work reasonably well. The acceptability threshold has to be set high enough to disqualify unusable foreground colors for a specific background color, which unfortunately disqualifies a small number of usable foreground colors as well. But the overall result is acceptable. To test this out, I made a small change to the nick color list feature so that if you add an item that has no color, it chooses a random color for the nickname. This seems like the easiest way of adding this feature, considering that there is no point in adding a no color item. It works as expected... all nicknames in the channel nick list are assigned random colors (based on a hash of their nickname) from the usable foreground colors list. You can then place this item in the order you want in the nick color list and it will only be applied if there are no other matches before it. This could be made a default setting for newly installed versions of mIRC to improve readibility. This will be in the next beta. Update: It just occurs to me that there is a reason you would add a no color item... you could use it to block matching nicks from being colored by items further down the list. Hmm...
Last edited by Khaled; 19/10/19 10:57 PM.
|
|
|
|
Joined: Aug 2019
Posts: 16
Pikka bird
|
OP
Pikka bird
Joined: Aug 2019
Posts: 16 |
This could be made a default setting for newly installed versions of mIRC to improve readibility. This will be in the next beta.
Excellent, looking forward to it!
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
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)))
|
|
|
|
Joined: Dec 2002
Posts: 5,490
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,490 |
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. Thanks this has been fixed for the next beta. There may be a few color combos that need to have a ban override. There are no plans to add such a feature. If you can find a foreground/background color combination algorithm that works better than the current one, I would be happy to use it though. 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. I should be able to add this to the next beta. In fact, it should exclude any color value that is already in the usable colors list, not just the color index. Thanks for your other comments.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
I tried to do a 'what-if' test using the contrast formula at https://ux.stackexchange.com/questions/107318/formula-for-color-contrast-between-text-and-backgroundand it looks like that's how the random color palette is currently being chosen. It appears that the blue/black combos I mentioned in the prior post are caused because the random nick colors use the color indexes with scores of approx 2.3 or higher. The formula at the url seems less accurate when blue is involved either as the foreground or background. Index 60 and mIRC Classic's index 12 both have scores of approx 2.4 against a black background, which is barely higher than the 2.3 selection cutoff. //echo -a $contrast(1,12) $contrast(1,60) Also, against blackground, the formula gives 12 and 60 slightly better contrast scores than index 29, but 29 is much easier to read than the others. Similarly, 74 and 84 have very similar scores against white, but 74 is much easier to see than 84. Perhaps someone else more familiar with luminosity/contrast formulas could suggest a better tweak of the formulas generating the contrast score, but perhaps a configuration option where people can indicate which minimum contrast score they wish to use. People with different eye compatibility can choose between having more random colors, or fewer colors which tend to exclude colors harder to see against the chosen background. By bumping the cutoff score from 2.3 up to 2.5, that eliminates several poor contrast combos like: //echo -a $chr(3) $+ 12,1 test12 $chr(3) $+ 12,1 test60 $chr(3) $+ 84,0 test84 For the alias below, "/test_contrast 2.3" imitates the colors I see currently chosen for white and blackgrounds. "/test_contrast 2.5" shows an alternate colors choice where a black background doesn't choose the hard-to-see blues. "/test_contrast 2.5 999" includes the option where it looks for close matches between 0-15 and 16-98. It currently tosses the higher index number instead of whichever has the better contrast. The $lum and $brightness aliases are borrowed from the Xpalette forum post. ; $1 is index 0-98
alias Lum {
tokenize 44 $rgb($color($1))
return $calc(0.2126 * $brightness($1) + 0.7152 * $brightness($2) + 0.0722* $brightness($3))
}
alias brightness {
var %res = $1 / 255
return $iif(%res <= 0.03928, $calc(%res / 12.92), $calc((( %res + 0.055) / 1.055) ^ 2.4))
}
; $1 and $2 are 2 color indexes 0-98
alias contrast {
var %a k0,x color x k1,x color x k0,y color y k1,y color y . kx,y color x on y ky,x color y on x .
echo -s $replace(%a,k,$chr(3),x,$1,y,$2)
clipboard $replace(%a,k,$chr(3),x,0,y,1)
tokenize 32 $sorttok($Lum($1) $Lum($2),32,nr)
return $calc( ($1 + 0.05) / ($2 + 0.05) )
}
; any channel with many nicks will do
alias test_contrast {
var %chan #freenode , %t $nick(%chan,0) , %i 0 , %nick.buckets $str(0 $chr(32),99)
while (%i < %t) {
inc %i | var %n $nick(%chan,%i) , %c $nick(%chan,%i).color , %c2 %c + 1
var %new.val $gettok(%nick.buckets,%c2,32) + 1 , %nick.buckets $puttok(%nick.buckets,%new.val,%c2,32)
; next line just shows everyone having same color as yourself
; if (%c == $nick(%chan,$me).color) echo -s %n %c
}
var %bg $color(background) , %fg $color(normal) , %rgb.taken $color(%bg) , %lum.bg $lum(%bg) , %rgb.0-15
var %threshhold 2.3 | if ($1 isnum 0-) var %threshhold $1
var %min.dist 0 | if ($2 isnum 0-) var %min.dist $2
var %i 0 , %yes.now , %nno.now $chr(3) $+ 0 $+ , $+ %bg , %alt.yes , %alt.nno %nno.now , %lum.array
while (%i < 99) {
var %j = %i + 1
var %lum.i $lum(%i) , %lum.array %lum.array %lum.i
if ($istok(%rgb,$color(%i),32) ) { echo -s toss %i is a dupe | inc %i | continue }
var %rgb %rgb $color(%i)
var %tmp $sorttok( %lum.i %lum.bg ,32,nr)
var %tmp $calc( ( $gettok(%tmp,1,32) + 0.05) / ($gettok(%tmp,2,32) + 0.05) )
if (%min.dist) {
if (%i < 16) var %rgb.0-15 %rgb.0-15 $rgb($color(%i))
else {
var %c 1 | while (%c isnum 1-16) {
tokenize 44 $gettok(%rgb.0-15,%c,32) $+ , $+ $rgb($color(%i))
var %dist $calc( ($1 - $4)^2 + ($2 - $5)^2 + ($3 - $6)^2 )
if (%dist < %min.dist) { var %tmp , %diff $v1 | break }
inc %c }
}
}
if (%tmp == $null) { echo -s toss %i close to $calc(%c -1) . $rgb($color(%i)) vs $rgb($color($calc(%c -1))) . dist %dist | inc %i | continue }
var %label $+($chr(3),%i,test,%i,=,%tmp)
if ($gettok(%nick.buckets,%j,32) == 0) var %nno.now %nno.now %label , %nno.contrasts %nno.contrasts %tmp
else var %yes.now %yes.now %label , %yes.contrasts %yes.contrasts %tmp
if (%tmp > %threshhold) var %alt.yes %alt.yes %label
else var %alt.nno %alt.nno %label
inc %i
}
echo -s ===== nicks in use: color|nick_count|luminosity
echo -s background: %bg zeroes: $wildtok(%nick.buckets,0,0,32) of 99 total: %t : $regsubex(foo,%nick.buckets,/(\S+)/g,$+($calc(\n -1),:,\t $+ $chr(22) $+ $round($gettok(%lum.array,\n,32),3) $+ $chr(22) ,$chr(32)))
;echo -s ===== sorted contrasts vs background
;echo -s yes.contrasts: $sorttok(%yes.contrasts,32,n)
;echo -s nno.contrasts: $sorttok(%nno.contrasts,32,n)
echo -s ===== colors used and their contrast vs background
echo -s $numtok(%yes.now,32) now.yes: %yes.now
echo -s ===== colors NOT used and their contrast vs background
echo -s $numtok(%nno.now,32) now.nno: %nno.now
clipboard %nno.now
if (%threshhold != 2.3) {
echo -s ===== what-if colors and their contrast vs background contrast: score > %threshhold
echo -s $numtok(%alt.yes,32) alt.yes: %alt.yes
echo -s $numtok(%alt.nno,32) alt.nno: %alt.nno
}
echo -s ===== $ $+ 1 == optional min contrast score (default 2.3) $ $+ 2 = optional 16-98 min distance vs 0-15 RGB (default 0 suggest 1000)
}
; $1 and $2 are index 0-98
alias distance {
tokenize 44 $rgb($color($1)) $+ , $+ $rgb($color($2))
return $calc( ($1 - $4)^2 + ($2 - $5)^2 + ($3 - $6)^2 )
}
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Update workaround for automatic random nick colors
For those who cannot use the automatic nick color change feature because the threshhold for accept contrast scores is too low, a possible workaround is to make a slight tweak to your background color.
The colors chosen for auto-color of nicks is based on what's the RGB shade of your background color, and depending on what that is, you can have more or fewer colors in the list of nick colors used.
The colors chosen seem to be chosen if they have a high-enough score in the formula described above. Because the accepted threshhold score is either set too low, or the formula doesn't really work for real life, there are several shades of blue that are chosen when the background color is 01 black, even though they contrast poorly visually with black. While 12/60 can be seen against black when your eyes are very close to the screen, the contrast drops off sharply when your head is arm's length away.
While nick colors are set to random, if you enter a channel with a lot of nicks in it, this can give you the list of colors chosen against your current background color:
//var %i $nick(#,0) | while (%i) { var %list $addtok(%list,$nick(#,%i).color,32) | dec %i } | echo -ag $sorttok(%list,32,n)
Note that this includes any colors given to nicks from other rules you may have set, such as forcing all @op to be a specific color.
A solution for people using 01 black as their background color is to realize that color 88 is identical to the default shade for 01 black, and as you increase from 88 to 97, these are increasingly lighter shades of gray, until you reach 98 which is a duplicate of 00 white. (Except 88 and 98 can't be changed like 01 and 00 can)
If you change your background color from 01 to 90 you'll find that most of the poorly contrasting blue nicks that were shown against 01 aka 88 are now gone. There may be some other nick colors that no longer contrast as well against the new dark-grey, or there may be another grey shade in that range which works better for you.
But the 'bad' nick colors can't be completely eliminated, because low-contrast-score colors will always be picked for random nicks, regardless of whatever RGB shade the background color uses.
|
|
|
|
Joined: May 2018
Posts: 222
Fjord artisan
|
Fjord artisan
Joined: May 2018
Posts: 222 |
This can already be done. In mIRC type /abook -l One more step, this is the one he wants:
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Hey eahm. I'm not sure if you're replying to my current post or to someone's post from 2019. My problem is that when I'm scripting to handle the ON TEXT event in a query window, there doesn't seem to be any identifier or command that works for me to be able to auto-color the <nick> string the way it is colored without scripting a replacement for it.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
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.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Referencing https://forums.mirc.com/ubbthreads....cnick-when-auto-color-is-used#Post271314I've asked around in several channels as well, and I can't find anyone who knows how to get the autocolor of a nick so that an echo in a query window can correctly auto-colors a nick. In trying to get the info, //echo -a $cnick(maroon) Returns 1, telling me the nick matches rule#1, but //echo -a $cnick($cnick(maroon)).color Returns $color(normal) telling me that rule#1 sets to that color, when it doesn't. But if I get more info from it, //echo -a $cnick(maroon).auto ... tells me the nick is being autocolored, and I should be able to get the autocolor assigned to that nick, but it's not true if the nick was colored using /cline, such as a script that was using /cline to color a nick in 1 channel as either blue or green depending on if there's a dcc-get or dcc-send with that nick, and the following returns the cline color, without giving the auto color. //cline 4 # maroon | if ($cnick(maroon).auto) echo -a $nick(#,maroon).color * * One solution for this could be an identifier that does not need to know a channel name in order to give a color, nor even needs auto color to be in effect, such as $autonickcolor(maroon) $ial(nick).color would work only if the nick is in the ial, which won't be true if you don't share a nick with them, or if yourself is not in any channels. Something that could kill two birds with one stone would be having the auto-nick-color look for a specific alias name as an optional ovreride to the default auto color scheme, which should return a number from 0 to 98. This alias could then be called by a script elsewhere to obtain the same $autonickcolor(maroon) answer as was obtained for creating the channel list. This would also allow overriding the current auto-color palette that allows nick colors that don't contrast well against the background, such as colors 60 and 12 chosen when the background is black. Stats say that 1/12th of males and 1/200 of females have some kind of colorblindness, and this could allow people with different kinds of colorblindness to have a palette of nick colors that work well for them, such as avoiding greens or reds. Something that an override alias for the nick-colors auto-coloring could also do is allow people to have more control over how auto-coloring works, such as colorizing based on $gettok($ial(maroon),2,64) or $mask($ial(maroon),4) so someone stays the same color regardless of what nick they use.
|
|
|
|
Joined: May 2018
Posts: 222
Fjord artisan
|
Fjord artisan
Joined: May 2018
Posts: 222 |
Oh sorry man I was just replying to him, he needs that extra steps if he wants the automatically set. I'm not sure why this "issue" always becomes a 50 posts thread with configurations and scripts, the colors are almost always fine, sometimes there is a dark blue but meh, it's readable enough. You may want to contact eskimo to see which algorithm he's using because he set the colors ONCE for Igloo and they are the absolute best of any client I've ever used (talking about Igloo for iOS btw).
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Related to my earlier post, workaround for auto colors with poor contrast, and additional hurdles to find the color for the <nick> in a query window.
**
I finally noticed a way to remove colors from the autocolor list when they don't contrast against the background, so users have a workaround to do this.
The rules for adding colors to the autocolor palette appear to be
1. If the RGB matches the RGB of a color already chosen, then don't add it. 2. If there's some other rule in the 'nick colors' list that uses that color, then skip it 3. If contrast( $color(background) , color index N) is considered high enough, then add it.
So for a black background, if the autocolor is the only rule, then per step#1 color 52 does not get added if it's an identical RGB to color index 4 that had already been added. But if there is a rule to make all @op be color 4, then color 4 does not get added to the auto color list, because 4 is used by some other rule. However since 4 now is not in the chosen list of autocolors, then 52 will not be rejected by step#2, even though it's identical RGB to the 4 that's attached to another rule.
But with color 12 and 60 added to autocolor in spite of having poor visual contrast against black, I can create a dummy rule to match NoSuchNick and attach color 60 to it, and make another such rule and attach it to color 12. And that will make autocolor not choose 12 or 60, even if that rule can never apply to anyone.
**
Using $cnick(nick) to identify the rule that applies to a nick returns false positives and false negatives. The $cnick(nick) returns the first rule that matches that nick, but doesn't allow specifying whether you want to know about matching the nicklist or the <message_nick>. So if that Nth rule is nicklist-only, then the script needs to loop through all the rules below it, to see if any match <message> for that nick.
$cnick(nick) cannot accurately find the rule that generated the color in a channel nicklist, because since it doesn't take a #channel as the parameter, it doesn't match any rule that matches only someone having a channel mode, so that causes it to return the position for a rule that has no actual effect.
While Nick Colors rules govern the nick color in a query window, just as what happens in a channel, $cnick(nick).color returns $color(normal) or $color(own), instead of returning whatever is the autocolor for that string.
It's not clear what benefit there is to having .color returning the default color whenever there's an autocolor rule in effect for that nick.
So, if the nick colors tab has rules:
1 auto-color *@* for nicklist only 2 red-if-nick-is-@op, for <message> only 3 yellow if matches libera's cloak *!*@user/* for nicklist only 4 blue if matches *!~*@* for <message> only
when the nick is an op, and has mask *!~*@user/* ...
$cnick(nick) returns 1 because the auto-color matches everyone for the nicklist. But $cnick(nick).color returns $color(normal) if the nick is someone else, or $color(own) for self, instead of the actual rando color shown. But can't determine that the <channel message nick> will be @op red, without looping through all the rules looking for a match that applies to <message>.
For the same thing in a query window, it needs to loop through all the rules looking for a match before determining that the <message nick> will be blue due to rule#4.
So it looks like for the <channel message> it would be helpful to have $nick(#,nick).messagenickcolor since it can be different than $nick(#,nick).color, except such a property would not be useful in a query window unless the property considers the channel parameter either optional or accepts a query window's name instead.
In addition to the message/nicklist colors being different due to message-only and nicklist-only rules, one or both can be overruled by
/cline color #channel nick /cline -m color #channel nick
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Heh, you ask why does this topic get a lot of activity, then you post a claim that the colors are fine. Colors are not a 'one size fits all', because if they were then nobody would care if the colors were all fixed constants for everything, and you wouldn't have a long list of color schemes in your pastebin. This next command forces all nicks in the nicklist to be 60 blue. (You can cancel this effect by repeating the command after deleting the '60'. //var %i $nick($chan,0) | while (%i) { cline -m 60 $chan %i | dec %i } Are you saying you have no idea seeing who the nicks are when the background is black? Well I guess I'm suffering from one of the variants of colorblind, because I can't read the nicks in color 60 without being very close to the monitor and then positioning off to the side. And that doesn't count the autocolor scheme including colors that contrast fine against black, but they look the same as each other, such as colors 14 and 94 used as random colors against black, but they both look like each other. What are the RGB colors of this wonderful igloo scheme? I looked at your pastebin list of color schemes, but didn't find any of them named igloo
|
|
|
|
Joined: May 2018
Posts: 222
Fjord artisan
|
Fjord artisan
Joined: May 2018
Posts: 222 |
What are the RGB colors of this wonderful igloo scheme? I looked at your pastebin list of color schemes, but didn't find any of them named igloo Lol wat? It's the algorithm of the nick coloring not a theme.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Yes, and if your background is black, then there's a group of colors chosen that may/may-not contrast against black, and may/may-not contrast against each other. But based on your opinion that the colors 12/60 are fine against the black background makes me wonder how wonderful things really look like from the inside of the igloo
|
|
|
|
|