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 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.

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 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 después recargar ResourcePackManager (~15 s más tarde)
• 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, los rangos de supported_formats se amplían para cubrir todos los paquetes (admite las formas de entero, array de dos enteros y objeto {min_inclusive, max_inclusive}), las entradas de overlay se combinan y las claves de nivel superior no estándar (p. ej. sodium) se conservan. Las entradas de overlay se normalizan para compatibilidad con 1.21.9+ añadiendo los campos min_format/max_format cuando faltan.

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, la conversión a Bedrock activada sin paquete de Bedrock en disco — 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.

¿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 se recarga mientras el watchdog está activo, este detecta el cambio de estado, se pausa, restablece todo el seguimiento de estabilidad y espera a que el plugin termine de reiniciarse.
• 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. Si selfHostForce: true, siempre autoaloja (omite todos los sondeos — principalmente para pruebas).
2. En caso contrario, si preferSelfHost: true (por defecto), intenta autoalojar primero, ejecuta tres comprobaciones de cordura (host resuelto no-LAN, sondeo a sí mismo en localhost, sondeo de accesibilidad externa vía magmaguy.com) y se decide por autoalojar si las tres pasan.
3. Si el autoalojamiento falla o está desactivado, sube el paquete a magmaguy.com/rsp/ y anuncia esa URL.

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 o una URL inválida 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.

Autoalojamiento

• selfHostEnabled — si el servidor HTTP integrado puede usarse (booleano, por defecto true)
• selfHostPort — puerto para el servidor HTTP de autoalojamiento. -1 (por defecto) lo deriva automáticamente como mcPort + networkHttpOffset-v2. Establécelo a cualquier entero positivo para forzar un puerto explícito.
• 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 — hostname público o IP que los clientes usan para alcanzar tu servidor de autoalojamiento. Vacío (por defecto) = autodetectar vía api.ipify.org / checkip.amazonaws.com.
• 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.

Un segundo archivo, plugins/ResourcePackManager/bedrock_display_offsets.yml, expone doce parámetros ajustables por el usuario para afinar dónde ven los jugadores de Bedrock los ítems en mano respecto a su mano (seis para primera persona, seis para tercera persona). Consulta Conversión a Bedrock para más detalles.

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 resuelve su clave una sola vez: lee su archivo network-key guardado si existe, si no toma el valor inicial de plugins/floodgate/key.pem si ese archivo existe (para que una red ya existente conserve su identidad tras la actualización), y si no genera una nueva. En cualquier caso guarda el resultado en network-key dentro de la carpeta de datos del propio plugin del proxy y nunca vuelve a mirar key.pem.
• 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 esto. Sí es necesario para que los jugadores de Bedrock puedan llegar al proxy, pero una red solo de Java puede usar las funciones de proxy de RSPM sin él.
• 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í. Si las huellas del proxy y del backend coinciden, el enlace está bien.

¿Por qué la consola está tan callada? ¿Está haciendo algo siquiera?

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

Si ves esa línea, funcionó.

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 a ítems 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. Solo se requiere un reinicio cuando cambia el conjunto de ítems personalizados (añadir nuevos o eliminar existentes), porque Geyser registra sus identificadores de ítems personalizados al arrancar.

¿Funciona ResourcePackManager en BungeeCord / Velocity?

Sí — es una topología soportada de primera clase. Es el mismo ResourcePackManager.jar en todas partes: colócalo en cada backend y coloca una copia en el proxy. El único jar incluye los puntos de entrada de Bukkit, Velocity y BungeeCord/Waterfall, de modo que se carga correctamente tanto si el host es un backend como si es un proxy. No hay jars de proxy separados por plataforma que construir o extraer — y si te olvidas de la copia del proxy, un backend con proxy te prepara una en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar y lo indica en la consola.

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.