Forums Feature Suggestions 16 color box limit

if mirc can support more then 16 box color limit it would be good.

This should be possible - mIRC supports more than 16 color codes, but I believe a lot of them represent the same color. I'm sure this has been discussed before though - I advise you to try the search, and set the time limit to include really old posts!

mirc support the colors with replacing in the limited 16 color box,if just more 4 5 more color box without changing the 16 box colors it would be nice,i couldn't find any add-on that extends the 16 color box..

mirc likely stores color changes in one byte so cant get any more than 16 colors since there isnt no more room in the byte, why its one (or if it is) I have no idea, but if it was going to be changed, well heck let it go all the way to truecolor 24bit, its only going to be 6 bytes Well maybe 3 depending on how its implemented.

Hello, correct me if i am wrong but isn't a byte = 8 bits can go from 0 to 255, can't this be used to code the colores?

thanks

yeah your right, 4 bits for the forground color, 4 bits for the background color, 8 bits in total, 4 bits = 16 options (in this case colors)

uhmm ok thanks for the tip...

It is highly doubtful that mIRC uses a single byte to process color codes. The information is presented as two integer values as part of a string. It would be more complicated to transform the codes into a bitwise value (string -> int -> byte-order -> byte) than to just parse them as integers (string -> int).

The most obvious reason as to why only 16 colors are allowed is the fact that no other clients (that I know of) support more than 16 colors. Extending the palette would create problems for other IRC applications, and I'm sure Khaled is aware of this.

Well everything is more complicated than if u dont do it now isnt it, doesnt mean you shouldnt do it tho does it. And a bitwise move is hardly rocket sience now is it.

And how the information is presented (to mirc) as two integers in a string doesnt mean thats how its stored in mirc to produce colors. Although Im not saying its not 2 bytes either.
An example of this is the following...
/echo 10,98abc98,12def13,98ghi

(* note my forground color is 1 & background color is 15)

highlight the text with the CTRL key down, then paste it into the editbox
10,15abc98,12def13,98ghi

now highlight the cdef with the CTRL key down, then paste it into the editbox
c98,12def

now highlight the def with the CTRL key down, then paste it into the editbox
1,12def

now highlight the fghi with the CTRL key down, then paste it into the editbox
f13,98ghi

now highlight the ghi with the CTRL key down, then paste it into the editbox
13,15ghi

An Inital ctrl-k colorization of text retrieved does not match that which it was set to ie: 98 becomes 1 or 15 depending if it was foreground or background, this alone would lead me to believe that each character has a seperate stored color value, and the ctrl-k codes that exist are simply stored for re-refrence sakes, rather than actually being used to color the text.

There are some other interestingish things such as
/echo <ctrl-k>1<ctrl-u><ctrl-b><ctrl-r>abc
highlight the text with the CTRL key down, then paste it into the editbox
1abc ... <ctrl-b><ctrl-u><ctrl-r><ctrl-k>1abc<ctrl-o>

Now this might be a result of a look back system to define what colors & appaernece it should be or it could be stored per byte as it went, i wouldnt like to hazzard a guess at which it is, with out greater study.

Here is a possable packaging of 2 bytes to represent each characters color and apparence
1 bit bold
1 bit underline
1 bit reverse
1 bit foreground value represents a numeric not a color
5 bits forground color (using 4 bits) || numeric representing one of the possable forground selectable texts ie "action text" "ctcp text" etc (using 5 bits)
1 bit background value represents a numeric not a color
4 bits forground color (using 4 bits) || numeric representing one of the possable forground selectable texts ie "windowl background" "listbox background" etc (using 2 bits)
2 bits still free

** Please remember everything about how mirc MAY pack info is speculative **




If this was the concern this doesnt limit the ability of local colorizing beyond 16 colors, it could have been simply noted that any value higher than 15 would be made mod 16.

Actually, it does mean you shouldn't do it. In terms of CPU cycles, the bitwise shifting would take more resources than a simple string-to-integer parse. Given that control codes are processed in each line displayed to a window, the speed of the parser is of the utmost importance.

What you have described is certainly possible and might prove advantageous given the right situation, however in this context it is not plausible to do the extra processing required, which provides no added advantage over a simple string parser.



That is a good point and would likely be the best solution for the problem and would prove easy to implement, however input text would need to be parsed and any values greater than 15 would be N % 16 - 1 (since it's zero based ). Furthermore, various shades of red would have to be parsed in such a way that they turned out to be red, otherwise mIRC's extended control codes would look like random colors to any other client.

You based that on a simple point that this is true IF the text well only ever be parser once, If mirc is based like this the parser would need to reparse the text everytime someone scrolled the window up or down, as that window is not a text box but a graphic window. ( refrence: see "The explanation" under /help Text Copy and Paste )



Take into account that a simple parser must/may have to reparse the screen over and over, and verse that against a simple read of info on how it should look becuase its already been parsed once.
And I can see a clear advantage. (if it really made much difference either way, I have coded in assembler and you can really jame a hidiously wastefull loop in and still come out smelling of roses over any highlevel langauge.

Im not actually saying either of these are how mirc actually does this. But I know that alot of things that appear wastefull of time or irelevent in the way you might do them, are often more advatages when placed into a bigger picture of how things must be used. an example just in mirc scripting is the difference in the way i see peoples coding take for example these to appearingly similar if statments (assume a all covering ON *:TEXT: event is in progress)

(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)

The 2nd of these IFs is far more efficent code, but most people (im not excluded here) becuase of how were taught to think from begining to end. well mostly go with the first option.

Sorry, off-topic question, but.. why is the second more efficient?

Are you saying that if the ($nick isop $chan) bit were false, mirc wouldn't bother checking whether (!allow * iswm $1-)
is true? (and since we only want it checking the second bit only while we are opped, it's more efficient?)

I always thought that whatever you put after the IF would get evaluated and checked regardless, hence order would make no difference.

As soon as the if condition can be defined as false or true no further testing of conditions is done.

example
alias x1 { echo -a x1 $1 | return $false }
alias x2 { echo -a x2 $1 | return $true }
alias x3 { echo -a x3 $1 | return $false }
alias test { if (($x1(a) == $x2(b)) || ($x2(c) == $x2(d)) || ($x1(e) == $x3(f))) { echo -a IF conditions met } }

/test
x1 a
x2 b
x2 c
x2 d
IF conditions met

evaluation of ($x1(e) == $x3(f)) never occurs, this is the most common method of if evaluation of any language I know of.

- Quite the opposite. It's far more unlikely for someone to be saying '!allow ...' than for them to be an op. The point of shortcut evaluation is to put the condition that is least likely to be true first with the and operator and the most likely first with the or operator. If your reasoning was meant to be that isop works faster than iswm then I'm afraid benchmarks show them to be approximately equal.

Lets see, the !allow command can only be activated by an OP so lets say we have 1 op and 99 users, every single one of them typer !allow blah

using method (1) there are 100 iswm and 100 isop done
using method (2) there are 100 isop and 1 iswm done

Are you telling me 100 iswm's and 100 isop's are "approximately equal" to 100 isop's and 1 iswm ?

The likely hood of someone saying something has no bearing on if its being checked for.




Thats a narrow view on its purpose im also not sure if in all cases that even holds, from what I know historicly it originated from coders wanting to put there accessing of something into the the same IF as there bound checking of it, such as beinga able to replace...
IF Element(x).exists { IF Element(x).result { ... } } * becuase you cause an error attempting a Element(x).result if it doesnt exist *
with
IF Element(x).exists && Element(x).result { ... } * becuase now no error occurs beucase no Element(x).result is done if it doesnt exist *

The first refrences to this I ever saw were, detecting division by zero errors and subscript out of range on arrays
if (x != 0) && ((y / x) > z) { .... } * under some early compilers this would produce runtime errors when x = 0, regardless of the fact the condition should have be protected by the != 0
if (x >= 0) && (x <= array().size) && (array(x) != y) { .... } * again produce runtime errors of out of bounds on array *




Actually I found benchmarking on that simple iswm to be faster than isop, but as i have said above In the end the !allow command is only for ops so why even test if it was said if there not an op.

Your resistance is futile. DaveC is the resident expert in all things related to computers and will be more than happy to inform you of your ignorance, regardless of whether you are right or wrong.

If the omnipotent DaveC is unable to thwart your attacks using logic or actual facts, he will formulate a post so lengthy and poorly connected that merely reading it will instantly render you incapable of reply.

If the sheer bulk of a DaveC post does not sufficiently boggle your mind, the copious amount of spelling mistakes, vague references to historical factoids (which may be real or imagined; such details do not concern DaveC) or random pastings of code will.

I have reached an epiphany on this forum tonight; the only winning move in DaveC's diabolical posting game is not to play.

Well thanks, glad to know you know your place.

Now Stay in it, unless you got soemthing to say.

PS: spelling mistake(s) included just for you.

I didn't read your whole post, but i'll reply anyway.
Starbucks is right.

&& (AND)



With the above, since it's not as likely that !allow <text> was said in the channel as it is that the person is an operator mIRC will only parse the part before && the majority of the time.



With the above, since it's more likely that someone will be an op than it is that someone says !allow <text> in the channel, mIRC will often parse both parts of the statement and find that the part after the && is $false.

|| (OR)



With the above, since it's not as likely that !allow <text> was said in the channel as it is that the person is an operator mIRC will have to parse both parts of the statement because the part before the || will be $false the majority of the time.



With the above, since it's more likely that someone will be an op than it is that someone says !allow <text> in the channel, mIRC will only have to parse the part before the || the majority of the time.

Benchmarks aren't needed here, logic itself will tell you that Starbucks is right.

Where did that clause come from? Nowhere before did you ever say that the '!allow ...' text was only relevant if an op says it - you're changing the rules in the middle of the game.

It doesn't really affect what I said anyway, because on most channels I would expect there to be a far higher ratio of ops[color:red]:non-ops[/color] than there is of '!allow ...' text[color:red]:non-'!allow ...' text[/color] on a channel. So your example is completely flawed. Yes, if 100 people say '!allow blah' and only 1 is an op then your original assertion is correct, however I can just as easily turn this around and say "What if 100 users on a channel are all ops and they each say something, only one of them says '!allow blah' - therefore my way is more efficient'. Of course that's a very flawed example also because it's very unlikely that all the people speaking in a channel will be ops. However, it is far more likely that someone speaking won't be saying '!allow ...' than it is that someone speaking won't be an op, and therefore my original post is still correct regardless of your added 'ops only' rule.




Well, no it's not applicable in all cases. If one condition takes an amount of time to resolve that's disproportionately larger than the difference between it and another condition failing then it would make sense to put the faster condition first anyway. However that's definitely not the case with what we're talking about here. Anyway, I didn't mean the sole point of shortcut evaluation existing was to be more efficient by putting conditions in a certain order (although that's certainly a major one), I simply meant that in order to get the efficiency boost that shortcut evaluation offers you should place your conditions in that order.

It's not a problem for me. I can easily be as arrogant and verbose as anyone else on these boards .

Im not going to answer after this one becuase its just turning into a can i break your reply reply contest. Well actually I dont know if there well be anything to reply to this.



Well i thought that...
(1) if (!allow * iswm $1-) && ($nick isop $chan)
(2) if ($nick isop $chan) && (!allow * iswm $1-)
spoke for themselfs that the !allow command was only for ops why else would i be checking if the $nick isop ?



Ill agree both our examples were right out there, to much of the bigheading trying to show my point of few, than looking at it in a clear light of day.
Im going to conceed and aggree with you, hows that?
I thought i should run it using a more realistic possable channel chat
Lets pretend a channel say 1 op for every 9 users? I dont know if u would call that fair, ones im in its higher on users, but not all talk.
6 people say something 2 of them twice, being 8 lines the op says something 2 times and does one !allow also, total 11 lines.
Assuming a iswm and isop are about the same time, and i got very little difference on themiswm came out quicker, but like 12 vs 13 second for 10,0000 IF's sooo pfffffft to that difference.
Anyway...
method (1) iswm checked 11 times isop checked 1
method (2) isop checked 11 times iswm checked 3
So you were right in the real world or my little example of it. I well come to your table sir with hat in hand and applogise for my mistake

I well however not appoligise to praetorian, since it seemed he got hyped after I mentioned that reparsing would likely be needed in windows when scrolling, backed up with refrences. Then he just had a whine about post lengths and typoes, I mean come on what next name calling?, lol I think he might have done that too.And Im sorry to him if i cant give a refrence to something I read about back in the 80's.

nothing wrong with lengthy replies. I bet you if the mIRC Help files were as lengthy on all of it's topics and examples, these scripting help forums that are about would look a lot thinner.

What references?



I thought you gave a reference!?