Remote 2

CTCP Events:

CTCP stands for Client To Client Protocol, and CTCP events are events being triggered by the use of
this protocol. Whenever you receive a CTCP request, your client will answer to this if there is a set answer
defined for the requested CTCP type, else it will not respond. The format of a typical CTCP event is similar
to the 2nd type of regular event mentioned earlier, like;

ctcp level:match:where/how:command(s)

The difference here is that the event part of the definition, is actually the match. You can specify a specific
word the event should trigger on, or a wildcard match..for example:

        ctcp 1:PING:*:{
           ctcpreply $nick PING  $rand(1,2000) sec(s) ! am i lagged :p~

ctcp is reacting on a PING request, and only a PING request. In other words, send it a PINGS
request and it hasn't got a clue what you're talking about, and will just ignore you ;). The ' * ' indicates that it
will trigger both on ctcp's sent to the channel ( # ), and to you privately ( ? ). It is a level 1 ctcp, which
means that on most default configurations, this request will be answered from all sites (unless you have them
ignored, of course. The ctcpreply is a special command that sends your reply back in CTCP format, you
can also use msg, notice, or nothing at all, just echoing to you that somebody ping'ed you, etc. This event
sends a ctcpreply to the nick pinging you, with a silly message asking wether xxx seconds is ok. Here xxx
will be a number between 1 and 3000000, randomly picked by using the $rand identifier.

        ctcp 3:*TIME*:?:{
           notice $nick TIME $asctime($ctime) $+ . And you?
           ctcp $nick TIME
       }

one is reacting on CTCP's that contain the word 'TIME' in them, so, it will answer both a request for
CTIME, TIMES, etc. Refering to above, the '?' means that only ctcp's sent directly to you will be
answered, while requests sent to an entire channel will be ignored. This is a level 3 ctcp, which means that
it will only be answered when coming from an user in your userlist with a level that is 3 or above, and again,
on most configurations, level 1 is 'all regular users', so unless you have somebody added to your userlist,
that ctcp won't be answered :). This ctcp sends a notice to the nick requesting your time, with your date
and time in a text format, and then the question 'And you?'. It will also send a ctcp request back to the nick,
requesting his/her time.

CTCP events has got this nice thing about them, you can define your own ctcp's to respond to, not just the
default ones (PING, TIME, VERSION (and sometimes also CLIENTINFO and FINGER), and of late;
SOUND), and except from reacting on TEXT and NOTICE (and similar) events, this is the only way you
can set your own events to react to :). A special version of the ctcp event is the CTCPREPLY event, which
will trigger when an user responds to a ctcp request you sent him/her. CTCPREPLY events are of the
format

on level:CTCPREPLY:match:command(s)

in other words, this is really just a regular event of the 2nd type mentioned above, the only reason why I
mention it here is that it is reacting on ctcp's.

RAW:

is the one kind of events that the helpfile is not covering very well, perhaps because it is a rather big
'field' to cover. Raw events is events that trigger on messages the server sends you, for instance when you
connect to a server, when you issue a /whois, when somebody invites you, etc. What makes Raw different
from regular events? Well, while regular events are mIRC specific, and the format of them are specified by
mIRC, Raw events are defined in the RFC  regarding IRC networks, and the format is very
variable. Raw events are also called 'numerics', or 'numeric events', as they're defined by numbers, and you
indicate them by numbers when scripting. The format of raw/numeric events is

raw numeric(number):filter:command(s)

re raw is the same as 'on', just an word identifying this as an event, raw event in this case. Numeric is
the numeric to trigger on, filter is a rule for when the numeric should trigger the commands, same as the
match in on text events. Most commonly you will want to use some kind of wildcard filter, or just a ' * ' to
catch all events. You can look up the numerics in the RFC, or you can use an alternate source, there are a
good number of web based lists of the numerics, as well as hints on how to use them etc. One of the
better/more convenient sources, is Jeepster's numeric reference, found in both the regular web based
format, as well as in a regular windows helpfile. An example of a raw event
may be

       raw 433:*:{
          echo -a Somebody is already using $2 $+ ! Automatic retry? (F3)
       halt }

Raw 433 is the numeric for 'nickname already in use', in other words, when you issue a /nick <newnick>
command, and the nick is taken, the server sends you a 433, and in this case, the event will be triggered.
What this example does is to echo to your active screen that somebody's using the desired nick, and then it
asks you wether you want to automatically retry the nick change, until you succeed (note that this must then
be scripted so that there actually is an alias that starts when you press F3 =P), then it halts the regular
output to the screen (which is; <nickname> Nickname is already in use.).

But why $2? The format of raw events is typically (not always) that $1 is the requester, and $2 is the
requested item. In this case, that means the requested nickname. You see the problem? The formats of
numeric replies is very changeable, so you will have to learn the format of the specific numeric event you
intend to react on/modify, always. You can use Joliano's numeric parser (script), or a similar (but slightly
more advanced) script I wrote to catch the numeric when it appears, or you can use a more simple method
(also courtesy of Joliano):

    raw *:*:{
        echo 12 -s Raw $numeric $+ :
        echo 12 -s 1: $1 2: $2 3: $3 4: $4 5: $5 6: $6 7: $7 8: $8 and 9+: $9-
        halt
   }

Place that line in your remotes, and every single raw will be echo'ed in blue in your status screen. The
$numeric identifier holds the number of the numeric event being triggered, in the example above it will be
like;

     Raw 433:
     1: Yournick 2: Newnick 3: Nickname 4: is 5: already 6: in 7: use 8: and 9+

like this:

Remote2

and the parameters from 1-8 will be numbered, while parameter 9 and out (if existant) will be just echo'ed
in one bulk. While regular events and ctcp events trigger by other people's actions, raw events are
responses the server sends back to you, triggered by your own or your IRC clients actions (in the above
example I was trying to take the nick 'IO'. ;))