[Script] Interviews
#1
Voici mon dernier petit script: Interviews
Description a écrit :Interviews
Ce script permet de gérer une interview en utilisant un canal de modération (rédaction).
Lorsqu'une interview est lancée sur un canal, celui-ci devient modéré (+m) et les utilisateurs posent leurs question à l'eggdrop en privé.
Dans le canal de modération, les questions sont affichées une par une, après acceptation ou refus de la précédente.
A la fin de l'interview, un fichier de log est généré.
Commandes de modération
  • .itw (ou !itw) : affichage de l'aide
  • .itstart [nick] : Démarre l'interview avec nick comme invité. Si aucun invité n'est déclaré, c'est le modérateur (qui lance l'interview) qui devient aussi l'invité
  • .itstop : Termine l'interview
  • .yes : Accepte une question
  • .no : Refuse une question
Sécurité
La sécurité est très faible sur ce script, c'est au modérateur de gérer le canal de rédaction.

To Do
  • Améliorer la gestion automatique de la sécurité
  • Gérer les intervenants par la userlist de l'eggdrop
  • Version multilingue
  • Création d'un système de réservation / annonce

N'hésitez pas à le tester et me faire vos commentaires et suggestions.

Interviews 1.0
  Répondre   Avertir
#2
Salut CrazyCat,

Quelques améliorations qui pourraient être sympa :

Activé une interview par un modérateur sur salon et non dans le tcl si plusieurs interviews doivent être sur des chans différents faudrait modifier le tcl c'est chiant.

Ensuite autre chose lors d'une interview si le bot et op il devrait devoiceall pour le mode +m sa serait bien aussi.
Et aussi mettre un temps pour l'interview genre : .inter 60 ce qui aura pour effet d'avoir une interview de 60 minutes en unixtime.
Et lorsqu'il restera par exemple 5 minutes avant la fin des 60 minutes le bot annoncera plus que 5 minutes et possibilité à un modérateur de faire durant c'est 5 dernières minutes : .rajout 10 qui ajoutera 10 minutes de plus au temps additionnels.

Et lorsque tout le temps sera écoulé le bot stoppera l'interview.
  Répondre   Avertir
#3
Je réponds vite fait, point par point:
alias_angelius a écrit :Activé une interview par un modérateur sur salon et non dans le tcl si plusieurs interviews doivent être sur des chans différents faudrait modifier le tcl c'est chiant.
Vu le fonctionnement du script, c'est forcément mono-canal, les questions étant passées en /msg. Donc, ça ne sera pas.
alias_angelius a écrit :Ensuite autre chose lors d'une interview si le bot et op il devrait devoiceall pour le mode +m sa serait bien aussi.
Oui, j'ai faillit le faire dans cette release, et je ne l'ai pas fait. Ce sera surement intégré à la prochaine version.
alias_angelius a écrit :Et aussi mettre un temps pour l'interview genre : .inter 60 ce qui aura pour effet d'avoir une interview de 60 minutes en unixtime.
Et lorsqu'il restera par exemple 5 minutes avant la fin des 60 minutes le bot annoncera plus que 5 minutes et possibilité à un modérateur de faire durant c'est 5 dernières minutes : .rajout 10 qui ajoutera 10 minutes de plus au temps additionnels.
Et lorsque tout le temps sera écoulé le bot stoppera l'interview.
Non, pour deux raisons:
- on impose jamais ce genre de choses IRL,
- c'est à l'interviewé ou au modérateur de gérer le temps de discussion, en fonction de leurs contraintes.
Par contre, il peut être intéressant dans la partie "gestion de réservation" de prévoir une durée estimée et un calcul de marge pour empécher d'avoir des interviews qui se chevaucheraient.
  Répondre   Avertir
#4
Tu comptes m'interviewer CrazyCat ?

Alors qqles idées, parce que j'ai déjà vécu/géré des grosses itw* sur IRC:

- Le mode +u sur le salon de l'itw, ça évite de voir les joins/parts qui peuvent gêné la lecture de l'itw.
- un canal pour l'invité où il écrirait ces réponses qui seraient relayer par un egg (qui aurait le nom de l'invité, bloqué en bind msg/ctcp/invites/notice), ça évite à l'invité d'être floodé directement par des questions, on connait pas son pseudo, donc pas de /whois, /query possible sur l'invité.
La question validé (sur le canal rédaction) devra être retransmise sur les deux autres canal (canal itw et le canal ou est l'invité).
- un système léger de badwords qui filtre les questions, gains de temps pour les modérateurs.
- Un ignore de x minutes/secondes sur la personne qui aura posé une question ou le droit à un nombre limité de question pendant la durée de l'itw, ça évite le flood de questions par une même personne (sans parler du flood tout court en msg).

J'ai pas regardé le code:
- Quand la question est validé, le pseudo du posteur est-il affiché? (dans le cas ou la question validé est retransmise sur le salon par l'egg avant la réponse).

C'est tout pour le moment Very Happy

*interview
  Répondre   Avertir
#5
BdS a écrit :Tu comptes m'interviewer CrazyCat ?
Idée qui pourrait être à retenir en effet.
BdS a écrit :- Le mode +u sur le salon de l'itw, ça évite de voir les joins/parts qui peuvent gêné la lecture de l'itw.
Oui, pas bête du tout. Mais en option (comme le +N) car il ne fonctionne pas partout.
BdS a écrit :- un canal pour l'invité où il écrirait ces réponses qui seraient relayer par un egg (qui aurait le nom de l'invité, bloqué en bind msg/ctcp/invites/notice), ça évite à l'invité d'être floodé directement par des questions, on connait pas son pseudo, donc pas de /whois, /query possible sur l'invité.
La question validé (sur le canal rédaction) devra être retransmise sur les deux autres canal (canal itw et le canal ou est l'invité).
J'ai fait le système en me basant sur le fait que l'invité serait en mode +D (un mode qui bloque tous les PV), mais oui un système alternatif de protection de l'invité grâce à l'eggdrop serait pas mal.
BdS a écrit :- un système léger de badwords qui filtre les questions, gains de temps pour les modérateurs.
Non, il y a déjà un nombre minimum de caractères que doit contenir une question, je pense que trop de protections nuiraient.
BdS a écrit :- Un ignore de x minutes/secondes sur la personne qui aura posé une question ou le droit à un nombre limité de question pendant la durée de l'itw, ça évite le flood de questions par une même personne (sans parler du flood tout court en msg).
Oui, un ignore (en avertissant l'utilisateur), pas bête.

BdS a écrit :- Quand la question est validé, le pseudo du posteur est-il affiché? (dans le cas ou la question validé est retransmise sur le salon par l'egg avant la réponse).
Oui, bien entendu, pour qui tu me prends ? Smile
  Répondre   Avertir
#6
Nouvelle version : Interviews 1.1
Modifications
  • Ajout de la gestion du mode Auditorium (+u). L'eggdrop doit être propriétaire du canal pour pouvoir appliquer ce mode.
  • Passage en multilangues. Ajout de la commande .itwlng pour changer de langue
  Répondre   Avertir
#7
Bonjour,
En utilisant le script, j'ai remarquer un bug : au bout d'un moment il fini par figé (ne réagit pas aux commandes .yes et .no) et l'on est obligé de relancer l'interview (.itstop puis .itstart) pour que ça refonctionne normalement ... pendant quelques minutes.
  Répondre   Avertir
#8
Bonjour,

Peut-être est-ce un souci d'occupation mémoire, peux tu me dire (grosso modo) combien de questions il y avait déjà eu, combien étaient en queue, ... ? Bref, toutes les informations utiles sur l'utilisation du script. Voir même les fichiers logs (de l'eggdrop et/ou de ton client, concernant le canal principal et le canal de modération) ?
  Répondre   Avertir
#9
Bonjour,
Lors du premier plantage, il y avais déjà eu une dizaine de questions de poster (ça faisait environ 15 minutes que l'interview était lancer) et lors du 2ème plantage, seulement 4 questions avais été posés.

Concernant les fichiers de logs, j'avais déjà regarder avant de poster ici, il n'y a rien de spécial (pas d'erreurs, rien).
  Répondre   Avertir
#10
Bizarre, je vais tester, mais sur mon eggdrop, ce script a résisté à bien plus.
Je vais essayer de faire une mise en situation à grande échelle pour voir ça.
  Répondre   Avertir
#11
Hello, voici un bug survenu après l'installation :

Lors du rehash :
11:38:47] <Interview> [11:38:43] Rehashing ...
11:38:47] <Interview> [11:38:43] Tcl error [::itw::deinit]: wrong # args: should be "::itw::deinit"

Et lors de la commande !quest en privé :
11:51:58] <Interview> [11:51:54] Tcl error [::itw::newquest]: missing "
  Répondre   Avertir
#12
Une correction a été faite sur le script (maintenant en version 1.11), suite au souci de spown et à l'intervention de MenzAgitat.

Pour la petite info, à une époque j'avais modifié la procédure deinit pour qu'elle détruise tout ses contenus, et en la modifiant j'ai viré un passage d'argument. Or, lorsqu'elle est appelée par un bind event (ce qui est le cas principal), elle reçoit un argument (le type d'event). Donc, correction de deux lignes et voila.
  Répondre   Avertir


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)