Introducci�n 
 
Las siglas CTCP significan “Client to Client Protocol” o “Protocolo de cliente a cliente” en castellano, y b�sicamente se trata de un tipo escpecial de comunicaci�n entre los usuarios de un server de IRC que ser� usada para provocar que los usuarios de el script que estemos haciendo ejecuten ciertas acciones autom�ticamente al recibir cierta informaci�n por CTCP. 
Por otra parte los usuarios remotos se refiere a algo que usted seguro que ya ha visto anteriormente en el tutorial de enventos remotos, se trata de ese numerito que siempre ponemos en el evento por ejemplo “on 1:OPEN:” , �qu� es ese ‘1’? Pues sencillamente es el nivel que necesita un usuario para hacer que salte ese evento con los comandos que se hayan especificado, despues entrar� en m�s detalle en esto, ahora volviendo al principio vamos a ver todo lo referente a los eventos CTCP: 
 
 
Comandos CTCP 
 
Para mandar informaci�n a otro usuario mediante CTCP lo haremos de la siguiente forma: 
  /ctcp <nick> <mensaje>

donde <nick> es el nick de la otra persona y <mensaje> es cualquier mensaje que queramos enviar por ese protocolo. L�gicamente no nos pondremos a hablar con un usuario mediante CTCP's ya que seria absurdo estando los dos conectados al IRC. Los CTCP's tienen otra utilidad... que es la de que el otro usuario reaccione autom�ticamente de una cierta manera al usted enviarle ese CTCP. Por ejemplo, existe uno que tiene el mIRC ya implementado: el famoso y consiste en enviar un ping al otro usuario: 
  /ctcp <nick> ping   
El programa del otro usuario responder� automaticamente al CTCP PING y lo har� devolviendo una informaci�n, que al llegarnos de nuevo el mIRC nos muestra en pantalla. En este caso en pantalla se muestra el “Lag” o retardo de la l�nea que hay entre usted y la persona a la que envi� el ping. Puede probar con los otros CTCP implementados ya en mIRC, el funcionamiento de todos es similar; solo varia la respuesta que proporcionan. 
 
A continuaci�n aprender� a crear sus propias respuestas a ciertos CTCP's, ya que el mIRC solo trae unas cuantas ya definidas (como son  PING, VERSION, TIME ...) pero usted quiz�s quiera hacer otras con otros nombres, o tal vez cambiar las respuestas que a los ya existendes dar� su programa. 
 
 
Eventos CTCP 

Vamos a ver ya como usamos este tipo de eventos para que la explicaci�n sea m�s f�cil de entender. En la secci�n “Remotes” del editor del mIRC es donde definiremos estos eventos y se hacen de una forma parecida al resto de eventos remotos. La sintaxis es: 
  ctcp <nivel>:<texto>:<#,?,*>:{ comandos }  
Este tipo de eventos haran que nuestro programa se comporte de cierta manera (es decir, que ejecute los comandos que le especifiquemos) cuando recibamos un CTCP <texto> de otro usuario. El <nivel> de momento lo dejaremos siempre en ’1’ , y el otro par�metro ha de ser o bien un ‘#’ si nos referimos a un canal, un ‘?’ para un privado(query) o un ‘*’ para “en cualquier lado”. Con un peque�o ejemplo lo veremos m�s claro, copie lo siguiente en el editor del mIRC, pesta�a “Remotes”: 
 
 ctcp 1:*hora*:*:{  

msg $nick Son las $time 

} 
 
Ese evento har� como ya habr� imaginado que cuando un usuario le haga un, usted autom�ticamente le responda envi�ndole un query en el que diga por ejemplo “Son las 19:45:23” . Como ve se pueden usar ‘*’ en el par�metro <texto> para indicar que si la palabra “hola” del mensaje CTCP viniera precedida de cualquier otra, o despues de esa palabra hubiera alguna palabra m�s, se ejcutar�a de todas formas en comando. En este ejemplo en concreto eso no es de mucha utlilidad, pero en el siguiente si que lo ser�: 
 
ctcp 1:dime*:*:{  

msg $nick Lo siento estoy ocupado 

} 
 
Este evento har� que cuando un usuario le env�e un /ctcp DIME , usted le responda diciendole que est� ocupado. Por ejemplo un usuario le podr�a hacer un /ctcp <sunick> dime la hora o quizas /ctcp <sunick> dime tu nombre. En cualquier caso la respuesta ser� la misma. 
 
Lo que hemos visto hasta ahora se refiere a crear eventos CTCP propios, que no exist�an antes en el mIRC y a los que el script responder� de la forma que le hemos especificado, pero tambi�n si quisiera, podr�a cambiar su respuesta a algunos de los eventos CTCP ya definidos, como es el caso del PING, para ello tendremos que especificar al final de los comandos, el comando /halt , por ejemplo: 
 
ctcp 1:PING:*:{  

notice $nick Nada de Pings, gracias! | halt 

} 
 
Este evento har� que cuando usted reciba un /ctcp ping de alg�n usuario, le enviar� un /notice dici�ndole: “Nada de Pings, gracias!”, y mediante el comando /halt haremos que el script deje de procesar ese evento, y de esa forma que no procese la parte que ya estaba hecha en el mIRC (la que nos devuelve el lag). Tambi�n podr�amos usar este procedimiento para otros CTCPs ya definidos como son TIME, USERINFO ... etc. 
Otra utilidad de estos eventos puede ser la de controlar nuestro mIRC “a distancia”, y me explico, si abrimos dos mIRCs, podremos controlar a uno de ellos mediante CTCPs mientras que el otro lo controlaremos normalmente, se pueden usar por lo tanto para controlar a nuestros clones, por ejemplo si copiamos el siguiente c�digo en la secci�n Remotes y abrimos dos mIRCs : 
   ctcp 1:habla*:#:{ /say $1- }  
Cuando desde uno de los mIRCs escribamos el otro mIRC que hemos abierto enviar� el mensaje que pongamos despu�s del “HABLA” al canal, por ejemplo si ponemos /ctcp <nickclon> habla soy un bot, me manejan con ctcps! har� que nuestro clon diga ese mensaje al canal. 
   ctcp 1:quit:*:{ /quit $1- }  
Este nuevo ejemplo har� que al recibirlo el CTCP, el clon cierre el mIRC con el mensaje especificado en ctcp 1:entra:*:{ /join $1 }  
Este har� que el clon entre en el canal que especifiquemos en /ctcp <nickclon> entra #canal ctcp 1:comosoy:#:{ /say Me llamo $1 , tengo $2 a�os y soy $3 }  
Este �ltimo har� que el clon diga en el canal ese mensaje usando las tres siguientes palabras que pongamos despues del /ctcp <nickclon> comosoy , por ejemplo si ponemos /ctcp <nickbot> comosoy Pepe 20 alto , el bot pondr� en el canal “Me llamo Pepe, tengo 20 a�os y soy alto”. 
 
Con esto hemos matado dos p�jaros de un tiro, no s�lo ya sabemos manejar los eventos CTCP y como evitar las respuestas predeterminadas de algunos de ellos, sino que hemos aprendido sobre su principal utilidad que es la creaci�n de Clones que obedezcan nuestras �rdenes, tambien conocidos como “bots”. 
 
Antes de pasar a la siguiente secci�n hay que comentar tambi�n que hay un tipo especial de eventos CTCP que sirven exclusivamente para cambiar la apariencia de las respuestas est�ndar de los CTCPs predefinidos en el mIRC... es decir que por ejemplo cuando usted hace un ping a alguien, ese alguien le devuelve la informaci�n del ping, y usted ve en pantalla algo como: 
 
[TeMpEsT PING reply]: 0 secs 
 
Pero quiz�s para hacer m�s bonito el script le gustar�a que pusiera: 
 
Lag con TeMpEsT: 0 segundos. 
 
para ello usamos el evento ON CTCPREPLY que tiene la siguiente sintaxis: 
  on 1:CTCPREPLY:<ctcp>:{ comandos }   
Donde <ctcp> pondremos el CTCP predefinido al que nos referimos, y en comandos la secuencia de comandos que queremos ejecutar. Generalmente para este tipo de acciones usaremos /echo para poner lineas de texto en pantalla. Vamos a ver como conseguiriamos hacer que la respuesta del PING nos fuera mostrada como hemos visto antes, debemos escribir en los “remotes”: 
 
on 1:CTCPREPLY:*PING*:{ 

%lag = $ctime - $2 
echo –s Lag con $nick : %lag 
halt

} 
 
Lo que hemos hecho es primero calcular el lag bas�ndonos en a informaci�n que nos devuelve el nick al que le hemos hecho el PING. En este caso nos devuelve: “PING 919197981” . �Y que es ese numero tan largo? . Ese numero corresponde a una referencia de tiempo, indicada como el numero de segundos transcurridos desde el 1 de enero de 1970 . El instante al que se refiere ese n�mero es el momento en que la persona recibio el PING, por lo tanto si restamos a la hora actual en el formato $ctime (que nos devolvera la hora actual como numero de segundos desde el 1 de enero de 1970) de la fecha en la que el nick recibio el ctcp, nos quedar� un numero m�s peque�o y corresponder� al LAG en segundos. Guardamos ese dato en la variable %lag y a continuacion, mediante un /echo,  ponemos la informaci�n en Status, y el comando /halt. Se debe estar preguntando �ese halt no parar� el proceso del PING y nos dejar� sin ver la informaci�n? La respuesta es no, puesto que cuando este evento “salta” la informaci�n del PING ya nos ha sido devuelta por la otra persona, as� que en este tipo de eventos el /halt al final lo �nico que har� ser� evitar que veamos, adem�s del mensaje que hemos especificado, el que ya hab�a por defecto. Pruebe ese ejemplo, y despu�s pruebelo de nuevo suprimiendo el /halt para que vea usted mismo a que me refiero. 
 
 
Usuarios Remotos 
 
Ya le he dado una pista antes de que son los usuarios remotos... nos referimos a un usuario remoto cada vez que especificamos un evento remoto , por ejemplo en el evento “on 1:JOIN” le estamos diciendo al mIRC “cuando un usaurio de nivel 1 entre a un canal...” . �sta es una secci�n completamente opcional y no necesariamente todos los scripts har�n uso de ella, puesto que s�lo es realmente �til para ciertas tareas muy espec�ficas. Antes que nada debe saber, que por defecto, nivel 1 quiere decir “todos los usuarios”, es por eso que hasta ahora todos los eventos remotos se han declarado con “on 1:...” para que tengan efecto sobre todos los usuarios, pero podr�a darse la ocasi�n en que usted quiera que algun o algunos usuarios en concreto tengan acceso a unos eventos y no lo tenga el resto, para ello les tendremos  que asignar un nivel. 
 

• Asignaci�n de niveles a usuarios

Para asignar un nivel determinado a un usuario iremos al editor del mIRC, pero esta vez a una pesta�a que seguramente tendremos en blanco, la pesta�a “USERS”. La sintaxis para declarar que un usuario tiene un cierto nivel es:  <nivel>:<nick>!<user>@<host>/<ip>  
por ejemplo: 
  10:TeMpEsT!*@*  20:Scytale!*@theilax.arrakis.es   
Hemos creado dos usuarios remotos, el primero TeMpEsT le hemos dado el nivel ‘10’ y cualquier persona con ese nick tendr� acceso a los privilegios de ese nivel 10, que los especificaremos m�s adelante. El segundo nivel que hemos es asignado es m�s especifico porque se lo asignamos a un nick y a una m�scara, es decir que el nivel 20 solo lo tendra aquel que su nick sea “Scytale” y su host sea “theilax.arrakis.es”, de esa forma nos aseguramos que los provilegios que especifiquemos para el nivel 20 solo los Scytale y no alguna persona que se ponga ese nick. Una cosa importante a recordar es que una persona con nivel 20 tendr� acceso no solo a los privilegios del nivel 20, sino tambi�n a los de nivel 19,18,17....etc, es decir que en el ejemplo anterior, Scytale tendria acceso a los eventos de nivel 20, pero tb a los de nivel 10. Si quisieramos que Scytale tuviera acceso �nicamente a los eventos de nivel 20, tendr�amos que escribirlo de la siguiente forma: 
  =20:Scytale!*@theilax.arrakis.es   
el ‘=’ delante del nivel indica que la persona especificada solo podra acceder a los eventos que marquemos con un nivel 20, es decir que los de nivel 1, o 2, o 10 no los podr� acceder el usuario Scytale. 
 
Pues bien as� se asignan los niveles de una forma “est�tica” es decir, vamos al editor del mIRC y los intriducimos a mano, pero tambien podr�amos hacerlo de una forma “din�mica” mediante comandos del mIRC, digo din�mica porque nos pueden servir estos comandos para m�s adelante permitir al usuario cambiar el nivel de cierta persona o a�adir mas gente con un determinado nivel. Los comandos son: 
 
 
/auser [-a] <niveles> <nick/host> 
 
A�ade un usuario con el nivel o niveles que especifiquemos a la lista de usuarios remotos, si especificamos el par�metro [-a] har� que si el usuario ya exist�a, se le a�ada el nuevo nivel al que ya ten�a. Por ejemplo: 
  /auser 10 TeMpEsT   
A�ade a TeMpEsT a la lista de usuarios remotos con nivel 10, si TeMpEsT ya estaba en esa lista, ser� borrado y sustituido por la nueva entrada 
 
 
/auser –a 12,13 TeMpEsT 
 
A�ade los niveles 12 y 13 a los que ya ten�a el usuario TeMpEsT, por lo tanto la secci�n users quedar� asi: 
  10,12,13:TeMpEsT   
En lugar de un nick podriamos haber especificado una m�scara con el modelo nick!user@host 
 
 
/flush [niveles] 
 
Este comando borrar� a todos los nicks de niveles especificados que no est�n actualmente en ninguno de nuestros canales. Por ejemplo: 
  /flush 1,2,3   
Borrar� de a lista de usuarios remotos a todas las personas que tengan nivel 1,2 o 3 y no est�n en ninguno de nuestros canales. 
   /flush   
Cuando se especifique este comando sin argumentos borrar� todas las entradas (en la pesta�a “Users” del mIRC) de gente que no est� actualmente en ninguno de nuestros canales 
 
 
/guser [-a] <niveles> <nick> [tipo] 
 
Este comando trabaja de la misma forma que /auser con la �nica diferencia de que solo le podemos especificar el nick de la persona y el mIRC mirar� su m�scara actual y la a�adir� al nick, para ello tenemos que especificarle tambi�n el [tipo] de m�scara que ser� un n�mero de 0 a 9 
  /guser 10 TipoX 4   
A�ade al nick TipoX con nivel 10 y una m�scara del tipo 4 (*!*@*.dominio) 
 
 
/ruser [niveles] <nick / host> [tipo] 
  
Borrar� los niveles que especifiquemos del nick o host que especifiquemos, podemos tambien darle solo el nick y especificar el [tipo] de m�scara para que el mIRC la mire y borre los niveles de los usuarios que tengan esa m�scara. 
  /ruser 10 Ytreme   
Borrar� el nivel 10 que le hayamos dado al nick Ytreme 
  /ruser Ytreme   
Borrar� a Ytreme de la lista de usuarios remotos (o lo que es lo mismo le quitar� todos los niveles) 
  /ruser 25 Ytreme 4   
El mIRC buscar� la informaci�n de Ytreme y borrar� el nivel 25 de todas las entradas en la lista de usuarios remotos que tengan esa m�scara. 
 
 
/rlevel [-r] <niveles> 
 
Borra a todos los usuarios de la lista de usuarios remotos cuyo primer nivel sea el que especifiquemos en <niveles>. Si usamos el par�metro [-r] borrar� a todos los usuarios que tengan el nivel <niveles> en cualquier lugar. Partiendo de: 
  10,12,15:TeMpEsT  12,20:Ytreme   
El comando: /rlevel 12 borrar� al usuario Ytreme puesto que su primer nivel el 12 
  /rlevel –r 12   
Borrar� tanto a Ytreme como a TeMpEsT puesto que tienen el nivel 12 , no importa en que posici�n 
 
 
/ulist [ < / > ] <nivel> 
 
Lista a los usuarios de nivel <nivel> , o bien podemos especificar el par�metro [ < / > ] como “>4” o “<10” . Por ejemplo: 
  /ulist >10   
Lista todos los usuarios cuyo nivel sea menor o igual a 10 
  /ulist >20   
Lista a todos los usuarios remotos cuyo nivel sea mayor o igual a 20 
 
 
Restricciones en el acceso a Eventos 
 
Vista ya la forma en la que asignamos niveles a usuarios, ahora veremos como puede hacer que ciertos eventos solo sean accesibles por usuarios especificos (con un nivel especifico), para ello simplemente cambiaremos ese “1” que soliamos poner en todos los eventos remotos/ctcps por el nivel m�nimo que necesitar� el usuario para acceder al evento: 
 
on 10:JOIN:#:{ echo –s Ha entrado un usuario de nivel 10 o superior} 
 
Este evento har� que cuando un usuario de nivel 10 o superior entre en un canal en el que usted est�, le salga un mensaje en en Status avis�ndole. Pero recuerde que este evento no s�lo lo accederan los usuarios de nivel 10, sino los de 20, 30, etc... 
Pero tambi�n podemos hacer que un evento solo sea accesible por los usuarios de un nivel determinado, y no por aquellos usuarios que tengan m�s nivel, lo haremos mediante el prefijo ‘+’ : 
 
on +5:JOIN:#:{ echo –s Ha entrado un usario de nivel 5 } 
 
De esta forma si entra un usuario con nivel 10 por ejemplo, este evento no se ejecutar� puesto que esta restringido a los usuarios de nivel 5 . 
 
Otra forma de restringir el acceso a eventos es mediante el sufijo ‘!’ al nivel, que har� que el evento no se ejecute si fue accionado por usted mismo, por ejemplo: 
 
on 1!:OP:#:{ /echo $nick le dio op a $opnick } 
 
Este evento har� que cuando un usuario le de op a otro nos sea notificado en la ventana activa, a excepci�n de cuando sea usted el usuario que da op 
 
Y al igual que restringimos el accceso a ciertos eventos tambi�n podemos tener eventos de “libre acceso” por todos los usuarios, independientemente del nivel que tengan usando un ‘*’ en lugar del nivel: 
 
on *:JOIN:#:{ echo $chan Ha entrado $nick } 
 
Ese evento mostrar� un mensaje en pantalla cada vez que entre un usuario a un canal, sin tener en cuenta su nivel. 
 
Tambi�n podemos usar el  prefijo ‘@’ para indicarle al script que ese evento solo salte cuando tengamos OP en ese canal, por ejemplo: 
 
on @10:JOIN:#:{ op $nick } 
 
Este evento har� que cuando un usuario de nivel 10 entre a un canal en el que estemos, y en el que seamos op, le demos op automaticamente 
 
Resumiendo un poco esta �ltima parte en la siguiente tabla de ejmplos: 
 
Evento Accesible por usuarios de nivel: 

• on 100:PART 100 o superior 
  on +30:DEOP �nicamente 30 
  on 5!:QUIT 5 o superior (excepto usted!) 
  on *:JOIN Todos 
  on @30:NICK 30 o superior (solo si usted es OP en el canal)  

Visto esto, y para finalizar, se va a realizar un ejemplo que mezcle los Usuarios Remotos con lo que vimos al principio de este documento sobre eventos CTCP, el objetivo ser� crear un medidor de LAG, algo que es fundamental en cualquier script. 
 
 
Ejemplo 1: Creaci�n de un medidor de LAG 

Para medir el lag que se tiene con una cierta persona, lo que se hace, como ya sabe, es hacerle a esa persona un CTCP PING, pues bien si usted quiere hallar el lag con usted mismo, es decir su propio lag con el server, lo que tendr� que hacer es como ya habr� adivinado, hacerse un CTCP PING a usted mismo, por lo tano analicemos un poco en que se basar� nuestro medidor para que despues nos sea m�s f�cil construirlo: 
 
Primero necesitaremos un TIMER , es decir que cada ‘X’ segundos el mIRC nos haga automaticamente un PING para hallar nuestro lag.
 
Despues necesitaremos que la respuesta a ese ping se nos muestre en un formato diferente al habitual y que la respuesta habitual se omita, pero habr� que tener en cuenta que cuando hagamos un ping a nosotros mismos, la respuesta que recibiremos ser� del tipo “Tu lag es de X segundos”, para ello usaremos el evento “ctcp 1:ping”. El problema es que si en ese evento ponemos una linea que diga “Tu lag es de X segundos” ese ctcp saltar� cada vez que alguien nos haga un ping, sea quien sea, y lo que haremos en este ejemplo es que ese evento solo se ejecute cuando la persona que le haga el ping sea usted misma, de esa forma conseguiremos que cada vez que usted se haga un ping (automaticamente mediante el timer) se active el evento ctcp del ping que usted habr� dise�ado y que cuando sea otra persona la que le haga un ping, �sta reciba el mensaje est�ndar. Pasemos ya a ver el c�digo para este ejemplo, y posteriormente l acabaremos de comentar: 
 
Copie lo siguiente en “Aliases”: 

/medidor { 

/timer 0 30 ctcp $me PING 
/auser 55 $me 

} 

Copie lo siguiente en “Remotes”: 

ctcp 55:PING:{ 

%lag = $ctime - $2 
titlebar Lag: %lag 
halt 

} 

on 1:CONNECT:{ medidor } 

Y ya est�, l�gicamente este es un medidor de lag bastante primitivo en el sentido de que se le pueden a�adir muchas m�s cosas, pero esta es la base y a partir de ella usted podr� ir elabor�ndo su propio medidor de lag con sus conocimientos. 
La explicaci�n es bastante simple, cuando usted conecte a un servidor de IRC (salta el evento on 1:connect) se ejcutar� el alias “medidor” que iniciar� un timer infinito (de ah� el ‘0’ como primer par�metro) que consistir� en hacerse a usted ($me) un CTCP PING cada 30 segundos. Adem�s cuando conecte usted ser� a�adido a la lista de usuarios remotos con nivel 55. Al cabo de 30 segundos se producir� por primera vez ese CTCP PING que pusimos en el timer, y puesto que el ping lo manda usted que es un usuario de nivel 55, saltar� el evento “CTCP 55” que calcular� el lag y lo mostrar� en la barra de t�tulo del mIRC mediante el comando “titlebar”, por ultimo se usa un “halt” para que la respuesta predeterminada del mIRC al PING quede escondida. Y obviamente si cualquiero otro usuario le hiciera un ping, como usted ser� el �nico con nivel 55, este evento no saltar� y por tanto el otro usuario recibir� la respuesta est�ndar del PING.