Aide sur une condition

[Epsilon]

Bonjour,

j'essaye de faire un petit script, lors de la connection d'un user mon bot effectue un ctcp version, jusqu'ici tout est ok, par contre je voudrais que dès qu'il reçoit aucun retour du ctcp il effectue une action je fais :

Code :

bind ctcr - VERSION ::repctcp::ctcp:reply
proc ::repctcp::ctcp:reply {nick uh hand dest key arg} {
 if {$arg == ""} {
        putlog "Aucune réponse CTCP de $nick"
 }
 return 0
}

Il reçoit bien le ctcp mais la condition doit être mauvaise parce qu'il m'envoit pas le putlog dès qu'il ne reçoit aucune valeur du ctcp

voilà ce qu'il reçoit dès qu'il a une valeur :

[11:28:50] CTCP reply VERSION: eggdrop v1.6.20 from Bobot (Bot@localhost) to Bobot

[Strategy]

C'est normal 

Si le client ne répond pas tu reçois rien ^^ 

Si tu veux faire ce que je pense il faut utiliser un timer

[Epsilon]

bah normalement on peut faire une condition qui dit si il ne reçoit pas de réponse, bah il effectue une cmds , non?

[Strategy]

Non

Je connais pas trop le TCL encore moins dans des eggdrops mais apparemment les binds c'est le déclenchement d'un événement

Un évenement c'est par exemple si j'envoi un message a ton bot il va déclencher le bind msg (je dit au pif)

dans le cas du CTCP c'est la même chose.

Tu demandes la version du client et il y a 2 cas possibles

1 Le client répond donc dès que ce client fait la request version a ton eggdrop l'eggdrop déclenche l'événement bind ctcr
2 Le client ne répond pas l'eggdrop ne recoit rien donc il déclenche aucun événements

Pour resumer une condition null fonctionnerait que si un client répondait au ctcp avec du null mais ca serrait étrange et pas sur que l'ircd accepte un message vide

[aliasangelius]

Question..
Pourquoi vous voulez faire des ctcp version aux personnes qui se connecte ?
C'est quoi l'utilité exact ?

Mise à part un truc qui sert pas à grand chose sans être méchant

[Strategy]

Question..
Pourquoi vous voulez faire des ctcp version aux personnes qui se connecte ?
C'est quoi l'utilité exact ?

Mise à part un truc qui sert pas à grand chose sans être méchant

Je pense qu'il veut faire le système que je lui ai dit hiers comme les 3/4 des clonneurs ne répondent pas au CTCP version et que tout les autres clients répondent il veut donc bloquer les clients qui ne répondent pas.  Quelque chose de très utile en soit ^^

[aliasangelius]

D'accord, oui je vois si y'a pas de réponse alors ont le refuse.

Petite idée partir sur un système de détection de connection du client, et la ont ctcp version, si réponse ont fait rien, si pas de réponse au bout de x temps ont refuse.

Le seul soucis, c'est qu'entre temps ils auront le temps d'aller sur les salon pour mettre un peut le bordel..

Donc une attribution de mode pour rejoindre un salon peut-être ? Ou un sapart forcer si la personne ne remplis pas les conditions à la connection "le retour du ctcp"

[CrazyCat]

bah normalement on peut faire une condition qui dit si il ne reçoit pas de réponse, bah il effectue une cmds , non?

Le seul moyen, c'est ce que disait  Strategy: lancer un timer lors de l'envoi du ctcp version et si on a pas eu de réponse adéquate au bout d'un certain temps, considérer qu'il n'y aura pas de réponse.

[Epsilon]

Je peux avoir un exemple sur mon code?

[MenzAgitat]

Voilà un exemple :
https://scripts.eggdrop.fr/details-Publi...-s147.html

[Strategy]

Le seul soucis, c'est qu'entre temps ils auront le temps d'aller sur les salon pour mettre un peut le bordel..

Cela dépend de comment sont reglés request et timer

[Strategy]

Après discussion avec MenzAgitat je m'apercoit t'avoir dit une bétise meme si c'est vrai que les clonneurs ne répondent pas au ctcp version (du moins très rarement)

explication: interroger si un client répond ou pas au ctcp version est impossible et cela pour la simple raison que si le client lag et si le clonneur ne répond pas au pings en plus ce serrait simplement impossible a savoir.

Un exemple:
Si le timer dure 10 secondes et que le client a un lag de 20 secondes il serra banni parce qu’il aura pas répondu au ctcp (Faux positif)
Ce problème est contourné en créant le callback a partir de la réponse ping

Mais un autre problème ce créer si le client ne répond ni au pings ni au ctcp alors le script serra inefficace

Autre solution gérer un temps de timeout a la connexion mais cela est encore une impasse car les IRCd gèrent déjà ca
du coup interroger les ctcp ne fonctionnera jamais

[aliasangelius]

Sinon, un tcl de mass join, ou un truc du genre qui met une limite sur salon (mode +l)