Meilleures Pratiques

Il y a plusieurs manières de créer un plugin et plusieurs pièges pour un développeur imprudent. Nous décrivons ici les pratiques pour développer un plugin qui feront les plus de l’API Sponge, en fixant des limites raisonnables au profit de la compatibilité. Ces informations pourront changer et être étendues au fur et à mesure que le projet Sponge gagnera en maturité.

Les recommandations pour le développement de plugin

Les recommandations suivantes ont été préparées pour aider les développeurs de plugins Sponge. Ce n’est pas une liste définitive et exhaustive, plutôt une tentative pour détailler les problèmes qui sont susceptibles de se poser durant le développement d’un plugin, et de proposer nos meilleures solutions.

Note

Nous réservons l’utilisation de Sponge pour les travaux officiels de SpongePowered. Merci de ne pas utiliser Sponge à l’intérieur du nom de votre plugin, sauf (1) si votre plugin concerne principalement le bloc de Minecraft « Éponge », ou (2) si votre plugin possède également des versions pour d’autres APIs (auquel cas vous pouvez ajouter « for Sponge » au titre).

API d’économie

L’API Économie est utilisée pour lier des plugins d’économie avec d’autres plugins qui utilisent l’économie (des plugins de vente, par exemple). Vous pouvez en savoir plus sur l’API Économie ici, qui détaille tout ce dont vous avez besoin de savoir à propos de l’API.

Packets

Tout ce qui concerne l’interception de packets, ou l’introduction d’objets/blocks/entités/etc personnalisés ne sont pas prévu de faire partie de l’API Sponge. Notez que l’utilisation de packets peut la mauvaise réponse à un problème et qu’il peut y avoir une solution réalisable avec l’API Sponge. Dans certains cas il peut être possible d’ajouter tout ce qui est nécessaire avec l’API Sponge; autrement, l’alternative est d’utiliser l’API Forge et de créer un Mod à la place.

Utiliser Forge ou les Classes NMS

Nous recommandons de ne pas de travailler du tout avec les classes de base de Forge et de Minecraft, à moins que ce soit pour fournir une compatibilité avec un mod à l’API Sponge. La plupart des utilisations de code NMS (Native Minecraft Server ou Serveur Minecraft Natif, en français) dans les plugins ne finissent pas proprement, rendant les diagnostics difficiles. Maintenir à jour les modifications NMS est également plus difficile que d’utiliser l’API Sponge. Les Mods qui ajoutent à l’API Sponge l’utilisation de code interne devront spécifiquement écrire une API, qui ne repose pas sur le code sous-jacent de Minecraft, pour être utilisable par les plugins Sponge. Cependant, des plugins peuvent être créés pour charger des modules de « compatibilité » pour interagir avec l’implémentation sous-jacente (SpongeForge ou SpongeVanilla).

Les plugins utilisant du code spécifique à une implémentation sont très susceptibles de se casser entre deux versions, et devraient être clairement étiquetés comme tels partout où ils sont hébergés. Ceux-ci devraient plus convenablement être étiquetés comme « Mods ».

Mixins

Les Mixins sont spécialement utilisés pour transformer les classes avant que d’autres mods/plugins démarrent. ForgeModLoader appelle ces mods « Coremods ». SpongeForge est un Coremod et déploie des mixins au démarrage. Les Mixins peuvent être utilisés par les plugins, mais soyez conscient des complexités additionnelles impliquées.

Mods Hybrides

Les plugins Sponge qui exploitent les mixins peuvent également être considérés comme des mods core, selon leur contenu.

• Pour utiliser les mixins dans FML, il doit être un coremod. Le jar doit également contenir un plugin Sponge, donc à proprement parler, le conteneur est un « mod hybride ».

• Pour utiliser les mixins dans SpongeVanilla, les intentions doivent être déclarées dans le manifest. SpongeVanilla injecte alors les mixins.

• Avoir les deux types dans un seul jar est entièrement possible. (En effet, un seul jar peut facilement contenir un tweaker, mod FML, coremod, plugin Bukkit, plugin Sponge, et/ou litemod.)

Certaines définitions peuvent être utiles ici.

Tweak Mod (alias Tweaker)

un mod au niveau du sous-système se raccorde directement au jeu en utilisant LaunchWrapper, hébituellement utilisé pour des ModSystems (par exemple LiteLoader, FML) et les mods autonomes (par exemple Optifine). Peut interagir directement avec n’importe quel aspect de l’environnement du jeu. Ne fonctionne généralement plus à chaque version.

Core Mod

dispose presque de l’équivalent du pouvoir d’un Tweak Mod mais doit être amorcé par un ModSystem. Peut interagir avec n’importe quel aspect de l’environnement du jeu directement. Ne fonctionne généralement plus à chaque nouvelle version du jeu.

Mod

interagit avec le jeu seulement via un ModSystem, le mod est exposé aux objets du jeu directement mais va généralement seulement s’attacher au jeu via les hooks fournits par le ModSystem. Se casse généralement à chaque version majeure du jeu (selon les fonctionnalités utilisées). Le terme mod est également utilisé comme un terme générique pour tout ce qui modifie le jeu, mais par souci de clarté, nous allons utiliser cette définition.

Plugin

interagit avec le jeu uniquement via une API, n’interagit pas directement avec les objets du jeu en quelconque façon, s’appuie seulement sur les objets exposés par l’API. Ne fonctionne généralement plus seulement lorsque l’API est révisée (et même pas, parfois).

Il est également important de distinguer le conteneur du contenu. Les problèmes avec la terminologie tendent à survenir parce qu’un jar contenant un mod tend à se référer en tant que « mod ». N’importe quel plugin qui n’est pas entièrement découplé via l’API se met dans la catégorie des Mods. Ce type de « plugin » peut être répandu lorsqu’il existe des lacunes dans une API.

Avantages des Mods Hybrides

Un mod hybride s’appuie sur un composant de plugin qui interagit via l’API, et un mod (ou même coremeod) dans un même package. Il présente les inconvénients d’un mod (ne fonctionne plus à chaque version) mais également la puissance d’un mod (peut interagir directemenet avec le jeu) couplé avec certains des avantages d’un Plugin (accès haut-niveau au jeu, et peut également interagir avec d’autrers plugins en tant que pair).

Le principal avantage de ce système est que la charge de la maintenance est réduite lors de la mise à jour du mod, car toutes les fonctionnalités accédées via l’API sont susceptibles d’être beaucoup plus stables.

Ce type de mod peut être utilisé pour implémenter des plugins qui ont besoin de déborder les capacités de l’API (dans le cas d’un plugin qui a besoin d’exploiter les mixins pour une fonctionnalité particulière); mais il peutégalement être utilisé poru les emods qui veulent tirer parti des services offerts par l’API (par exemple un mod qui veut fournir un support direct pour les permissions ou les canaux de chat).

Contrairrement aux « plugins » qui exploitent les NMS, un mod hybride clarifie sa nature.

Interopérabilité des Plugins

Une explication de comment communiquer avec les autres plugins, à être annoncé.