Solución de problemas de Resource Pack Manager

Esta página solo cubre el comportamiento que está confirmado actualmente en el código de ResourcePackManager.

El primer paso más útil para cualquier problema de RSPM es:

/rspm status

Imprime la versión, el modo de despliegue (independiente vs network-backend), una huella corta y no secreta de la clave de red más de dónde vino esa clave, el estado de los paquetes Java + Bedrock, la ruta de entrega activa con la URL, el host externo resuelto + la IP pública autodetectada, el resultado de la última comprobación de autoalojamiento, todos los flags de configuración relevantes, un recordatorio de despliegue del proxy (el jar del proxy de red es el mismo ResourcePackManager.jar) y la detección de Floodgate / Geyser-Spigot. El mismo comando existe cuando el jar se ejecuta en un proxy e imprime los equivalentes del lado del proxy (lista de backends, resultados de obtención por backend, estado del paquete fusionado).

La consola muestra pocos mensajes de forma deliberada

RSPM imprime una línea cada vez que inicializa de cero una ruta de entrega — el resultado:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip
[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

Todo lo demás — cada paquete preparado, cada clúster fusionado, cada comprobación de estabilidad, cada sondeo de autoalojamiento y su resultado — se suprime por defecto. Una condición de la que RSPM se recupera por sí mismo no se reporta como advertencia. Si un sondeo de autoalojamiento falla y RSPM cambia silenciosamente al alojamiento remoto, eso es un éxito, no un fallo, y la consola no dice nada al respecto.

La línea de resultado significa que RSPM eligió y publicó una URL de entrega. No demuestra que un cliente concreto haya descargado o representado el paquete. Verifícalo con un jugador que se conecte e inspecciona un objeto o modelo personalizado conocido. Antes de informar de un fallo de alojamiento o fusión, activa el registro detallado:

/rspm verbose on

y luego /rspm reload. Ese comando escribe verboseLogging: true en plugins/ResourcePackManager/config.yml por ti y la opción sobrevive a los reinicios, así que ejecuta /rspm verbose off cuando termines. Editar la clave a mano hace lo mismo. El convertidor de Bedrock tiene un interruptor aparte, bedrockConverterDebug, que es solo de configuración.

Las advertencias que sí puedes ver legítimamente son fallos genuinos: fallo repetido en la entrega del paquete a un jugador concreto, un cliente informando de INVALID_URL, un puerto HTTP que no se pudo enlazar, el fallo de ambas rutas de entrega, o un proxy que ha sondeado varios ciclos sin que ningún backend produzca contenido.

Los jugadores no están recibiendo el paquete de recursos

Comprueba primero estos puntos:

• autoHost debe estar activado si quieres la entrega automática normal (selfHostForce es la anulación explícita para pruebas)
• el paquete fusionado debe existir y al menos una ruta de entrega (autoalojamiento o remoto) debe haber tenido éxito
• los jugadores reciben el paquete al conectarse. Los jugadores que se conectaron mientras no había ningún paquete publicado lo reciben cuando el alojamiento queda listo, también cuando el alojamiento se vuelve a registrar más adelante en la sesión (por ejemplo, tras caducar una sesión remota)
• los jugadores de Floodgate se omiten intencionadamente en la entrega de Java porque Geyser es el dueño de su sesión de paquete de Bedrock

Si es necesario:

1. Ejecuta /rspm status y mira la sección "Hosting". Active delivery muestra si el autoalojamiento, el remoto o ninguno está actualmente en uso.
2. Si "active delivery: not yet ready" — la mezcla o la subida aún están en curso. El plugin muestra un banner llamativo en la consola cuando un jugador se conecta demasiado pronto y enviará automáticamente el paquete en el momento en que la entrega esté lista.
3. Si "active delivery: none — hosting disabled or failed" — autoHost está desactivado, o los sondeos de autoalojamiento y la subida remota fallaron ambos. Consulta "Las comprobaciones de cordura del autoalojamiento fallaron" y "El alojamiento automático no puede contactar con el servidor remoto" más abajo.
4. Pon verboseLogging: true, ejecuta /rspm reload, observa la consola en busca de los resultados de la subida / del sondeo de autoalojamiento, y luego vuelve a conectarte con un jugador de prueba. (Sin esa opción los pasos del sondeo no se imprimen — solo la línea final de resultado "Resource pack is live via ...".)

La oferta al conectarse se retrasa alrededor de un segundo. Si un cliente de Java informa de FAILED_DOWNLOAD o DISCARDED, RSPM lo reintenta automáticamente hasta tres intentos para esa sesión de jugador. No reintenta un rechazo del jugador, un INVALID_URL ni un FAILED_RELOAD; el agotamiento repetido de reintentos y las URLs inválidas sí se registran como fallos reales.

FAILED_RELOAD significa que el cliente descargó el paquete, pero falló su propia recarga de recursos, así que volver a descargar el mismo paquete no sirve de nada. RSPM registra Client <name> reported FAILED_RELOAD for the resource pack. Check that client's latest.log for the resource reload error; not retrying. Lee el latest.log del cliente de ese jugador para encontrar el recurso o los metadatos del paquete que rechazó el cliente.

Si otro sistema se encarga del alojamiento y la entrega (autoHost: false), RSPM no envía su URL. Para colocar un proxy inverso HTTPS delante de RSPM, mantén autoHost: true y utiliza selfHostExternalUrl. Así se conservan la entrega automática a jugadores y el alojamiento remoto alternativo.

ItemsAdder está instalado, pero su contenido falta en el paquete final

Esto suele significar que ItemsAdder sigue configurado de una forma que impide a ResourcePackManager leer o alojar su salida.

Usa:

/rspm itemsadder configure

Ese comando actualmente:

• activa resource-pack.hosting.no-host.enabled
• desactiva protection_1, protection_2 y protection_3
• establece resource-pack.zip.compress-json-files: false
• ejecuta /iareload y luego /iazip
• espera a que RSPM fusione la exportación regenerada de ItemsAdder e informa de si la fusión tuvo éxito

No recarga ResourcePackManager. Tras el mensaje de fusión, comprueba el alojamiento con /rspm status.

Si el comando te indica que ItemsAdder ya está alojando su propio paquete, desactiva manualmente el alojamiento de ItemsAdder primero y vuelve a ejecutar el comando.

El paquete fusionado es inválido o no se sube

La integración de alojamiento automático de ResourcePackManager gestiona explícitamente estos tipos de errores del lado del servidor:

• archivos requeridos faltantes
• archivo demasiado grande
• formato de archivo no válido
• sesión faltante
• servidor remoto no disponible

RSPM comprueba por sí mismo el límite de tamaño de archivo antes de subirlo: un paquete Java de más de 50.000 KiB (51.200.000 bytes) no se sube, y la consola muestra Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes. Después, RSPM intenta en su lugar el autoalojamiento verificado. Consulta Autoalojamiento.

Un paquete de más de 250 MiB (262.144.000 bytes) es demasiado grande para cualquier host. Los clientes de Minecraft vanilla se niegan a descargar un paquete de recursos de servidor por encima de ese tamaño, lo aloje quien lo aloje. Cuando RSPM prueba el alojamiento automático con un paquete así, el aviso de la consola indica que ningún host, autoalojamiento incluido, puede entregarlo, y da ambos límites: 262.144.000 bytes para los clientes y 51.200.000 bytes para el alojamiento automático. RSPM no impide autoalojar un paquete de ese tamaño, así que /rspm status aún puede mostrar una URL autoalojada que los clientes vanilla rechazan. Reduce o elimina paquetes de origen y después ejecuta /rspm reload.

Si te topas con uno de estos:

1. Ejecuta /rspm reload para reconstruir el paquete.
2. Comprueba si uno de los paquetes fuente está mal formado, cifrado o es ilegible por algún otro motivo.
3. Comprueba si el paquete final fusionado todavía contiene un pack.mcmeta y un pack.png válidos en la raíz.

Si un paquete activado no se puede extraer o preparar, la mezcla actual se aborta y la consola indica cuál es el paquete que falla. Repara ese paquete, elimina un ZIP añadido manualmente o pon isEnabled: false en su configuración de integración automática antes de recargar.

Metadatos de superposición y estructura del archivo

La fusión final conserva las declaraciones de formato originales de las superposiciones, incluidos formats, min_format, max_format y los metadatos adicionales. Si varios paquetes comparten un directorio de superposición, gana la entrada de mayor prioridad.

Se hace una única reescritura. Minecraft 1.21.9 y posteriores rechazan todo el pack.mcmeta cuando alguna superposición de la lista llega al formato de paquete 64 o inferior y otra superposición no declara formats. Dos paquetes válidos por separado pueden incumplir esa regla una vez combinadas sus listas de superposiciones. Cuando una lista fusionada contiene una superposición cuyo límite inferior es 64 o menos, RSPM añade un rango formats a cada entrada que solo declara min_format y max_format. El rango cubre los mismos clientes que los límites propios de la entrada, con un tope de 64 cuando empieza en 64 o menos. El registro de colisiones anota Added the formats range to N overlay entries. Las entradas que ya declaran formats, o cuyos límites no se pueden analizar, se quedan como están. Aparte de eso, RSPM no concilia rangos de distintas generaciones de clientes ni repara declaraciones inválidas; corrige los metadatos incompatibles en el paquete de origen.

RSPM comprueba que el directorio de superposición sea una ruta relativa no vacía que no salga de la raíz del paquete ensamblado. Rechaza las rutas absolutas, las que tras normalizarse quedan fuera de la raíz y las rutas inválidas. Superar esta comprobación no garantiza que Minecraft acepte el nombre o los metadatos de formato de la superposición.

Un ZIP con Pack Name/assets/ y Pack Name/pack.mcmeta tiene un directorio contenedor adicional. RSPM avisa de ello; vuelve a comprimir el contenido de modo que assets/ y pack.mcmeta estén en la raíz del ZIP. Los archivos cuyo contenido está deduplicado se leen mediante su directorio central para conservar las entradas que comparten datos comprimidos, incluidos los metadatos de animación de texturas.

Texturas del atlas de bloques

El atlas de bloques fusionado expande las fuentes de directorio en referencias exactas a los recursos PNG del paquete fusionado. Conserva el orden de las fuentes y los identificadores de sprites. Las texturas cuyas dimensiones de fotogramas de animación no son seguras para los niveles mip requeridos reciben copias deterministas calculadas con vecino más cercano bajo resourcepackmanager_internal:mip_safe/; los archivos originales permanecen intactos para los cargadores de fuentes y otros cargadores.

Si una textura que usa el atlas de bloques no es un PNG que Java pueda decodificar, RSPM deja esa entrada del atlas tal como la incluyó el paquete y termina la fusión. La consola avisa con Left blocks-atlas texture <resource> unchanged because <path> is not a readable PNG. junto con la ruta completa del archivo. Minecraft omite un sprite que no puede decodificar y sigue cargando el resto del atlas. Sustituye el archivo en el paquete de recursos que lo incluye.

No crees contenido bajo el espacio de nombres reservado resourcepackmanager_internal. Las colisiones se rechazan. Este proceso no es una conversión de Java a Bedrock y no garantiza la compatibilidad con todos los sombreadores personalizados del cliente ni con todas las extensiones de atlas.

Un paquete roto ya no bloquea todo para siempre

Un paquete que no se puede preparar falla igual en cada reintento, así que si se deja tal cual atascaría la entrega de forma permanente — la fusión nunca se completa y el mismo error se repite indefinidamente. Tras tres fallos consecutivos del mismo archivo, RSPM saca ese paquete de la fusión para que los demás puedan distribuirse, y lo dice una vez, bien alto:

[ResourcePackManager] Resource pack X.zip failed to stage 3 times in a row and has been excluded
from the merge so the remaining packs can be delivered. The merged pack is now INCOMPLETE ...

El mensaje significa que al paquete publicado le falta el contenido de ese plugin. La causa habitual es un zip corrupto o escrito a medias.

La exclusión se limpia sola. El registro del fallo se indexa por el tamaño y la fecha de modificación del archivo, así que reparar o reemplazar el archivo retira automáticamente la cuarentena y el paquete vuelve a la siguiente fusión — sin comando, sin reinicio. /rspm reload también reinicia desde cero todos los registros de cuarentena. Los recuentos de fallos que nunca llegaron a tres se descartan tras cualquier mezcla exitosa, de modo que contratiempos transitorios sin relación entre sí repartidos a lo largo de un tiempo de actividad largo no pueden acumularse hasta provocar una exclusión.

Ante un error SESSION_NOT_FOUND del auto-host remoto, RSPM borra su UUID de sesión y se reinicializa en el siguiente tick de keep-alive — sin intervención manual.

Los recursos de un plugin sobrescriben los de otro

Esto se controla mediante priorityOrder en:

plugins/ResourcePackManager/config.yml

Las entradas superiores ganan sobre las inferiores.

Para archivos no fusionables, ResourcePackManager reemplaza el archivo de menor prioridad. Para archivos JSON fusionables, fusiona el contenido en su lugar. Las categorías JSON actualmente fusionables son:

• sounds.json
• archivos de idioma
• JSON de modelos de ítems vanilla en minecraft/models/item (fusión no recursiva: solo se combina el array overrides entre paquetes, 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+ en items/ (fusión consciente del formato que respeta la estructura del árbol de predicados)

pack.mcmeta también se fusiona de forma especial: gana el pack_format más alto y se combinan los rangos de formato declarados. Las entradas de superposición conservan sus rangos y metadatos adicionales; los directorios duplicados usan la entrada de mayor prioridad. La única adición es un rango formats en las entradas que lo necesitan para que la lista combinada cargue en clientes 1.21.9+ (consulta Metadatos de superposición). Aparte de eso, RSPM no repara metadatos incompatibles del autor. Conserva los demás metadatos que no entren en conflicto. Las fuentes del atlas base se fusionan en los archivos de atlas de superposición para evitar que estos oculten entradas base.

Si necesitas inspeccionar qué ocurrió durante la última fusión, consulta:

plugins/ResourcePackManager/collision_log.txt

El texto de la interfaz o los elementos basados en fuentes se ven mal

Los archivos de fuente son una de las categorías JSON que ResourcePackManager fusiona, pero eso no garantiza que dos sistemas de fuentes distintos convivan bien en Minecraft.

Si un menú o HUD basado en fuentes se ve mal:

1. Cambia priorityOrder para que el paquete que deseas que gane tenga mayor prioridad.
2. Ejecuta /rspm reload.
3. Revisa collision_log.txt para confirmar que las colisiones ocurrieron donde esperabas.

Un paquete que añadí a mano falta o se ve mal

1. Confirma que el paquete funciona por sí solo en la misma versión del cliente de Minecraft. Si depende de mods del cliente como OptiFine CEM o CIT, todos los jugadores siguen necesitando ese mod. RSPM fusiona y envía archivos de paquetes; no añade funciones de renderizado en el cliente.
2. Coloca el .zip original en plugins/ResourcePackManager/mixer/. pack.mcmeta, pack.png (si existe) y assets/ deben estar en la raíz del ZIP, no dentro de una carpeta adicional (consulta la estructura del archivo).
3. Añade el nombre de archivo exacto, incluido .zip, a priorityOrder en config.yml. La primera entrada tiene la prioridad más alta. Un ZIP que no aparece en la lista se fusiona igualmente con la prioridad más baja, y los ZIP que comparten esa prioridad se ordenan por nombre de archivo.
4. Ejecuta /rspm reload, y después abre plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip y plugins/ResourcePackManager/collision_log.txt. El registro de colisiones solo lo reescribe una fusión que tuvo colisiones, así que comprueba su hora Generated:.

Para los archivos normales y para los JSON que no se pueden fusionar, como los modelos personalizados, los blockstates y los archivos de equipment, gana el archivo completo del paquete de mayor prioridad. Solo se combinan los tipos de JSON indicados en Los recursos de un plugin sobrescriben los de otro. Por eso, dos paquetes que reemplazan el mismo modelo de entidad o la misma textura necesitan que el ganador previsto figure por encima del otro, o un paquete de compatibilidad hecho para ambos.

Los cambios del paquete de recursos no aparecen de inmediato

ResourcePackManager tiene un watchdog para las fuentes de paquetes compatibles.

Espera hasta que un paquete modificado permanezca sin cambios durante 3 segundos, y entonces, una vez que todos los paquetes vigilados son estables, la nueva mezcla ocurre inmediatamente.

Si estás regenerando activamente el paquete de otro plugin, dale unos segundos después de que terminen las escrituras de archivos. En caso de duda, ejecuta /rspm reload después de que el plugin de origen haya terminado.

/rspm status dice alojamiento remoto, pero yo esperaba autoalojamiento

Puede ocurrir con preferSelfHost: true (por defecto) si falla una comprobación del autoalojamiento. Las comprobaciones de accesibilidad se registran a nivel de detalle y quedan ocultas salvo con verboseLogging: true; algunos mensajes incluyen «This is OK.». Si el alojamiento remoto funciona, el resultado es Resource pack is live via automatic hosting — .... Una configuración inválida o fallos del servidor HTTP o de comunicación remota aún pueden generar advertencias.

La línea Last self-host check de la sección Alojamiento de /rspm status muestra el resultado de la comprobación más reciente, incluido el fallo concreto de descarga o de accesibilidad, sin necesidad de registro detallado. Para ver toda la cadena de decisiones, ejecuta /rspm verbose on (o pon verboseLogging: true) y /rspm reload. Las tres capas son:

1. Capa 1 (heurística) — el host externo resuelto es RFC1918 / loopback / link-local. Bien establece selfHostExternalHost a tu hostname público real, o asegúrate de que el plugin pueda alcanzar api.ipify.org / checkip.amazonaws.com.
2. Capa 2 (descargas locales y de la URL anunciada) — RSPM descarga hasta el primer KiB desde http://127.0.0.1:<port>/rspm.zip y la URL exacta del jugador, y compara ambas muestras con el paquete local. Exige HTTP 200 o 206, longitudes indicadas coincidentes y el Content-Range esperado para 206. Las redirecciones, bytes incorrectos, archivos ausentes y fallos de NAT loopback desde el servidor rechazan el autoalojamiento.
3. Capa 3 (sondeo de accesibilidad externa) — magmaguy.com debe indicar que la URL anunciada es accesible con HTTP 200 o 206. Un puerto HTTP cerrado, una solicitud fallida o el servicio de sondeo no disponible rechazan el autoalojamiento automático. El estado y cualquier código de motivo aparecen con verboseLogging.

Soluciones (en orden de preferencia): abre el puerto HTTP en el cortafuegos y el router, establece selfHostExternalHost con un nombre de host accesible o establece preferSelfHost: false para intentar primero el alojamiento remoto. Establece también selfHostEnabled: false si el autoalojamiento nunca debe usarse como alternativa y deja selfHostForce: false.

Si el servicio de sondeo es inaccesible, el autoalojamiento queda sin verificar y RSPM intenta el alojamiento remoto. El respaldo tras un fallo remoto debe pasar las mismas comprobaciones. Solo selfHostForce: true omite la verificación; si ambas rutas automáticas fallan, RSPM no puede anunciar una URL de entrega nueva. Los sondeos correctos tampoco demuestran una descarga completa y la aceptación del paquete desde la red de cada jugador.

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

El alojamiento automático no puede contactar con el servidor remoto

El host remoto integrado de ResourcePackManager se comunica con:

https://magmaguy.com/rsp/

Si esa conexión falla, el plugin registra advertencias de comunicación y no puede usar el respaldo remoto hasta que vuelva a conectar correctamente.

Tus opciones son:

1. arreglar la conectividad HTTPS saliente del servidor
2. esperar a que el servicio remoto vuelva a estar accesible
3. desactivar autoHost y alojar el zip generado tú mismo
4. abrir el puerto HTTP, establecer selfHostExternalHost con tu nombre público y mantener preferSelfHost: true. El nombre explícito omite la autodetección de IP pública, pero las comprobaciones local, de la URL anunciada y externa deben seguir pasando. Un servicio de sondeo inaccesible impide elegir el autoalojamiento automático.

Quiero autoalojar el paquete fusionado a través de mi propio servidor web

La configuración soportada por el código es:

1. Establece autoHost: false.
2. Establece resourcePackRerouting si quieres que ResourcePackManager escriba una copia adicional en una carpeta existente.
3. Aloja ResourcePackManager_RSP.zip tú mismo.

resourcePackRerouting se resuelve relativo al directorio plugins, y la carpeta de destino debe existir previamente.

Si en cambio quieres usar el servidor HTTP de autoalojamiento integrado de RSPM (cosa distinta — la misma JVM que el plugin), consulta Autoalojamiento.

Necesito inspeccionar qué datos remotos están almacenados para este servidor

Usa:

/rspm data_compliance_request

Si hay una sesión de alojamiento remoto 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 sesión remota (p. ej. estás usando autoalojamiento), el comando informa que no hay datos remotos que solicitar.

El paquete de Bedrock no se está generando

bedrockConversionEnabled por defecto es true, así que debería ejecutarse automáticamente. Ejecuta /rspm status primero — la sección del paquete Bedrock te dirá por qué el paquete no está en disco:

• "No Bedrock target detected" — no hay Geyser-Spigot local, no hay Floodgate local y no está en modo de red. La conversión se omite intencionadamente. Instala Floodgate (para configuraciones de proxy) o Geyser-Spigot (para configuraciones independientes) y ejecuta /rspm reload.
• "Network mode is active so this backend SHOULD produce a Bedrock pack. The file is missing" — normalmente el primer ciclo de mezcla aún no se ha completado (espera ~30 s tras el arranque), o la conversión no encontró ni mappings de ítems convertibles ni paquetes de entidades permitidos, o la conversión lanzó una excepción. Busca en la consola advertencias [BedrockConverter]. Con bedrockConverterDebug: true, el escáner también registra Generic scanner: discovered N item definitions; un recuento de 0 significa que el paquete fusionado no tiene definiciones de ítems convertibles. (El diagnóstico de estado cita esta línea como discovered 0 items definition files.)

Si falla la autodetección de Geyser:

1. Establece bedrockGeyserFolder en config.yml a la ruta de tu carpeta de datos de Geyser (p. ej. Geyser-Spigot).
2. Las rutas absolutas funcionan. Una ruta relativa se prueba primero desde el directorio de trabajo del servidor y después relativa al directorio plugins.

El convertidor autodetecta Geyser en plugins/Geyser-Spigot/, cualquier variante plugins/Geyser-*/, o config/Geyser-*/ para configuraciones Fabric/NeoForge.

Para salida de log por ítem / por hueso, establece bedrockConverterDebug: true y recarga.

Bedrock: el proveedor en vivo se omitió porque existe un paquete heredado

Si la consola informa de Legacy RSPM Bedrock pack detected, Geyser ya escaneó un ResourcePackManager_Bedrock.zip antiguo de su directorio de paquetes durante el arranque. Borrar ese archivo mientras el proceso está en marcha dejaría a Geyser con un códec en memoria para una ruta que ya no existe, así que RSPM omite deliberadamente su proveedor de paquetes en vivo durante ese arranque.

Detén el servidor por completo, borra únicamente la ruta exacta del archivo heredado que RSPM imprimió y vuelve a arrancar el servidor. No uses /reload para esta migración. El paquete actual permanece en plugins/ResourcePackManager/output/ y se sirve por sesión; no pertenece al directorio packs/ de Geyser.

Los jugadores de Bedrock ven los objetos en mano en una posición incorrecta

Primero verifica que se hayan cargado el modelo previsto y el paquete más reciente: vuelve a conectar el cliente de Bedrock para que reciba el paquete actual. RSPM deriva la pose en mano de las transformaciones display.firstperson_righthand y display.thirdperson_righthand del modelo Java, así que una pose que también está mal en Java se corrige en el modelo Java. Si en Java se ve bien y en Bedrock no, infórmalo adjuntando el archivo del modelo.

bedrock_display_offsets.yml y sus opciones de desplazamiento se eliminaron y ya no se leen; editar una copia antigua no tiene ningún efecto. Consulta Poses de ítems en mano.

Las texturas de armadura personalizadas faltan en los jugadores de Bedrock

La armadura personalizada se renderiza en Bedrock combinando la geometría de armadura vanilla con la textura Java como capa visible. Para que esto funcione, el paquete del plugin de origen debe definir un archivo de equipamiento bajo assets/<namespace>/equipment/<material>.json junto a la definición del ítem. Si el log de conversión muestra el ítem pero no aparece textura de armadura en el juego, verifica que ese archivo existe en el paquete fusionado.

Proxy: un backend dice que no tiene clave de red

En el backend, /rspm status muestra Network key source: not set — the proxy sends one when a player next connects here, y la consola repite "This backend is behind a proxy but has no network key yet".

Que falte plugins/floodgate/key.pem no es la causa — ese archivo ahora es opcional. El proxy es el dueño de la clave: carga su propio archivo network-key, o la siembra una vez desde el key.pem de Floodgate si está presente, o genera una clave nueva, y luego se la envía a cada backend cuando un jugador se conecta allí.

Comprueba, en orden:

1. ¿Se ha conectado algún jugador a ese backend desde que arrancó el proxy? La concesión viaja con una conexión de jugador.
2. ¿Está ResourcePackManager.jar realmente en el proxy? El backend prepara una copia de su propio jar por ti en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar e imprime esa ruta — cópialo al plugins/ del proxy y reinicia el proxy.
3. En Velocity con reenvío moderno, ¿coincide el secreto de reenvío del backend con el del proxy? Un backend con reenvío moderno rechaza deliberadamente una concesión sin firmar o mal firmada; su log indica cuál de los dos casos es. Corrige el secreto en ambos lados y la siguiente conexión de un jugador lo reintenta por sí sola.
4. Compara las líneas Network key fingerprint de /rspm status en ambos lados. Las huellas idénticas indican la misma identidad de red; inspecciona los resultados de las descargas para verificar la conectividad. La clave en sí nunca se imprime.

Consulta Redes proxy para la secuencia completa.

Si /rspm status indica en cambio NetworkSync isn't running y sugiere que falta el archivo key.pem de Floodgate, lee el error anterior del arranque. Esa indicación entre paréntesis está desactualizada: el proxy actual puede generar y guardar su propia clave de red sin Floodgate. El error de inicialización, los permisos del sistema de archivos y la conectividad con los backends determinan el siguiente paso. Si falta por completo el comando /rspm del proxy, busca en el registro de arranque un fallo de identidad de red.

Reversión incompleta de una publicación

Si falla la publicación de un paquete Bedrock, una entrada del proxy o un paquete fusionado y no se pueden restaurar todos los archivos anteriores, RSPM conserva copias de recuperación y registra su directorio y los destinos afectados. También intenta retirar de uso el conjunto incompleto. Conserva el directorio indicado, resuelve los errores del sistema de archivos y comprueba la coherencia del paquete y sus asignaciones antes de reintentarlo. Una reversión fallida no es una publicación correcta.

Proxy: "Could not establish persistent RSPM network identity"

Las versiones actuales no funcionan con una clave sin guardar. Si el proxy no puede guardar en network-key una clave recién resuelta, o no puede leer un archivo network-key existente, el rol de proxy se detiene durante el arranque con Could not establish persistent RSPM network identity: ... o Cannot read established RSPM network identity. La sincronización de red, la entrega de Bedrock y el comando /rspm del proxy no arrancan, así que los backends conservan sus claves existentes en lugar de enlazarse con una clave que podría cambiar en el siguiente reinicio.

Corrige los permisos del sistema de archivos en la carpeta de datos del plugin del proxy (plugins/resourcepackmanager/ en Velocity, plugins/ResourcePackManager/ en BungeeCord) y después reinicia el proxy. Un archivo network-key mal formado que se pueda leer se sustituye automáticamente.

Proxy: "no merged pack" tras varios ciclos de sondeo

Primero comprueba el número de participantes RSPM confirmados en /rspm status. Un proxy nuevo sin participantes confirmados continúa con el descubrimiento de backends, sin considerar cada servidor registrado como un backend RSPM fallido. Los servidores no confirmados no retrasan la sincronización.

Tras cuatro ciclos de sondeo vacíos consecutivos con participantes confirmados, RSPM muestra un diagnóstico con los participantes, las URL HTTP probadas y sus resultados. El intervalo predeterminado es de cinco segundos, pero las operaciones de red pueden alargar el tiempo transcurrido. El diagnóstico explica las soluciones más comunes:

• CONNECT_FAILED en cada backend → el proxy no puede alcanzar el puerto HTTP del backend. Comprueba que la dirección en velocity.toml / config.yml sea una que el proxy pueda alcanzar realmente (no, p. ej., un nombre interno de Docker que no se resuelve desde la red del proxy) y que el puerto HTTP anunciado del backend esté abierto entre el proxy y el backend. El banner imprime la URL exacta que intentó; antes de que un backend haya anunciado su puerto, el proxy recurre a mcPort + network-http-offset-v2, por lo que un CONNECT_FAILED temprano también puede significar que ese puerto de respaldo aún no es accesible.
• NOT_FOUND_404 en cada backend → los backends están en marcha pero no producen un paquete de Bedrock. Ejecuta /rspm status en cada backend; el bloque de diagnóstico del paquete Bedrock te dirá por qué.

El banner se dispara una vez por periodo de atasco y se registra una línea "NetworkSync: recovered" cuando al menos un backend vuelve a devolver contenido. Consulta Redes proxy para más información.

Proxy: los jugadores de Bedrock no ven modelos en el primer arranque

Geyser registra su tabla de ítems personalizados solo al arrancar el proxy. Si el proxy arrancó antes de que ningún backend produjera un paquete de Bedrock, Geyser se ejecuta con una tabla de mappings vacía y permanece así durante el resto de la sesión.

La solución es reiniciar el proxy una vez que haya registrado Merged Bedrock pack published at .... RSPM prepara las asignaciones de la ejecución anterior al arrancar el proxy, para que los arranques posteriores puedan registrar las asignaciones guardadas. Los identificadores nuevos introducidos después del arranque pueden requerir este reinicio de nuevo.

Backend: "Backend HTTP server failed to bind on port X"

En modo de red, el backend expone sus salidas de Bedrock a través de un pequeño servidor HTTP. Si el puerto está en uso o no disponible, verás un bloque [ERROR] de varias líneas en la consola. Soluciones:

• Establece selfHostPort a un valor positivo diferente en config.yml.
• O cambia networkHttpOffset-v2 para alejar el puerto autoderivado de la colisión (p. ej. ¿RCON en mcPort + 1? ponlo en 2 o 3). No necesitas actualizar el proxy para que coincida: una vez que el backend se enlaza correctamente, anuncia su puerto HTTP real al proxy automáticamente, por lo que el propio network-http-offset-v2 del proxy solo importa como conjetura previa al anuncio.

Mientras el servidor HTTP del backend esté caído, el paquete de Bedrock de este backend no llegará al proxy por obtención directa. El respaldo por relevo de magmaguy.com sigue funcionando (el backend envía sus archivos al relevo y el proxy los obtiene a través de allí).

Limpiar una configuración v1 obsoleta

Los operadores que actualizan desde RSPM v1 pueden tener una clave networkHttpOffset (sin -v2) muerta en su config.yml. RSPM v2 intencionadamente no lee la clave antigua — obtienes el valor por defecto de la v2 (1) escrito en la configuración en el siguiente arranque automáticamente. La clave v1 muerta queda en tu config como un artefacto inofensivo hasta que la limpies a mano.

Qué incluir en un informe de error

Empieza con /rspm status y el registro completo de fusión y alojamiento, con verboseLogging: true activado antes del /rspm reload que muestra el problema. Comprueba que la máquina de un jugador pueda descargar la URL del paquete que indica /rspm status. Un puerto que responde en local aún puede estar bloqueado por un cortafuegos, un proxy o un proveedor de alojamiento.

• Texturas y modelos incorrectos o ausentes: los paquetes de origen implicados, el config.yml con tu priorityOrder, collision_log.txt y el ResourcePackManager_RSP.zip generado. Un registro del servidor muestra la versión de RSPM y si la fusión terminó, pero no puede identificar un conflicto a nivel de archivo entre dos paquetes.
• Problemas de Bedrock en una red: las versiones de RSPM en el backend y en el proxy, qué servidores ejecutan Geyser y Floodgate, y los registros de ambos lados.

Mantén fuera de los informes las claves de Floodgate, el archivo network-key, los tokens de Nightbreak y otras credenciales.