I agree with the statements of
color codes (Sorries Watchdog) but just a few other points.
1. You mentioned that with other color codes, you use a specific color, how would this be changes when you deal with the other numbers? Such things like changing value 17 could alter another script that is also dependant on that color values.
You used the example of white to red. Okay, now if you change the red back to white, the scripts whos original intent to have red was altered. Now what about color 17. What if the user wants it a soft yellow, and you make it a bright blue? Yet another script is altered.
2.
Slushey's point on $chr(3)#RGBSETTINGS. Though I’d like to add that the best way to call the rgb values into use would be: $rgb(n,n,n) whereby ‘n’ is replaced by the associate colour values, and any text following the $rgb would then be viewed as its colour rgb.
Bad-idea. First off we have a preset 2 digits that mirc follows for a color code. Now, as for those two digits you realise its possible to have such things as []1510a. Meaning now
10a will apear. Well, now if you allow $rgb, the 1510 will not be enterpreted as an rgb value. Now we see
a appears.
Now not only does it propose a problem with these such statements, but scripts that depend on this relation of double-digit, then outputted text would need to change. This means any and all scripts that depend on this uniform would need to be updated. Also any older versions of mircs and any other clients that support ansi-mirc colors would need to also be changed and updated, or else if i use []16711935Hello everyone might see
711935Hello and say to themselves "wtf".
I mean don't get me wrong, Im all for the idea of new colors but every situation has ups and downs. I still think 0-15 should be standard as said by d3m0n and that the rest can be altered. I do however feel the rgb value is not a good idea.
Just something to think about.
