Minecraft THGBM's World

Une meilleure gestion des commandes utilisateurs

Dans notre exemple l'action faites lors de la saisie '/salut' est gérée dans notre classe principale. Il serait peut être préférable de la 'ranger' ailleurs car pour l'instant on n'a qu'une commande mais que se passera t'il quand on en ajoutera ? Si on change rien la classe principale va s'alourdir et devenir de moins en moins lisible.

A mon goût (oui vous savez "les goûts et les couleurs"..) je préfère 'ranger' mes commandes dans un package séparé et je vais vous montrer une méthode pour se faire.

Créez le package 'net.thgbm.forum.Commands'

Vous devez créer le package 'net.thgbm.forum.Commands', si vous ne vous rappelez plus comment faire remontez en haut de ce tutoriel.

Créez dans ce package une classe par commande

Nous avons pour l'instant qu'une seule commande : salut.
Créez donc une nouvelle classe en faisant un clic droit sur le package 'net.thgbm.forum.Commands' puis 'New' -> 'Class'.
Pour notre exemple appelez cette classe 'SalutCommand'.

Dans cette classe on va retrouver la méthode utilisée dans la classe principale mais sera donc exécutée dans le SalutCommand, voici le code :

package net.thgbm.forum.Commands;

import org.bukkit.command.CommandExecutor;
import org.bukkit.command.CommandSender;
import org.bukkit.command.Command;
import org.bukkit.ChatColor;
import org.bukkit.entity.Player;

import net.thgbm.forum.Hello.Hello;


public class SalutCommand implements CommandExecutor {

    @SuppressWarnings("unused")
    private final Hello plugin;

    public SalutCommand(Hello plugin) {
        this.plugin = plugin;
    }
    
    
    @Override
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {

        if(label.equalsIgnoreCase("salut"))
        { 
            Player player = (Player)sender;
            player.sendMessage(ChatColor.DARK_AQUA + "Salut à toi encore une fois " + player.getName() );
            return true;
        }
        return false;
    }
    
    
}

Il faut implémenter CommandExecutor pour accéder on onCommand().
La méthode onCommand n'a pas beaucoup changée comme vous pouvez le constater sauf que je colore le texte envoyé au joueur grâce à la classe org.bukkit.ChatColor comme vous pouvez le constater dans la ligne :

player.sendMessage(ChatColor.DARK_AQUA + "Salut à toi encore une fois " + player.getName() );

Devinez quoi, ça sera écrit en bleu....

Modification sur la classe principale Hello

Il faut maintenant modifier notre classe principale pour envoyer la gestion de la commande /salut vers notre classe SalutCommand.

Commençons par ajouter nos imports :

import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;

import net.thgbm.forum.Commands.*;

Ensuite on supprime notre commande onCommand() et dans le onEnable() on va rediriger la gestion de la commande /salut vers notre SalutCommand :

// La commande /salut sera executée par net.thgbm.forum.Commands.SalutCommand
getCommand("salut").setExecutor(new SalutCommand(this));

Regénez votre .jar et ça devrait fonctionner.

Conclusion

Maintenant que notre commande est 'rangée' dans son package vous vous rendez compte que la classe principale reste claire et que la gestion de la commande nécessite peu de codes au final.
En mettant en place ce système lorsque vous souhaiterez ajouter de nouvelles commandes il ne vous restera qu'à :

• ajouter votre commande dans votre fichier plugin.yml

• ajouter dans le onEnable() de votre classe principale :
  

  getCommand("<VotreCommande>").setExecutor(new <VotreCommande>Command(this));

• créer votre classe <VotreCommande>Command dans le package Commands

• adaptez le code de la classe SalutCommand à vos besoins pour cette nouvelle classe

Le fichier plugin.yml indispensables références pour votre mod

Le fichier plugin.yml, comme son extension volontairement explicite l'indique, doit respecter le standard YAML.
Vous pouvez voir les références sur cette page si vous êtes curieux autrement sachez qu'il ne vous faudra pas longtemps pour vous créer le votre car le minimum d'informations requises est assez rapide à mettre en place.

ATTENTION
Bukkit server attend de votre part que vous lui fournissiez avec votre mod quelques informations indispensables à son goût et que le fichier porte obligatoirement ce nom sans quoi il refusera de le charger.

Dans les informations à lui fournir on retrouve :

• le nom de votre mod

• la classe de base

• l'auteur

• la version de développement de votre mod

Le YAML n'est pas balisé comme le html par exemple ou le bbcode mais est structuré d'une autre manière ou les sauts de ligne et espaces sont très importants et ont une signification précise. Ceci étant dis je précise également que selon les éditeurs de texte la tabulation ne se retranscrit pas de la même manière dans le fichier et est souvent cause de mauvaises interprétation du fichier .yml.
Donc si vous voulez vous éviter ce genre de soucis n'utilisez pas la tabulation mais faites plutôt des espaces du genre une tabulation = 2 espaces.

Si on prends notre exemple voici à quoi ressemblerait notre fichier plugin.yml avec le minimum d'informations :

name: Hello
main: net.thgbm.forum.Hello.Hello
version: 0.01
website: http://thgbm.net
authors: boozaa
description: >
    Mon premier plugin qui affiche un message quand je me connecte
    Qui me salue quand je lui demande
    Qui me dit quand je casse un block

La propriété 'name' permet de faire cohabiter aussi plusieurs commandes identiques partagées par plusieurs mods. Ceci étant tout de même à éviter mais sachez que si par exemple vous avez créé une commande '/home' et que cette commande est déja définie par un autre mod vous pouvez l'appeler en jeu par '/Hello:home' dans notre exemple <-- ceci étant à vérifier.

La propriété 'main' doit représenter le nom complet, package et nom de fichier inclut sans le '.java' ou le '.class', de la classe qui étends JavaPlugin.

La propriété 'version' est facile à comprendre, c'est donc la version de votre release.

La propriété 'website' si vous en avez un.

La propriété 'authors' là c'est de vous dont on parle .

La propriété 'description', une petite description de ce que fait votre mod.

Votre plugin contient des commandes utilisateurs ?

Pour éviter que les commandes d'un mod soient écrasées par celles d'un autre et pour instaurer une certaine cohésion vous devez préciser dans votre plugin.yml les commandes utilisateurs que vous avez créés de la forme :

commands:
  salut:
    description: Une commande pour me saluer
    usage: /<command>

Ce schéma doit être respecté pour toutes vos commandes utilisateurs, le 'usage' sera le message en réponse d'une mauvaise utilisation de la commande '/salut'.

Ce qui nous donnerait donc en combinant le tout :

name: Hello
main: net.thgbm.forum.Hello.Hello
version: 0.01
website: http://thgbm.net
authors: boozaa
description: >
    Mon premier plugin qui affiche un message quand je me connecte
    Qui me salue quand je lui demande
    Qui me dit quand je casse un block
commands:
  salut:
    description: Une commande pour me saluer
    usage: /<command>

Mais pourquoi déclarer mes commandes utilisateurs ?

Sauf erreur de ma part voici le pourquoi.
Quand un joueur tapes dans le tchat une commande, par exemple '/salut', le serveur cherche cette commande parmi celles déclarées aux chargements des mods.
Si il trouve la commande il connaît le mod qui souhaite la traiter et lui renvoi l’événement.

Avant cette structure .yml le serveur devait sûrement user plus de ressources car, toujours sauf erreur de ma part, il envoyait cet événement à tous les mods un par un jusqu'à ce qu'il y en ait un qui le traite. C'était une des raisons qui me faisait dire à l'époque qu'il valait mieux créer tout ce dont on a besoin plutôt qu'entasser les mods.

Où placer ce fichier ?

Il faut que ce fichier se trouve au même niveau que votre dossier 'src'. Dans le .jar après la génération il se trouvera donc à la racine du .jar.

La classe principale, celle qui hérite de JavaPlugin de bukkit

Maintenant que nos packages principaux sont faits on va s'attaquer à notre première classe.
Cette classe va hériter de JavaPlugin de bukkit pour pouvoir accéder à tout ce dont on a besoin dans notre mod.

Création de notre classe Hello

Faites un clic droit sur le package 'net.thgbm.forum.Hello' et choisissez 'New' -> 'Class'.

Dans la fenêtre de création assisté de Classe vous avez juste à préciser le nom de la classe à créer : Hello et valider en cliquant sur 'Finish'.

Notre fichier Hello

Notre fichier s'ouvre donc et vous voyez le code minimal généré par Eclipse

package net.thgbm.forum.Hello;

public class Hello {

}

Dans ce code nous allons commencer par importer le nécessaire pour notre classe et hériter de JavaPlugin en modifiant le fichier comme suit :

package net.thgbm.forum.Hello;

//Import du nécessaire de l'API
import org.bukkit.event.Event;
import org.bukkit.event.Event.Priority;
import org.bukkit.plugin.PluginManager;
import org.bukkit.plugin.java.JavaPlugin;
// Import de nos listeners
import net.thgbm.forum.Listeners.*;

public class Hello extends JavaPlugin {

}

Vous avez du remarquer que votre Eclipse vous signale des erreurs ou des avertissements. Comme vous venez d'hériter de JavaPlugin il vous faut obligatoirement définir 2 fonctions qui sont :
onEnable() et onDisable()

Ces deux fonctions sont les 'accroches' au serveur.
onEnable() là bukkit server démarre votre mod, c'est ici que vous allez démarrer votre application et également informer dans la console que votre mod a bien démarré.

onDisable() ici ce sera tout le ménage à faire lorsque votre mod s'arrète.

Ceci étant dit modifiez votre fichier en y ajoutant ces 2 fonctions :

package net.thgbm.forum.Hello;

//Import du nécessaire de l'API
import org.bukkit.event.Event;
import org.bukkit.event.Event.Priority;
import org.bukkit.plugin.PluginManager;
import org.bukkit.plugin.java.JavaPlugin;
// Import de nos listeners
import net.thgbm.forum.Listeners.*;

public class Hello extends JavaPlugin {

    @Override
    public void onEnable() 
    { 
        registerEvents();
        System.out.println(this.getDescription().getFullName() + " by " + this.getDescription().getAuthors().toString() + " started" );
    }

    @Override
    public void onDisable()
    {
        System.out.println(this.getDescription().getFullName() + " by " + this.getDescription().getAuthors().toString() + " stopped" );
    }

}

Dans le onEnable() vous avez certainement remarqué que j'appele une autre fonction qui est registerEvents(). Cette fonction va attacher les évenements serveur souhaités pour pouvoir les récupérer quand activés et ajouter nos modifications.

Notre registerEvents()

Voila la partie qui nécessite le plus de connaître les finalités de notre mod.
Pour rappel, je crée ce mod pour :
- me saluer quand je me connecte
- à nouveau me saluer lorsque je lance la commande '/salut'
- et me dire lorsque je casse un bloc

Les événements à capter pour cela sont donc respectivement :
- Event.Type.PLAYER_JOIN
- Event.Type.PLAYER_INTERACT
- Event.Type.BLOCK_DAMAGE

Vous remarquerez donc que 2 de ces 3 types d’événements sont PLAYER et un BLOCK. On revient à ce que je vous disais au début de ce tuto et on voit là nos 2 familles d’événements principaux le blockListener et le playerListener.

Nous allons donc ajouter à notre code le nécessaire pour capter ces 3 types d’événements.

Nous saluer lorsqu'on tape /salut

Voici maintenant le code pour que le serveur nous salut sur demande:

public boolean onCommand(CommandSender sender, Command cmd, String commandLabel, String[] args){    
    // On recupere le joueur qui a lancé la commande
    Player player = (Player) sender;
    // Si cette commande est '/salut'
    if(commandLabel.equalsIgnoreCase("salut")){ 
        player.sendMessage(    player.getName() + ", salut à toi encore une fois." );
        return true;
    }else{
        return false;
    }
}

Le code ressemblera à cela :

package net.thgbm.forum.Hello;

//Import du nécessaire de l'API
import org.bukkit.event.Event;
import org.bukkit.event.Event.Priority;
import org.bukkit.plugin.PluginManager;
import org.bukkit.plugin.java.JavaPlugin;
// Import de nos listeners
import net.thgbm.forum.Listeners.*;

public class Hello extends JavaPlugin {


    // BlockListener
    private final HelloBlockListener blockListener = new HelloBlockListener(this);
    // PlayerListener
    private final HelloPlayerListener playerListener = new HelloPlayerListener(this);
    
    /**
     * Capture des events nécessaires
     */
    private void registerEvents() {
        PluginManager pm = getServer().getPluginManager();
        /* Block events */
        pm.registerEvent(Event.Type.BLOCK_DAMAGE, blockListener, Priority.Normal, this);
        /* Player events */
        pm.registerEvent(Event.Type.PLAYER_JOIN, playerListener, Priority.Normal, this);
        pm.registerEvent(Event.Type.PLAYER_INTERACT, playerListener, Priority.Normal, this);
    }

    @Override
    public void onEnable() 
    { 
        registerEvents();
        System.out.println(this.getDescription().getFullName() + " by " + this.getDescription().getAuthors().toString() + " started" );
    }

    @Override
    public void onDisable()
    {
        System.out.println(this.getDescription().getFullName() + " by " + this.getDescription().getAuthors().toString() + " stopped" );
    }

    public boolean onCommand(CommandSender sender, Command cmd, String commandLabel, String[] args){    
        // On recupere le joueur qui a lancé la commande
        Player player = (Player) sender;
        // Si cette commande est '/salut'
        if(commandLabel.equalsIgnoreCase("salut")){ 
            player.sendMessage(    player.getName() + ", salut à toi encore une fois." );
            return true;
        }
        return false;
    }


}

Cette méthode onCommand() permet de lancer des actions donc sur des commandes lancées dans le tchat.

Pour notre projet cela est suffisant. Dans le code vous voyez que je déclare 2 Listeners : HelloBlockListener et HelloPlayerListener : ce sont nos Listeners qui va falloir créer et qui feront le boulot qu'il reste.

Concepts essentiels

Petit rappel sur les packages java

Un package Java, par exemple net.thgbm.forum se retranscrits dans l'archive .jar comme une arborescence de dossier, ce qui nous donne pour cet exemple la structure de dossier suivante :

- net
    - thgbm
        - forum

Gardez bien cela en mémoire pour vous permettre de bien 'ranger' vos futures classes, interface & co.
Je vous donne un exemple concret : dans ce package j'ai plusieurs fonctions qui envoi des messages customisés, un message en rouge pour un joueur précis, un message pour tout le monde etc..
Pour bien les ranger vous pouvez les mettre dans le package, par exemple, net.thgbm.forum.utils.message à coté des fonctions qui travaillent sur les strings par exemple net.thgbm.forum.utils.string, cela vous donnera une arborescence de ce genre :

- net
    - thgbm
        - forum
            - utils
                - message
                - string

Pensez donc à bien structurer votre code pour bien 'ranger'.

Les événements

On peut interagir grâce aux mods sur différents aspects du serveur.
On peut créer une action lors d'un clic sur un block, lors de la destruction d'un block, lors de l’arrivée sur le serveur d'un joueur ... et j'en passe ..

Ces actions sur lesquelles on peut agir sont en fait des événements. Pour pouvoir les modifier ou ajouter de nouvelles fonctions dés qu'un de ces événements intervient il vous faut les 'capter'.
Vous verrez que l'un des intérêts de travailler avec une IDE c'est qu'elle vous listera pour cet exemple tous les événements disponibles dans l'API.

On reste trois pour l'instant...

Alors pour l'instant sauf erreur de ma part on est 3 :
- boozaa
- bar_na_bet
- benofdark

Il nous manquerait un 4°.

J'espere que le comité n'est pas contre le fait de réparer ce que l'on voit de déteriorer dans ce genre d'exemple en se promenant, un bloc ou deux, une dalle...?
Dans ces exemples y a pas mort d'homme on va dire que c'est de la maintenance ordinaire ou vous préferez la delation pour ajouter ce genre de petits délits à la charge du coupable ?

Genuflexion devant chaque habitant ?

Mouarfhihi ca devient la gestapo le Gros Oeil.

Ah Ah Ah ... alors bienvenue

Je sais c'était pas drôle..

Salut à toi et j'espere pour toi que tu seras accepté.
C'est rigolo de voir un message sans ' '' '', je savais pas qu'il était retiré du dico ...Larousse ... ok je sais c'est nul je sors.