 |
 |
 |
Eventos CTCP
EVENTOS CTCP
Introducción.-
Las siglas
CTCP significan “Client to Client
Protocol” o “Protocolo de
cliente a cliente” en español, básicamente se trata de un tipo
especial de comunicación entre los usuarios de un servidor 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.
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 cualquiera de
los mensajes que queramos enviar por ese protocolo. Lógicamente no nos
pondremos a hablar con un usuario mediante CTCP’s
ya que sería 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 enviarle nosotros ese CTCP. Por ejemplo, existe uno que tiene
el mIRC ya implementado: el famoso CTCP
PING y consiste en enviar un ping al otro usuario:
/ctcp <nick> ping
El
programa del otro usuario responderá automáticamente al CTCP PING y lo hará
devolviendo una información, que al llegarnos de nuevo a nosotros el mIRC nos muestra en la pantalla. En ese
caso en la pantalla se muestra el “Lag” o retardo de línea que hay
entre nosotros y la persona a la que enviamos el ping. Se puede probar con
otros CTCP implementados ya en el mIRC, el funcionamiento de todos es
similar, solo varia la respuesta que proporcionan.
Eventos CTCP.-
Vamos a
ver 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 de script 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 harán 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, 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
}
Este
evento hará como ya habrá imaginado que cuando un usuario nos haga un /ctcp
<nick> hora le respondamos de forma automática enviándole un
query en el que diga por ejemplo “Son las 18:35:24”. Como se ve, se
pueden usar “*” en el parámetro <texto> para indicar que si
la palabra “hora” del mensaje CTCP
viniera precedida de cualquier otra, o después de esa palabra hubiera alguna
palabra más, se ejecutaría de todas formas ese comando. En este ejemplo en
concreto eso no es de mucha utilidad pero en 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 que
está ocupado. Por ejemplo un usuario que 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 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 esta
forma no procese la parte que ya estaba hecha en el mIRC (la que 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 /ctcp
<nick_clon> habla <mensaje> el otro mIRC que hemos abierto enviará el mensaje que pongamos después de
“habla” al canal, por ejemplo si ponemos /ctcp <nick_clon>
habla soy un bot, me manejan con ctcp’s! hará que nuestro clon diga ese
mensaje al canal.
ctcp
1:quit*:*:{ /quit $1- }
Este nuevo
ejemplo hará que al recibir el CTCP,
el clon cierre el mIRC con el
mensaje especificado en /ctcp <nickclon> quit
<mensaje_de_quit>.
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 ponemos después del /ctcp <nickclon> comosoy por
ejemplo, si ponemos: /ctcp <nickclon> comosoy Pepe 20 alto, el clon pondra
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, también
conocidos como “bots”.
Veamos
ahora los eventos CTCP a que nos
referimos con anterioridad, los que mandan respuestas estándar exclusivamente
que ya vienen predefinidos en el mIRC.
Por ejemplo cuando usted hace un pinga un usuario, ese usuario le devuelve la
información del ping y usted ve en la pantalla algo así:
[<nick] PING reply]: 0 secs
Pero
quizás para hacer más bonito el script le gustaría que pusiera:
Lag
con <nick>: 0 segundos
para ello
usaremos 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 las líneas de texto en
pantalla. Vamos a ver como conseguiríamos hacer que la respuesta del ping nos
fuera mostrada como hemos visto antes, debemos escribir en “remotes”:
on 1:ctcpreply:ping:{
%lag =
$time - $2
echo
–s Lag con $nick $+ : %lag
halt
}
Lo que
hemos hecho es primero calcular el lag basándonos en la información que nos
devuelve el nick al que le hemos hecho el ping. En este caso nos devuelve
“PING 919197981”. ¿Y qué es ese número tan largo?. Ese número
corresponde a una referencia de tiempo, indicada como el número 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 recibió el PING, por lo tanto si
restamos a la hora actual en el formato $time
(que os devolverá la hora actual como número de segundos desde el 1 de enero de
1970) de la fecha en la que el nick recibió el ctcp, nos quedará un número más
pequeño y corresponderá al LAG en segundos. Guardamos ese dato en la
variable %lag y a continuación,
mediante /echo, ponemos la información en la ventana de Status, y el comando
halt. Se debe de estar preguntando ¿ese halt no parará el preoceso del PING y
nos dejará sin ver la información? La respuesta es no, puesto que cuando ese
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 pruébelo de nuevo
suprimiendo el /halt para que vea usted mismo a que nos referimos.