What I was suggesting is base mirc's LOCAL colors on how many colors the video card can handle vs a set number of new colors - some of which a card might not be able to handle.

If more colours are allowed locally then just stick to 24-bit colour. Windows will handle the colour conversion for the system's display settings. It's unnecessary for that kind of control to be implemented in software, especially when we're talking about coloured text.

see? that's why I love this forum, because there's soo much expertise on here that there's a wealth of information I get your point and it makes a lot of sense. I wasnt trying to say let MIRC handle the colors, I was saying let mirc tap into WINDOWS handling of colors. I probably didn't explain myself right, in which case, I am fully agreeing with your post

Never re-installed a PC where you had to safe-boot with networking support to get the display drivers from the internet ? You'll get there as it will still display but the colours are horrendous!

You're right, I never have, but a reformat should not be considered normal operating procedures. If it WAS, there would be MANY more features people would want and to be quite honest, if you need to do that continuously after the reformat, the OS sucks to begin with :P

Although that sounds good, Windows really does run better if it's reinstalled at least every couple of years. Of course, perhaps that DOES say something about the OS.

Well, ignoring the MS rants that people tend to do here, I still think mirc should, IF it plans on supporting more colors, take the S.O.P. (standard operating procedure) and use that instead of catering towards those who need to "backdoor" the video stuff.

how about

/echo rgb37463 -a t

I don't see the point. Could just make an extra switch rather than do that (if you feel that's necessary), to keep it consistent with the rest of the language. /echo -R

I have better luck with every 6 months :p

But back to the topic.

I like the local/public colors idea. This gives the user the ability to use up to 98 (I personally would like to see 0-255) colors, but, for clients that like to colorspam for god only knows what reason, its still only going to be in the 16 base colors.

Though, if these are added, dialogs will have to be redesigned to show the new colors. Adding in a simple 'More..' button would do the job. Pops up a larger display much like ctrl+k that shows all colors. (16x16 grid would be perfect for 256 colors..) Im sure an option to Enable/disable the extra colors would be needed to as there is prolly some users out there that dont want the extra colors.

If you take a look at irc servers.. how many of them follow the rfc standard anymore? Why should clients be forced to do the same? The server programs are trying to innovate.. I would think clients would do the same :p

some copy/print screening and messing with colors results in this:



This is just 64 color boxes. (and being lazy, only filled most of them) While doing this, i realized.. 64 is a LOT of colors.. and might be plenty. Forget 98 some :p

why not let mirc use html colors
and even the option ( on/ off ) to display the other users their color.

The main thing to keep in mind is that other clients are used rather than just mIRC. Adding additional colors (except locally), would just cause problems. Additional local colors wouldn't be bad for scripted events and other things, but I don't think you need hundreds of them.

Using html colors would have to be local only, otherwise only mirc would be able to understand it (unless other clients adopted it)

Staying with ctrl+k is the best way to 'upgrade' colors.. and the local colors only would prolly be the best route out of all of them.

I would think doing it this way would be less of a coding nightmare, it wouldn't change the already established 'protocol' and other clients would have the option to add more colors or not. This would also keep people who use other clients from seeing new mirc color codes as random giberish on their clients :p

@all

I don't know if it has been mentioned before, but I think mIRC used to consider color codes 16-98 to simply be repeats of 0-15. Now, it seems to consider 16-98 to be default text color. If other clients do the same thing (accept color codes 16-98 without errors) then mIRC could actually send extended color codes to channels. The non-mIRC clients would simply see the colors as however their client is set to render them. Other mIRC clients would see the correct colors, of course.

-genius_at_work

Interesting... I knew it rotated through the colors after 15, (16=0, 17=1, 18=2...) but didn't know that it changed recently.. perhaps its being changed for more colors? we can only hope :p

Just for comparison, Ircle supported 28 colors... seen here...


Beleive me, 28 colors was enough. I don't see why the number of colors (for text) should be more than 32. MSPAINT also has a default palette of 28 colors.

Of course... when will mIRC's editbox be WYSIWIG? It still can't display color or styles. Nore can the SCRIPT editor. Rather you still see "03Hello World" instead of "Hello World". This needs to be addressed!

If you feel this needs to be addressed, then it should be done so in it's own topic.

I dont agree, if the editbox is made WYSIWYG, then how are you to know WHERE the control codes are? and how are you to easily edit/remove them?

I assume he means to make it like IM or Word or whatever, where you have a color pallete that you highlight text and select the color and it changes it and you never see control codes. I'd rather just see colors based on what command(s) you're using like you see in many programming languages.