$chr(3) Color Codes , /color , $color - mIRC Discussion Forums

A few suggestion regarding the limits of the color codes box.

ctrl+k ($chr(3)) codes as everyone knows is limited to 15 colors. This is insufficient when it comes to using colors outside of the mirc color theme settings.
I'm sure its possible for mirc to have a user stated /color 16-99 <rgb value>.

Furthermore, in the case of expanding the color box colors there should be an $color(num).state where it will return if its 1 meaning used or 0 returning $null for empty.

This idea is fairly simple and i'm sure many would agree with me that it could be very useful if this feature was implimented.

comments are welcome.

-merde

You say useful, I say annoying. I find 16 colors annoying enough, I don't want more colors. And furthermore, you leave out the whole idea of compatibility with other clients.

hi.. not a bad idea, maby add in like $chr(3)#RGBSETTINGS or something too, that would be preety cool, but probably wont happen. Remember, mIRC isn't the only irc client out there.

[exploit deleted by moderator. there is absolutely no need whatsoever for you to continually post an exploit that can only do someone harm. for the last time: if you have a quarrel with someone, take it private]

LOOK WHAT I MADE THE OTHER MONTH!!!

Code:

alias c {
  if ($1 isnum) { 
    if ($2) { return  $+ $1 $+ , $+ $2 | goto end }
    if ($1) { return  $+ $1 }
    :end
  }
  if $1 === b return 
  if $1 === u return 
  if $1 === o return 
  if $1 === r return 
  if $1 === n return 
  else { return }
}

Why u made an alias for that, i will never know, but in any case...

Code:

alias c {
  if ($1 isnum 0-99) { 
    if ($2) return  $+ $1 $+ , $+ $2
    else if ($1) return  $+ $1
  }
  else if ($1 === b) return 
  else if ($1 === u) return 
  else if ($1 === o) return 
  else if ($1 === r) return 
  else if ($1 === n) return 
  return
}

In addition to the color topic, i do agree the the primary 16 colors are fine, but the ability to customize 17-on would be a great idea. Not necciserily have them show on the color map, but just the ability to change them to your preference. So color 0 could be white, but then 16 could also be a different color than white.

I thought it was elseif not else if.

either or, no matter. Im used to C where there isn't a elseif, so i just stay in the habbit. Does the same, just runs more like..

Code:

if (condition) statement
else
  if (condition) statement
  else statement

rather than

Code:

if (condition) statement
else if (condition) statement
else statement

No difference tho.

personally id like to see something like the defualt 0-16 be uneditable ..... then making 17-99 custome colors ...... that user can make as they please ....... it would in my opinion ..... make the first 16 be a standard and then allow u to add to your color pallet as u choose with the remaineder 17-99 ...... this has also been suggested before ..... dunno what will ever come of it ..... but there was also some pretty cool color dialogs some ppl went thru alot of trouble to make

Quotes:
_D3m0n_

personally id like to see something like the default 0-16 be un-editable ..... then making 17-99 custom colours ...... that user can make as they please ....... it would in my opinion ..... make the first 16 be a standard and then allow u to add to your colour pallet as u choose with the remainder 17-99 ...... this has also been suggested before ..... dunno what will ever come of it ..... but there was also some pretty cool colour dialogs some ppl went thru a lot of trouble to make

-------------------------------
slushey

hi.. not a bad idea, maybe add in like $chr(3)#RGBSETTINGS or something too, that would be pretty cool, but probably wont happen. Remember, mIRC isn't the only irc client out there.

--------------------------------

These two quotes are great suggestions to my original post and I’d like to put my thoughts forward on what I think them in regards to the purpose on why something should be done about the current dialog code colour system.

The reasons why I suggest something should be done is that there is a severe problem in that way a mirc scripter such as myself scripts addon’s etc that include colour values. Now it’s come to my attention that the colour dialog in mirc is customable in order to suit the use of mircs background/text default colours. These colours are then the bases of the 0-15 ‘colour values’. When someone like myself intends on scripting text/backgrounds to appear in a certain colour I’d like to know for sure that those colours will be used, without the intent on changing the colour values of anyone else’s script that happens to be loaded on the users mirc.
I.E. If the user changes the default 0 to a lighter red, I want to make sure that the colour I want will be white without having to change the users 0 to its default colour as that may disrupt someone elses script that the users loaded.

The following means could be implemented to ensure the flexibility and useability of both mirc scripting and colours in the colour dialog.

· _D3m0n_ suggestion of having the 0-15 colours un-editable…
· 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.
· In following _D3m0n_’s idea, and my idea of extending the editable values of 16-99 store values, then any custom value added should be visible in the colour dialog. Further-more, any custom colours in the rgb dialog should be made either to replace the currently selected colour box (0-15) or create a new value somewhere between (16-99).

If you are not sure about anything I've said, please feel free to ask, but before you do please read what I’ve said a few times to make sure you are not clear as I've tried to explain myself as thoroughly as I could.

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.

Quote:

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.

You raised some interesting issues and i thankyou for replying, though i think you failed to read my first post where i stated:
Furthermore, in the case of expanding the color box colors there should be an $color(num).state where it will return if its 1 (meaning: used) or 0 (returning: $null) for empty

I surpose that maybe my fault for not re-mentioning that in my last post

I do now agree however now that the $rgb maybe a bad idea and i thankyou for pointing your concerns out. If someone has a problem with the first and second points i stated in my last post used as a feature suggestion I see no reason to retract my suggestion.

I'd like to see extra colours too though I do not see why the colour customisation should have to be removed to accomodate it. Surely mIRC can have both.