Referenciadev

API

Leer el catálogo de skins, el vestidor de un jugador y las skins escritas en la armadura.

ArmorSkinService es por donde otro plugin lee y maneja ExyliaArmorSkin: el catálogo, el vestidor en el que elige el jugador, y las skins escritas en la armadura misma.

ExyliaAPI.get(ArmorSkinService.class).ifPresent(skins -> {
    skins.select(player, ArmorPiece.HELMET, "sakura");
    skins.skinItem("sakura").ifPresent(item -> player.getInventory().addItem(item));
});

Agregarlo a tu proyecto

El artefacto, el repositorio y la línea del plugin.yml son los mismos para todos los plugins de Exylia y están en la página de la API pública.

Todo se direcciona por id de skin, comparado sin distinguir mayúsculas. Un id que el catálogo no declara no es un error — una recarga puede quitar uno mientras una caja todavía lo reparte —, así que las búsquedas devuelven vacío y las escrituras devuelven false.

El catálogo

Método	Qué hace
`skins()`	Todas las skins que declara el servidor, en el orden en que las dibuja el menú. Una foto: sirve para montar una tienda, sobra dentro de un bucle.
`skin(String skinId)`	Una skin como `Optional<ArmorSkin>`. Vacío cuando el catálogo no declara ese id.
`exists(String skinId)`	Si el catálogo declara ese id.

Permisos

Método	Qué hace
`canUse(Player, String skinId)`	Si puede llevar la skin en al menos una pieza.
`canUse(Player, String skinId, ArmorPiece)`	Si puede llevarla en esa pieza concreta.

Los dos responden con la regla del propio servidor, que incluye el ajuste que apaga los permisos por completo: una tienda que pregunta recibe la misma respuesta que daría el vestidor, no una comprobación cruda de nodo. La forma por pieza existe aparte porque un rango se vende ranura a ranura: quien tiene el nodo del casco lleva la skin en la cabeza y en ningún otro sitio.

El vestidor

Método	Qué hace
`mode()`	De dónde salen las skins que dibuja este servidor, como `SkinMode`.
`selected(UUID player, ArmorPiece)`	El id de skin elegido para esa ranura, como `Optional<String>`. Vacío cuando no eligió ninguna, el vestidor está apagado, o su vestidor todavía se está leyendo.
`select(Player, ArmorPiece, String skinId)`	Fija la elección de esa ranura. `true` cuando quedó guardada.
`clear(Player, ArmorPiece)`	Quita la skin elegida de una ranura. `true` cuando había algo que quitar.
`clearAll(Player)`	Quita todas las skins elegidas. `true` cuando había algo que quitar.

selected es una elección, no un resultado: sigue puesta con la ranura vacía, y la skin vuelve a aparecer en cuanto el jugador se equipa una armadura que encaje.

select fija, y aquí además comprueba

select fija en vez de alternar: llamarlo dos veces deja la skin puesta. En este plugin sí pasa por permiso: el vestidor ofrece una sola escritura, esa escritura aplica la regla del servidor, y a un jugador que no puede llevar la skin se le rechaza. Es lo contrario de ExyliaArmorTrims y ExyliaArrows, donde el ajuste del propio dueño dice que la selección nunca se limita por nodo. Pregunta antes por canUse(Player, String, ArmorPiece) si quieres saber el motivo antes de pedirlo.

Skins en los objetos

Método	Qué hace
`skinOf(ItemStack armor)`	El id de skin escrito en esa armadura, como `Optional<String>`. Vacío cuando no lleva ninguna.
`apply(ItemStack armor, String skinId)`	Escribe una skin en la armadura, en el sitio, conservando todo lo demás que tenía. `true` cuando se escribió.
`strip(ItemStack armor)`	Quita la skin y no devuelve nada a cambio. `true` cuando había una.
`skinItem(String skinId)`	Un objeto de skin listo para entregar, como `Optional<ItemStack>`. Vacío cuando el catálogo no declara esa skin.
`isSkinItem(ItemStack)`	Si un objeto es uno de los objetos de skin del plugin.

Pregunta isSkinItem antes de que un cofre, una tienda o un intercambio traten un stack como botín normal: un objeto de skin se dibuja como le convenga y no es el material que aparenta.

Redibujar

Método	Qué hace
`refresh(Player)`	Recalcula cómo se ve el jugador y lo reenvía a todos los que puedan verlo.

Solo hace falta cuando cambió algo que el service no conoce: un permiso concedido en caliente, un objeto cambiado por otro plugin. Todas las escrituras de arriba ya redibujan.

Tipos

ArmorSkin — id, name (con los códigos de color dentro), permission (el nodo que concede la skin en todas las piezas donde encaja) y pieces. supports(ArmorPiece) responde si encaja en una ranura. Cómo se ve la skin no está a propósito: eso es el código de dibujo del plugin, y skinItem ya cubre lo que necesita un tercero.

ArmorPiece — HELMET, CHESTPLATE, LEGGINGS, BOOTS. slot() da el EquipmentSlot de Bukkit, para que quien lea un inventario no mantenga un switch propio al día.

SkinMode — de dónde sale la skin dibujada: ITEM (solo lo que un objeto de skin escribió en la armadura), WARDROBE (solo lo que eligió quien la lleva; los objetos de skin no hacen nada) o BOTH. usesItems() y usesWardrobe() responden sin switch. Vale la pena preguntarlo antes de escribir nada: la mitad que un servidor no usa devuelve false o vacío en lugar de lanzar, así que una integración escrita para las dos funciona en cualquiera.

Las consultas son baratas, las acciones no

Todo lo que devuelve un valor lee la caché del plugin y es seguro desde un redibujado de menú o un placeholder. Todo lo que cambia un vestidor escribe en la base de datos y redibuja al jugador para todos los que lo ven: llama a eso desde el hilo principal, y no más seguido de lo que podría un jugador.

Lo que no expone

No hay eventos: ExyliaArmorSkin no publica ninguno. Los abridores de menú, el flujo de edición del vestidor, las definiciones de animación y las filas crudas de configuración quedan fuera a propósito: un contrato público no se puede romper después, así que lleva lo que una integración necesita y nada que solo tuviera sentido dentro de una versión.

Si de verdad te falta algo, pídelo en Discord.

¿Falta algo en esta página? Dínoslo en Discord