Aller au contenu principal

Conversion Java vers Bedrock

ResourcePackManager peut convertir le pack de ressources Java fusionné en pack de ressources Bedrock afin que les clients GeyserMC voient le même contenu personnalisé que les clients Java. Cette conversion est activée par défaut.

Ce qui est converti​

Le convertisseur n'est plus réservé à FreeMinecraftModels. Il exécute deux pipelines successifs sur le pack Java fusionné :

  1. Scanner d'os FreeMinecraftModels — récupère les modèles d'os FMM sous assets/freeminecraftmodels/models/ et convertit chaque os en attachable Bedrock.
  2. Pipeline générique de définitions d'items — parcourt chaque fichier assets/<namespace>/items/*.json au format 1.21.4+ (en ignorant les espaces de noms minecraft et freeminecraftmodels). Pour chaque modèle feuille, il fait soit :
    • émettre une icône d'inventaire Bedrock plate (pour les parents intégrés plats du type minecraft:item/generated), soit
    • émettre une géométrie Bedrock, un attachable, un fichier d'animation et une icône d'inventaire 2D rendue par logiciel (pour les vrais modèles 3D).

Un identifiant Bedrock unique est généré par paire (modèle × item de base), de sorte que par exemple un même modèle d'épée enregistré contre plusieurs items de base n'entre pas en collision côté Geyser.

Les sets d'armures personnalisées sont détectés lorsqu'un fichier voisin assets/<namespace>/equipment/<material>.json existe. Le convertisseur câble un attachable d'armure qui combine la géométrie d'armure vanilla avec la texture Java comme couche visible, afin que les joueurs Bedrock voient la bonne texture d'armure en portant l'item.

L'UUID du manifeste du pack Bedrock est dérivé de manière déterministe du nom du pack, de sorte qu'il reste stable entre les reconstructions ; seul le triplet de version est incrémenté à chaque build (jeton de cache-bust dérivé du temps de build).

Distribution en direct par session​

Lorsque Geyser-Spigot est détecté, ResourcePackManager enregistre un abonné SessionLoadResourcePacksEvent. Chaque joueur Bedrock qui se connecte après une nouvelle fusion reçoit le dernier pack Bedrock servi directement depuis le disque, sans qu'un redémarrage du serveur soit requis pour les modifications de textures ou de modèles.

Les mappings d'items personnalisés de Geyser (les JSON dans custom_mappings/) sont toujours figés au démarrage, donc ajouter de nouveaux items personnalisés ou en supprimer nécessite un redémarrage du serveur avant que les clients Bedrock voient ces changements. RSPM pré-déploie le fichier de mappings du précédent build tôt dans le démarrage afin que l'enregistrement des items personnalisés effectué par Geyser au boot le récupère automatiquement.

Les joueurs Bedrock actuellement connectés conservent le pack qu'ils ont reçu au moment de leur connexion — c'est une contrainte du protocole Bedrock, pas quelque chose que le plugin puisse outrepasser en pleine session.

Fichiers de sortie​

Après une fusion réussie, les fichiers Bedrock se trouvent dans :

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

Si l'auto-déploiement est activé et que Geyser a été détecté, le fichier de mappings est également copié vers :

<geyser-folder>/custom_mappings/rspm_geyser_mappings.json

Le zip du pack Bedrock n'est pas copié dans <geyser-folder>/packs/ — il est servi en direct par session à la place. RSPM supprime également toute copie héritée que d'anciennes versions du plugin auraient laissée dans ce dossier, afin que Geyser ne finisse pas par servir le pack deux fois (des UUID en double sèmeraient la confusion chez le client Bedrock).

Paramètres de config.yml​

# Active/désactive entièrement la conversion Java vers Bedrock.
bedrockConversionEnabled: true

# Copie le fichier de mappings personnalisés Geyser dans le dossier
# custom_mappings/ du dossier Geyser détecté à chaque fusion.
bedrockAutoDeployToGeyser: true

# Surcharge manuelle pour le dossier de données Geyser. Vide = détection automatique.
# Peut être absolu ou relatif au répertoire plugins/.
bedrockGeyserFolder: ""

La détection automatique examine, dans cet ordre :

  1. bedrockGeyserFolder s'il est défini (traité d'abord comme chemin absolu, puis comme chemin relatif à plugins/).
  2. plugins/Geyser-Spigot/
  3. plugins/Geyser-*/ (toute variante)
  4. config/Geyser-*/ (pour les configurations Fabric/NeoForge)

Réglage de l'affichage des items tenus en main : bedrock_display_offsets.yml​

Bedrock rend l'item tenu en main via un os parent dont la pose de repos diffère des transformations première/troisième personne de Java, donc la conversion algorithmique doit appliquer un décalage de base par-dessus tout ce que la transformation display du modèle Java spécifie. Les décalages par défaut fonctionnent pour les modèles Java typiques droitiers, mais certains cas particuliers peuvent nécessiter un réglage.

La première personne et la troisième personne sont deux passes de rendu Bedrock totalement séparées (os parents différents, poses de repos différentes), donc chacune dispose de son propre ensemble indépendant de six paramètres. Régler l'une n'affecte pas l'autre.

# ===== Première personne (main droite, vue par le porteur) =====
firstPersonBaseRotationX: -90.0   # tangage (basculement vers/loin de la caméra). Par défaut annule la rotation parente.
firstPersonBaseRotationY: 0.0     # lacet (rotation autour de la ligne verticale)
firstPersonBaseRotationZ: 0.0     # roulis (autour de l'axe caméra-avant)
firstPersonBasePositionX: 0.0     # vertical à l'écran (positif = vers le haut)
firstPersonBasePositionY: 12.5    # profondeur (positif = plus loin dans la scène)
firstPersonBasePositionZ: 0.0     # horizontal à l'écran (positif = vers la droite)

# ===== Troisième personne (main droite, vue par les autres joueurs / F5) =====
thirdPersonBaseRotationX: 90.0    # tangage tel que les observateurs le voient
thirdPersonBaseRotationY: 0.0     # lacet
thirdPersonBaseRotationZ: 0.0     # roulis autour de l'axe long de l'item
thirdPersonBasePositionX: 0.0     # horizontal en travers du corps du porteur (positif = vers l'extérieur)
thirdPersonBasePositionY: 12.5    # vertical (positif = monte le modèle)
thirdPersonBasePositionZ: 0.0     # profondeur par rapport au porteur (positif = vers l'avant)

Les valeurs de position sont en pixels, où 1 pixel = 1/16 de bloc. Les rotations sont en degrés.

Le client Bedrock recharge à chaud le JSON des attachables sans redémarrage. Si un client de test Bedrock est connecté, modifiez la valeur, exécutez /rspm reload, et la prochaine connexion Bedrock (ou dans certains cas le même joueur connecté après une petite action en jeu qui relie l'attachable) affichera le nouveau décalage. Itérez jusqu'à obtenir le bon rendu.

Limites et comportements connus​

  • Les icônes d'inventaire 3D sont rendues par logiciel à partir de la transformation display.gui du modèle Java. Le rendu est raisonnable mais pas parfait au pixel près ; si l'icône paraît incorrecte, la cause la plus fréquente est un fichier de texture référencé par le modèle qui est manquant ou mal nommé.
  • Les textures « flipbook » utilisées comme icônes d'item sont rognées à la frame 0 — le item_texture.json de Bedrock ne prend pas en charge les icônes animées, seulement les textures animées de blocs/terrain via flipbook_textures.json.
  • La version du format de géométrie des attachables est fixée à 1.21.0 (elle était 1.16.0 dans les versions plus anciennes du plugin) ; mettez Geyser à jour si votre installation ne peut pas l'analyser.
  • Les modèles d'items vanilla (shield.json, crossbow.json) ne sont pas fusionnés récursivement entre packs afin d'éviter la corruption des arbres de prédicats entre packs ; c'est la copie du pack de priorité la plus haute qui l'emporte pour ces deux-là spécifiquement.
  • Si le convertisseur ne peut pas résoudre un fichier de texture ou de modèle référencé, cette feuille est ignorée et un avertissement [BedrockConverter] est enregistré ; le reste du pipeline continue.