Extensión de Geyser y Entidades Personalizadas de Bedrock

Convertir el paquete de recursos hace que los jugadores de Bedrock reciban las texturas y modelos correctos para los ítems. Conseguir que tengan verdaderas entidades personalizadas — un jefe modelado que se renderiza y se anima en lugar de aparecer como un armor stand — requiere código ejecutándose dentro del propio Geyser. Eso es lo que hace la extensión de Geyser de RSPM.

No la descargas por separado. El mismo ResourcePackManager.jar que instalas como plugin es la extensión.

Un Jar, Tres Roles

ResourcePackManager.jar es simultáneamente:

• el plugin de backend de Bukkit/Paper,
• el plugin de proxy de Velocity y BungeeCord/Waterfall,
• y una extensión de Geyser.

El cargador que lo abra elige el punto de entrada que corresponda. Las versiones antiguas incluían un ResourcePackManager-GeyserBridge.jar separado; ese archivo está retirado y RSPM limpia los restos automáticamente.

Cómo se instala

RSPM instala la extensión por ti en los casos en los que puede. Lo que ocurre depende de dónde viva Geyser:

Tu configuración	Qué hace RSPM
Geyser-Spigot en el mismo servidor	Copia el jar en ejecución a plugins/Geyser-Spigot/extensions/ResourcePackManager.jar. Si ya hay allí una versión distinta, en su lugar prepara la nueva a través de la propia cola de actualización de Geyser en extensions/update/. En cualquier caso obtienes una línea en consola pidiéndote que reinicies una vez.
Geyser en el proxy (Geyser-Velocity / Geyser-BungeeCord)	El rol de proxy hace lo mismo en la carpeta Geyser-*/extensions/ del proxy.
Floodgate local, Geyser externo (Geyser se ejecuta en un proceso aparte)	RSPM no puede alcanzar ese proceso. Exporta una copia a plugins/ResourcePackManager/geyser-extension/ y te avisa de que copies ese jar exacto en la carpeta extensions/ del Geyser externo y reinicies Geyser.
Ni Geyser ni Floodgate presentes	Nada que hacer — RSPM registra una línea informativa y omite la instalación.

Una versión más nueva que ya esté en extensions/ nunca es sobrescrita por una más antigua.

La instalación siempre requiere un reinicio. Geyser carga las extensiones al arrancar, así que un jar recién copiado o preparado no hace nada hasta que el servidor o el proxy se reinicien.

Desactivar la instalación automática

Cada rol tiene su propio interruptor, y son independientes:

Dónde	Opción	Por defecto
Backend plugins/ResourcePackManager/config.yml	geyserExtensionAutoInstall	true
Proxy config.yml	geyser-extension-auto-install	true

Poner cualquiera de los dos en false impide que ese rol instale la extensión o prepare una actualización para ella, y registra una línea diciéndolo. Lee bien la semántica:

• Impide la instalación futura y la preparación de actualizaciones.
• No elimina un jar de extensión que ya esté en extensions/. Geyser tiene ese archivo abierto. Para desactivar realmente el puente, pon el flag en false, detén Geyser, borra a mano el jar de RSPM de extensions/ y vuelve a arrancarlo.
• Desactivarlo no afecta en nada a la conversión ni a la entrega del paquete. Los ítems, texturas y modelos se siguen convirtiendo y sirviendo; solo dejan de funcionar las entidades personalizadas de Bedrock.

Desactivarlo en el backend también omite la preparación de una actualización descargada de RSPM en la cola de actualización de un Geyser-Spigot local, de modo que la extensión y el plugin pueden acabar en versiones distintas — que es justo el estado que la protección de compatibilidad de más abajo existe para detectar.

Qué hace realmente la extensión

• Registra en Geyser las definiciones de entidades de Bedrock personalizadas de RSPM al arrancar, leyendo los identificadores de entidad del paquete de Bedrock generado.
• Cambia la definición de Bedrock de las entidades que aparecen, de modo que una entidad modelada aparezca como su entidad de Bedrock personalizada en lugar del respaldo vanilla.
• Aplica datos de entidad y sobrescrituras de propiedades en vivo mientras la entidad existe.
• Prepara con antelación los IDs de red de recetas de Geyser, lo que evita una clase de problemas de colisión de IDs de recetas en Geyser 2.11.

Los recursos del lado de Bedrock a los que se refieren esas definiciones provienen de los paquetes de entidades descritos en Conversión a Bedrock — un plugin incluye archivos nativos de entidades de Bedrock bajo assets/<namespace>/rspm_bedrock_pack/ y RSPM los lleva al paquete generado.

Requisitos de versión de Geyser

La extensión está dirigida a Geyser 2.11+.

Su descriptor declara deliberadamente un nivel de API de Geyser más bajo (2.9.0), de modo que un Geyser más antiguo la cargará sin problemas en lugar de rechazar el jar de plano. El requisito real se aplica en tiempo de ejecución: la extensión comprueba si existen las clases que necesita y se desactiva cuando no están, lo que produce un mensaje claro en vez de un rechazo en tiempo de carga que un operador no puede interpretar.

Está diseñada para fallar de forma cerrada ante incompatibilidades de clases o enlazado en lugar de llevarse a Geyser por delante. La cáscara de la extensión solo referencia tipos de la API de Geyser que existen desde hace mucho; las clases sensibles a la versión se comprueban antes de que arranque el núcleo. Si tu compilación de Geyser no incluye una clase que el puente necesita, el puente se desactiva a sí mismo y lo indica:

Disabled the RSPM custom Bedrock entity bridge: this Geyser build does not ship <class>. Geyser itself is unaffected, but custom Bedrock entities will not appear until a ResourcePackManager update matches this Geyser version.

Los ítems, texturas y modelos siguen convirtiéndose y sirviéndose con normalidad en ese estado — solo se ven afectadas las entidades personalizadas. La solución es actualizar Geyser, o esperar a la versión de RSPM que coincida con tu compilación de Geyser.

Las versiones anteriores de RSPM conseguían el mismo resultado intercambiando una copia interna de uno de los traductores de paquetes internos de Geyser dentro del registro de Geyser. Ese reemplazo de traductor ha desaparecido: la extensión ahora usa el ciclo de vida y los eventos públicos de entidades de Geyser 2.11 para el registro y la sustitución de definiciones de aparición. El núcleo todavía comprueba un conjunto limitado de internos de Geyser que usa para construir instancias de definición y recibir mensajes de plugin descendentes, y por eso la protección de compatibilidad y la coincidencia exacta de versiones RSPM/Geyser siguen importando.

Orden: por qué a veces hace falta un reinicio

Geyser registra las definiciones de entidades durante su propia ventana de arranque. Si RSPM termina de generar el paquete de Bedrock después de que esa ventana se haya cerrado — que es exactamente lo que ocurre en una instalación nueva, donde no hay ningún paquete al arrancar — las definiciones llegan demasiado tarde para entrar en los registros ya congelados de Geyser. RSPM las conserva para el siguiente arranque y te avisa:

RSPM custom Bedrock entity definitions became available after Geyser closed its startup registration windows ... restart the proxy once to activate the newly generated custom models.

Reinicia una vez el proceso del servidor o del proxy que aloja Geyser tras la primera generación correcta del paquete. Reconectarse por sí solo no puede activar definiciones que se perdieron la ventana de arranque. El orden es correcto en los arranques posteriores porque el paquete ya existe cuando Geyser abre sus ventanas de registro.

Verificar que funciona

1. Comprueba que la carpeta extensions/ de destino contiene realmente ResourcePackManager.jar.
2. Al arrancar, Geyser debería listar la extensión como cargada, y RSPM registra cuántas definiciones de entidades de Bedrock personalizadas ha registrado.
3. Únete desde Bedrock y mira una entidad modelada. Si ves armor stands en lugar de modelos, o la extensión no está cargada, o el paquete no llegó al cliente, o las definiciones llegaron tarde — revisa los avisos anteriores en ese orden.

Solución de problemas

"La extensión está cargada, pero las entidades siguen siendo armor stands." El paquete y la extensión son dos mitades separadas. Confirma primero que el propio paquete de Bedrock llegó al cliente (consulta Conversión a Bedrock); sin los recursos de entidad del paquete no hay nada que las definiciones puedan renderizar.

"Funcionaba, luego actualicé Geyser y las entidades se rompieron." Busca el mensaje de autodesactivación mencionado arriba. Una actualización de Geyser puede mover la superficie de API que el puente comprueba.

"Nunca se instaló nada en extensions/." Busca en la consola Automatic Geyser extension installation is disabled by geyserExtensionAutoInstall (backend) o ... by geyser-extension-auto-install (proxy). Alguien apagó el interruptor. Si Geyser y Floodgate faltan ambos localmente, verás en su lugar Geyser-Spigot and Floodgate were not detected locally; skipping automatic Geyser extension installation — eso es RSPM decidiendo correctamente que no hay nada donde instalar.

"Actualicé RSPM pero la extensión sigue siendo la versión antigua." La extensión solo se reemplaza al reiniciar, y si RSPM la preparó a través de la cola de actualización de Geyser hace falta un reinicio para que se intercambie. Mantén el jar del plugin y el jar de la extensión en la misma versión — son el mismo archivo, así que basta con volver a copiar el plugin.

En Velocity, la suscripción automática de extensiones de Geyser no se dispara como en otras plataformas, así que el plugin del proxy retransmite los eventos del ciclo de vida por su cuenta. Esto se gestiona internamente y no necesita configuración.

Dónde ir a continuación

• Conversión a Bedrock / Geyser — qué se convierte y cómo se sirve el paquete
• Redes con proxy — Geyser en un proxy
• Solución de problemas