Extension Geyser et entités Bedrock personnalisées

Convertir le pack de ressources permet aux joueurs Bedrock d'obtenir les bonnes textures et modèles pour les items. Leur donner de véritables entités personnalisées — un boss modélisé qui s'affiche et s'anime au lieu d'apparaître comme un porte-armure — nécessite du code s'exécutant à l'intérieur même de Geyser. C'est exactement ce que fait l'extension Geyser de RSPM.

Vous ne la téléchargez pas séparément. Le même ResourcePackManager.jar que vous installez comme plugin est l'extension.

Un seul jar, trois rôles

ResourcePackManager.jar est simultanément :

• le plugin backend Bukkit/Paper,
• le plugin proxy Velocity et BungeeCord/Waterfall,
• et une extension Geyser.

Le chargeur qui l'ouvre sélectionne le point d'entrée correspondant. Les anciennes versions livraient un fichier ResourcePackManager-GeyserBridge.jar séparé ; ce fichier est retiré et RSPM nettoie automatiquement les résidus.

Comment elle est installée

RSPM installe l'extension à votre place dans les cas où il le peut. Ce qui se passe dépend de l'endroit où se trouve Geyser :

Votre configuration	Ce que fait RSPM
Geyser-Spigot sur le même serveur	Copie le jar en cours d'exécution vers plugins/Geyser-Spigot/extensions/ResourcePackManager.jar. Si une version différente s'y trouve déjà, il place la nouvelle dans la file de mise à jour de Geyser, sous extensions/update/. Dans les deux cas, vous obtenez une ligne de console vous demandant de redémarrer une fois.
Geyser sur le proxy (Geyser-Velocity / Geyser-BungeeCord)	Le rôle proxy fait la même chose dans le dossier Geyser-*/extensions/ du proxy.
Floodgate local, Geyser externe (Geyser s'exécute dans un processus séparé)	RSPM ne peut pas atteindre ce processus. Il exporte une copie vers plugins/ResourcePackManager/geyser-extension/ et vous avertit de copier ce jar exact dans le dossier extensions/ du Geyser externe, puis de redémarrer Geyser.
Ni Geyser ni Floodgate présents	Rien à faire — RSPM enregistre une ligne d'information et ignore l'installation.

Une version plus récente déjà présente dans extensions/ n'est jamais écrasée par une plus ancienne.

L'installation nécessite toujours un redémarrage. Geyser charge les extensions au démarrage, donc un jar fraîchement copié ou mis en file d'attente ne fait rien tant que le serveur ou le proxy n'a pas redémarré.

Désactiver l'installation automatique

Chaque rôle possède son propre interrupteur, et ils sont indépendants :

Où	Réglage	Défaut
Backend plugins/ResourcePackManager/config.yml	geyserExtensionAutoInstall	true
config.yml du proxy	geyser-extension-auto-install	true

Mettre l'un ou l'autre à false empêche ce rôle d'installer l'extension ou de mettre en file une mise à jour pour elle, et une ligne de journal le signale. Lisez attentivement la sémantique :

• Cela empêche les futures installations et mises en file de mises à jour.
• Cela ne supprime pas un jar d'extension déjà présent dans extensions/. Geyser garde ce fichier ouvert. Pour réellement désactiver le pont, mettez le drapeau à false, arrêtez Geyser, supprimez à la main le jar RSPM de extensions/, puis relancez.
• Le désactiver n'a aucun effet sur la conversion ni sur la distribution du pack. Les items, textures et modèles continuent d'être convertis et servis ; seules les entités Bedrock personnalisées cessent de fonctionner.

Le désactiver sur le backend empêche aussi de placer une mise à jour RSPM téléchargée dans la file de mise à jour d'un Geyser-Spigot local, de sorte que l'extension et le plugin peuvent diverger en version — c'est précisément l'état que la garde de compatibilité ci-dessous sert à détecter.

Ce que fait réellement l'extension

• Enregistre auprès de Geyser les définitions d'entités Bedrock personnalisées de RSPM au démarrage, en lisant les identifiants d'entités dans le pack Bedrock généré.
• Remplace la définition Bedrock des entités qui apparaissent, afin qu'une entité modélisée apparaisse comme son entité Bedrock personnalisée plutôt que comme le repli vanilla.
• Applique en direct les données d'entité et les surcharges de propriétés pendant l'existence de l'entité.
• Amorce tôt les identifiants réseau de recettes de Geyser, ce qui évite une catégorie de problèmes de collision d'ID de recettes sur Geyser 2.11.

Les ressources côté Bedrock auxquelles ces définitions font référence proviennent des bundles d'entités décrits dans Conversion Bedrock — un plugin livre des fichiers d'entités Bedrock natifs sous assets/<namespace>/rspm_bedrock_pack/ et RSPM les transporte dans le pack généré.

Versions de Geyser requises

L'extension cible Geyser 2.11+.

Son descripteur déclare délibérément un niveau d'API Geyser inférieur (2.9.0), afin qu'un Geyser plus ancien la charge volontiers plutôt que de refuser le jar d'emblée. La véritable exigence est appliquée à l'exécution : l'extension sonde les classes dont elle a besoin et se désactive lorsqu'elles sont absentes, ce qui produit un message clair au lieu d'un rejet au chargement qu'un opérateur ne peut pas interpréter.

Elle est conçue pour échouer de façon fermée en cas d'incompatibilité de classe ou de liaison, plutôt que d'entraîner Geyser dans sa chute. La coquille de l'extension ne référence que des types de l'API Geyser de longue date ; les classes sensibles à la version sont sondées avant le démarrage du cœur. Si votre build de Geyser ne fournit pas une classe dont le pont a besoin, le pont se désactive lui-même et le signale :

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.

Les items, textures et modèles continuent d'être convertis et servis normalement dans cet état — seules les entités personnalisées sont concernées. La solution est de mettre Geyser à jour, ou d'attendre la version de RSPM correspondant à votre build de Geyser.

Les versions antérieures de RSPM obtenaient le même résultat en injectant dans le registre de Geyser une copie embarquée de l'un de ses traducteurs de paquets internes. Ce remplacement de traducteur a disparu : l'extension utilise désormais le cycle de vie et les événements publics d'entités de Geyser 2.11 pour l'enregistrement et le remplacement des définitions d'apparition. Le cœur sonde toujours un ensemble limité d'internes de Geyser utilisés pour construire les instances de définitions et recevoir les messages de plugin en aval, ce qui explique pourquoi la garde de compatibilité et la correspondance exacte des versions RSPM/Geyser restent importantes.

Ordonnancement : pourquoi un redémarrage est parfois nécessaire

Geyser enregistre les définitions d'entités pendant sa propre fenêtre de démarrage. Si RSPM termine la génération du pack Bedrock après la fermeture de cette fenêtre — ce qui est exactement le cas sur une toute nouvelle installation, où aucun pack n'existe encore au démarrage — les définitions arrivent trop tard pour entrer dans les registres gelés de Geyser. RSPM les conserve pour le prochain démarrage et vous avertit :

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.

Redémarrez une fois le processus serveur ou proxy qui héberge Geyser, après la première génération réussie du pack. Une simple reconnexion ne peut pas activer des définitions qui ont manqué la fenêtre de démarrage. L'ordonnancement est correct aux démarrages suivants, car le pack existe déjà quand Geyser ouvre ses fenêtres d'enregistrement.

Vérifier que cela fonctionne

1. Vérifiez que le dossier extensions/ cible contient bien ResourcePackManager.jar.
2. Au démarrage, Geyser devrait lister l'extension comme chargée, et RSPM indique dans les journaux combien de définitions d'entités Bedrock personnalisées il a enregistrées.
3. Connectez-vous sur Bedrock et regardez une entité modélisée. Des porte-armures au lieu des modèles signifient soit que l'extension n'est pas chargée, soit que le pack n'a pas atteint le client, soit que les définitions sont arrivées en retard — vérifiez les avertissements ci-dessus dans cet ordre.

Dépannage

« L'extension est chargée, mais les entités sont toujours des porte-armures. » Le pack et l'extension sont deux moitiés distinctes. Confirmez d'abord que le pack Bedrock lui-même a atteint le client (voir Conversion Bedrock) ; sans les ressources d'entités du pack, les définitions n'ont rien à afficher.

« Ça marchait, puis j'ai mis Geyser à jour et les entités ont cassé. » Cherchez le message d'auto-désactivation ci-dessus. Une mise à jour de Geyser peut déplacer la surface d'API que le pont recherche.

« Rien n'a jamais été installé dans extensions/. » Cherchez dans la console Automatic Geyser extension installation is disabled by geyserExtensionAutoInstall (backend) ou ... by geyser-extension-auto-install (proxy). Quelqu'un a désactivé l'interrupteur. Si Geyser et Floodgate sont tous deux absents localement, vous verrez plutôt Geyser-Spigot and Floodgate were not detected locally; skipping automatic Geyser extension installation — c'est RSPM qui décide correctement qu'il n'y a nulle part où installer.

« J'ai mis RSPM à jour mais l'extension est toujours en ancienne version. » L'extension n'est remplacée qu'au redémarrage, et si RSPM l'a placée dans la file de mise à jour de Geyser, un redémarrage est nécessaire pour qu'elle soit substituée. Gardez le jar du plugin et le jar de l'extension sur la même version — c'est le même fichier, donc recopier le plugin suffit.

Sur Velocity, l'abonnement automatique aux extensions de Geyser ne se déclenche pas comme sur les autres plateformes, donc le plugin proxy relaie lui-même les événements de cycle de vie. C'est géré en interne et ne nécessite aucune configuration.

Où aller ensuite

• Conversion Bedrock / Geyser — ce qui est converti et comment le pack est servi
• Réseaux proxy — Geyser sur un proxy
• Dépannage