• 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.
  

• C'est l'abréviation de Progressive Access System.

• 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).

• 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.

• Un accès restreint interdit l'utilisation des commandes qui demandent un nombre de points d'accès supérieur à 0.

• 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.

• 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.

• 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é.

• 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.

• 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.

• 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é.

• 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 !
  

Citation :v0.99 RC1

• release candidate
  

v1.0

• 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.01

• 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.02

• 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.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 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.04

• 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.05

• 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é.
  

v1.1

• 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.
  

Citation :v1.0

• 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.

Citation :v1.01

• 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à.

Citation :v1.02

• 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.

Citation :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 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.

Citation :v1.04

• 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.

# Autorisations requises pour consulter son propre accès :
variable getownaccess_auth "-|-"

# Commande et autorisations requises pour demander à PrAcSys de protéger
# une commande :
variable protectcmd_auth "nm|nm"

Citation :v1.05

• 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é.