Preguntas frecuentes de Resource Pack Manager

Si tu pregunta no se responde aquí, revisa primero las otras páginas de ResourcePackManager en la barra lateral.

¿Qué comandos expone actualmente ResourcePackManager?

En el backend (Paper / Spigot), la superficie de comandos respaldada por código es:

• /rspm setup — abre un menú de configuración GUI dentro del juego (estado de actualización del plugin, plugins recomendados, interruptor de actualizaciones automáticas, enlaces al wiki / Discord / cuenta de Nightbreak)
• /rspm recommendedplugins — muestra el menú compartido de plugins recomendados de Nightbreak (o una lista de texto en consola)
• /rspm downloadpluginupdate — descarga una actualización disponible de ResourcePackManager para el siguiente reinicio
• /rspm downloadall — descarga todas las actualizaciones disponibles que expone este plugin (actualmente la actualización de ResourcePackManager)
• /rspm applypluginupdate — forma parte del conjunto de comandos compartidos de Nightbreak; RSPM siempre lo rechaza porque sus actualizaciones necesitan reiniciar el servidor (su extensión de Geyser solo se carga cuando Geyser arranca)
• /rspm reload — reconstruye y vuelve a alojar el paquete fusionado
• /rspm status — volcado de diagnóstico completo (estado del paquete, modo de alojamiento, huella de la clave de red, integraciones)
• /rspm verbose [on|off] — activa o desactiva el registro de diagnóstico detallado. Sin argumento, alterna el estado. El resultado se escribe de vuelta en verboseLogging dentro de config.yml, así que persiste entre reinicios. También se acepta como /rspm verboselogging.
• /rspm itemsadder configure — configura ItemsAdder para el alojamiento por RSPM
• /rspm itemsadder dismiss — descarta permanentemente la advertencia de ItemsAdder para el UUID de tu jugador
• /rspm data_compliance_request — descarga todos los datos almacenados de forma remota para este servidor

El comando raíz es /resourcepackmanager, con /rspm como su alias. Los comandos de actualización y de plugins recomendados de arriba son comandos compartidos de MagmaCore/Nightbreak registrados por RSPM.

MagmaCore también registra estos comandos de nivel superior, que no son subcomandos de /rspm:

• /nightbreaklogin <token> y /nightbreaklogout guardan o borran el token compartido de la cuenta de Nightbreak del servidor. Ambos requieren nightbreak.login (op por defecto). Consulta Vinculación de cuenta Nightbreak.
• /nightbreak plugins explora el catálogo de plugins de Nightbreak y requiere nightbreak.plugins (op por defecto).
• /logify sube el registro actual del servidor a mclo.gs y requiere logify.* (op por defecto).
• /resourcepackmanagerchangelog [dismiss|disable] muestra a los administradores las notas de versión de ResourcePackManager que no han leído. Consulta Notificaciones de changelog.

El plugin de Nightbreak que cargue primero registra /nightbreaklogin, /nightbreaklogout, /nightbreak y /logify para todo el servidor.

Permisos en el backend:

• /rspm setup y /rspm recommendedplugins requieren resourcepackmanager.setup. /rspm setup es solo para jugadores porque abre una GUI de inventario.
• /rspm downloadpluginupdate, /rspm downloadall, /rspm applypluginupdate, /rspm reload, /rspm status, /rspm verbose, /rspm itemsadder <configure|dismiss> y /rspm data_compliance_request requieren resourcepackmanager.*.

En el plugin del proxy (Velocity / BungeeCord), solo existen comandos de diagnóstico:

• /rspm status — instantánea del lado del proxy: lista de backends, resultados de obtención por backend, estado del paquete fusionado, detección de Geyser/Floodgate
• /rspm debug bedrock [on|off] — Velocity y BungeeCord. Alterna las líneas de log verbosas [RSPM-BedrockDebug] emitidas por GeyserBinder para diagnosticar casos de "el jugador de Bedrock se conectó pero no vio el paquete". Se restablece a off al reiniciar el proxy. Ejecutarlo sin argumento imprime el estado actual.

En Velocity, los comandos del proxy aceptan resourcepackmanager.command.status o resourcepackmanager.*. BungeeCord registra el nodo exacto resourcepackmanager.command.status; un plugin de permisos puede satisfacerlo igualmente mediante expansión de comodines. La consola puede ejecutar los comandos. La salida es segura de compartir — la clave de red aparece solo como una huella hash corta de un solo sentido, nunca la clave en sí, y no se imprimen tokens —, por lo que conceder estos permisos de forma amplia no supone ningún problema.

¿Qué plugins son compatibles actualmente?

ResourcePackManager incluye entradas de integración predefinidas para estos plugins:

• BackpackPlus
• BetterHUD
• BetterStructures
• CannonRTP
• EliteMobs
• EternalTD
• FreeMinecraftModels
• InfiniteVehicles
• ItemsAdder
• MegaBlockSurvivors
• MMOInventory
• ModelEngine
• Nexo
• Nova
• Oraxen
• RealisticSurvival
• ResurrectionChest
• ValhallaMMO
• vane-core

Estas integraciones solo surten efecto si el plugin está instalado y su ruta local o URL remota configurada es utilizable.

Cada integración tiene su propio archivo de configuración YAML en plugins/ResourcePackManager/compatible_plugins/. Allí puedes personalizar isEnabled, pluginName, localPath, url, zips, cluster, additionalLocalPath y reloadCommand por plugin. La opción cluster le indica a ResourcePackManager que trate la ruta local como un directorio de varias subcarpetas de paquetes de recursos que deben fusionarse todas juntas.

¿Cómo excluyo una integración automática de plugin?

Pon isEnabled: false en el archivo de esa integración bajo plugins/ResourcePackManager/compatible_plugins/ y luego ejecuta /rspm reload (o reinicia). RSPM elimina las entradas de paquete de recursos que generó o registró para esa integración, incluidas sus copias generadas en el mezclador. Quitar el plugin de priorityOrder no lo excluye; solo mueve ese paquete a la prioridad más baja. Para excluir un ZIP que añadiste manualmente, elimínalo o muévelo fuera de la carpeta mixer.

¿Es ResourcePackManager compatible con ItemsAdder?

Sí. ResourcePackManager incluye un asistente integrado y un flujo de advertencia para ItemsAdder.

Si ItemsAdder está instalado y aún necesita ser ajustado para el alojamiento por ResourcePackManager, los jugadores OP reciben una advertencia clicable unos segundos después de conectarse. Los jugadores que descartaron permanentemente la advertencia ya no la ven. Desde allí puedes:

• ejecutar /rspm itemsadder configure para establecer resource-pack.hosting.no-host.enabled: true, desactivar las tres opciones protect-file-from-unzip, establecer compress-json-files: false, ejecutar /iareload y luego /iazip, y esperar a que RSPM fusione la exportación regenerada (informa de si la fusión tiene éxito o falla; no recarga RSPM)
• ejecutar /rspm itemsadder dismiss para descartar permanentemente esa advertencia para tu UUID de jugador

Si ItemsAdder ya está configurado para alojar su propio paquete mediante uno de sus modos de alojamiento, el comando asistente no lo anula automáticamente. Te indica que desactives manualmente el alojamiento de ItemsAdder primero.

¿Puedo añadir mi propio paquete a la mezcla?

Sí, y hay dos sitios donde ponerlo según lo que tengas.

Un .zip terminado va en:

plugins/ResourcePackManager/mixer

Si deseas controlar qué paquete gana los conflictos de archivos, añade el nombre exacto del archivo, incluyendo .zip, a priorityOrder en plugins/ResourcePackManager/config.yml.

Una carpeta de paquete descomprimida (un árbol assets/ más pack.mcmeta) va en:

plugins/ResourcePackManager/resource_pack

RSPM comprime esa carpeta él mismo y la fusiona bajo la entrada ResourcePackManager de priorityOrder, que está en lo más alto de la lista por defecto — así que, por defecto, sus archivos ganan los conflictos frente a todos los paquetes de plugins. Baja ResourcePackManager en la lista si prefieres que pierda.

La carpeta relacionada plugins/ResourcePackManager/blueprint contiene el pack.png y el pack.mcmeta que RSPM aporta a cada fusión. Edita esos dos archivos para cambiar el icono del paquete fusionado o su descripción en el menú; la carpeta se vuelve a comprimir en blueprint.zip en cada arranque.

Ejemplo:

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

¿Cómo funciona la prioridad?

priorityOrder tiene la mayor prioridad arriba y la menor abajo.

Para archivos no fusionables, el paquete de mayor prioridad reemplaza al archivo de menor prioridad. Para archivos JSON fusionables, ResourcePackManager fusiona el contenido en lugar de reemplazarlo a ciegas.

El código trata actualmente como fusionables:

• sounds.json
• archivos de idioma bajo lang o languages
• JSON de modelos de ítems vanilla bajo minecraft/models/item (estos reciben una fusión no recursiva: solo se combina el array overrides entre paquetes, mientras que el resto del archivo sigue la regla de que gana la mayor prioridad)
• archivos de atlas
• archivos de fuente
• definiciones de modelos de ítems 1.21.4+ bajo items/ (fusión consciente del formato: deja los árboles de predicados intactos, no entra recursivamente a ciegas en distintos tipos de nodos)

pack.mcmeta se fusiona de forma especial: gana el pack_format más alto y se combinan los rangos de formato declarados. Se combinan las entradas de overlay con directorios distintos; si el directorio coincide, gana la entrada de mayor prioridad. Cada overlay conserva los valores formats, min_format, max_format y los metadatos adicionales de su autor. La única adición: Minecraft 1.21.9+ rechaza una lista de overlays en la que algún overlay llega al formato de paquete 64 o inferior y otro no declara formats, así que cuando una lista fusionada contiene un overlay así, RSPM da a cada entrada que solo declara min_format/max_format un rango formats equivalente. Aparte de eso, RSPM no reescribe los rangos de los overlays. Los campos adicionales de pack, overlays y el objeto de nivel superior se conservan cuando no entran en conflicto con un valor de mayor prioridad.

Tras fusionar todos los paquetes, ResourcePackManager fusiona las fuentes de atlas base en los archivos de atlas de overlay. Esto evita que los overlays oculten accidentalmente entradas del atlas base cuando Minecraft activa un overlay (p. ej. ia_overlay_modern_atlas / ia_overlay_legacy_atlas de ItemsAdder).

Otros archivos JSON se reemplazan en lugar de fusionarse.

Los paquetes que no estén listados en priorityOrder se incluyen igualmente en la mezcla pero reciben la prioridad más baja.

Las entradas ZIP completas byte a byte idénticas se deduplican antes de fusionar, conservando la primera copia (la de mayor prioridad). Tras la fusión, RSPM también repara dos defectos comunes de los modelos Java: añade una textura particle faltante a partir de la primera textura concreta del modelo cuando es posible, y recorta las coordenadas UV de modelo inválidas al rango 0..16 de Minecraft.

¿ResourcePackManager se reconstruye automáticamente cuando los paquetes cambian?

Sí. Vigila los cambios en las fuentes de paquetes compatibles.

Cuando un paquete vigilado deja de cambiar durante 3 segundos, ResourcePackManager lo marca como estable. Una vez que todos los paquetes vigilados son estables, la nueva mezcla ocurre inmediatamente. Durante esa transición, los jugadores OP en línea reciben la notificación: "All resource packs are stable. Mixing and sending now."

Una nueva mezcla cuyas entradas son byte a byte idénticas a la anterior no vuelve a fusionar. RSPM calcula una huella de la lista ordenada de paquetes de origen (nombre, tamaño, hash de contenido) y la guarda junto a la salida como .rspm_mix_fingerprint; cuando la huella coincide y todos los archivos de salida esperados siguen presentes, republica el zip existente en lugar de reconstruirlo. Cualquier cosa dudosa — una salida faltante, una huella ilegible, un ZIP fusionado cuyo SHA-1 ya no coincide — cae en una mezcla completa. Por eso también un /rspm reload que no cambia nada puede terminar casi al instante y reutilizar el registro de alojamiento existente.

Cuando las entradas de Java no han cambiado pero hay que rehacer la parte de Bedrock (conversión a Bedrock activada sin paquete de Bedrock en disco, un cambio en bedrockConversionEnabled o en el destino de Bedrock, o una actualización del convertidor que cambia la salida de Bedrock), RSPM conserva el ZIP de Java verificado y rehace solo el paso de Bedrock, así que los bytes y el SHA-1 del paquete de Java no cambian.

Al arrancar, RSPM comprueba la huella guardada y el SHA-1 del ZIP fusionado antes de que los plugins vigilados terminen de inicializarse. Si coinciden, el alojamiento de Java empieza de inmediato a partir del paquete guardado. El watchdog sigue volviendo a mezclar si después cambia un paquete de origen.

¿El watchdog tiene en cuenta la inicialización de plugins?

Sí. El watchdog es consciente de los estados de inicialización de los plugins de Magmacore.

• Espera a que todos los plugins monitorizados terminen su inicialización de Magmacore antes de comenzar las comprobaciones de estabilidad.
• Si un plugin entra en INITIALIZING mientras el watchdog está activo, este se pausa y restablece el seguimiento de estabilidad hasta que termine la inicialización. Las integraciones opcionales fallidas o sin inicializar no bloquean indefinidamente todo el mezclador.
• Esto evita falsas detecciones de "inestable" que de otro modo ocurrirían durante secuencias normales de arranque o recarga de plugins.

¿Cómo reciben los jugadores el paquete final?

Cuando autoHost está activado (por defecto), o cuando selfHostForce lo anula explícitamente, RSPM elige una ruta de entrega y envía esa URL a cada jugador de Java que se conecta. El árbol de decisión es:

1. Con selfHostForce: true, intenta el autoalojamiento sin sondeos, principalmente para pruebas. La validación de la URL y el inicio del servidor HTTP deben seguir funcionando.
2. En caso contrario, con preferSelfHost: true (por defecto) y selfHostEnabled: true, comprueba la dirección, compara muestras del paquete descargadas desde localhost y la URL exacta del jugador, y exige accesibilidad externa mediante magmaguy.com. Elige el autoalojamiento solo si todas las comprobaciones pasan.
3. Si el autoalojamiento falla o está desactivado, reutiliza o sube el paquete a magmaguy.com/rsp/ y anuncia esa URL. Un fallo remoto puede recurrir al autoalojamiento si está activado, pero debe pasar las mismas comprobaciones. Un sondeo externo no disponible rechaza el autoalojamiento automático; si ambas rutas fallan, no se anuncia una URL de entrega nueva.

Una vez que tiene una URL, RSPM usa la API de varios paquetes para poder coexistir con otros paquetes enviados por el servidor. El descriptor actual del plugin de Bukkit requiere Minecraft 1.21.4 o posterior.

La oferta al conectarse se aplaza alrededor de un segundo. Una respuesta FAILED_DOWNLOAD o DISCARDED se reintenta automáticamente, hasta tres intentos para esa sesión de jugador; un paquete rechazado, una URL inválida o un FAILED_RELOAD (falló la recarga de recursos del propio cliente; revisa el latest.log de ese cliente) no se reintentan. Los jugadores de Floodgate se omiten aquí porque su paquete de Bedrock se entrega a través de Geyser.

Si autoHost: false y selfHostForce: false, RSPM no envía ninguna URL — se espera que tomes el zip de plugins/ResourcePackManager/output/ y lo sirvas a través de tu propia canalización.

Consulta Autoalojamiento para el árbol de decisión completo de entrega.

¿Puedo autoalojar en lugar de usar el alojamiento automático integrado?

Sí — y a partir de RSPM v2, el servidor HTTP integrado es la ruta de autoalojamiento recomendada. selfHostEnabled: true y preferSelfHost: true están ambos activos por defecto.

Si deseas alojar el zip a través de tu propio servidor web ya existente en lugar de cualquiera de las rutas integradas:

• Establece autoHost: false.
• Opcionalmente establece resourcePackRerouting a una ruta de carpeta existente relativa al directorio plugins.
• Toma el paquete fusionado de plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip y sírvelo tú mismo.

Si resourcePackRerouting está establecido, RSPM también escribe una copia de ese zip en la carpeta de redireccionamiento. Esa ruta se resuelve relativa al directorio plugins, y la carpeta de destino debe existir previamente.

¿Hay un comando para solicitar los datos almacenados en el host?

Sí. Usa:

/rspm data_compliance_request

Si el auto-host remoto de magmaguy.com tiene una sesión activa, ResourcePackManager descarga la respuesta en:

plugins/ResourcePackManager/data_compliance/data.zip

RSPM también escribe un ReadMe.md en esa misma carpeta data_compliance.

Si no hay una sesión remota activa (p. ej. estás autoalojando), el comando te indica que no hay datos remotos que solicitar.

¿Qué opciones de configuración hay disponibles?

plugins/ResourcePackManager/config.yml expone las siguientes:

General

• priorityOrder — lista que controla qué paquetes ganan los conflictos de archivos (mayor prioridad primero)
• autoHost — si ResourcePackManager auto-aloja y envía el paquete fusionado (booleano, por defecto true)
• forceResourcePack — si se fuerza a los jugadores a aceptar el paquete (booleano, por defecto false)
• resourcePackPrompt — el mensaje de aviso mostrado cuando se ofrece el paquete (por defecto "Use recommended resource pack?")
• resourcePackRerouting — ruta de carpeta opcional (relativa a plugins) donde escribir una copia adicional del zip fusionado
• verboseLogging — imprime cada paso de la preparación del paquete y del handshake de alojamiento (booleano, por defecto false). Desactivado por defecto para que la consola muestre solo el resultado final; actívalo cuando estés diagnosticando un problema de fusión o de alojamiento. /rspm verbose on|off cambia esta misma clave en tiempo de ejecución y la guarda. Es independiente de bedrockConverterDebug, que cubre la canalización de Bedrock.
• nightbreak.autoDownloadPluginUpdates — si RSPM descarga automáticamente sus propias actualizaciones de plugin al arrancar (booleano, por defecto false; aún se requiere un reinicio para aplicar una actualización descargada). Esta es una clave anidada bajo la sección nightbreak:, no una clave de nivel superior — buscar en config.yml una línea autoDownloadPluginUpdates suelta solo la encontrará indentada bajo nightbreak:. Es el mismo interruptor expuesto en la GUI de /rspm setup. Las descargas automáticas del plugin necesitan un token de cuenta de Nightbreak válido y una membresía activa de supporter en Patreon. RSPM no escribe la clave compartida nightbreak.applyPluginUpdatesWithoutRestart y nunca aplica una actualización descargada sin reiniciar, porque su extensión de Geyser solo se carga cuando Geyser arranca.

Autoalojamiento

• selfHostEnabled — si el servidor HTTP integrado puede usarse (booleano, por defecto true)
• selfHostPort — puerto del servidor HTTP de autoalojamiento. -1 (por defecto) lo calcula como mcPort + networkHttpOffset-v2. Los puertos explícitos y calculados deben estar entre 1 y 65535.
• networkHttpOffset-v2 — desplazamiento de respaldo añadido al puerto del servidor de Minecraft cuando selfHostPort = -1. Por defecto 1 (p. ej. MC 25565 → HTTP 25566). En una red ya no tienes que mantenerlo sincronizado con el proxy: el backend anuncia automáticamente al proxy el puerto HTTP exacto al que realmente se enlazó, y el proxy solo usa su propio network-http-offset-v2 como conjetura antes de que llegue ese anuncio.
• selfHostExternalHost — nombre de host público o IP que los clientes usan para acceder a tu servidor de autoalojamiento. Vacío (por defecto) = detección automática del host.
• selfHostExternalUrl — URL pública HTTP/HTTPS completa del paquete, incluida su ruta, para un proxy inverso. Vacía por defecto. Sustituye la URL anunciada, sin cambiar el servidor que escucha localmente; se rechazan las credenciales incrustadas y los fragmentos.
• selfHostForce — omite todas las comprobaciones de cordura Y la subida remota, siempre autoaloja (booleano, por defecto false — para pruebas).
• preferSelfHost — intenta autoalojar primero con comprobaciones de cordura antes de recurrir a la subida remota (booleano, por defecto true).

Bedrock

• bedrockConversionEnabled — convierte el paquete Java fusionado en un paquete de Bedrock para GeyserMC (por defecto true)
• bedrockAutoDeployToGeyser — copia el archivo de mappings personalizados de Geyser a la carpeta de Geyser detectada (por defecto true)
• bedrockGeyserFolder — sobrescritura manual de la ruta para la carpeta de Geyser; vacío = autodetectar
• bedrockConverterDebug — líneas de log verbosas por ítem / por hueso de la canalización de Bedrock (por defecto false)
• geyserExtensionAutoInstall — instala y actualiza el ResourcePackManager.jar universal como extensión de Geyser para que se rendericen las entidades de Bedrock personalizadas (por defecto true). Ponerlo en false detiene la instalación y la preparación de actualizaciones futuras; no borra un jar de extensión que ya esté ahí — elimínalo a mano con Geyser detenido. El plugin del proxy tiene el mismo interruptor con otro nombre, geyser-extension-auto-install.

Las versiones anteriores también tenían plugins/ResourcePackManager/bedrock_display_offsets.yml, con ajustes de desplazamiento de los ítems en mano. Ya no se lee: las poses de los ítems en mano en Bedrock proceden ahora de las transformaciones display del modelo Java. Consulta Poses de ítems en mano.

Intencionadamente no existe ninguna opción de configuración network-key, ni en el backend ni en el proxy. Pegar una clave a mano era la mayor fuente de configuraciones erróneas: una errata rompía en silencio el enlace proxy↔backend sin ningún error en ninguna parte.

En su lugar, el proxy es el dueño de la clave de red y la reparte:

• El proxy primero lee un network-key guardado y válido, después intenta derivar la clave de plugins/floodgate/key.pem y, si ninguno está disponible, genera una clave aleatoria. Guarda el resultado en su carpeta de datos. Los siguientes arranques reutilizan la clave mientras sea válida; perderla repite el proceso y puede recrear la misma clave derivada de Floodgate. Consulta la recuperación de la clave de red.
• Cada backend recibe esa clave por el canal de plugin rspm:network la primera vez que un jugador se conecta a él, y después la guarda de forma persistente en su propio data.yml. Un backend que ya tiene una clave ignora concesiones posteriores: reapuntar un backend a otra red es una acción del operador, no algo que pueda hacer un mensaje.
• Floodgate no es necesario para enlazar RSPM. La autenticación de Bedrock depende del modo de autenticación elegido en Geyser; consulta Floodgate y autenticación en línea.
• Un servidor independiente (sin proxy) genera y conserva su propia clave, porque él mismo es una red de un solo servidor.

/rspm status, en cualquiera de los dos lados, imprime una huella hash corta y unidireccional de la clave, nunca la clave en sí. Las huellas coincidentes indican una identidad de red compartida; comprueba por separado los resultados de las descargas para verificar la conectividad y la entrega de paquetes.

¿Por qué la consola muestra tan pocos mensajes? ¿Está haciendo algo?

Es intencionado. Preparar un paquete es una canalización larga — preparar el paquete de cada plugin contribuyente, fusionar clústeres, esperar a que dejen de cambiar, mezclar, convertir para Bedrock, entregar el resultado a un host. Narrar todo eso producía unas sesenta líneas de consola por arranque y enterraba las dos únicas cosas que alguien lee: si los jugadores van a recibir el paquete, y qué hacer si no lo reciben.

Así que un arranque normal imprime una línea:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip

Esa línea confirma la publicación de una URL de entrega. Conéctate con un cliente e inspecciona contenido personalizado conocido para verificar la descarga y la representación gráfica.

RSPM tampoco avisa deliberadamente de condiciones que arregla por sí mismo. Si un sondeo de autoalojamiento falla y RSPM recurre al alojamiento remoto, eso es un éxito — la consola informa del resultado, no del rodeo. Avisar de algo que ya está resuelto se lee como un fallo y hace que la gente persiga un problema inexistente.

Para ver la narración completa, ejecuta /rspm verbose on (o pon verboseLogging: true en config.yml) y después /rspm reload. Para el convertidor de Bedrock en concreto, usa bedrockConverterDebug: true en su lugar.

¿Pueden otros plugins registrar sus paquetes mediante código?

Sí. ResourcePackManager expone una API de Java para el registro programático de paquetes. Consulta la página de API para más detalles.

¿La conversión a Bedrock solo funciona para FreeMinecraftModels?

No, ya no. El convertidor actual gestiona recursivamente cualquier plugin cuyo paquete incluya definiciones de ítems 1.21.4+ bajo assets/<namespace>/items/**/*.json. Eso cubre modelos por huesos de FreeMinecraftModels, equipo de EliteMobs, ítems personalizados de Oraxen/Nexo, sets de armadura personalizados y cualquier paquete que tú mismo construyas en ese formato. Los ítems personalizados 2D planos se emiten como iconos planos de Bedrock; los ítems 3D personalizados emiten geometría/attachables de Bedrock y un icono de inventario renderizado por software.

¿Necesito reiniciar el servidor cada vez que cambia el paquete de Bedrock?

Los ajustes de textura y modelo de objetos personalizados existentes surten efecto para el siguiente jugador de Bedrock que se conecte: RSPM sirve el paquete de Bedrock en vivo por sesión mediante la API de Geyser. Reinicia el proceso que aloja Geyser cuando cambien las asignaciones de objetos personalizados o cuando deban registrarse nuevos identificadores de entidades personalizadas o tipos de propiedades. Estos registros se realizan al arrancar. Las exportaciones repetidas de identificadores de entidades ya registrados, sin cambios en sus tipos de propiedades, no requieren por sí solas otro reinicio.

¿Funciona ResourcePackManager en BungeeCord / Velocity?

Sí. Instala el mismo ResourcePackManager.jar en el proxy y en cada backend que proporcione paquetes de recursos. El jar incluye los puntos de entrada de Bukkit, Velocity y BungeeCord. Un backend detrás de un proxy prepara una copia en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar si no ha recibido una clave de red. Los demás servidores registrados pueden funcionar sin RSPM; la detección de backends evita que retrasen la sincronización de paquetes.

Ejecutándose como plugin del proxy, fusiona el paquete de Bedrock convertido de cada backend y lo sirve a los clientes de Bedrock a través del Geyser del proxy. La entrega del paquete Java sigue siendo gestionada por cada backend directamente — los clientes de Java ven los paquetes por backend.

Los pasos de configuración, solución de problemas y verificación están en Redes proxy.