Un script Tcl, que nous appellerons plus simplement “Tcl” permet d'ajouter (ou de modifier) des fonctions à l'Eggdrop. Un script est basé sur trois points essentiels:

• le déclencheur qui permettra de lancer l'action,
• la procédure de traitement (l'action en elle-même),
• la sortie effective.

Autant que faire se peut, un script doit être bien structuré de manière à pouvoir être corrigé et évolué sans se perdre dans le code. Habituellement, on trouve X parties dans un script:

Il s'agit de commentaires indiquant le nom du script, son auteur, la version (et sa date), les évolutions par rapport à une version précédente, l'utilisation, …

En lisant l'en-tête d'un script, vous devriez avoir toutes les informations pour le configurer et l'utiliser.

La plupart des scripts doivent être configurés pour bien fonctionner, ceci se fait très souvent avec des variables qui sont définies dans le script. Ceci est placé juste après l'en-tête pour que l'utilisateur non-averti n'ait pas à modifier dans les parties actives, ce qui évite les mauvaises manipulations.

Pensez toujours à mettre un commentaire expliquant l'utilité de la variable et, si besoin est, un ou plusieurs exemples.

Les déclencheurs, ou Binds (contrainte) sont les éléments qui permettront à l'Eggdrop de réagir à un évènement qui peut être une action utilisateur (un message en canal par exemple), une action propre à l'eggdrop (une connexion au serveur) ou un évènement programmé (une date).

Certains préfèrent mettre les binds avant les procédures qui en découlent, d'autres préfèrent lister tous les binds au début du script. En règle générale, il vaut mieux les mettre ensemble car il n'est pas rare que plusieurs binds appellent la même fonction. Les fonctions

En Tcl, les fonctions sont appelées procédures. Une procédure reçoit une liste d'arguments, la traite et renvoit le résultat du traitement.

Il est courant de mettre à la fin du script une petite ligne qui indiquera en Party-Line que le script est bien chargé.

#
# Script example Version 1.0
#
# Auteur: CrazyCat <crazycat@mail.invalid.com>
# Date: 01/10/2007
# 
# Ce script est juste un exemple
#
# Utilisation: !exemple en canal
#
 
# CONFIGURATION
# message à afficher
set ex_msg "L'exemple est réussi"
 
# NE PAS MODIFIER CI-DESSOUS
bind pub - "!exemple" exemple:repond
 
proc exemple:repond {nick uhost handle chan args} {
   global ex_msg
   putserv "PRIVMSG $chan :$ex_msg"
   return 1
}
 
putlog "example 1.0 chargé"

Les variables peuvent être définies en deux groupes, les variables locales et les variables globales.

Elles sont habituellement définies au sein d'une procédure et sont temporaires: la variable n'existe qu'à l'intérieur de la procédure en cours.

Une variable globale existe non-seulement au sein de tout le script, mais elle est globale pour l'eggdrop. Elles sont définies hors des procédures, comme ex_msg dans notre exemple précédent.

La globalité d'une variable peut être très pratique, par exemple celles qui sont propres à l'eggdrop comme $botnick (le nick actuel de l'eggdrop), mais aussi très handicapant car une variable déclarée dans un script peut être écrasée par un autre script.

Pour vous éviter ce type de problème, il y a quelques astuces:

1. n'utiliser des variables globales qu'à bon escient,
2. utiliser un préfixe propre à chaque script pour vos noms de variables,
3. préférer un tableau unique contenant les diverses variables du script,
4. utiliser un espace de nom