21/11/2013, 21:37
(Modification du message : 03/04/2015, 12:09 par MenzAgitat.)
Introduction :
Pour plus de facilité et de concision, nous appellerons ce script PrAcSys.
PrAcSys est un concept original pour gérer les accès de vos utilisateurs d'une façon totalement différente.
Il vous permet, entre autres choses, de contrôler qui a le droit ou non d'utiliser telle ou telle commande, et ce d'une façon beaucoup plus précise qu'en ne comptant que sur les seuls flags habituels que connaît Eggdrop.
PrAcSys introduit 4 nouveaux types d'accès afin de répondre aux besoins des plus exigeants : évolutif, statique, restreint et paria.
Vous pourrez par exemple grâce à l'accès évolutif, récompenser l'assiduité des utilisateurs et optionnellement pénaliser leur trop long absentéisme, en leur faisant respectivement gagner ou perdre des points d'accès. Ces points d'accès déterminent les commandes qu'ils pourront utiliser.
Vous pourrez grâce à PrAcSys, protéger les commandes et binds de votre Eggdrop en leur attribuant un niveau, niveau qui déterminera le nombre de points d'accès requis pour les utiliser.
Vous pourrez même empêcher un utilisateur d'utiliser la moindre commande grâce à l'accès paria, ou encore rendre des commandes "payantes" en points d'accès, si c'est ce que vous souhaitez.
Vous pourrez en outre laisser des commentaires sur vos utilisateurs, qui seront consultables par ceux que vous aurez choisi d'autoriser, les admins par exemple.
Vous pourrez ainsi expliquer pourquoi tel utilisateur s'est retrouvé avec un accès paria, afin d'une part de vous en souvenir par la suite, et d'autre part de permettre à d'autres personnes d'en connaître la raison.
PrAcSys est une aide à la gestion des accès et ne prétend en aucun cas l'automatiser entièrement. Il vous faudra par exemple veiller à ce que les hosts associés aux handles soient pertinents et en ajouter manuellement si nécessaire, grâce aux commandes de partyline.
Fonctionnalités :
- Ajoute 4 nouveaux types d'accès : évolutif, statique, restreint et paria.
- Possibilité d'associer des flags supplémentaires aux 4 nouveaux types d'accès afin par exemple de voicer automatiquement les accès évolutifs, d'empêcher les parias d'être opés/halfopés à l'avenir, etc...
- Contrôle des autorisations sur les commandes et les binds de l'Eggdrop de façon très précise et nuancée, en leur attribuant à tous un niveau.
- Possibilité d'attribuer un coût en points d'accès aux commandes et binds, donc de les rendre "payants" ou même rémunérateurs si le coût est négatif.
- Peut interdire totalement à certains utilisateurs d'utiliser la moindre commande, en leur laissant ou non la possibilité de se racheter par leur présence.
- Peut récompenser l'assiduité des utilisateurs en leur donnant plus de pouvoirs au fil du temps.
- Peut pénaliser le trop long absentéisme des utilisateurs en leur faisant perdre des pouvoirs au fil du temps.
- Les utilisateurs peuvent connaître leur type d'accès et leur nombre de points d'accès à tout moment.
- Laisser des commentaires sur les utilisateurs pour faciliter le partage de l'information entre administrateurs.
- Archivage automatique des commentaires des utilisateurs dont le handle est supprimé.
- Peut automatiquement informer les personnes de votre choix lorsqu'un commentaire est ajouté, qu'un accès est modifié, et lors de quantité d'autres actions.
- Des alias de commandes vous permettent de simplifier certaines actions.
- Interface de communication permettant à d'autres scripts d'interagir avec les accès des utilisateurs, de modifier le nombre de leurs points d'accès, d'en connaître le nombre, ou encore d'ajouter des commentaires sur eux.
- Mode "économe" pour l'écriture des bases de données, pour ceux d'entre vous qui ont des quotas limités.
- Création quotidienne d'une copie de sauvegarde des bases de données.
- Restauration automatique d'une copie de sauvegarde si une base de donnée est perdue ou gravement endommagée.
- Désinstallation facile et propre du script.
- Nombreux paramètres de configuration.
Terminologie : qu'est-ce que... :
PrAcSys
- C'est l'abréviation de Progressive Access System.
Accès évolutif
- Un utilisateur possédant un accès évolutif gagnera automatiquement des points d'accès en fonction de la régularité de sa présence sur le chan concerné, lui donnant ainsi le droit d'utiliser plus de commandes au fil du temps.
Il pourra aussi perdre des points d'accès lorsqu'il sera absent pendant trop longtemps (optionnel).
Accès statique
- Les points d'accès d'un accès statique n'augmentent pas automatiquement.
Ce type d'accès donne droit aux commandes d'un niveau inférieur ou égal aux points d'accès de l'utilisateur.
Accès restreint
- Un accès restreint interdit l'utilisation des commandes qui demandent un nombre de points d'accès supérieur à 0.
Accès paria
- Un accès paria a un rôle punitif.
Quelqu'un possédant un tel accès ne pourra utiliser aucune commande dont le niveau d'accès est supérieur ou égal à 0, c'est à dire techniquement aucune commande que vous aurez choisi de protéger.
Accès passe-droit
- Quelqu'un possédant ce type d'accès peut utiliser toutes les commandes quel que soit le nombre de points d'accès requis.
Points d'accès
- Les points d'accès sont gagnés automatiquement pour les accès évolutifs, ou manuellement pour les accès statiques.
Leur nombre détermine quelles commandes un utilisateur pourra utiliser.
Un utilisateur possédant un accès évolutif voit son compte de points d'accès augmenter de jour en jour s'il fait acte de présence : il gagne un point de présence chaque minute en étant connecté, et en perd 0.5 chaque minute en ne l'étant pas.
Pour gagner un point d'accès, il devra par défaut atteindre 60 points de présence.
Il n'est possible de gagner un point d'accès par ce moyen qu'une fois toutes les 24h.
Les points d'accès ne sont pas nécessairement une valeur entière, ils peuvent être un nombre décimal.
Un utilisateur peut avoir un nombre négatif de points d'accès, auquel cas il ne pourra utiliser aucune commande.
Un accès évolutif possédant un nombre négatif de points d'accès augmentera normalement à raison d'un point par jour de présence s'il fait preuve de suffisamment d'assiduité, et l'utilisateur pourra à nouveau utiliser normalement les commandes lorsque ce nombre de points atteindra 0.
C'est l'équivalent d'un accès paria qui expirerait après un temps donné.
Points de présence
- Les points de présence permettent d'avoir une représentation de l'assiduité des utilisateurs ayant un accès évolutif, pour savoir s'ils méritent de gagner un point d'accès supplémentaire.
Il s'agit en quelque sorte de l'uptime d'un utilisateur, mais d'un uptime un peu particulier puisqu'il peut aussi décroître.
Si un utilisateur a gagné son dernier point d'accès depuis plus de 24h, il gagne un point de présence chaque minute tant qu'il se trouve sur le chan, et en perd 0.5 toutes les minutes lorsqu'il ne s'y trouve pas (sans pouvoir descendre en dessous de 0).
Lorsqu'un utilisateur cumule suffisamment de points de présence, il gagne un point d'accès supplémentaire.
Niveau d'une commande (ou d'un bind)
- Chaque commande publique ou privée ainsi que la plupart des binds de votre Eggdrop, peuvent être protégés par PrAcSys et un niveau d'accès peut leur être attribué.
Ce niveau représente le nombre de points d'accès qu'un utilisateur doit posséder afin d'utiliser la commande ou de déclencher le bind.
Protéger une commande au niveau 0 permettra à n'importe quel utilisateur même inconnu de l'utiliser, mais pas à un accès paria.
Par exemple, définir la commande !meteo au niveau 5 empêchera tout utilisateur n'ayant pas au moins un accès évolutif ou statique, et au moins 5 points d'accès de l'utiliser.
Coût d'une commande (ou d'un bind)
- Vous pouvez aussi attribuer un coût d'utilisation aux commandes et binds en nombre de points d'accès.
Lorsqu'un utilisateur ayant un accès évolutif utilise une commande ou déclenche un bind dont le coût est différent de 0, le nombre de ses points d'accès sera débité du montant indiqué.
Le coût peut être un nombre décimal positif ou négatif.
Si le coût est négatif, l'utilisateur gagnera des point d'accès au lieu d'en perdre.
Seul un accès évolutif est affecté par le coût des commandes et binds.
Si un coût est attribué à une commande ou un bind qui n'est pas lié à un chan (dans le cas d'une commande par message privé par exemple), le coût sera répercuté sur tous les chans sur lesquels l'utilisateur se trouve et où PrAcSys est activé.
Installation, activation et mise en service :
- Mettez le fichier Progressive_Access_System.tcl dans le répertoire scripts/ de votre Eggdrop.
- Mettez le répertoire progressive_access_system/ et tout ce qu'il contient dans le répertoire scripts/ de votre Eggdrop afin d'avoir la structure suivante : scripts/progressive_access_system/
- Paramétrez le fichier progressive_access_system/Progressive_Access_System.cfg à votre convenance.
- Ajoutez la ligne suivante dans le fichier eggdrop.conf, après le chargement de tous les autres scripts :
source scripts/Progressive_Access_System.tcl
Remarque importante : il est nécessaire de charger PrAcSys en dernier afin qu'il puisse prendre le contrôle des autres scripts.
- Redémarrez (ou rehashez) votre Eggdrop.
- Utilisez la commande de partyline suivante pour activer PrAcSys sur les chans que vous voulez :
.chanset #NomDuChan +PrAcSys
- Utilisez la commande !protectcmd pour protéger les commandes et binds que vous voulez.
- Utilisez la commande !setaccess pour définir les accès de vos utilisateurs.
- Jouissez tranquillement de la reconnaissance de vos utilisateurs pour avoir mis en place un système d'accès aussi génial sur votre chan !
Syntaxe des commandes :
Toutes les commandes se déclinent en 3 versions : publique, par message privé, et en partyline.
!access [nick ou handle]
access <nick ou handle> <chan>
.access <nick ou handle> <chan>
Affiche des informations sur l'accès d'un utilisateur.
Si l'utilisateur est connecté, le nick peut être spécifié plutôt que le handle.
---
!setaccess <nick ou handle> <paramètres>
setaccess <nick ou handle> <chan> <paramètres>
.setaccess <nick ou handle> <chan> <paramètres>
Modifie le statut de l'accès d'un utilisateur, ou le nombre de ses points d'accès.
L'ordre des paramètres n'est pas important et certains sont cumulables.
Si l'utilisateur est connecté, le nick peut être spécifié plutôt que le handle.
Les paramètres peuvent valoir :
+/-évolutif :
ajoute ou enlève un accès évolutif
+/-statique :
ajoute ou enlève un accès statique
+/-restreint :
ajoute ou enlève un accès restreint
+/-paria :
ajoute ou enlève un accès paria
[+/-]valeur :
ajoute ou enlève des points d'accès, ou définit le nombre de points d'accès si aucun opérateur arithmétique n'est spécifié.
-host xxx!xxx@xxxx.xxx :
permet de spécifier un masque de host qui sera utilisé si la création d'un handle est requise pour appliquer un accès.
Des variantes sont supportées pour les changements de statut.
Par exemple +évolutif équivaut à +evolutif, +e, +evolutive et +E, et -restreint équivaut à -restricted, -restrict et -r.
A vous de les découvrir toutes.
Les points d'accès peuvent être des nombres décimaux.
Exemples de syntaxe valide :
!setaccess machin évolutif -host machin*!*@123456ABC.fbx.proxad.net
!setaccess machin -P +30
!setaccess machin 10
Pour faciliter l'utilisation de la commande !setaccess, des alias sont disponibles. Reportez-vous à la configuration du script pour en prendre connaissance et les paramétrer à votre convenance.
---
!protectcmd <commande ou bind> [-d] [niveau] [$coût]
protectcmd <commande ou bind> [-d] [niveau] [$coût]
.protectcmd <commande ou bind> [-d] [niveau] [$coût]
Demande à Progressive Access System de prendre le contrôle de la commande ou du bind spécifié.
Voici les différents types de binds que PrAcSys peut protéger : pub, pubm, join, rejn, part, sign, splt, topc, kick, nick, mode, msg, msgm, dcc, ctcp et ctcr.
Le niveau déterminera qui peut utiliser la commande et doit être un nombre entier, positif ou négatif.
Le coût, qui doit être précédé d'un $, détermine le nombre de points d'accès que coûtera l'utilisation de la commande ou le déclenchement du bind.
S'il n'est pas spécifié, le coût sera par défaut de 0.
Le coût peut être un nombre décimal ou une valeur négative.
L'option -d sert à déprotéger la commande.
Pour afficher le niveau de protection actuel d'une commande ou son coût, ne précisez ni le niveau, ni le coût.
L'ordre des paramètres n'est pas important.
Exemples de syntaxe valide :
!protectcmd !meteo 5
!protectcmd !meteo
!protectcmd -d !meteo
!protectcmd {msg -|- meteo ::meteoscript::msg_meteo} 5
!protectcmd -d {msg -|- meteo ::meteoscript::msg_meteo}
!protectcmd !randomkick 5 $0.5
---
!rebind
rebind
.rebind
Demande à PrAcSys de reprendre le contrôle des commandes et binds qu'il doit protéger.
Cela peut s'avérer nécessaire si vous avez rechargé un script.
---
!comment <nick ou handle> [commentaire]
comment <nick ou handle> <chan> [commentaire]
.comment <nick ou handle> <chan> [commentaire]
Affiche les commentaires laissés sur un utilisateur ou en ajoute un.
Si l'utilisateur est connecté, le nick peut être spécifié plutôt que le handle.
!comment <nick ou handle> del <n° du commentaire>
comment <nick ou handle> <chan> del <n° du commentaire>
.comment <nick ou handle> <chan> del <n° du commentaire>
Efface le commentaire dont vous avez spécifié le numéro.
Si l'utilisateur est connecté, le nick peut être spécifié plutôt que le handle.
Syntaxe des commandes Tcl du protocole de communication inter-scripts :
::set_access <nom_du_script_appelant> <handle> <chan> <host> <modif_d_accès> [peut_produire_accès_<0]
Permet à d'autres scripts de modifier le type d'accès d'un utilisateur ou le nombre de ses points d'accès.
Aucun paramètre ne peut être vide sauf <host> dans certaines conditions.
<host> ne sera utilisé que pour la création d'un handle si nécessaire et peut être laissé vide si l'opération consiste en une modification du nombre de points d'accès.
<modif_d_accès> peut valoir +E -E +S -S +R -R +P -P ou un nombre précédé optionnellement de + ou - et sert à intervenir sur le type d'accès ou le nombre de points d'accès d'un utilisateur.
[peut_produire_accès_<0] peut valoir 0 ou 1.
Il vaut 1 par défaut s'il n'est pas spécifié.
Si ce paramètre vaut 0, l'application d'une modification de points d'accès ne pourra pas produire un nombre négatif et s'arrêtera à une valeur plancher de 0; si l'utilisateur possède déjà un accès négatif, aucun changement ne sera effectué.
La commande retourne 1 si l'opération s'est déroulée avec succès, ou 0 si elle a échoué.
---
::add_comment <nom_du_script_appelant> <handle> <chan> <commentaire>
Permet à d'autres scripts d'ajouter des commentaires sur les utilisateurs possédant un handle.
Aucun paramètre ne peut être vide.
Le handle doit déjà exister au préalable.
La commande retourne 1 si l'opération s'est déroulée avec succès, ou 0 si elle a échoué.
---
::get_access_pts <handle> <chan>
Permet à d'autres scripts d'interroger le nombre de points d'accès d'un utilisateur.
Aucun paramètre ne peut être vide.
La commande retourne le nombre de points d'accès, qui peut être un nombre décimal ou négatif, ou "-" si aucune entrée n'existe pour cet utilisateur dans la liste d'accès de PrAcSys.
Choses à savoir, questions qu'on se pose et autres paradoxes :
Un utilisateur ne se trouvant sur aucun chan sur lequel PrAcSys est activé, ne pourra pas déclencher un bind protégé par PrAcSys à un niveau supérieur à 0.
Il ne pourra par exemple pas utiliser une commande de niveau 1 par message privé .
Une commande ou un bind protégé par PrAcSys à un niveau supérieur à 0, ne pourra jamais être déclenché par un utilisateur n'ayant pas au moins un accès évolutif ou statique et un nombre de points d'accès au moins équivalent au niveau de protection.
Si un utilisateur se trouvant sur plusieurs chans gérés par PrAcSys tente d'utiliser une commande privée protégée, son niveau d'accès le plus petit sur tous ces chans sera pris en compte.
S'il a un accès paria ou restreint sur un de ces chans, sa capacité à utiliser les commandes privées s'en verra également affectée.
Lorsque vous comptez désinstaller un script dont une commande ou un bind est protégé par PrAcSys, pensez à d'abord enlever la protection avant.
Si vous ne le faites pas, PrAcSys vous signalera un problème en essayant de localiser le script manquant, et tentera de restaurer les binds d'origine de ce dernier lorsque vous en supprimerez la protection.
Le coût en points d'accès d'une commande ou d'un bind peut être négatif, ce qui aura pour effet d'ajouter des points au lieu d'en enlever.
Du code est injecté dans les commandes de partyline et fonctions suivantes, afin d'en lier le fonctionnement à PrAcSys : setuser delhost deluser .deluser .-user .+host .-host reload et .reload
La commande !setaccess utilise 4 flags personnalisés de l'Eggdrop pour représenter les 4 types d'accès, qu'elle définit toujours localement.
C'est à dire qu'attribuer un accès paria à un utilisateur lui mettra le flag +P sur le chan concerné seulement.
Mais savez-vous qu'il vous est également possible de définir ces flags globalement afin qu'ils prennent effet sur tous les chans à la fois ?
Il vous faudra néanmoins le faire manuellement, que ça soit pour mettre ou pour enlever ces flags globaux, car bien que PrAcSys le supporte, il ne propose pas de le faire avec ses commandes.
Reportez-vous à la documentation de la commande de partyline .chattr pour savoir comment faire.
PrAcSys se déclare en tant que package sous le nom "PrAcSys" afin que d'autres scripts puissent vérifier sa présence avant d'utiliser les fonctions d'interopérabilité ::set_access, ::get_access_pts et ::add_comment.
FAQ :
Q- Pourquoi ?
R- Pourquoi pas ?
Annexe Technique :
Structure de la base de données contenant les accès des utilisateurs :
handle_hash {H 1 #chan1 {C 2 AP 3 PP 4 LLT 5 LPC 6} #chan2 {....}}
1 = Handle de l'utilisateur
2 = Statut connecté / déconnecté, peut valoir 0 ou 1.
3 = Nombre de points d'accès
4 = Nombre de points de présence
5 = Date du dernier point d'accès gagné. Peut valoir 0 si aucun point n'a jamais été gagné.
6 = Contiendra d'abord la date de la dernière fois que l'utilisateur a été vu sur le chan, puis la date du dernier point d'accès perdu pour cause d'absentéisme.
---
Structure de la base de données contenant la table des binds protégés :
niveau_de_protection coût {bind modifié par PrAcSys} {bind d'origine}
---
Structure de la base de données contenant les commentaires sur les utilisateurs :
handle_hash {handle 1 #chan1 {{timestamp 2 author 3 comment 4} {...}} #chan2 {{...} {...}}}
1 = Handle de l'utilisateur
2 = Date à laquelle le commentaire a été laissé.
3 = Auteur du commentaire
4 = Commentaire
---
Structure de la base de données contenant les commentaires archivés sur des utilisateurs dont le handle a été supprimé :
handle_hash {handle 1 del_timestamp 2 del_author 3 #chan1 {{timestamp 4 author 5 comment 6} {...}} #chan2 {{...} {...}}}
1 = Handle de l'utilisateur
2 = Date à laquelle le handle a été supprimé.
3 = Responsable de la suppression du handle (peut être un handle ou le nom d'un script)
4 = Date à laquelle le commentaire a été laissé.
5 = Auteur du commentaire
6 = Commentaire
Changelog :
Citation :v0.99 RC1v1.0
- release candidate
v1.01
- Correction : il pouvait arriver qu'un utilisateur se retrouve avec un accès évolutif d'un niveau supérieur au maximum autorisé par le paramètre de configuration max_level si celui-ci possédait un nombre de points d'accès avec une décimale.
- Correction : utiliser !setaccess pour créer un accès à un nouvel utilisateur en définissant en même temps un compte de points d'accès (par exemple : !setaccess machin +e 10) avait pour effet de créer un nouveau handle sans aucun host associé.
- Correction : la vérification d'autorisation provoquait une erreur si un utilisateur possédant un accès sur un chan, utilisait une commande ou déclenchait un bind sur un autre chan où il ne possèdait pas d'accès.
- Ajout : nouveau paramètre de configuration show_rounded_axx_pts_for_users vous permettant de choisir d'arrondir ou non le nombre de points d'accès affichés par la commande !access pour les simples utilisateurs.
- Ajout : nouveaux paramètres de configuration presence_points_increase et presence_points_decrease afin de pouvoir paramétrer la quantité de points de présence gagnés par minute de présence et perdus par minute d'absence.
v1.02
- Correction : un bug faisait parfois passer le statut d'un utilisateur connecté en "non connecté" dans certaines conditions.
- Correction : un bug introduit dans la v1.0 empêchait le gain normal de points de présence si req_pres_pts > max_level.
- Correction : la commande !protectcmd n'affichait pas le coût des commandes et binds en tapant !protectcmd <commande/bind> sans autres arguments.
- Correction : utiliser la commande !protectcmd pour modifier seulement le niveau OU seulement le coût d'un bind réinitialisait l'autre valeur à 0.
- Correction : quelques bugs mineurs ça et là.
v1.03
- Correction : les commandes ou binds n'étant pas liés à un chan et ayant un niveau de protection >0 ne pouvaient pas être utilisés à cause d'une mauvaise détection du plus petit niveau d'accès d'un utilisateur.
v1.04
- Correction : les commandes ou binds n'étant pas liés à un chan et ayant un niveau de protection > à 0 ne pouvaient pas être utilisés par les accès passe-droit.
- Correction : utiliser une commande ou un bind "payant" ne relançait pas le compteur de points de présence tant que l'utilisateur restait sur le chan.
v1.05
- Correction : spécifier un chan invalide lors de l'utilisation de la commande "access" en partyline ou par message privé provoquait une erreur du script.
- Correction : un espace en trop avant ou après le nick lors de l'utilisation de la commande publique !access empêchait celle-ci de fonctionner correctement.
v1.1
- Correction : les points d'accès perdus pour cause d'absentéisme faisaient parfois descendre les accès en dessous de 0.
- Correction : les exemples d'utilisation inclus dans l'aide en ligne de la commande !setaccess indiquaient par erreur d'utiliser la commande !access.
- Correction : la commande !setaccess ne reconnaissait pas l'utilisateur si son nick était différent de son handle.
- Correction : en cas de modification manuelle du nombre de points d'accès, la date du dernier point d'accès gagné n'est plus réactualisée si l'accès a été diminué.
- Correction : en cas de modification manuelle du nombre de points d'accès, le compte de points de présence est remis à 0 si l'accès a été augmenté.
- Correction : en cas de paramètre invalide passé à la commande .setaccess tapée en partyline, les exemples d'utilisation donnés n'indiquaient pas la nécessité de spécifier un chan.
- Correction : en raison de l'imprécision de Tcl pour le calcul en virgule flottante, enlever par exemple 0.1 pt d'accès à un utilisateur ayant 0.8 pts d'accès le faisait passer à 0.7000000000000001
- Correction : après une modification manuelle des points d'accès d'un utilisateur connecté 24h/24 et ayant un accès évolutif, ceux-ci cessaient d'augmenter automatiquement toutes les 24h.
- Correction : si un utilisateur ayant un accès évolutif n'était pas reconnu par l'Eggdrop à cause d'un problème de host, puis qu'il était à nouveau reconnu suite à un ajout de host à son handle, il ne gagnait plus de points de présence ou d'accès jusqu'à son prochain quit / retour. Les accès seront désormais resynchronisés automatiquement en cas d'utilisation des fonctions et commandes setuser, delhost, .+host, .-host, reload et .reload
- Correction : la commande .comment refusait le nick d'un utilisateur connecté si son nick différait de son handle.
- Correction : créer un accès paria à un utilisateur avec .setaccess provoquait une erreur si celui-ci possédait déjà un handle et n'avait jamais eu aucun des 4 types d'accès spécifiques à PrAcSys avant.
- Correction : la commande !protectcmd fonctionnait mal dans certaines conditions et a été corrigé en de nombreux points.
- Correction : si le fichier de configuration n'était pas trouvé, le script tentait par erreur de supprimer un autre namespace que le sien (celui du script Public Quotes System)
- Ajout : ajout d'un nouveau paramètre de configuration cost_can_result_in_negative_axx_pts, permettant d'autoriser ou non le fait qu'une commande/bind ayant un coût de déclenchement puisse faire descendre le nombre de points d'accès de l'utilisateur en dessous de 0.
- Ajout : nouveau paramètre pour la commande ::set_access, permettant d'autoriser ou non l'application d'une modification de points d'accès à produire un nombre négatif.
- Modification : nouvelle option pour le paramètre de configuration inform_on_what afin de différencier une modification manuelle du nombre de points d'accès, d'une modification effectuée par un script externe.
- Modification : lors de la suppression d'un handle utilisateur, un message sera maintenant affiché (en partyline et dans les logs de l'Eggdrop) pour signaler que le profil de l'utilisateur et/ou ses commentaires ont été supprimés, voire archivés le cas échéant.
Téléchargement :
Progressive Access System v1.1
Vous pouvez trouver une liste de mes autres releases ici
Laissez vos commentaires / suggestions / rapports de bugs ici...
