Mejores Prácticas

There are many ways to create a plugin, and many pitfalls for an unwary developer. Here we describe the plugin development practices that will make the most of SpongeAPI, setting sensible boundaries for the benefit of compatibility. This information may change and expand as the Sponge project matures.

Pautas de Desarrollo de Complementos

Las siguientes pautas se han preparado para ayudar a los desarrolladores de complementos de Sponge. No es una lista definitiva o exhaustiva, sino que sencillamente un intento de detallar algunos problemas que pueden surgir durante el desarrollo de complementos, y proponer nuestras mejores soluciones.

Nota

Nos reservamos el uso de Sponge para trabajos oficiales de SpongePowered. No utilice Sponge como parte del nombre de su complemento, a menos que (1) su complemento se refiera principalmente al bloque «Sponge» de Minecraft, o (2) su complemento también tenga versiones para otras API (en cuyo caso puede agregar «para Sponge » en el título).

Lal API de la Economía

La API de Economía es usada para vincular complementos económicos con otros complementos que usan la economía (es decir, tiendas). Ud. puede leer sobre la API de Economía aquí here, el cual detalla todo lo que Ud. necesita saber sobre la API.

Paquetes

Anything to do with intercepting packets, or introducing custom items/blocks/entities/etc., is not planned to be part of SpongeAPI. Note that using packets may be looking at the problem the wrong way, as there may be a solution achievable with the existing SpongeAPI. In some cases, it may be possible to add whatever is needed to SpongeAPI; otherwise, the alternative is to use the Forge API and create a Mod instead.

Usando Forge o Clases de NMS

We do not recommend working with Forge or Minecraft base classes at all, unless it is to provide compatibility with a mod for SpongeAPI. Most uses of NMS (net.minecraft.server) code in plugins do not fail gracefully, making troubleshooting very difficult. Maintaining NMS modifications is also more difficult than using SpongeAPI. Mods that add to SpongeAPI using code internals will have to specifically write an API, which does not rely on underlying Minecraft code, to be usable by Sponge plugins. However, plugins can be created that load separate “compatibility” modules to interact with the underlying implementation (SpongeForge or SpongeVanilla).

Los complementos que usan códigos específicos de implementación tienen muchas probabilidades de quebrarse entre versiones, y deben etiquetarse claramente como tales en cualquier lugar en el que se alojen. Estos pueden etiquetarse más apropiadamente como «Mods».

Mixins

Los Mixins son específicamente para transformar clases antes de que comiencen otros mods/complementos. ForgeModLoader llama a estos mods «Coremods». SpongeForge es un Coremod y despliega mixins al inicio. Mixins puede ser usado por complementos, pero tenga en cuenta las complejidades adicionales involucradas.

Modificaciones Híbridas

Los complementos de Sponge que aprovechan las mixins también pueden considerarse mods centrales, basados ​​en el contenido.

• Para usar mixins en FML, debe ser un mod central. El jar también puede contener un complemento de Sponge, por lo que lo más adecuado es que el contenedor sea un «mod híbrido».

• Para usar mixins en SpongeVanilla, las intenciones deben ser declaradas en el manifiesto. SpongeVanilla luego inyecta los mixins.

• Tener ambos tipos en un solo jar es completamente posible. (De hecho, un solo jar puede contener fácilmente un tweaker, un mod FML, un mod central, un complemento de bukkit, un complemento de Sponge y/o un litemod.)

Algunas definiciones puede servir de ayuda aquí.

Mod Tweak (es decir Tweaker)

a subsystem-level mod which hooks directly into the game using LaunchWrapper, usually used for ModSystems (e.g. LiteLoader, FML) and stand-alone mods (eg. Optifine). Can interact with any aspect of the game environment directly. Generally breaks every version.

Mod Central

tiene una potencia casi equivalente a una Mod Tweak pero debe ser iniciado por un ModSystem. Puede interactuar directamente con cualquier aspecto del entorno del juego. Generalmente se rompe en cada versión nueva del Juego.

Modificación

interactúa con el juego solo a través de un ModSystem, el mod está expuesto directamente a los objetos del juego pero generalmente solo se enganchará al juego a través de los ganchos provistos por el ModSystem. Generalmente quiebra cada versión principal del juego (dependiendo de las características utilizadas). El término mod también se usa como término general para cualquier cosa que modifique el juego, aunque para mayor claridad usaremos esta definición.

Plugin

interactúa con el juego solo a través de una API, no interactúa directamente con los objetos del juego de ninguna manera, solo aprovecha los objetos expuestos por la API. Generalmente se rquiebra solo cuando se revisa la API (y algunas veces ni siquiera así).

También es importante distinguir el contenedor de los contenidos. Los onconvenientes con la terminología tienden a surgir porque un jar que contiene un mod tiende a ser referido como un «mod». Cualquier complemento que no esté completamente desacoplado a través de la API se coloca en la categoría de Mod. Este tipo de «complemento» puede ser prevalente cuando hay deficiencias en una API.

Ventajas de los Mods Híbridos

Un mod híbrido aprovecha tanto un componente de complemento que interactúa a través de la API como un mod (o incluso un mod central) en el mismo paquete. Esto tiene las desventajas de un mod (quiebra todas las versiones) pero también el poder de un mod (puede interactuar directamente con el juego) junto con algunos de los beneficios de un Complemento (acceso abstracto de alto nivel al juego, y también puede interactuar con otros complementos como un par).

El principal beneficio de este sistema es que la carga de mantenimiento se reduce cuando se actualiza el mod, debido a que es probable que las funciones a las que se accede a través del API sean mucho más estables.

This type of mod can be used to implement plugins whose needs overflow the capability of the API (in the case of a plugin which needs to leverage mixins for a particular feature); but can also be used for mods which want to leverage services afforded by the API (e.g. a mod which wants to provide direct support for permissions or chat channels).

A diferencia de los «complementos» de explotación de NMS, un mod híbrido hace de su naturaleza algo claro.