Salut crazy,
En gros, oui.
Un BNC doit être ajouté avec l'ident que l'utilisateur aura choisi.
La commande serait ".request <ident>"
De là, le script vérifie si la commande ".regles" à été utilisée, si oui il vérifie si l'host/auth de l'utilisateur est déjà connu par l'un des BNC existant et évidemment si l'ident demandé est toujours disponible. Alors un nouveau BNC est ajouté avec l'ident demandé par l'utilisateur.
Dans le cas contraire, un message d'erreur est alors donné à l'utilisateur.
Voici un exemple concret:
<DeeJay> .request deejay
<Bot> Vous devez d'abord prendre connaissances de nos règles, utiliser .regles pour voir la liste.
<DeeJay> .regles
<DeeJay> .request deejay
<Bot> Vérification . . . (regarde si l'ident "deejay" est disponible - vérifie l'host et l'auth de DeeJay pour voir dans la liste des BNC déjà crée si ces informations sont déjà connues). 3 réponse possible:
<Bot> Erreur, deejay n'est plus disponible choisissez un autre ident!
<Bot> Erreur, votre host/auth est déjà connu par l'un de nos BNC.
<Bot> OK un BNC va être crée avec l'ident "deejay", les informations pour vous y connecter vont vous être envoyé en MP (le script initial se charge de créer le BNC ainsi que l'envoi des info par MP à l'utilisateur, en l’occurrence DeeJay dans ce cas ci)
C'est sans doute indiqué dans le script mais il s'agit de shroudBNC (pour ceux qui connaissent).
A noter que le script initial fonctionne à condition que l'eggdrop soit connecté à un BNC ayant les droits d'admin, pour implémenter la fonction .request, j'imagine qu'un fichier .txt doit être crée avec les Host/Auth des utilisateurs qui se connecte à nos BNC.
En gros, oui.
Un BNC doit être ajouté avec l'ident que l'utilisateur aura choisi.
La commande serait ".request <ident>"
De là, le script vérifie si la commande ".regles" à été utilisée, si oui il vérifie si l'host/auth de l'utilisateur est déjà connu par l'un des BNC existant et évidemment si l'ident demandé est toujours disponible. Alors un nouveau BNC est ajouté avec l'ident demandé par l'utilisateur.
Dans le cas contraire, un message d'erreur est alors donné à l'utilisateur.
Voici un exemple concret:
<DeeJay> .request deejay
<Bot> Vous devez d'abord prendre connaissances de nos règles, utiliser .regles pour voir la liste.
<DeeJay> .regles
<DeeJay> .request deejay
<Bot> Vérification . . . (regarde si l'ident "deejay" est disponible - vérifie l'host et l'auth de DeeJay pour voir dans la liste des BNC déjà crée si ces informations sont déjà connues). 3 réponse possible:
<Bot> Erreur, deejay n'est plus disponible choisissez un autre ident!
<Bot> Erreur, votre host/auth est déjà connu par l'un de nos BNC.
<Bot> OK un BNC va être crée avec l'ident "deejay", les informations pour vous y connecter vont vous être envoyé en MP (le script initial se charge de créer le BNC ainsi que l'envoi des info par MP à l'utilisateur, en l’occurrence DeeJay dans ce cas ci)
C'est sans doute indiqué dans le script mais il s'agit de shroudBNC (pour ceux qui connaissent).
A noter que le script initial fonctionne à condition que l'eggdrop soit connecté à un BNC ayant les droits d'admin, pour implémenter la fonction .request, j'imagine qu'un fichier .txt doit être crée avec les Host/Auth des utilisateurs qui se connecte à nos BNC.