Detobel36

Créateur de plugins (PhoenixRebirth)
Support
17 Août 2012
10 530
24
2 247
347
27
Bruxelles - Belgique
www.phoenix-rebirth.fr
Salut,

J'ai remarqué (après 1000 messages ;) ) que pas mal d'admin ne savaient pas bien (voir pas du tout) configurer un plugin de permission. J'ai donc décidé de faire un petit tuto sur le plugin GroupManager, même si ce n'est pas mon plugin de permissions Favori.

Juste avant de commencer ce tutoriel, je m'excuse pour mes futures fautes d'orthographes ;) (je suis meilleur en math qu'en français xD).


Info sur le Tutoriel :
Je vous prévient tout de suite: je n'utiliserais pas les globalgroups. Si vous désirez en savoir plus, je vous renvoie sur le wiki de GroupManager. Pour configurer vos plugins, je vous recommande Notpad++. Le langage yml (langage utilisé pour configurer les plugins) est assez exigent au niveau des espaces et plus particulièrement des tabulations. En effet, vous ne pouvez pas mettre de tabulation dans votre fichier de configuration. Les accents ne sont pas pris en compte par le plugin. Leurs utilisation rendra votre configuration illisible pour le plugin et donc, celui ci ne fonctionnera pas.

Sommaire:
  1. GroupManager, qu'est ce que c'est ?
  2. Installation
  3. Configuration des permissions
  4. Mettre les joueurs dans le bon groupe
  5. Configuration du fichier config.yml
  6. Le mot de la fin
1. GroupManager, qu'est ce que c'est :
GroupManager fait donc partie de ces nombreux plugins dit "plugins de permissions". Il permet de créer des groupes, des rangs et de leurs attribuer des permissions. 90% des plugins on un système de permissions.
GroupManager est un plugin de permissions un peu spécial. Il a sur tout été conçus pour les serveur ayant différentes map. En effet, GroupManager vous permettra très facilement de donner une permission dans un monde et pas dans un autre. Il vous permettra aussi de créer des groupes différent en fonction des mondes.
Mais vous pouvez très bien faire en sorte de garder les mêmes groupes et les mêmes permissions dans tout les mondes ;)

2. Installation:
Pour installer GroupManager (de son nom complet: EssentialsGroupManager), il vous suffit de le télécharger et de le placer dans votre dossier plugins. Pour le télécharger, rendez vous ici ou cliquez directement ici.
Vous aurez peux être aussi besoin de EssentialsAntiBuild, mais je vous en reparlerais plus tard.
Une fois les plugins téléchargé, il vous suffit de les placer dans votre dossier plugins et de redémarrer votre serveur (un /reload marche aussi mais je vous le déconseil...).
Une fois le redémarrage effectué, un nouveau dossier (GroupManager) sera apparu (toujours dans le dossier plugins).

3. Configuration des permissions:
Nous voici dans le vif du sujet. Nous allons donc travailler sur le fichier groups.yml qui se trouve dans plugins/groupmanager/worlds/nom de votre monde
Voici la configuration minimum qu'il faut pour que le plugin fonctionne:
Code:
groups:
  Default:
    default: true
    permissions:
    - essentials.help
    - essentials.list
    - essentials.motd
    - essentials.rules
    info:
      prefix: '&5'
      build: true
      suffix: ''
  Admin:
    default: false
    permissions:
    - '*'
    inheritance:
    - default
    info:
      prefix: '&4'
      build: true
      suffix: ''
Regardons cela de plus près... Mais avant cela, je voudrais vous rappeler qu'il est interdit de mettre de tabulation dans un fichier .yml.
Bien, on voit que le fichier est divisé en 2 parties: Default et Admin.
Chacune de ces parties est divisé de la même façon:
Code:
default:
permissions:
inheritance:
info:
Explication:
  • default: cette "option" vous permet de définir si le groupe est le groupe par défaut. Donc, si vous mettez "true" (vrai) le plugin va automatiquement mettre les nouveaux joueur dans ce groupe. Attention: il faut qu'il y ai un groupe qui ai cette option. Un ! pas plus, pas moins...
  • permissions: c'est dans cette partie que vous allez écrire les permissions que vous voulez donner au groupe. La, vous allez me dire: "ok, mais je les trouve où tes permissions ?". Et bien chaque plugin à ses propres permissions. Voici quelques lien: permissions de GroupManager, Essentials, WorldEdit et WorldGuard.
    Vous cherchez donc la permission que vous voulez donner à un groupe et vous la mettez dans la partie permissions comme ceci:
    Code:
        permissions:
        - essentials.help
        - permissions.exemple
    Vous remarquerez qu'il y a 4 espaces devant "permissions" et 4 espaces également devant la permission.
    Attention: il faut bien mettre 4 espaces et non pas des tabulations.
    En vous baladant dans les permissions de Essentials vous allez tomber sur des permissions dans ce genre la:
    Code:
    essentials.warps.*
    Et la:
    noob a dit:
    Qu'est ce que c'est ce machin la *
    On appel ça une super permissions... Si vous êtes un petit peu curieux, vous avez peut remarqué que la permissions pour se tp à un warp est:
    Code:
    essentials.warps.<nom du warp>
    Donc cela veux dire qu'il y a autant de permissions qu'il y a de warps... Sauf que si vous avez 300 warps comme sur mon serveur, vous aurez 300 permissions... :confused:
    C'est pourquoi les super permissions existent. L'étoile * remplace toutes les possibilités. On pourrait écrire: * = tout. Et donc vous comprenez pourquoi dans le groupe/rang Admin on à mis '*' (remarque: ne me demandez pas pourquoi on à mis des apostrophes, c'est comme ça... c'est le plugin qui veux cela).
    noob a dit:
    Oui mais moi je veux interdire une permission. On peut faire cela ?
    Oui, il suffit de mettre 2 tirets, comme ceci:
    Code:
        permissions:
        - essentials.warp.*
        - -essentials.warp.admin
    Ici, j'ai autorisé à faire la commande /warp <le nom du warp> sauf pour le warp portant le nom "admin".
  • inheritance: peux de personnes savent à quoi sert vraiment cette partie. C'est dans cette partie que vous écrirez les "options" de superglobal, mais nous n'allons pas nous y intéresser. Cette partie sert surtout à hiérarchiser vos groupes. On va dire au plugin ce groupe la à moins d'importance que ce groupe ci... Le nom de groupe que l'on va mettre dans inheritance est le groupe inférieur a celui ci. C'est un peu flou pour vous ?
    Pas de problème, je vais prendre un exemple et vous allez comprendre.
    Prenons 3 groupes: visiteur, membre et admin.
    Il n'y a pas de groupe "plus petit" que visiteur (c'est ce groupe qui aura l'option default sur true). Donc cela ne sert à rien d'écrire l'inheritance. On peux supprimer cette "option".
    Membre est "au dessus" de visiteur. L'inheritance de membre serra donc visiteur. Nous allons donc écrire:
    Code:
        inheritance:
        - visiteur
    Et dans l'inheritance du groupe admin, nous allons écrire:
    Code:
        inheritance:
        - membre
    Et la:
    noob a dit:
    Ok, mais ça sert à quoi de hiérarchiser ses groupes ?
    Et bien cela va vous évitez d'écrire plusieurs fois les mêmes permissions (et donc rendre votre fichier de configuration beaucoup plus simple à lire). Imaginons que je mette la permissions
    Code:
    essentials.suicide
    Au groupe visiteur et que j'ai précisé les inheritances. Et bien le groupe membre aura automatiquement cette permission, je ne serrais pas obligé de la préciser.
  • info: Cette partie est elle même divisé en plusieurs sous partie:
    Code:
        info:
          prefix: '&2'
          build: true
          suffix: ''
    prefix vous permet de définir le préfixe que le groupe aura.
    noob a dit:
    C'est quoi ça: &2 ? Ça veux dire quoi ?
    Il y a un code couleur intégré à Minecraft (où a Bukkit, je sais plus...). Ce code couleur utilise le symbole "&". Pour avoir la liste des codes couleurs, allez faire un tour ici.
    Vient ensuite build. Cette "option" vous permet de dire si un groupe peux construire ou non. Pour que cette "option" fonctionne, il vous faut le plugin EssentialsAntiBuild. J'en profite pour vous donner un lien de toutes les permissions de ce plugins: ici.
    Et enfin, il y a suffix. Cette "option" vous permet, de définir le suffix qu'aura le groupe (à l'inverse de prefix).
Avant de vous détaillé tout cela, je vous parlais du fait que le fichier était découpé en plusieurs "partie". Et bien chaque partie défini un groupe/rang. Vous pouvez rajouter autant de partie que vous voulez, mais vous devez mettre toutes les "options" que nous avons vu ici au dessus (sauf pour "inheritance" que vous ne devez écrire que si vous écrivez quelque chose dans cette "option").

4. Mettre les joueurs dans les bons groupes
Et donc, tout naturellement:
noob a dit:
Et quand j'ai créé tout mes groupes, tout le monde est dans le groupes par défaut... Comment je fait ?
Vous pouvez mettre chaque joueur dans le bon groupe manuellement, mais vous prenez plus de risque de faire une erreur (d'espacement par exemple). Je vous conseil donc d'utiliser les commandes que le plugin vous proposes. Vous trouverez la liste complète ici.
Et concrètement, vous devez taper la commande:
Code:
/manuadd <pseudo> <groupe>

5. Configuration du fichier config.yml:
Donc, nous allons nous intéresser au fichier config.yml qui se trouve dans le dossier GroupManager.
Vous devriez avoir quelques choses comme ceci:
Code:
settings:
  config:
    # With this enabled anyone set as op has full permissions when managing GroupManager
    # The user will be able to promote players to the same group or even above.
    opOverrides: true
 
    # Default setting for 'mantoglevalidate'
    # true will cause GroupManager to attempt name matching by default.
    validate_toggle: true
    # **********************************************************************************************************************************
    # *** NOTE: Having this feature enabled, improper use of commandblocks will lead to undesireable permission changes, be alarmed! ***
    # **********************************************************************************************************************************
    allow_commandblocks: false
 
  data:
    save:
      # How often GroupManager will save it's data back to groups and users.yml
      minutes: 10
      # Number of hours to retain backups (plugins/GroupManager/backup)
      hours: 24
 
  logging:
    # level of detail GroupManager will use when logging.
    # Acceptable entries are - ALL,CONFIG,FINE,FINER,FINEST,INFO,OFF,SEVERE,WARNING
    level: INFO
 
  mirrors:
        # Worlds listed here have their settings mirrored in their children.
        # The first element 'world' is the main worlds name
        # subsequent elements 'world_nether' and 'world_the_end' are worlds which will use
        # the same user/groups files as the parent.
        # Each child world can be configured to mirror the 'groups', 'users' or both files from it's parent.
        world:
          world_nether:
          - users
          - groups
          world_the_end:
          - users
          - groups
    # world2: (World2 would have it's own set of user and groups files)
    # world3:
    # - users (World3 would use the users.yml from world2, but it's own groups.yml)
    # world4:
    # - groups (World4 would use the groups.yml from world2, but it's own users.yml)
    # world5:
    # - world6 (this would cause world6 to mirror both files from world5)
Nous n'allons pas détailler tout ce fichier car il y a très peu de choses à modifier.
Il n'y a rien à modifier dans la partie config. Vient ensuite la partie data. Dans cette partie, vous pourrez configurer le moment où le plugin doit faire un backup de ses fichiers (il va sauvegarder les fichier groups.yml et users.yml et il va les mettre dans le dossier backup qui se trouve dans le dossier GroupManager).
Pas besoin de s'intéresser à la partie logging.
Et nous arrivons à la partie mirrors. C'est la partie la plus intéressante de ce fichier. Elle vous permet de dire: les groupes du monde 1 doivent être les mêmes dans le monde 2. En effet, vous n'êtes pas obligé de copier/coller votre fichier groups.yml dans chaque dossier présent dans le dossier worlds.
Nous allons prendre un exemple. J'ai 3 mondes: world, world_pvp, world_freebuild. Je veux que les mêmes groupes dans le monde world et world_pvp mais je veux aussi que les joueurs soit dans leur groupe (et non pas dans le groupe par défaut).
Je vais donc écrire:
Code:
      world:
          world_pvp:
          - users
          - groups
Maintenant, dans le monde world_freebuild, je ne veux pas que les joueurs puisse faire /tpa. Je vais donc modifier le fichier groups.yml. Mais je veux que les joueurs soit toujours dans le même groupe. Cela va donner:
Code:
      world:
          world_pvp:
          - users
          - groups
          world_freebuild:
          - users
Vous pouvez évidement faire en sorte que les joueurs soient dans un autre groupe lorsqu'ils changent de monde. Je ne crois pas que je doit vous mettre d'exemple ;)

Le mot de la fin
Je terminerais se tuto en vous donnant quelques liens:
Le wiki de GroupManager
Tuto de VeryGames où vous pourrez trouver des configurations d'exemple.
Si vous avez des questions, où des remarques à faire sur ce tuto, n'hésitez pas à posté un message...


Cordialement,
Detobel36



PS: un j'aime fait toujours plaisir ;)
 
Dernière édition:

Edwins

Codeur java
10 Avril 2012
485
124
100
Super tuto Detobel,
détailler et bien expliquer.
Par contre tu n'aborde pas un raccourcis drôlement pratique : le globalgroups.yml

Bien à toi
Edwins
 

Detobel36

Créateur de plugins (PhoenixRebirth)
Support
17 Août 2012
10 530
24
2 247
347
27
Bruxelles - Belgique
www.phoenix-rebirth.fr
Salut,

Merci pour ton commentaire Edwins ;)
Par contre tu n'aborde pas un raccourcis drôlement pratique : le globalgroups.yml
C'est fait exprès ;)
Pour 3 raisons:
1. Je ne l'utilise pas xD
2. Je trouve qu'il n'a d'utiliser que si l'on fait beaucoup de map ayant des permissions différentes... Les personnes qui font cela ont (la plus part du temps) une certaine expériences dans les permissions.
3. Je n'avais pas envie de compliquer le tuto avec quelques choses que je trouve (c'est un avis personnel) ne sert a pas grand chose...


Cordialement,
Detobel36