Forums Feature Suggestions More colors PLEASE!

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).