Forums Bug Reports Address book bug or design flaw??

Ok, let me break down how I duplicate the bug/designflaw/my possible misunderstanding:


1) join a channel that you'll have ops in
2) add yourself to mirc's internal aop list
3) make sure the list is turned off (either manually or type /aop off)
4) Go into the COLORS tab
5) Color $me as any color of your choosing
6) Color any color of your choosing OTHER than the color above with the condition of OP list checked (nothing else checked/filled in so the entry says ANY LIST (OP))
7) place the "op listed" color ABOVE the $me color
8) You should be colored as in step #5
9) type /aop on
10) you should now be colored as in step #6

I use mask type 9 a lot altho I DOUBT it's $mask dependant. Now, correct me if Im wrong here, but shouldnt you be colored the "op color" REGARDLESS of weather or not the list is actually turned ON? I mean the entry exists regardless of it's active/deactive status. So is this a bug, a design flaw, or am I just not getting the way it's SUPPOSED to work. I have NOT tried it with older mircs as I only thought about doing this tonight (the reason that caused me to find the "bug")

If somebody could give me confirmation on this I'd appreciate it. just dont wanna think Im crazy or anything ;-) Address book issues tend not to get addressed as quickly as other bugs

The behaviour is purposeful, if the ignore list isn't enabled, then the coloring doesn't apply since the user will not be opped. I could have made it work either way really, it was just a matter of choosing one or the other.

I thank you for your input. This tells me that it was (as you stated) deliberate. I would love to see this changed to work regardless of the list being on or off for one reason (which I dont know if you'd remember was a gripe of mine from the old board). With the current method, there's no way to color an op (in the list) who's no longer opped a separate color to make them stand out unless the list is on (which is weird because the entry is still valid regardless of it's active status - at least to me ). If this was changed (and believe me, it is YOUR decision and not mine by any means), we'd be able to colorize deopped/voiced nicks separate colors. Just something to think about Keep up the awesome work K, you've made the most popular client out there for windows based IRCing

I suppose someone might use the Op/Voice/Ignore lists independantly of the built in Oping/Voicing/Ignoring mechinism. The lists would still be valid and used, but users would be opped/voiced and even Ignored using an independant event or trigger (such as password opping).

Coloring in this case would seem to be useful, as they are still trusted ops regardless of how they become opped.

- Raccoon

Actually, I use it very similar to how you point it out and if it was changed to work regardless of (de)active state of said list, it WOULD handle a color combo in the nicklist under the circumstance of getting voiced & deopped. Back on the old board I asked for a way to color DEmoded nicks in specific colors and if the change was made (a huge if based off of what Khaled decides to do ), it wouldnt matter anymore and voice/deopped nicks could now look specific ways instead of using /cnick to override the address book listing.