Mejores Prácticas
Hay muchas maneras de crear un complemento y muchas dificultades para un desarrollador incauto. Aquí describimos las prácticas de desarrollo de complementos que aprovecharán al máximo la API de Sponge, estableciendo límites razonables en beneficio de la compatibilidad. Esta información puede cambiar y expandirse a medida que el proyecto Sponge madure.
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 se usa para vincular complementos de economía con otros complementos que usen la economía (ejemplo, tiendas). Puede leer sobre la API de Economía :doc: here<economy/index>, que detalla todo lo que necesita saber sobre la API.
Paquetes
Cualquier cosa que tenga que ver con la interceptación de paquetes o la introducción de elementos personalizados/bloques/entidades/etc., no es planeado para ser parte de la API de Sponge. Note que el uso de paquetes puede estar mirando el problema de la manera incorrecta, ya que puede haber una solución que se pueda lograr con la API de Sponge existente. En algunos casos, es posible agregar lo que sea necesario a la API de Sponge; de lo contrario, la alternativa es usar la API de Forge y crear un Mod en su lugar.
Usando Forge o Clases de NMS
No recomendamos trabajar con las clases base de Forge o Minecraft en absoluto, a menos que sea para proporcionar compatibilidad con un mod para la API de Sponge. La mayoría de los usos del código NMS (net.minecraft.server) en los complementos no fallan con mucha gracia, lo que dificulta la solución de problemas. Mantener las modificaciones de NMS también es más difícil que usar la API de Sponge. Las modificaciones que se agreguen a la API de Sponge mediante el código interno tendrán que escribir específicamente una API que no dependa del código de Minecraft subyacente, para que pueda ser utiizado por los complementos de Sponge. Sin embargo, se pueden crear complementos que carguen módulos de «compatibilidad» separados para interactuar con la implementación subyacente (SpongeForge o 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)
un mod con nivel de subsistema que se engancha directamente en el juego utilizando LaunchWrapper, generalmente usado para ModSystems (por ejemplo, LiteLoader, FML) y mods independientes (por ejemplo, Optifine). Usted puede interactuar directamente con cualquier aspecto del entorno del juego. Generalmente rompe cada versión.
- 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.
Este tipo de mod puede usarse para implementar complementos cuyas necesidades rebosen la capacidad de la API (en el caso de un complemento que necesita aprovechar mixins para una característica particular); pero también se puede usar para mods que quieran aprovechar los servicios proporcionados por la API (por ejemplo, un mod que desee proporcionar soporte directo para permisos o canales de chat).
A diferencia de los «complementos» de explotación de NMS, un mod híbrido hace de su naturaleza algo claro.
Interoperabilidad de los Complementos
Una explicación de cómo comunicarse con otros complementos, TBA.
