Forums Bug Reports remote script misinterpretation of colons ":"

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:

just do

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),*)):*:{.

its not readable

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.

($chr though, not $asc)

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

How's that?

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