Salut,

Il n'y a plus besoin d'API pour faire des mods énergétique depuis l'introduction des capabilities. Si tu ne sais pas utiliser ces dernières je te conseille le le tutoriel à ce sujet.

Autre point qui a déjà été relevé : tu n'es pas dans la bonne section. Cette section permet aux membres ne faisant pas partie du staff de créer et partager des tutoriels.

Ainsi, pour effectuer une demande de tutoriel, merci de poster une message en réponse de ce post.

Bonne journée

En 1.13 Mojang a décidé de changer entièrement le système de commande de Minecraft. Les développeurs (enfin, surtout Dinnerbone) ont ainsi créé Brigadier, une librairie open-source utilisée à présent dans Minecraft. Bien qu'elle ai été développée pour Minecraft, elle peut être utilisée dans bien d'autre programmes.
Dans ce tutoriel nous allons donc nous pencher sur la création de commandes pour votre mod dans le cadre du modding Minecraft.

Sommaire

• Pré-requis
• Concept
• Code
• Résultat
• Crédits

Pré-requis

• Créer la base d'un mod

Concept

Avant de nous attaquer au code on va d'abord voir comment les commandes sont vues dans Brigadier. En réalité ce n'est pas très compliqué, c'est un simple arbre, chaque nœud de celui-ci peut être lié à aucun, un ou plusieurs autres nœuds. Quand on utilise une commande on ne fait que se déplacer dans cet arbre.
Le premier nœud de cet arbre est <root>, lorsque que vous ajoutez une commande vous reliez en réalité un nouveau nœud à <root>.
Voici un exemple de ce à quoi ressemble (partiellement) l'arbre représentant les commandes de Minecraft :

Il existe plusieurs types de nœud, il y a les nœuds dits "littérales" et les nœuds de type "argument". Un nœud littéral représente un texte prédéfini à taper, la plupart des nœuds montrés plus haut sont de ce type (ex. add, query, say, difficulty, etc ...). Les nœuds de type argument représente une donnée qui sera donnée par l'utilisateur et dont on va se servir pour exécuter la commande. Par exemple dans l'arbre ci-dessus time <int> est un argument demandant un entier et la valeur passée sera utilisée dans l'exécution de la commande. De même que message <String> qui est un message à afficher qui sera donné par l'utilisateur.

Lorsque l'on tape une commande on peut s'arrêter à n'importe quel nœud, vous pouvez alors rencontrer deux cas :

• Le nœud a défini un comportement et dans ce cas celui-ci s'exécute. Par exemple le nœud difficulty montré plus haut a pour comportement d'afficher la difficulté actuelle.

• Le nœud n'a pas défini de comportement et dans ce cas une erreur est affichée, c'est le cas par exemple du nœud time.

Bon, plongeons-nous à présent dans le code.

Code

Nous allons créer une commande qui met le feu aux entités renseignées dans la commande ou aux blocs dans le rayon indiqué. Pour cela nous allons créer en premier lieu une classe SetFireCommand et dans cette classe nous allons ajouter une fonction prenant en paramètre un objet CommandDispatcher<CommandSource> :

public static void register(CommandDispatcher<CommandSource> dispatcher)
{


}

C'est grâce à cet objet CommandDispatcher que nous allons pouvoir enregistrer nos commandes.
Avant de commencer à coder notre commande je vais vous donner la syntaxe que je souhaite pour ma commande.
Mettre le feu aux entités : /setfire entities <targets> [duration]
Mettre le feu aux blocs : /setfire blocks <radius>
Commençons !

Pour enregistrer une commande il faut appeler CommandDispatcher#register en lui passant un LiteralArgumentBuilder. La chaine de caractère passée dans ce builder sera le nom de notre commande (dans mon cas je met donc setfire).

dispatcher.register(
        LiteralArgumentBuilder.<CommandSource>literal("setfire") // Il est nécessaire de renseigner le type générique
);

Une chose que je n'ai pas précisé c'est que je veux que seuls les joueurs étant opérateurs puissent utiliser la commande, je vais donc l'indiquer tout de suite à l'aide de la méthode ArgumentBuilder#requires :

dispatcher.register(
        LiteralArgumentBuilder.<CommandSource>literal("setfire")
        .requires(src -> src.hasPermissionLevel(2))
);

Pour rajouter un nouveau nœud au nœud setfire que nous venons de créer il faut utiliser la méthode ArgumentBuilder#then. Je vais commencer par le nœud concernant les entités :

dispatcher.register(
        LiteralArgumentBuilder.<CommandSource>literal("setfire")
        .requires(src -> src.hasPermissionLevel(2))
        .then(
                Commands.literal("entities")
        )
);

Je viens donc de créer un nœud littéral, si vous vous souvenez de la suite de la syntaxe de ma commande je veux maintenant prendre en argument les entités à mettre en feu. Il faut donc que j'ajoute un nœud de type argument :

dispatcher.register(
        LiteralArgumentBuilder.<CommandSource>literal("setfire")
        .requires(src -> src.hasPermissionLevel(2))
        .then(
                Commands.literal("entities")
                .then(
                        Commands.argument("targets", EntityArgument.multipleEntities())
                )
        )
);

Pour ajouter un argument on utilise donc Commands#argument qui demande le nom de l'argument (ici targets car il représente les cibles de la commande) puis un type d'argument. Ici j'ai utilisé EntityArgument.multipleEntities() qui indique que j'accepte aucune, une seule ou plusieurs entités.

Afin de continuer notre commande nous allons créer une fonction dans notre classe qui aura pour but de mettre en feu une liste d'entités pendant une certaine durée :

/**
 * Met en feu les entités données pendant la durée donnée. Indique aussi au joueur que les entités ont été mises en
 * feu.
 * @param src La source de la commande
 * @param targets Les entités à mettre en feu
 * @param duration La durée du feu
 * @return le nombre d'entités mises en feu
 */
private static int setFireEntities(CommandSource src, Collection<? extends Entity> targets, int duration)
{
    targets.forEach(e -> e.setFire(duration));

    src.sendFeedback(new TextComponentString(targets.size() + " entities burnt !"), false);
    
    return targets.size();
}

Nous pourrons donc appeler cette fonction par la suite pour mettre en feu certaines entités. Continuons notre commande, nous sommes arrivés au nœud concernant les cibles, il reste à renseigner la durée du feu cependant nous voulons que si celle-ci n'est pas renseigné les entités brûle quand même pendant 5 secondes. Faisons cela :
Je ne mets ici qu'une partie du code de la commande

Commands.literal("entities")
.then(
        Commands.argument("targets", EntityArgument.multipleEntities())
        .executes(ctx -> setFireEntities(ctx.getSource(), EntityArgument.getEntitiesAllowingNone(ctx, "targets"), 5))
)

J'utilise EntityArgument#getEntitiesAllowingNone pour récupérer les cibles renseignée par l'utilisateur de la commande. J'y passe le contexte récupéré via la lambda ainsi que le nom de l'argument (ici targets).

Maintenant, si l'utilisateur renseigne la durée du feu il faut la prendre en compte. On rajoute donc un nœud à l'argument targets :

Commands.argument("targets", EntityArgument.multipleEntities())
.executes(ctx -> setFireEntities(ctx.getSource(), EntityArgument.getEntitiesAllowingNone(ctx, "targets"), 5))
.then(
        Commands.argument("duration", IntegerArgumentType.integer(0))
)

Cette fois-ci j'utilise le type IntegerArgumentType en appelant IntegerArgumentType#integer(int: min), le 0 correspond donc au minimum (je ne veux pas un temps négatif). Il faut à présent que je mette le feu aux entités pendant la durée renseignée.

Commands.argument("duration", IntegerArgumentType.integer(0))
.executes(ctx -> setFireEntities(ctx.getSource(), EntityArgument.getEntitiesAllowingNone(ctx, "targets"), IntegerArgumentType.getInteger(ctx, "duration")))

Là encore je récupère la durée renseignée en utilisant IntegerArgumentType#getInteger en indiquant bien duration qui est le nom du nœud que j'ai indiqué plus tôt.

Il semblerait que nous ayons terminé la partie concernant les entités. Passons maintenant à celle concernant les blocs.

Nous allons tout d'abord ajouter une fonction pour mettre en feu les blocs alentours sur un certain rayon.

/**
 * Met les blocs autour de la source en feu
 * @param src La source de la commande
 * @param radius Le rayon d'action
 * @return le nombre de blocs mis en feu
 */
private static int setFireBlocks(CommandSource src, int radius)
{
    Vec3d srcPos = src.getPos();
    World world = src.getWorld();
    int count = 0;
    for(int x = -radius; x < radius; x++)
    {
        for(int z = -radius; z < radius; z++)
        {
            BlockPos pos = new BlockPos(srcPos.x + x, srcPos.y, srcPos.z + z);
            IBlockState state = world.getBlockState(pos);
            if(state.getBlock() == Blocks.AIR)
            {
                world.setBlockState(pos, Blocks.FIRE.getDefaultState());
                count++;
            }
        }
    }

    src.sendFeedback(new TextComponentString(count + " blocks set to fire !"), false);

    return count;
}

Maintenant nous allons ajouter la branche relative aux blocs à notre commande. Rappelez-vous la commande est actuellement dans cet état :

public static void register(CommandDispatcher<CommandSource> dispatcher)
{
    dispatcher.register(
            LiteralArgumentBuilder.<CommandSource>literal("setfire")
            .requires(src -> src.hasPermissionLevel(2))
            .then(
                    Commands.literal("entities")
                   // [...]
            )
           // Le reste du code va aller ici
    );
}

Rajoutons un nœud littéral nommé blocks puis encore un nœud de type argument qui s’appellera radius et qui sera un entier positif :

.then(
        Commands.literal("blocks")
        .then(
                Commands.argument("radius", IntegerArgumentType.integer(0))
        )
)

Il ne manque plus qu'à appeler notre fonction setFireBlocks lors de l'exécution :

.then(
        Commands.literal("blocks")
        .then(
                Commands.argument("radius", IntegerArgumentType.integer(0))
                .executes(ctx -> setFireBlocks(ctx.getSource(), IntegerArgumentType.getInteger(ctx, "radius")))
        )
)

Rien de nouveau par rapport à ce que nous avons vu précédemment, ceci sert juste d'exemple supplémentaire, c'est pourquoi je passe rapidement dessus.

À présent il faut appeler SetFireCommand#register sinon nous n'aurons jamais notre commande en jeu. Pour cela rendez-vous dans la classe principale de votre mod et ajoutez la méthode suivante :

private void serverStartingEvent(FMLServerStartingEvent event)
{
	SetFireCommand.register(event.getCommandDispatcher());
}

Dans cette méthode nous enregistrons notre commande en lui passant une instance de CommandDispatcher. Pour le moment celle-ci n'est pas appelée, pour résoudre ce problème ajoutez dans le constructeur de votre classe principale :

public ModTutorial() {
	// [...]

	MinecraftForge.EVENT_BUS.addListener(this::serverStartingEvent);
}

Et voilà, le tour est joué. Vous pouvez lancer votre jeu et tester votre commande.

Résultat

Retrouvez le commit relatif à ce tutoriel sur le Github de MinecraftForgeFrance

Crédits

Ce tutoriel rédigé par @BrokenSwing corrigé par @robin4002 et publié sur Minecraft Forge France est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International

Retour vers le sommaire des tutoriels

Salut, tu trouveras sur le forum des tutoriels te renseignant sur la façon de créer des objets, je suis sûr qu'ils expliquent aussi comment les enregistrer pour qu'ils soient ajoutés au jeu.
Bonne journée

Et attention de ne pas te tromper d'interface ITickable, il ne faut pas prendre celle qui concerne les texures.

@Voltorise Salut,
Cela vient d'une erreur de conversion des tutoriels depuis notre changement de moteur pour le forum. Les * correspondent en réalité à des [i].

Comme beaucoup de jeux et de logiciels, Minecraft est séparé en deux parties : le client et le serveur. Dans de nombreux cas, ces deux parties ont besoin de communiquer afin d'échanger des informations. Afin d'y parvenir, celles-ci utilisent ce que l'on appelle des paquets et nous allons voir comment créer nos propres paquets afin d'échanger nos propres informations.

Cas d'utilisation :

Cas n° 1 : Nous possédons un système d'argent par joueur et nous voulons afficher la somme que le joueur possède sur son écran. Alors, il nous faut connaître cette dernière du côté client afin d'être capable d'effectuer le rendu. Il faut donc que le serveur communique cette somme au client.

Cas n° 2 : Nous possédons une GUI (Graphical User Interface) avec des boutons et nous voulons être notifié côté serveur (rappelons qu'une GUI se situe côté client) afin d'effectuer une action associée à ce bouton. Il faut donc que le client communique cette information au serveur.

Sommaire du tutoriel

• Fonctionnement du réseau
• Création d'un channel
• Création d'un paquet
• Enregistrement d'un paquet
• Envoyer un paquet
• Approfondissement
• Résultat sur Github

Fonctionnement du network

Si vous savez déjà comment fonctionne le système de paquets de Forge, vous pouvez passer cette partie.

Pour communiquer entre le client et le serveur, Minecraft utilise un framework appelé Netty, vous n'aurez cependant pas à utiliser ce framework directement car que ce soit Minecraft ou Forge, chacun possède une surcouche facilitant la communication entre notre client et notre serveur.

Afin de communiquer, il nous faudra faire transiter nos paquets via le réseau, pour cela nous devrons créer ce que l'on appelle des channels. Il faut voir un channel comme étant une route entre votre client et votre serveur sur laquelle vos paquets vont se déplacer, on peut avoir plusieurs routes entre un même client et le serveur. En pratique, on utilisera au minimum un channel par mod.

Pour ce qui est des paquets, il faut se les représenter comme un tas de données brutes (des octets) que l'on fait transiter via le réseau. Or, en Java, on utilise généralement des objets dans notre code. Afin de faire transiter nos objets, il nous faudra alors les sérialiser sous formes d'octets afin des les envoyer au client ou au serveur puis, arrivés là-bas il faudra les désérialiser afin de les retransformer en objets.

Afin d'appeler la bonne fonction de sérialisation et de désérialisation, Forge nous demande d'associer ensemble :

• Une nombre unique (appelé discriminant)
• Une classe (que l'on appellera T ici)
• Une fonction de sérialisation pour la classe T
• Une fonction de désérialisation pour la classe T
• Une fonction qui sera appelée à la réception du paquet

Ainsi, lorsqu'on demande à Forge d'envoyer un certain objet via le réseau, il cherche dans la liste des associations que l'on lui a fourni, l'association pour la classe de l'objet donné. Ensuite, il appelle la fonction de sérialisation sur l'instance à envoyer afin de transformer l'objet en octets. Enfin, il rajoute le discriminant au début des octets.

Le tout est envoyé via le channel sur lequel est enregistré l'association.

À la réception du paquet, Forge récupère le discriminant et cherche dans les associations celle possédant le discriminant du paquet reçu, il appelle alors la fonction de désérialisation afin de récupérer une instance de l'objet similaire à celle envoyée, puis passe cet objet à la fonction gérant la réception du paquet.

Création d'un channel

Nous allons tout d'abord créer une classe qui regroupera tout ce qui concerne le réseau (création des channels et enregistrement des paquets).
Pour ma part je vais l'appeler TutorialNetwork. Le nom a peu d'importance, du moment que vous vous y retrouvez par la suite.
Avant toute chose, nous allons avoir besoin de spécifier la version de notre channel, c'est une chaîne de caractères qui n'a de sens que pour vous (il est nécessaire de l'indiquer, mais vous ne vous en préoccuperez pas en réalité).
Créons donc un champ contenant la version, dans mon cas il contiendra la valeur 1.

public static final String PROTOCOL_VERSION = String.valueOf(1);

Ensuite nous allons ajouter notre channel . La classe du channel est SimpleChannel et nous allons utiliser le builder NetworkRegistry.ChannelBuilder pour l'instancier :

public static final SimpleChannel CHANNEL = NetworkRegistry.ChannelBuilder
        .named(new ResourceLocation(ModTutorial.MOD_ID, "my_channel"))
        .networkProtocolVersion(() -> PROTOCOL_VERSION)
        .clientAcceptedVersions(PROTOCOL_VERSION::equals)
        .serverAcceptedVersions(PROTOCOL_VERSION::equals)
        .simpleChannel();

Voyons un peu ce que nous venons de faire ici :

• Ligne 2 : .named prend une ResourceLocation représentant le nom de votre channel. Mettez l'id de votre mod en domaine (ici c'est mon ModTutorial.MOD_ID) puis ce que vous voulez pour le chemin (ici mon my_channel).

• Ligne 3 : .networkProtocolVersion prend un Provider<String> qui doit renvoyer la version de votre protocol. Ici nous renvoyons le champ que nous avons créé plus haut.

• Lignes 4 et 5 : celles-ci demandent un Predicate<String> afin de vérifier que la version sur le côté client et sur le côté serveur sont compatibles. Dans notre cas nous vérifions simplement que la version correspond à la version actuelle de notre protocol.

• Ligne 6 : .simpleChannel() finalise la création de notre channel et nous renvoie son instance.

Création d'un paquet

Comme expliqué précédemment, un paquet est représenté par une classe, nous allons donc en créer une. Pour ma part, je l'appellerai MySimplePacket. Pour commencer, je ne vais y mettre qu'une valeur d'entier comme attribut :

public class MySimplePacket
{
    private int value;

    public MySimplePacket(int value)
    {
        this.value = value;
    }
}

Nous allons ensuite créer les fonctions de sérialisation et de désérialisation. Leur nom importe peu, mais :

• La fonction de sérialisation doit prendre en paramètre l'objet à sérialiser (ici une instance de MySimplePacket et un PacketBuffer dans lequel on stockera l'objet sous forme d'octets. Elle ne doit rien retourner.

• La fonction de désérialisation doit prendre en paramètre un PacketBuffer et retourner l'instance de l'objet désérialisé (ici une instance de MySimplePacket).

Fonction de sérialisation :

public static void encode(MySimplePacket packet, PacketBuffer buffer)
{
    buffer.writeInt(packet.value);
}

Dans cette fonction j'écris donc l'entier de mon paquet dans le PacketBuffer.

Fonction de désérialisation :

public static MySimplePacket decode(PacketBuffer buffer)
{
    int value = buffer.readInt();
    MySimplePacket instance = new MySimplePacket(value);
    return instance;
}

Et dans cette fonction, je récupère la valeur de mon entier dans le PacketBuffer puis la passe en paramètre au constructeur de mon objet que je retourne ensuite. NB : J'aurais pu directement mettre return new MySimplePacket(buffer.readInt()).

Si vous avez suivi correctement le tutoriel jusqu'à maintenant vous devriez savoir qu'il ne reste plus qu'à créer la fonction qui gérera la réception de votre paquet. Cette fonction prend en paramètres une instance de votre paquet (ici une instance de MySimplePacket) et un Supplier<NetworkEvent.Context> et ne renvoie rien. Ce second argument permet de récupérer le contexte dans lequel le paquet a été envoyé. Il permet, entre autres, de récupérer l'instance du joueur côté serveur ou encore de savoir si nous sommes côté client ou côté serveur.

Ajoutons donc cette fonction à notre classe :

public static void handle(MySimplePacket packet, Supplier<NetworkEvent.Context> ctx)
{
    System.out.println(packet.value);
    ctx.get().setPacketHandled(true);
}

Ici, j'affiche donc la valeur de mon paquet, puis j'appelle NetworkEvent.Context#setPacketHandled afin de dire que j'ai géré le paquet. Il est nécessaire de dire que nous avons géré le paquet sinon ce dernier est envoyé dans le code de Minecraft qui gère les paquets et affiche un message d'erreur.

Nous sommes maintenant prêts à enregistrer notre paquet tout neuf sur notre channel.

Enregistrement d'un paquet

De retour dans notre classe TutorialNetwork. Nous allons créer une fonction dans laquelle nous enregistrerons nos paquets. Pour ma part, je vais l'appeler registerNetworkPackets. Ensuite, nous allons utiliser SimpleChannel#messageBuilder pour enregistrer notre paquet :

public static void registerNetworkPackets()
{
    CHANNEL.messageBuilder(MySimplePacket.class, 0)
            .encoder(MySimplePacket::encode)
            .decoder(MySimplePacket::decode)
            .consumer(MySimplePacket::handle)
            .add();
}

Le code précédent ne devrait pas être surprenant et vous devriez facilement faire le parallèle avec les associations dont je vous ai parlé auparavant. Mais analysons-le quand même :

• Ligne 3 : .messageBuilder prend en paramètres la classe de votre paquet ainsi que le discriminant (cf. 1ère partie du tuto).

• Ligne 4 : .encoder prend en paramètre la fonction de sérialisation.

• Ligne 5 : .decoder prend en paramètre la fonction de désérialisation.

• Ligne 6 : .consumer prend en paramètre le fonction qui va gérer votre paquet à sa réception.

• Ligne 7: .add permet de finaliser l'enregistrement.

Il suffit maintenant d'appeler la fonction registerNetworkPackets dans la fonction setup de votre mod (celle prenant en paramètre FMLCommonSetupEvent).

public ModTutorial() {
    // [...]
    FMLJavaModLoadingContext.get().getModEventBus().addListener(this::setup);
    // [...]
}

private void setup(final FMLCommonSetupEvent event)
{
    // [...]
    TutorialNetwork.registerNetworkPackets();
    // [...]
}

Envoyer un paquet

Pour envoyer votre paquet il suffit maintenant d'appeler SimpleChannel#send pour le faire transiter du client au serveur ou du serveur à un ou des clients. Il vous faudra aussi vous aider des champs déclarés dans la classe PacketDistributor, je vous donne quelques exemples ci-dessous.

• Exemple d'envoi de notre paquet sur le serveur :
  Les deux lignes de code ci-dessous parviennent au même résultat.

// Affichera la valeur 12 dans la console du serveur :

// 1ère solution
TutorialNetwork.CHANNEL.sendToServer(new MySimplePacket(12));
// 2nd solution
TutorialNetwork.CHANNEL.send(PacketDistributor.SERVER.noArg(), new MySimplePacket(12));

• Exemple d'envoi de notre paquet sur le client :
  Pour envoyer un paquet à un client, il faut avoir une instance de EntityPlayerMP.

public static void sendTo(EntityPlayerMP player)
{
    // Affiche 10 dans la console du client
    TutorialNetwork.CHANNEL.send(PacketDistributor.PLAYER.with(() -> player), new MySimplePacket(10));
}

• Exemple d'envoi d'un paquet à tous les clients du serveur :

// Affiche 42 dans la console de tous les clients
TutorialNetwork.CHANNEL.send(PacketDistributor.ALL.noArg(), new MySimplePacket(42));

• Exemple d'envoi d'un paquet à tous les clients se trouvant dans une dimension donnée :

// Affiche 36 dans la console de tous les joueurs se trouvant dans le nether
TutorialNetwork.CHANNEL.send(PacketDistributor.DIMENSION.with(() -> DimensionType.NETHER), new MySimplePacket(36));

Voilà pour les exemples, n'hésitez pas à regarder la classe PacketDistributor pour découvrir les autres filtres d'envoi.

Approfondissement

J'ai volontairement survolé quelques points dans les sections précédentes car ce n'était pas forcément le moment d'en parler, mais ce moment est arrivé.

• Sérialiser/Désérialiser vos objets :

La sérialisation et la désérialisation de vos objets est une étape importante la création de votre paquet. Il va en effet généralement vous falloir découper votre objets en des objets ou type primitifs facilement sérialisables (String, int, boolean, UUID, etc ...).
Je ne vais pas faire l'inventaire des types facilement sérialisables via le PacketBuffer, pour cela il vous suffit de chercher toutes les méthodes qui commencent par write dans cette classe.
Je vais cependant donner un exemple de sérialisation d'une collection d'objets de la classe suivante :

public class MyComplexObject
{
    private String foo;
    private int bar;
    private UUID foobar;
    private ItemStack stack;
}

Dans un premier temps je vais écrire une méthode qui va sérialiser une instance de MyComplexObject dans un PacketBuffer :

public void writeToBuffer(PacketBuffer buffer)
{
    buffer.writeString(this.foo);
    buffer.writeInt(this.bar);
    buffer.writeUniqueId(this.foobar);
    buffer.writeItemStack(this.stack);
}

Ensuite, je vais écrire une méthode qui va désérialiser cet objet. Pour ce faire, je vais créer un constructeur qui prend un PacketBuffer en entrée :

public MyComplexObject(PacketBuffer buffer)
{
    this.foo = buffer.readString(32767); // 32767 correspond à la longueur max de la chaine de caractères
    this.bar = buffer.readInt();
    this.foobar = buffer.readUniqueId();
    this.stack = buffer.readItemStack();
}

On rappelle qu'il faut lire les données dans le même ordre qu'elles ont été écrites.
Une fois tout cela fait, je crée mon paquet :

public class MyComplexPacket
{
    private Collection<MyComplexObject> myCollection;
    
    public MyComplexPacket(Collection<MyComplexObject> collection)
    {
        this.myCollection = collection;
    }
}

Puis je crée les fonctions de sérialisation et de désérialisation du paquet :

public static void encode(MyComplexPacket pck, PacketBuffer buf)
{
    // J'écris le nombre d'objet que je vais sérialiser
    buf.writeInt(pck.myCollection.size());
    
    // Puis je sérialiser chaque objet
    pck.myCollection.forEach(o -> o.writeToBuffer(buf));
}

public static MyComplexPacket decode(PacketBuffer buffer)
{
    // Je lis combien d'objet on été sérialisés
    int collectionSize = buffer.readInt();
    
    // Puis je lis autant d'objet qui ont été sérialisés
    Collection<MyComplexObject> complexObjects = Stream
            .generate(() -> new MyComplexObject(buffer))
            .limit(collectionSize)
            .collect(Collectors.toList());
    
    // Enfin, je retourne l'instance de mon paquet
    return new MyComplexPacket(complexObjects);
}

Et voilà, vous savez maintenant sérialiser et désérialiser une collection d'objets.

• Quelques informations sur le NetworkEvent.Context :

Comme vu précédemment, lorsque l'on gère l'arrivé d'un paquet, on nous met à disposition un Supplier<NetworkEvent.Context>. Ici, nous allons voir légèrement plus en profondeur ce que ce dernier nous donne comme informations.

Dans un premier temps, vous pouvez tout simplement récupérer le contexte dans lequel le paquet a été reçu en appelant Supplier#get qui va vous retourner une instance de NetworkEvent.Context, c'est celui-ci qui nous intéresse bien sûr.

• Context#getDirection vous permet de récupérer une énumération indiquant vers où le paquet a été envoyé. NetworkDirection#PLAY_TO_SERVER et NetworkDirection#LOGIN_TO_SERVER pour client vers serveur, NetworkDirection#PLAY_TO_CLIENT et NetworkDirection#LOGIN_TO_CLIENT pour serveur vers client. La différence entre PLAY et LOGIN correspond au moment où le paquet est envoyé, PLAY si l'entité du joueur a été créée, LOGIN si l'entité n'a pas encore été créée et que le client est encore en phase de chargement. Vous ne devriez avoir à gérer que le premier cas (PLAY).

• Context#enqueueWork permet de définir un travail qui sera réalisé au prochain tick sur le thread du client ou du serveur (pas sur le thread de Netty).

• Context#getSender renvoie une instance de EntityPlayerMP correspondante au client qui a envoyé le paquet au serveur. Comme vous venez de le comprendre, celle-ci n'est utilisable que sur le serveur.

• Context#attr permet d'accéder à un certain attribut du channel entre le serveur et le client. L'utilisation de cette fonctionnalité correspond à des cas particulier que vous ne rencontrerez sûrement pas, je ne vais donc pas m'étendre plus longtemps dessus (mais sachez que ça existe).

• SimpleChannel#reply(NetworkEvent.Context, MSG) permet de renvoyer un message à celui qui vous en a envoyé un.

Je pense que nous avons maintenant fait le tour de ce qu'il y a à voir, j'espère que vous compris comment fonctionne le network et je vous souhaite du bon modding.

Résultat sur Github

Vous pouvez consulter le commit concernant ce tutoriel sur le Github de MinecraftForgeFrance.

Ce tutoriel de Minecraft Forge France est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International

Retour vers le sommaire des tutoriels

Salut, c'est une opération assez simple :

def : style
Pour i allant de 1 à (taille(args) - 1):
    Si args[i] dans valeurs(EnumFormatting) :
         def : format = récupérerEnumFormattingDepuisNom(args[i])
         style.ajouterFormat(format)

Voilà, plus qu'à traduire cette logique en Java.

Salut, as-tu lu le tutoriel sur les commandes ?

Si tu as déjà lu ce dernier, peux-tu nous indiquer sur quelle partie tu bloques ?

Salut,

Effectivement, pour commencer il est plus simple de suivre les différents tutoriels que l'on peut trouver sur Internet (j'ai personnellement commencé le modding en suivant les tutoriels de MFF), après tout, c'est très confortable de se reposer dessus au début.

Cependant, si tu comptes progresser rapidement dans le milieu du modding je te donnerai plusieurs conseils :

• Lorsque tu lis les tutoriels, je te conseille de mettre un point d'honneur à comprendre TOUT le code que tu écris, c'est si facile de copier/coller du code sans comprendre ce qu'il fait mais si peu efficace (car ceux qui font ça on besoin de revenir sur le tutoriel à chaque fois qu'ils veulent reproduire la feature).

• N'hésite pas à lire le code source de Forge, et de Minecraft. Cela te permettra d'avoir une très bonne idée de la manière dont chaque donnée est gérée et quelles méthodes sont appelées quand et où. De plus, certaines fonctionnalités n'ont pas de tutoriel dédié sur le forum (généralement les fonctionnalités avancées), c'est donc dans le code source que tu trouvera le plus d'informations sur leur fonctionnement.

• Code dans les dernières version. Je veux dire par là que, sans revenir dans l'éternel débat avec la 1.7.10, la plupart des moddeurs compétents développent dans les versions récentes pour plusieurs raisons (je suis conscient qu'il y a aussi des raisons qui poussent certains développeurs à modder dans d'ancienne versions) :

  • Celles-ci ont des fonctionnalités rendant le modding plus agréable
  • Elles ont un meilleur support (cf. le forum de MinecraftForge qui ne fait plus de support pour les vieilles versions)
  • Elles sont plus performantes (des fois, pas tout le temps )
  • Elles sont mieux mappées (cf. les mappings MCP)

• Demande de l'aide, mais en étant le plus clair possible. Il faut éviter le problème xy et il faut utiliser un vocabulaire précis (fonction != méthode, classe != interface, etc ...). Ce cette manière, les réponses seront elles aussi plus claires (cela t'évitera aussi les "Laisse moi consulter ma boule de cristal").

• Pour en revenir aux tutoriels : si, lors de leur lecture, il y a un point que tu ne trouves pas très clair, qui n'est pas très bien expliqué, contact un rédacteur ou un modérateur afin qu'il puisse clarifier le tutoriel. Cela te profitera et profitera aussi aux autres.

Pour terminer je te conseil, si ce n'est pas déjà le cas, de rejoindre le Discord de MinecraftForgeFrance, on peut y aborder différents sujets assez intéressants que tu ne trouvera pas vraiment sur le forum (chose qui est dommage quand j'y pense. Je vais me pencher sur ce point là, tient.)

Sur ce, je te souhaite de t'amuser en moddant et surtout de ne pas désespérer si tu as quelques difficultés au début.

TL;DR : Dommage pour toi