Saltar al contenido principal

Conversión de Java a Bedrock

ResourcePackManager puede convertir el paquete de recursos Java fusionado en un paquete de recursos de Bedrock para que los clientes de GeyserMC vean el mismo contenido personalizado que los clientes de Java. Está activado por defecto.

Qué se convierte​

El convertidor ya no es exclusivo de FreeMinecraftModels. Ejecuta dos canalizaciones de forma consecutiva sobre el paquete Java fusionado:

  1. Escáner de huesos de FreeMinecraftModels — recoge los modelos por huesos de FMM bajo assets/freeminecraftmodels/models/ y convierte cada hueso en un attachable de Bedrock.
  2. Canalización genérica de definición de ítems — recorre cada archivo assets/<namespace>/items/*.json en el formato 1.21.4+ (omitiendo los namespaces minecraft y freeminecraftmodels). Para cada modelo hoja:
    • emite un icono de inventario plano de Bedrock (para minecraft:item/generated simple y otros padres planos integrados similares), o
    • emite geometría de Bedrock, un attachable, un archivo de animación y un icono de inventario 2D renderizado por software (para modelos verdaderamente 3D).

Se genera un identificador único de Bedrock por cada par (modelo × ítem base), de modo que, por ejemplo, un único modelo de espada registrado contra varios ítems base no colisione del lado de Geyser.

Los sets de armadura personalizados se detectan cuando existe un archivo hermano assets/<namespace>/equipment/<material>.json. El convertidor cablea un attachable de armadura que combina la geometría de armadura vanilla con la textura Java como capa visible, para que los jugadores de Bedrock vean la textura de armadura correcta al llevar el ítem.

El UUID del manifest del paquete de Bedrock se deriva de forma determinista del nombre del paquete, por lo que se mantiene estable entre reconstrucciones; solo el triplete de versión se incrementa por compilación (token de invalidación de caché derivado del tiempo de compilación).

Servicio en vivo por sesión​

Cuando se detecta Geyser-Spigot, ResourcePackManager registra un suscriptor a SessionLoadResourcePacksEvent. Cada jugador de Bedrock que se conecte después de una nueva mezcla recibe el paquete de Bedrock más reciente servido directamente desde disco, sin necesidad de reiniciar el servidor para ediciones de textura o modelo.

Las asignaciones de ítems personalizados de Geyser (el JSON en custom_mappings/) siguen congeladas al arrancar, por lo que añadir nuevos ítems personalizados o eliminar los existentes requiere reiniciar el servidor antes de que los clientes de Bedrock vean esos cambios. RSPM predespliega el archivo de mappings de la ejecución anterior al principio del arranque para que el registro de ítems personalizados de Geyser, durante el arranque, lo recoja automáticamente.

Los jugadores de Bedrock actualmente conectados conservan el paquete que recibieron al conectarse — esa es una restricción del protocolo de Bedrock, no algo que el plugin pueda anular a mitad de sesión.

Archivos de salida​

Tras una mezcla exitosa, los archivos de Bedrock viven en:

plugins/ResourcePackManager/output/ResourcePackManager_Bedrock.zip
plugins/ResourcePackManager/output/rspm_geyser_mappings.json

Si el despliegue automático está activado y Geyser fue detectado, el archivo de mappings también se copia a:

<geyser-folder>/custom_mappings/rspm_geyser_mappings.json

El zip del paquete de Bedrock no se copia a <geyser-folder>/packs/ — se sirve en vivo por sesión. RSPM también elimina cualquier copia heredada que versiones anteriores del plugin hubieran dejado en esa carpeta, para que Geyser no termine sirviendo el paquete dos veces (los UUIDs duplicados confundirían al cliente de Bedrock).

Opciones en config.yml​

# Activa o desactiva por completo la conversión de Java a Bedrock.
bedrockConversionEnabled: true

# Copia el archivo de mappings personalizados de Geyser al directorio
# custom_mappings/ de la carpeta de Geyser detectada en cada mezcla.
bedrockAutoDeployToGeyser: true

# Sobrescritura manual de la carpeta de datos de Geyser. Vacío = autodetectar.
# Puede ser absoluta o relativa al directorio plugins/.
bedrockGeyserFolder: ""

La autodetección busca, en orden:

  1. bedrockGeyserFolder si está establecido (se trata primero como ruta absoluta y luego como ruta relativa a plugins/).
  2. plugins/Geyser-Spigot/
  3. plugins/Geyser-*/ (cualquier variante)
  4. config/Geyser-*/ (para configuraciones Fabric/NeoForge)

Ajuste de la visualización del ítem en mano: bedrock_display_offsets.yml​

Bedrock renderiza el ítem en mano a través de un hueso padre cuya pose de reposo difiere de las transformaciones de primera/tercera persona de Java, por lo que la conversión algorítmica debe aplicar un desplazamiento base por encima de lo que indique la transformación display del modelo Java. Los desplazamientos por defecto funcionan para modelos Java diestros típicos, pero los casos atípicos pueden necesitar ajustes.

La primera persona y la tercera persona son dos pases de renderizado de Bedrock completamente separados (huesos padre distintos, poses de reposo distintas), por lo que cada uno tiene su propio conjunto independiente de seis parámetros. Ajustar uno no afecta al otro.

# ===== Primera persona (mano derecha, vista por el propio portador) =====
firstPersonBaseRotationX: -90.0   # pitch (inclinación hacia/desde la cámara). Por defecto cancela la rotación del padre.
firstPersonBaseRotationY: 0.0     # yaw (giro alrededor de la línea vertical)
firstPersonBaseRotationZ: 0.0     # roll (alrededor del eje hacia adelante de la cámara)
firstPersonBasePositionX: 0.0     # vertical en pantalla (positivo = arriba)
firstPersonBasePositionY: 12.5    # profundidad (positivo = más adentro de la escena)
firstPersonBasePositionZ: 0.0     # horizontal en pantalla (positivo = derecha)

# ===== Tercera persona (mano derecha, vista por otros jugadores / F5) =====
thirdPersonBaseRotationX: 90.0    # pitch tal como lo ven los observadores
thirdPersonBaseRotationY: 0.0     # yaw
thirdPersonBaseRotationZ: 0.0     # roll alrededor del eje largo del ítem
thirdPersonBasePositionX: 0.0     # horizontal a través del cuerpo del portador (positivo = hacia afuera)
thirdPersonBasePositionY: 12.5    # vertical (positivo = sube el modelo)
thirdPersonBasePositionZ: 0.0     # profundidad relativa al portador (positivo = hacia adelante)

Los valores de posición están en píxeles, donde 1 píxel = 1/16 de bloque. Las rotaciones están en grados.

El cliente de Bedrock recarga en vivo el JSON de attachable sin relanzar. Si tienes un cliente de prueba de Bedrock conectado, cambia el valor, ejecuta /rspm reload, y el siguiente jugador de Bedrock que se conecte (o, en algunos casos, el mismo jugador conectado tras una pequeña acción en el mundo que vuelva a vincular el attachable) verá el nuevo desplazamiento. Itera hasta que se vea bien.

Limitaciones y comportamiento conocido​

  • Los iconos de inventario 3D se renderizan por software a partir de la transformación display.gui del modelo Java. El renderizado es razonable pero no perfecto a nivel de píxel; si el icono se ve mal, la causa más común es un archivo de textura faltante o con el nombre incorrecto referenciado por el modelo.
  • Las texturas de flipbook usadas como iconos de ítem se recortan al fotograma 0 — el item_texture.json de Bedrock no soporta iconos animados, solo texturas animadas de bloques/terreno mediante flipbook_textures.json.
  • La versión de formato de la geometría de attachable está fijada en 1.21.0 (era 1.16.0 en versiones anteriores del plugin); actualiza Geyser si tu instalación no puede analizarla.
  • Los modelos de ítems vanilla (shield.json, crossbow.json) no se fusionan recursivamente entre paquetes para evitar corrupción del árbol de predicados entre paquetes; para esos dos específicamente gana la copia del paquete de mayor prioridad.
  • Si el convertidor no puede resolver un archivo de textura o modelo referenciado, esa hoja se omite y se registra una advertencia [BedrockConverter]; el resto de la canalización continúa.