Forums Feature Suggestions More colors PLEASE!

I have been using mIRC for many years (atleast over a decade), and I have been generally happy with it. I have troied other irc programs, but for one reason or another, I did not like them as much as this ine. However, there is one shortfall that has bothered me over the years. The anemic choice of colors offered. How about expanding the color options? I cannot see why it could be possible to include an option to define custom colors. MSPaint offers 28 colors, Internet Explorer offers 56 colors (with the option of "defining custom colors"), and Firefox offers 70 colors! mIRC only offers 16 (!?!) colors! How hard can it be to extend the color range?
Unless Mr. Mardam-Bey wants to go in history as the "Bill Gates of IRC" ("No one will need more than 640K of memory"), I would strongly suggest to him to widen the color choices.

This has been discussed plenty of times in the time that I've been hanging around the forums. The main thing stopping this seems to be the lack of standards. I'm not an expert on irc standards but the first 16 colors are standardized and more have never been added.

It also seems mIRC won't get more colors until there is some standard for more colors. Though I'm sure others could elaborate more on the topic, or you could search the forum for similar topics.

Open the color dialog, right click a color, select your custom color. Or use the /color command.

Well the problem with this argument is mirc already tries to interpret colors from ^k17 to 99, or atleast strips them from text. Also even though the first 16 are standardized alot of scripts change the defaults to suit their scheming.

You're comparing image editing software and two multi-media web browsers with a text-based IRC client. Of course they will have more colour choice-- that's practically what they are built for.

Colours over IRC were an after thought. They're technically not even part of the protocol. The limit is implicit in how the protocol was proposed well over a decade ago (when you started using IRC). So the 16 colour limit isn't really something mIRC can do much about now.

Of course you can also use colours locally, and there need not be any limit here, but the way colours are rendered are tied closely to the way they are rendered over IRC (it uses the same syntax), so extending the 16 colour limit would require a new syntax for local use. This would probably not be all that trivial.

However, the assumption here is that 16 colours is limiting. Is it really? We're talking local usage only, we can't change how colours work remotely. Colour usage locally would probably just be used for theming scripts. Themes tend to use only a handful of colours-- maybe 6 or 7 at most. Most themes only make use of ~3-4 colours (text, event, bg, accent). I don't know any themes that actually use 16 colours... so I'd question why you'd need more.

Note that the reason web browsers support all 16-million colours is because they are meant to allow designers to develop anything they want. Basically, if designers want to break the rules and use lots of colours, they can-- but this doesn't really happen that often. Designers are also responsible for designing the entire page, not just the content, so it's often required to use more colours when you're dealing with the overall page design (though even this is limited to a very small palette, in practice). If you actually look at most websites, you'll find that, minus the "chrome" (the skeleton of the design), there are again only a handful of colours used for text content (foreground, background, accent). Browsers still have to let developers pick any set of colours, which is why they support any colour, but designers won't just use every colour that is available to them just because they can.

mIRC actually works the same way in this respect-- you can pick ANY colour you want. So technically, your statement is misleading... mIRC offers 16 million colours. The difference is that you can only use 16 of them at a time. But again, given what I said above about themes, this tends to be way more than enough in practice.

The only real problem with colour limitations is that you have to share your local colour palette with the remote colour palette. IOW, if you change your "royal blue" (color #2) to a "neon blue", someone typing Ctrl+K+2 will send a neon blue, not a royal blue. That can make it difficult to apply non-standard theme colours while still using the standard colours over IRC. But again, this limitation is due to the way mIRC shares the palette. I think a separate palette for local use was suggested (extending Ctrl+K to 99 when not sent over the server and using the 16+ values for local palette codes), but I imagine it's not an easy change.

Thanks! I did not know that you could do that! Well, that answered my question. I do appreciate it.

Well, the standard 48 colors should be enough for starters. Besides, Loki12583 has already provided us with a more than adequate solution to the problem.

I think besides just allowing for a separate color palette or using another option for local colors (e.g. $rgb), it might be worthwhile to try and get the protocol standards updated to include more colors so that all clients can make use of a larger standard set of colors locally and remotely. It does mean people have to update their clients, but that really isn't such a horrible thing.

Of course, I don't know that anyone will get the right people together to make that kind of protocol/standards change on something that sees relatively little use. But who knows?

There is no such thing.

Well, there are at least standards in that Ctrl-K is color, Ctrl-B is bold, etc. It may be that the colors themselves are not standard, but the use of Ctrl-K is. It may not be part of the protocol, but it's still a standard. Getting an agreement to allow/handle more colors either using Ctrl-K through 99 or using some other method among the major clients would make it possible to use more colors over IRC once the clients are updated to make use of those colors. They don't have to agree on a specific set of colors; just that they will handle more colors in a specific way.

Just a thought. I don't really expect it to happen. Though mIRC could just force it to happen considering it's a leader in IRC clients and if mIRC users suddenly started using a lot of colors, other clients would need to either block those or handle them or their users would get upset at all the numbers/codes/etc that are mixed into their text incorrectly. But I think what will happen (if anything) is just that local colors will increase, but you won't be able to send more than 16 colors to anyone else.

I'd guess it's just a matter of desire to add it. Italics were added for v7 using ctrl+I (control code 29) - plenty of other control codes left that, to other clients, would just appear as an odd error until they would add support for it. And therein lays the rub. Think about a decade back and you might have seen oddball messages ("# appears as NAME NAME") from Microsoft's chat client - nothing else embraced that (avatars, I suppose) and those users were often finding themselves kicked swiftly.

If more colors did end up being allowed, I would imagine it would actually have an RGB type syntax. mIRC would probably have to drop its palette-based drawing, though.

This is sort of what it comes down to. You could easily extend mIRC to use 99 colours 0-98 (99 is transparency), that would only cause minor issues with unsupporting clients. The problem would be: which 99 colours would be standardized as the default? A palette based solution needs standardized colour choice, otherwise doing something like <ctrl+k> + 10,40 could easily overlay 2 very similar shades of blue in one client, making the text unreadable, while making it completely readable (yellow on black for instance) in another. This is why if there were ever any new standardization for colours, it would be RGB, not palette/index based-- but an RGB system would NOT be backwards compatible with mIRC's current colour parsing mechanisms, so that would be problematic too.

Well, one possible, but incredibly hacky and ugly, method would be to specify colors as multiple existing color codes.

i.e.
<ctrl+k>Rf[,Rb]<ctrl+k>Gf[,Gb]<ctrl+k>Bf[,Bb]<ctrl+k>Pf[,Pb][text here]

Where *f = foreground, *b = background, R, G and B are color values (within the range 0-99 rather than 0-255) and P are the 'standard' palette entries.
Clients supporting this would notice the 4 sequential color instructions and interpret them as above, while clients that don't support it would naturally fall back to the last color instruction.
( There's a caveat with regard to background colors, as a color instruction without background color component won't reset the background color. )

Even if IRC doesn't support additional colours it would be nice if mIRC did locally.

/echo could support RGB values with no problems whatsoever.

It could (I mentioned that), but it would be very rudimentary. You would only be able to apply the colour to the entire line, not specific parts, which I could see as being a big limitation for many scripters.

I don't see any reason why RGB would be limited to one color on the entire line in an /echo. It wouldn't be that difficult to make it possible to add any number of colors to a local /echo using RGB. Whether they are done using some RGB identifier or a switch that tells mIRC to treat all Ctrl-K's as RGB and parse them as RGB instead of the normal way... Ctrl-K255,35,124 or Ctrl-K255,35,124,40,87,237 for background colors or something like that (semicolon between would look better, but doesn't fit line up with normal color syntax). Or not use RGB in that way, but convert it so it's one number... Ctrl-K23578,54023 or whatever. The switch would just tell mIRC not to use only 1-2 numbers for the color code. There may be better methods as well. The point is that it shouldn't be difficult at all for local /echo to have many colors throughout a line using RGB, so there shouldn't be any limitation.

This is a nice proposal, but it's fairly short-sighted and hacked together on the premise that /echo is the only input to a window, and that no data ever comes out of that window. It doesn't answer many of the real issues you'd have with properly handling those coloured lines consistently throughout the execution of the client. For instance:

How would mIRC render these control codes when Ctrl+Copied? How would they get logged? How would something like /loadbuf know to interpret the syntax used among non-RGB codes? What would /msg # $line(#otherchan,N) do with those codes? More importantly, how would you be able to mix the 2 syntaxes in a single line? This would be extremely important for theming, since you would basically be unable to use RGB colour codes in an ON TEXT event (where incoming data might contain palette based colour codes) otherwise. You can recall similar theming problems in 6.x when scripts printed codepage characters in theme output on Unicode channels. The idea that just because it's local you can control whether you're using one syntax or another exclusively per-line doesn't actually work that way in practice.

Adding a special switch in a single command that changes the way mIRC parses an extremely common control code syntax won't work very well when you consider how the control codes need to interact with the rest of the client.

The only real way to support RGB style colours would be to add a completely new control code for that purpose; but then things get really weird and confusing for new users, especially given the ever-mounting problem that mIRC hasn't even rendered control code glyphs properly for the last 5+ years. The inability to differentiate control codes is likely to be a source of confusion and bugs, and frankly, given the rendering problems, I think it would be wiser if we found a strategy to move away from control codes, not add more.

Obviously I was talking about a single command. Such a method could just as easily be applied throughout mIRC in any command or event that can be used locally. There is no reason why RGB can't be made to work locally. It absolutely can. Yes, it will require work, but it can be done. Besides, the switch was just one option. Using some kind of identifier would work as well as I mentioned. mIRC could even let a remote user include the identifier and then display the right colors locally so that it was possible to send any color to someone who has a newer mIRC. Obviously, if other users who don't have the newest mIRC see it, they will see the identifier, but that would be completely up to the sender if they wanted to do that. Sending the identifier could be disabled by default, allowing a user to enable it if they want to send it. If they know everyone in the channel has a new version of mIRC, they could enable it and everyone could send any colors they wanted and everyone could see them. If they were in a channel where most aren't using a new enough version of mIRC, they can leave it disabled. That's just a side option that could be done to make it even more useful without suddenly having a lot of "messed up" text being sent to channels. Or, if there are any available CTRL codes, one of them can be used instead of Ctrl-K for setting colors and that code would always refer to RGB like you mentioned. Sure, rendering is a problem, but when it comes down to it, people are doing just fine scripting right now regardless of the rendering problem. It's not ideal, but it does work fine.

Logging should be changed anyhow. There should be an option to strip all codes and then you can open the logs in Notepad if you want, but if you allow codes, it should save in a format like RTF or something similar, where the codes are replaced with real formatting information. Then, you can open the logs in a word processor and see all formatting. It also lets you log any kind of color or formatting and load it back into mIRC without the slightest problem.

Why would you need to mix syntax? If I want a color from the palette, I can just use the RGB version of it. I'd expect with RGB enabled that you can have some kind of color wheel or similar to use and the standard palette colors should be included so you can click on them and their RGB information would be easily available.

And as far as your on TEXT example, we are talking about local display. on TEXT wouldn't even have to look for any kind of RGB if it's entirely local. You would assume the text coming in is palette-based. Then, if you wanted to adjust colors to RGB, you can halt it and echo the way you want.

However it is done, it definitely can be done. And there is no reason to think that multiple colors on a line are not possible or too difficult. No, adding RGB wouldn't be simple and easy. But neither was Unicode. Unicode took a year or more to do. Maybe RGB will take many months to do, but it can definitely be done.

Personally, I'd rather add scriptable image support to channels/queries first. Then people can script emoticons into their clients and others can use it for displaying things like warning images on errors or whatever else they might want to display for a local theme. But I wouldn't be surprised at all to see RGB in mIRC somewhere down the road.

My point was never that adding RGB syntax was "impossible", so I don't know what you're arguing. The issue is that there are a huge amount of inconsistencies, problems, blockers and edge cases that will make scripting with 2 distinct syntaxes much more difficult, and, in some cases, impossible, if you were to overload Ctrl+K.

One of the impossible cases:



I explained why:



You cannot assume, even when echoing local data, that your local data will only use a single format, because although you might be displaying data locally, you cannot guarantee that the data does not come from a remote source (and therefore unfiltered). As I pointed out, a good example of this is an ON TEXT event. If you do (echo -R being the fictional "enable RGB syntax switch"):



You cannot guarantee that $1- will not contain palette based codes. In fact, it's highly likely that they will. We had this same problem in 6.x when scripters would put $chr(160) in their themes, breaking Unicode lines because the $1- was interpreted as invalid unicode, since encoding was based on the entire line being valid UTF8. This is a case where /echo might be local but depends on remote input that you cannot control. You therefore need to support mixing the syntax, otherwise the feature would be extremely limited, as I originally stated. The only way you could fix this would be to manually convert every palette based code to RGB syntax, which would be quite complex, and still not entirely predictable.

Consider another example, of entirely local /echo with absolutely no remote data, but rather, input from your user only. Let's say it's a local game script, but your script has some options for the user:



You want a colourful name, so you add control codes. There's no reason why your script can't handle control codes, so you want to support this. But you also use RGB syntax when echoing data:



The issues with palette based code mixing are obvious here, so you would consider converting the colours to RGB syntax. However there are less obvious issues here, namely, you don't even know if the input is going to be a palette based control code syntax. The user could be aware of RGB syntax and wants to use that in his player name. You can't only support one or the other-- I mean, you can, but this is the kind of thing that makes scripting difficult and riddled with gotchas.

Obviously the real solution is a new control code, but I'm personally against that, and I don't think other clients (and servers, since they have to strip this stuff out too) are going to enjoy having to update their code to support yet another colour syntax.

Final note: this is not the same as the Unicode conversion. mIRC's conversion to Unicode was a completely internal change that for 95% of scripts did not affect a single line of code, and for the other 5% only affects a few lines that used $chr()s over 128 for whatever reason. The result was that you could begin to use Unicode in more places without needing any changes to your scripts (in fact, it actually fixed long standing incompatibilities like the $chr(160) issue I pointed out above). Changing the colour syntax in an indistinguishable manner via a line switch causes weird side effects all over the place that are not containable to the original point of usage, not without extreme diligence and modified scripts to support the new syntax. This is very different. You can't just start supporting RGB syntax in your script without the side effects leaking out to other parts and having unintended backwards incompatible behaviours. Logging to RTF format is one of those backwards incompatible changes. What if a user WANTS text based logs? mIRC should obviously still support this via switch. In that case, you still haven't answered how the syntax would get logged-- or even how the data would get copied (which wouldn't even be an RTF problem).

It seems to me that it would make more sense to come up with something other than $chr(3) to allow for multiple colours on a line.

Given that mIRC would likely use a new switch to specify that RGB colours are being used, the formatting options are limitless.

//echo -aR [color:16777215]a[/color][color:255]b[/color][color:0]c[/color]

There's no reason why something like this couldn't work. I'm not saying that's a good way of doing this, just using it as an example.