mIRC remote scripts misinterprete colons on the "on *:whatever:..."
Example, if i wanted mirc to respond to some certain text or maybe just an emoticon, it does work, i know that i could evaluate it out for all text, or situation... but just to see what would happen if i didnt:
on *:TEXT:*:)*:*:{
...
}
or..
on *:TEXT::):*:{
...
}
now the script thinks the the colon in that smilely is part of syntax.
I don't see that as a bug.
Agreed, an escape character
would be useful though:
on *:text:*[color:red]\[/color]:):#:{ }
As always introducing new meaning to something that could already be in use has the possibility to break a lot of things. I don't see what the problem is with just using on *:TEXT:$($+(*,$asc(58),$asc(41),*)):*:{.
I can read it just fine. The parentheses of identifiers make them very easy to follow. At least as much as escape characters or sequences.
so can I, but can the author?
yes... as i said before, i "know" that i can evaluate it out to see if its true or not, and yes i do use the $chr instead (if i have to)... but like someone said up their ^, an escaping code would be definately nice.
In which case scripters could add an extra char to their scripts, they could even let mIRC do it for them: Edit > Find Text... > Replace "\" with "\\"
It's hardly as simple as replacing all uses of \ with \\ since it's only in events. Plus it reuires of course that people are actually aware of the change.
Anyway, on *:text:*\:):#:{ } looks a damn sight more confusing than using identifiers IMO.
I was talking about \ being an escape character for the whole language, eg: $mycoolidentifier(param1,param2\,,param3)
$1 = param1
$2 = param2,
$3 = param3
I think $chr() looks very messy, whereas \ looks neat, each to their own I suppose.
I'd like that, especially as adding it wouldn't break current scripts (which is important).
Oh wait... never mind that it would break some things... :rolleyes:
This is not actually an absolute equivalence! Using an if statement would make your remote look like this:
on *:TEXT:*:*:{
(or something like this anyway - with a '*' for wildmask)
This however would prevent other on text remotes placed under it to run! There are ways through that but some people find it convenient to use a lot of on text events one under the other with different wildmasks, levels or channels.
I agree with starbucks_mafia's suggestions.
Yes so why not place it in a new script? There now the other wildcard on text wont be affected