Forums Feature Suggestions More colors?

I wish I had more "nuances" of the colors..

It really makes for a great envirment, when one can use the same color, in diferent shades.

Thank you for hearing me, and pleas help!

here is a picture to ilustrate what I mean; Sorry for my spelling and grammars.

When you have the mIRC colours dialog open, put the mouse in one of the colours and right click.

lol..

I should have know..

Thank you so much for answering such a "silly" question!

Great!


Edit..

still cannot do it some places though.

would be neat to have it all the places, like in the display meny settings thing.


like here i.e.

those are the 16 possable colors, so if u alter a color it alteres there.

By the way, maybe some people would like to see more colors added. I mean, being able to send messages using "true colors" (24/32 bits) for example.
I'd like to highlight the fact that the colors' implementation is client dependant (so for example, the display may not be the same under mIRC and xchat, if any).
What's more, the current implementation needs to embed color codes using special characters. I'm not sure it can be expanded so as to allow for "abritrary" colors to be sent.

The problem is that it would use too much of the message lenght. I think a max of 100 colors would be nice. (0-99)

0-98. The 99th is the transparent color

Id like to point out..


IT IS OK THAT THERE IS ONLY 16 COLOURS FOR SENNDING..


OR else MIRC would look like a [censored] rainbow!
:tongue:

No one wants that..

Theses Colours I request is ONLY SEEN BY THE PERSON USING THAT SINGUALR VERSION OF MIRC!

But i see now what the confusion is about, and I see why this may or may not help out there..

I think you're wrong, a lot of people want that, I've seen this being requested many times here and there (and I'm aware that I'm just discussing it again, but since you've brought the subject...). Additional colour spots (16-98) would be great.

mIRC would look like a [censored] rainbow only if its particular user wanted it to look like that. I can't see what's wrong about it. The colour values aren't shared through IRC, only the ctrl codes they associate with are. Other people would see the colours they wanted mIRC to show.

Of course, I could see a problem with people creating autocolour scripts using 30, 40 colours per message. To avoid this particular problem, my suggestion is: make additional colours local (ie. IRC messages with ctrlK+16 would still show up with the same colour as ctrlK+0, but you could use ctrlK+16's unique colour for things other than messages sent or received - for displaying purposes). If they're local, then no autocolour scripts like in the example mentioned would be possible.

mIRC theming (as in old 5.xx "efnet" scripts like opal, convex, one, etc etc) could rise from the dead if such feature existed.

Sorry for bumping an old thread (with such a frequently discussed subject, though), but I've just noticed that the idea I've been suggesting here is supported (or even created) by Ircle's colour coding protocol: a list of private colours and another list of public ones, the former being known as "static" and the latter as "dynamic". The suggestion here is almost behind the same idea, and I thought this was worth mentioning: it's been done, I think it would be great if mIRC did the same or something like that.

I don't mean mIRC should apply to Ircle's method, because I don't think anyone would like the idea of "static" colours, or the lack of background colours, etc. It's too late to change the colour system, in my opinion. However, mIRC could base its own method behind the "public-private" principle, and then people could use all the colours from 16 to 98 (as private colours) as they'd want for their scripts, leaving 0 to 15 as they currently are (public colours).

For more info on Ircle's colour coding protocol and the debate behind the different protocols, click here. There are some good points in that page, in my opinion. I realize there must have been a lot of discussion about this subject in the past, but after reading that, I thought I should at least point out where the idea comes from.

I'd like the the colour argument for /echo to accept RGB values.



I don't think the human eye would really be able to tell the difference between 0 to 15 on the RGB scale (I can't anyway), so it could still accept those values as mIRC colours, and people could use 16 for black.

I can't think of a single problem with this method, but I'm sure someone else might.

I think an RGB value for /echo is a good idea for a simple coloured info line or something, but that's about it, that's very limited for the matter at hand...



I'm not sure I understood what you're talking about. Which values are "those"?
Edit: nevermind, I've read the first post on this thread again, now this makes sense.

Just in case anyone else misses the point, what I meant was that /echo [0-15] would use the colour for that index set in the box that opens when you hit ctrl+k, but anything above 15 would refer to the RGB value of a colour.

/echo 37463 -a t would be valid, for example.

As for it being limited, it will let you locally use any colour in the spectrum. I don't actually think it can get any better than that :p

I cant see no harm in locally extending the colours. Wouldn't put them to use myself though.

It can get better. I mean, this would be limited because this wouldn't support colour themes natively. You still wouldn't be able to assign such an RGB colour to "info text" echoes, for example, without compromising the ctrl+k+0-15 colour range.
This is the whole point of having a local colour range: to make it work with mIRC colour themes. Otherwise, of course, a simple RGB switch for /echo would be sufficient... but it's not.

I would definately support that idea for extended /echo RGB color chart.

I could see how compromising the 0-15 color range could bug people who were using older versions of mIRC, the code might show up on their screen, and be non-interpretable to thier current version?

As a stepping stone, enhancing local colors would be great. I think it would catch the eye of alot of users who aren't into using dll's as a means of theme enhancement. Dll's are nice but there is a sense of satisfaction that comes along with knowing that the scheme is a result of ones own fabrication rather than whatever result the dll produces. Not to mention that a dll, is generally for advanced users, ...people who arent sure how they work have a hard time taking the step to learn. Especially when they dont really know what its doing, you just get what you get.

As to where giving them more colors to make code the way they already know how, might make things more interesting for level 1 or otherwise starter writers. In turn, promoting mIRC.

replied to last in thread:


I dont know if anybody mentioned this, but perhaps mirc could (maybe thru dll - I dont pretend to know about this stuff) base it's color range based off of video display settings. For example, my video card (GForce FX 5600) is set for 32bit color. If mirc were to allow local color enhancements, it would be good to use that as it's starting point to see how many colors can be used, and then do (for sake of example) the hexidecimal (the way HTML can do it - if I called this wrong) codes. Basically:

1) Gather video card settings to figure out displayable colors
2) on the local side, allow for a pallette for us to choose from


Make any sence?

Sorry, I don't quite follow you here... but if you're by any chance suggesting a modification in the colour "protocol" mIRC uses, I'd say that's not the way...

Im saying expand (not change necessarily) how mirc handles LOCAL colors not colors that go out over the net. I'm beyond trying to change mirc's EXTERNAL behavior for reasons of never wanting to hear the words "that's not in the RFC standard" as the excuse for why nothing gets changed for the better.

Yeah, I didn't get the handling, though.