Saltar al contenido principal

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), la clave de red enmascarada, el estado de los paquetes Java + Bedrock, la ruta de entrega activa con la URL, el host externo resuelto + la IP pública autodetectada, 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).

Los jugadores no están recibiendo el paquete de recursos​

Comprueba primero estos puntos:

  • autoHost debe estar activado si quieres que ResourcePackManager envíe una URL automáticamente
  • el paquete fusionado debe existir y al menos una ruta de entrega (autoalojamiento o remoto) debe haber tenido éxito
  • los jugadores solo reciben el paquete al conectarse, o mediante la difusión de la primera subida que se dispara en el momento en que el alojamiento queda listo

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

Si estás autoalojando a través de tu propia canalización externa (autoHost: false), RSPM no envía tu URL personalizada por ti. En esa configuración aún necesitas tu propio flujo de entrega de paquete desde el servidor.

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
  • recarga ResourcePackManager unos 15 segundos después

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

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.

El plugin omite los paquetes que no puede extraer correctamente y registra advertencias en consola cuando esto ocurre.

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 assets de un plugin están sobrescribiendo los de otro plugin​

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, los rangos de supported_formats se amplían (se admiten 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 se conservan. Las entradas de overlay se normalizan para compatibilidad con 1.21.9+ añadiendo los campos min_format/max_format cuando faltan. Las fuentes de atlas base también se fusionan en los archivos de atlas de overlay para evitar que los overlays oculten entradas base.

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

plugins/ResourcePackManager/collision_log.txt

El texto de GUI o 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.

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.

Las comprobaciones de cordura del autoalojamiento fallaron; recurriendo al alojamiento remoto​

Este mensaje es comportamiento normal cuando preferSelfHost: true (el valor por defecto) y una de las tres comprobaciones de cordura del autoalojamiento falló:

  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 (sondeo a sí mismo en localhost) — una solicitud HEAD a http://127.0.0.1:<port>/rspm.zip no devolvió 200 con un cuerpo no vacío. Detecta colisiones de enlace de puerto o archivos de paquete faltantes.
  3. Capa 3 (sondeo de accesibilidad externa) — magmaguy.com intentó obtener tu URL anunciada y no pudo alcanzarla. Lo más común: el puerto HTTP no está reenviado en el router / firewall. La URL del sondeo y el motivo se registran.

Soluciones (en orden de preferencia): abre el puerto HTTP en tu firewall + router, establece selfHostExternalHost a un hostname enrutable, o establece preferSelfHost: false para omitir el autoalojamiento por completo.

Cuando el propio sondeo de magmaguy.com es inaccesible (RSPM no puede hablar con él para preguntarle), se mantiene el autoalojamiento en lugar de marcarlo como fallido — el razonamiento es que la ruta de respaldo también necesita magmaguy.com, por lo que negarse a comprometerse por incapacidad de sondear sería paradójico.

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 tu puerto HTTP y mantener preferSelfHost: true para que RSPM use el autoalojamiento sin necesitar magmaguy.com en absoluto (en este escenario, establece también selfHostExternalHost a tu hostname público para que el sondeo externo de la Capa 3 sea innecesario — RSPM mantiene el autoalojamiento ante un IOException del sondeo)

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

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 el escáner encontró cero definiciones de ítems en el paquete fusionado, o la conversión lanzó una excepción. Busca en la consola advertencias [BedrockConverter] o la línea Generic scanner: 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. La ruta puede ser absoluta o 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.

Los jugadores de Bedrock ven los ítems en mano en una posición incorrecta​

Esto es un problema de ajuste, no un fallo de conversión. Abre plugins/ResourcePackManager/bedrock_display_offsets.yml y ajusta el eje pertinente. La primera persona y la tercera persona son independientes — ajustar una no afecta a la otra. El cliente de Bedrock recarga en vivo el JSON de attachable sin relanzar, así que iterar es rápido. Consulta Conversión a Bedrock para ver la lista completa de parámetros y lo que controla cada uno.

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: "Floodgate key.pem missing" al arrancar el proxy​

El plugin del proxy no pudo encontrar plugins/floodgate/key.pem en el host del proxy y quedó inactivo. RSPM deriva la identidad de red de ese archivo, así que sin él el proxy no puede enlazar con ningún backend. Solución:

  1. Instala Floodgate en el proxy. Es necesario para que los jugadores de Bedrock alcancen el proxy de todos modos, así que es algo que necesitas independientemente de RSPM.
  2. Asegúrate de que plugins/floodgate/key.pem en el proxy sea idéntico byte a byte al mismo archivo en cada backend. Copia un key.pem canónico a cada componente (los demás backends + el proxy) y reinicia todo. Floodgate ya lo requiere para la autenticación de Bedrock, así que si los jugadores de Bedrock funcionan actualmente en tu red, esto ya está hecho.

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

Tras ~20 segundos de ciclos de sondeo vacíos (4 ciclos × intervalo por defecto de 5 s) en el proxy, RSPM registra un banner de diagnóstico único que lista cada backend que sondeó, la URL HTTP que intentó y el resultado (200 / 304 / 404 / CONNECT_FAILED / etc.). El banner 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 del proxy​

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 después de que el backend haya registrado Wrote merged Geyser mappings: N entries. RSPM predespliega los mappings de la ejecución anterior al arrancar el proxy, por lo que esto solo afecta en una instalación completamente nueva — los arranques posteriores tienen algo listo antes de que Geyser escanee.

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.