FAQ Resource Pack Manager

Si votre question n'a pas de réponse ici, consultez d'abord les autres pages ResourcePackManager dans la barre latérale.

Quelles commandes ResourcePackManager expose-t-il actuellement ?

Sur le backend (Paper / Spigot), les commandes actuellement implémentées sont :

• /rspm setup — ouvre un menu de configuration via une interface graphique en jeu (état de la mise à jour du plugin, plugins recommandés, bascule des mises à jour automatiques, liens vers le wiki / Discord / le compte Nightbreak)
• /rspm recommendedplugins — affiche le menu partagé Nightbreak des plugins recommandés (ou une liste texte en console)
• /rspm downloadpluginupdate — télécharge une mise à jour disponible de ResourcePackManager pour le prochain redémarrage
• /rspm downloadall — télécharge toutes les mises à jour disponibles exposées par ce plugin (actuellement la mise à jour de ResourcePackManager)
• /rspm applypluginupdate — fait partie de l'ensemble de commandes partagées Nightbreak ; RSPM la refuse toujours, car ses mises à jour nécessitent un redémarrage du serveur (son extension Geyser ne se charge qu'au démarrage de Geyser)
• /rspm reload — reconstruit et réhéberge le pack fusionné
• /rspm status — vidage de diagnostic complet (état du pack, mode d'hébergement, empreinte de la clé réseau, intégrations)
• /rspm verbose [on|off] — active ou désactive la journalisation de diagnostic détaillée. Sans argument, elle bascule l'état. Le résultat est réécrit dans verboseLogging dans config.yml, il persiste donc entre les redémarrages. Également acceptée sous la forme /rspm verboselogging.
• /rspm itemsadder configure — configure ItemsAdder pour l'hébergement par RSPM
• /rspm itemsadder dismiss — masque définitivement l'avertissement ItemsAdder pour votre UUID joueur
• /rspm data_compliance_request — télécharge toutes les données stockées à distance pour ce serveur

La commande racine est /resourcepackmanager, avec /rspm comme alias. Les commandes de mise à jour et de plugins recommandés ci-dessus sont des commandes partagées MagmaCore/Nightbreak enregistrées par RSPM.

MagmaCore enregistre aussi ces commandes de premier niveau, qui ne sont pas des sous-commandes de /rspm :

• /nightbreaklogin <token> et /nightbreaklogout enregistrent ou effacent le token de compte Nightbreak partagé du serveur. Les deux nécessitent nightbreak.login (op par défaut). Voir Liaison de compte Nightbreak.
• /nightbreak plugins parcourt le catalogue de plugins Nightbreak et nécessite nightbreak.plugins (op par défaut).
• /logify envoie le journal serveur actuel vers mclo.gs et nécessite logify.* (op par défaut).
• /resourcepackmanagerchangelog [dismiss|disable] affiche aux administrateurs les notes de version de ResourcePackManager qu'ils n'ont pas encore lues. Voir Notifications des notes de version.

Le premier plugin Nightbreak chargé enregistre /nightbreaklogin, /nightbreaklogout, /nightbreak et /logify pour tout le serveur.

Permissions du backend :

• /rspm setup et /rspm recommendedplugins nécessitent resourcepackmanager.setup. /rspm setup est réservée aux joueurs car elle ouvre une interface graphique d'inventaire.
• /rspm downloadpluginupdate, /rspm downloadall, /rspm applypluginupdate, /rspm reload, /rspm status, /rspm verbose, /rspm itemsadder <configure|dismiss> et /rspm data_compliance_request nécessitent resourcepackmanager.*.

Sur le plugin proxy (Velocity / BungeeCord), seules des commandes de diagnostic existent :

• /rspm status — instantané côté proxy : liste des backends, résultats de récupération par backend, état du pack fusionné, détection de Geyser/Floodgate
• /rspm debug bedrock [on|off] — Velocity et BungeeCord. Active les lignes de journal détaillées [RSPM-BedrockDebug] du GeyserBinder pour diagnostiquer les cas « le joueur Bedrock a rejoint mais n'a pas vu le pack ». Remis à off au redémarrage du proxy. L'exécuter sans argument affiche l'état actuel.

Sur Velocity, les commandes du proxy acceptent resourcepackmanager.command.status ou resourcepackmanager.*. BungeeCord enregistre exactement le nœud resourcepackmanager.command.status ; un plugin de permissions peut malgré tout le satisfaire par expansion de joker. La console peut exécuter les commandes. La sortie peut être partagée sans risque — la clé réseau n'apparaît que sous la forme d'une courte empreinte de hachage à sens unique, jamais la clé elle-même, et aucun jeton n'est affiché — donc des octrois généreux ne posent pas de problème.

Quels plugins sont actuellement pris en charge ?

ResourcePackManager est livré avec des entrées d'intégration préconfigurées pour ces plugins :

• BackpackPlus
• BetterHUD
• BetterStructures
• CannonRTP
• EliteMobs
• EternalTD
• FreeMinecraftModels
• InfiniteVehicles
• ItemsAdder
• MegaBlockSurvivors
• MMOInventory
• ModelEngine
• Nexo
• Nova
• Oraxen
• RealisticSurvival
• ResurrectionChest
• ValhallaMMO
• vane-core

Ces intégrations ne prennent effet que si le plugin est installé et que son chemin local ou son URL distante configurés sont exploitables.

Chaque intégration possède son propre fichier de configuration YAML dans plugins/ResourcePackManager/compatible_plugins/. Vous pouvez y personnaliser isEnabled, pluginName, localPath, url, zips, cluster, additionalLocalPath et reloadCommand par plugin. L'option cluster indique à ResourcePackManager de traiter le chemin local comme un répertoire contenant plusieurs sous-dossiers de packs de ressources qui doivent tous être fusionnés ensemble.

Comment exclure une intégration automatique de plugin ?

Définissez isEnabled: false dans le fichier de cette intégration sous plugins/ResourcePackManager/compatible_plugins/, puis exécutez /rspm reload (ou redémarrez). RSPM retire les entrées de pack de ressources qu'il avait générées ou enregistrées pour cette intégration, y compris ses copies générées dans le mixeur. Retirer le plugin de priorityOrder ne l'exclut pas ; cela déplace simplement ce pack à la priorité la plus basse. Pour exclure un ZIP que vous avez ajouté manuellement, retirez ou déplacez ce ZIP du dossier mixer.

ResourcePackManager est-il compatible avec ItemsAdder ?

Oui. ResourcePackManager inclut un assistant intégré et un flux d'avertissement pour ItemsAdder.

Si ItemsAdder est installé et nécessite encore d'être ajusté pour un hébergement par ResourcePackManager, les joueurs OP reçoivent un avertissement cliquable quelques secondes après leur connexion. Les joueurs ayant définitivement masqué l'avertissement ne le revoient pas. À partir de là, vous pouvez :

• exécuter /rspm itemsadder configure pour définir resource-pack.hosting.no-host.enabled: true, désactiver les trois paramètres protect-file-from-unzip, définir compress-json-files: false, exécuter /iareload puis /iazip, et attendre que RSPM fusionne l'export régénéré (il indique si la fusion a réussi ou échoué ; il ne recharge pas RSPM)
• exécuter /rspm itemsadder dismiss pour masquer définitivement cet avertissement pour votre UUID joueur

Si ItemsAdder est déjà configuré pour héberger son propre pack via l'un de ses modes d'hébergement, la commande d'assistant ne le remplace pas automatiquement. Elle vous indique de désactiver d'abord vous-même l'hébergement ItemsAdder.

Puis-je ajouter mon propre pack à la fusion ?

Oui, et il y a deux endroits où le placer selon ce que vous avez.

Un .zip fini va dans :

plugins/ResourcePackManager/mixer

Si vous souhaitez contrôler quel pack l'emporte sur les conflits de fichiers, ajoutez le nom de fichier exact, y compris .zip, à priorityOrder dans plugins/ResourcePackManager/config.yml.

Un dossier de pack décompressé (une arborescence assets/ plus pack.mcmeta) va dans :

plugins/ResourcePackManager/resource_pack

RSPM zippe lui-même ce dossier et le fusionne sous l'entrée ResourcePackManager de priorityOrder, qui se trouve en tête de la liste par défaut — donc par défaut ses fichiers l'emportent sur ceux de tous les packs de plugins. Descendez ResourcePackManager dans la liste si vous préférez qu'il perde.

Le dossier associé plugins/ResourcePackManager/blueprint contient les pack.png et pack.mcmeta que RSPM apporte à chaque fusion. Modifiez ces deux fichiers pour changer l'icône du pack fusionné ou sa description dans le menu ; le dossier est re-zippé dans blueprint.zip à chaque démarrage.

Exemple :

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

Comment fonctionne la priorité ?

priorityOrder place la priorité la plus haute en haut et la plus basse en bas.

Pour les fichiers non fusionnables, le pack de priorité supérieure remplace le fichier de priorité inférieure. Pour les fichiers JSON fusionnables, ResourcePackManager fusionne le contenu au lieu de le remplacer aveuglément.

Le code traite actuellement ces éléments comme fusionnables :

• sounds.json
• les fichiers de langue sous lang ou languages
• le JSON des modèles d'items vanilla sous minecraft/models/item (ceux-ci subissent une fusion non récursive : seul le tableau overrides est combiné entre packs, tandis que le reste du fichier suit la règle priorité-la-plus-haute-l'emporte)
• les fichiers atlas
• les fichiers de police
• les définitions de modèles d'items 1.21.4+ sous items/ (fusion adaptée au format : préserve les arbres de prédicats intacts, ne descend pas aveuglément dans des types de nœuds différents)

pack.mcmeta suit des règles particulières : le pack_format le plus élevé l'emporte et les plages de formats déclarées sont combinées. Les entrées d'overlay visant des répertoires distincts sont réunies ; si le répertoire est identique, l'entrée de priorité supérieure l'emporte. Chaque overlay conserve les valeurs formats, min_format, max_format et les métadonnées supplémentaires de son auteur. Seul ajout : Minecraft 1.21.9+ rejette une liste d'overlays dans laquelle un overlay atteint le format de pack 64 ou inférieur alors qu'un autre ne déclare pas de formats. Lorsqu'une liste fusionnée contient un tel overlay, RSPM donne donc à chaque entrée qui ne déclare que min_format/max_format une plage formats équivalente. En dehors de ce cas, RSPM ne réécrit pas les plages des overlays. Les champs supplémentaires de pack, d'overlays et de l'objet racine sont conservés lorsqu'ils n'entrent pas en conflit avec une valeur de priorité supérieure.

Après la fusion de tous les packs, ResourcePackManager fusionne les sources d'atlas de base dans les fichiers d'atlas d'overlay. Cela évite que les overlays ne masquent accidentellement les entrées d'atlas de base quand Minecraft active un overlay (par ex. ia_overlay_modern_atlas / ia_overlay_legacy_atlas d'ItemsAdder).

Les autres fichiers JSON sont remplacés au lieu d'être fusionnés.

Les packs qui ne sont pas listés dans priorityOrder sont quand même inclus dans la fusion mais reçoivent la priorité la plus basse.

Les entrées ZIP complètes identiques octet par octet sont dédupliquées avant la fusion, en conservant la première copie (la plus prioritaire). Après la fusion, RSPM répare également deux défauts fréquents des modèles Java : il ajoute une texture particle manquante à partir de la première texture concrète du modèle lorsque c'est possible, et ramène les coordonnées UV de modèle invalides dans la plage 0..16 de Minecraft.

ResourcePackManager reconstruit-il automatiquement quand les packs changent ?

Oui. Il surveille les sources de packs prises en charge pour détecter les modifications.

Lorsqu'un pack surveillé cesse de changer pendant 3 secondes, ResourcePackManager le marque comme stable. Une fois que tous les packs surveillés sont stables, la refusion s'exécute immédiatement. Pendant cette transition, les joueurs OP en ligne sont notifiés : « All resource packs are stable. Mixing and sending now. »

Une refusion dont les entrées sont identiques octet par octet à la précédente ne refusionne pas. RSPM calcule une empreinte de la liste ordonnée des packs source (nom, taille, hachage du contenu) et la stocke à côté de la sortie sous .rspm_mix_fingerprint ; lorsque l'empreinte correspond et que chaque fichier de sortie attendu est toujours présent, il republie le zip existant au lieu de le reconstruire. Tout ce qui est douteux — une sortie manquante, une empreinte illisible, un ZIP fusionné dont le SHA-1 ne correspond plus — bascule vers un mix complet. C'est aussi pourquoi un /rspm reload qui ne change rien peut se terminer presque instantanément et réutiliser l'enregistrement d'hébergement existant.

Lorsque les entrées Java sont inchangées mais que la partie Bedrock doit être refaite (conversion Bedrock activée sans pack Bedrock sur le disque, changement de bedrockConversionEnabled ou de la cible Bedrock, ou mise à jour du convertisseur qui modifie la sortie Bedrock), RSPM conserve le ZIP Java vérifié et ne refait que l'étape Bedrock : les octets et le SHA-1 du pack Java restent donc identiques.

Au démarrage, RSPM vérifie l'empreinte enregistrée et le SHA-1 du ZIP fusionné avant que les plugins surveillés aient fini de s'initialiser. S'ils correspondent, l'hébergement Java démarre immédiatement à partir du pack enregistré. Le watchdog relance tout de même un mix si un pack source change ensuite.

La surveillance tient-elle compte de l'initialisation des plugins ?

Oui. La surveillance tient compte des états d'initialisation des plugins Magmacore.

• Il attend que tous les plugins surveillés terminent leur initialisation Magmacore avant de commencer les vérifications de stabilité.
• Si un plugin passe à l'état INITIALIZING pendant la surveillance, celle-ci se met en pause et réinitialise le suivi de stabilité jusqu'à la fin de l'initialisation. Les intégrations facultatives en échec ou non initialisées ne bloquent pas indéfiniment l'ensemble du mixeur.
• Cela empêche les fausses détections d'« instabilité » qui se produiraient sinon pendant le démarrage normal des plugins ou les séquences de rechargement.

Comment les joueurs reçoivent-ils le pack final ?

Lorsque autoHost est activé (par défaut), ou lorsque selfHostForce le surcharge explicitement, RSPM choisit un chemin de distribution et pousse cette URL à chaque joueur Java qui se connecte. L'arbre de décision est :

1. Avec selfHostForce: true, tenter l'auto-hébergement sans sondes, principalement pour les tests. La validation de l'URL et le démarrage HTTP doivent toujours réussir.
2. Sinon, avec preferSelfHost: true (par défaut) et selfHostEnabled: true, vérifier l'adresse, comparer les échantillons du pack téléchargés via localhost et l'URL exacte du joueur, puis exiger l'accessibilité externe via magmaguy.com. Choisir l'auto-hébergement uniquement si tous les contrôles réussissent.
3. Si l'auto-hébergement échoue ou est désactivé, réutiliser ou téléverser le pack sur magmaguy.com/rsp/ et annoncer cette URL. Un échec distant peut revenir à l'auto-hébergement s'il est activé, mais avec les mêmes contrôles. Une sonde externe indisponible empêche l'auto-hébergement automatique ; si les deux voies échouent, aucune nouvelle URL de distribution n'est annoncée.

Une fois une URL en main, RSPM utilise l'API multi-packs afin de coexister avec d'autres packs envoyés par le serveur. Le descripteur de plugin Bukkit actuel exige Minecraft 1.21.4 ou plus récent.

L'offre de connexion est différée d'environ une seconde. Une réponse FAILED_DOWNLOAD ou DISCARDED est réessayée automatiquement, jusqu'à trois tentatives pour cette session de joueur ; un pack refusé, une URL invalide ou un FAILED_RELOAD (le rechargement des ressources du client lui-même a échoué ; consultez le latest.log de ce client) ne sont pas réessayés. Les joueurs Floodgate sont ignorés ici, car leur pack Bedrock est distribué via Geyser.

Si autoHost: false et selfHostForce: false, RSPM ne pousse aucune URL — vous êtes censé prendre le zip dans plugins/ResourcePackManager/output/ et le servir via votre propre pipeline.

Voir Auto-hébergement pour l'arbre de décision de distribution complet.

Puis-je auto-héberger au lieu d'utiliser l'hébergement automatique intégré ?

Oui — et depuis RSPM v2, le serveur HTTP intégré est le chemin d'auto-hébergement recommandé. selfHostEnabled: true et preferSelfHost: true sont tous deux activés par défaut.

Si vous voulez plutôt héberger le zip via votre propre serveur web existant, en dehors de l'un ou l'autre des chemins intégrés :

• Définissez autoHost: false.
• Définissez éventuellement resourcePackRerouting sur un chemin de dossier existant relatif au répertoire plugins.
• Prenez le pack fusionné dans plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip et hébergez-le vous-même.

Si resourcePackRerouting est défini, RSPM écrit également une copie de ce zip dans le dossier de reroutage. Ce chemin de reroutage est résolu relativement au répertoire plugins, et le dossier cible doit déjà exister.

Existe-t-il une commande pour demander les données stockées chez l'hébergeur ?

Oui. Utilisez :

/rspm data_compliance_request

Si l'hébergement automatique distant magmaguy.com possède une session active, ResourcePackManager télécharge la réponse dans :

plugins/ResourcePackManager/data_compliance/data.zip

RSPM écrit également un ReadMe.md dans ce même dossier data_compliance.

S'il n'y a pas de session distante active (par ex. si vous auto-hébergez), la commande vous indique qu'il n'y a aucune donnée distante à demander.

Quelles options de configuration sont disponibles ?

plugins/ResourcePackManager/config.yml expose les éléments suivants :

Général

• priorityOrder — liste contrôlant quels packs l'emportent sur les conflits de fichiers (priorité la plus haute en premier)
• autoHost — indique si ResourcePackManager héberge automatiquement et envoie le pack fusionné (booléen, défaut true)
• forceResourcePack — indique s'il faut forcer les joueurs à accepter le pack (booléen, défaut false)
• resourcePackPrompt — le message d'invite affiché lorsque le pack est proposé (défaut "Use recommended resource pack?")
• resourcePackRerouting — chemin de dossier optionnel (relatif à plugins) pour écrire une copie supplémentaire du zip fusionné
• verboseLogging — affiche chaque étape de la préparation du pack et de la poignée de main d'hébergement (booléen, défaut false). Désactivé par défaut afin que la console n'affiche que le résultat final ; activez-le pour diagnostiquer un problème de fusion ou d'hébergement. /rspm verbose on|off bascule cette même clé à l'exécution et l'enregistre. Distinct de bedrockConverterDebug, qui couvre le pipeline Bedrock.
• nightbreak.autoDownloadPluginUpdates — indique si RSPM télécharge automatiquement ses propres mises à jour de plugin au démarrage (booléen, défaut false ; un redémarrage reste nécessaire pour appliquer une mise à jour téléchargée). C'est une clé imbriquée sous la section nightbreak:, et non une clé de premier niveau — rechercher une ligne autoDownloadPluginUpdates nue dans config.yml ne la trouvera qu'indentée sous nightbreak:. C'est la même bascule exposée dans l'interface graphique /rspm setup. Les téléchargements automatiques du plugin nécessitent un token de compte Nightbreak valide et un abonnement Patreon supporter actif. RSPM n'écrit pas la clé partagée nightbreak.applyPluginUpdatesWithoutRestart et n'applique jamais une mise à jour téléchargée sans redémarrage, car son extension Geyser ne se charge qu'au démarrage de Geyser.

Auto-hébergement

• selfHostEnabled — indique si le serveur HTTP intégré peut être utilisé (booléen, défaut true)
• selfHostPort — port du serveur HTTP d'auto-hébergement. -1 (par défaut) le calcule comme mcPort + networkHttpOffset-v2. Les ports explicites et calculés doivent être compris entre 1 et 65535.
• networkHttpOffset-v2 — décalage de repli ajouté au port du serveur Minecraft lorsque selfHostPort = -1. Défaut 1 (par ex. MC 25565 → HTTP 25566). Sur un réseau, vous n'avez plus à le maintenir synchronisé avec le proxy : le backend annonce automatiquement au proxy le port HTTP exact auquel il s'est réellement lié, et le proxy n'utilise son propre network-http-offset-v2 que comme estimation avant l'arrivée de cette annonce.
• selfHostExternalHost — nom d'hôte ou IP publique que les clients utilisent pour atteindre votre serveur d'auto-hébergement. Vide par défaut pour détecter automatiquement l'hôte.
• selfHostExternalUrl — URL publique HTTP/HTTPS complète du pack, chemin compris, pour un proxy inverse. Vide par défaut. Remplace l'URL annoncée, sans changer le point d'écoute local ; les identifiants intégrés et les fragments sont refusés.
• selfHostForce — saute toutes les vérifications de cohérence ET le téléversement distant, auto-héberge toujours (booléen, défaut false — pour les tests).
• preferSelfHost — essayer d'abord l'auto-hébergement avec des vérifications de cohérence avant de se replier sur le téléversement distant (booléen, défaut true).

Bedrock

• bedrockConversionEnabled — convertir le pack Java fusionné en pack Bedrock pour GeyserMC (défaut true)
• bedrockAutoDeployToGeyser — copier le fichier de mappings personnalisés Geyser dans le dossier Geyser détecté (défaut true)
• bedrockGeyserFolder — surcharge manuelle du chemin du dossier Geyser ; vide = détection automatique
• bedrockConverterDebug — lignes de journal détaillées par item / par os du pipeline Bedrock (défaut false)
• geyserExtensionAutoInstall — installe et met à jour le ResourcePackManager.jar universel en tant qu'extension Geyser afin que les entités Bedrock personnalisées s'affichent (défaut true). Le mettre à false empêche les futures installations et mises en file de mises à jour ; cela ne supprime pas un jar d'extension déjà présent — retirez-le à la main pendant que Geyser est arrêté. Le plugin proxy possède le même interrupteur sous un autre nom, geyser-extension-auto-install.

Les versions antérieures avaient aussi plugins/ResourcePackManager/bedrock_display_offsets.yml, avec des paramètres de décalage des items tenus en main. Ce fichier n'est plus lu : les poses Bedrock des items tenus en main proviennent désormais des transformations display du modèle Java. Voir Poses des objets tenus en main.

Il n'existe intentionnellement aucune option de configuration network-key, ni sur le backend ni sur le proxy. Coller une clé à la main était la plus grande source de mauvaise configuration — une faute de frappe cassait silencieusement le lien proxy↔backend sans la moindre erreur nulle part.

À la place, c'est le proxy qui possède la clé réseau et qui la distribue :

• Le proxy lit d'abord un network-key enregistré et valide, puis essaie de dériver la clé de plugins/floodgate/key.pem ; à défaut, il génère une clé aléatoire. Il enregistre le résultat dans son dossier de données. Les démarrages suivants réutilisent la clé tant qu'elle est valide ; sa perte relance ce processus et peut recréer la même clé dérivée de Floodgate. Voir la récupération de la clé réseau.
• Chaque backend reçoit cette clé sur le canal de messages de plugin rspm:network la première fois qu'un joueur s'y connecte, puis la conserve dans son propre data.yml. Un backend qui détient déjà une clé ignore les attributions ultérieures — rattacher un backend à un autre réseau est une action d'opérateur, pas quelque chose qu'un message puisse faire.
• Floodgate n'est pas requis pour la liaison RSPM. L'authentification Bedrock relève du mode choisi dans Geyser ; voir Floodgate et authentification en ligne.
• Un serveur autonome (non proxifié) génère et conserve sa propre clé, car il constitue son propre réseau à un seul serveur.

/rspm status de chaque côté affiche une courte empreinte de hachage à sens unique de la clé, jamais la clé elle-même. Des empreintes identiques indiquent une identité réseau commune ; vérifiez séparément les résultats de récupération pour confirmer la connectivité et la distribution du pack.

Pourquoi la console est-elle si silencieuse ? Le plugin travaille-t-il vraiment ?

C'est voulu. Préparer un pack est un long pipeline — préparer le pack de chaque plugin contributeur, fusionner les clusters, attendre qu'ils cessent de changer, mixer, convertir pour Bedrock, remettre le résultat à un hébergeur. Raconter tout cela produisait environ soixante lignes de console par démarrage et enterrait les deux seules choses que l'on lit : les joueurs vont-ils recevoir le pack, et que faire si ce n'est pas le cas.

Un démarrage normal n'affiche donc qu'une ligne :

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip

Cette ligne confirme la publication d'une URL de distribution. Connectez-vous avec un client et inspectez un contenu personnalisé connu pour vérifier le téléchargement et le rendu.

RSPM n'avertit délibérément pas des conditions qu'il corrige de lui-même. Si une sonde d'auto-hébergement échoue et que RSPM se replie sur l'hébergement distant, c'est un succès — la console rapporte le résultat, pas le détour. Avertir à propos de quelque chose de déjà géré se lit comme une panne et envoie les gens courir après un problème inexistant.

Pour voir la narration complète, exécutez /rspm verbose on (ou définissez verboseLogging: true dans config.yml) puis /rspm reload. Pour le convertisseur Bedrock spécifiquement, utilisez plutôt bedrockConverterDebug: true.

D'autres plugins peuvent-ils enregistrer leurs packs par code ?

Oui. ResourcePackManager expose une API Java pour l'enregistrement programmatique des packs. Voir la page API pour plus de détails.

La conversion Bedrock ne fonctionne-t-elle que pour FreeMinecraftModels ?

Non, plus maintenant. Le convertisseur actuel gère récursivement n'importe quel plugin dont le pack expédie des définitions d'items 1.21.4+ sous assets/<namespace>/items/**/*.json. Cela couvre les modèles d'os FreeMinecraftModels, l'équipement EliteMobs, les items personnalisés Oraxen/Nexo, les sets d'armures personnalisées, et tout pack que vous assemblez vous-même dans ce format. Les items personnalisés 2D simples sont émis sous forme d'icônes Bedrock plates ; les items personnalisés 3D émettent une géométrie/des attachables Bedrock ainsi qu'une icône d'inventaire rendue par logiciel.

Dois-je redémarrer le serveur chaque fois que le pack Bedrock change ?

Les modifications de textures et de modèles d'objets personnalisés existants prennent effet pour le prochain joueur Bedrock qui se connecte : RSPM distribue le pack Bedrock par session via l'API Geyser. Redémarrez le processus hébergeant Geyser lorsque les mappings d'objets changent ou que de nouveaux identifiants d'entités personnalisées ou types de propriétés doivent être enregistrés. Ces enregistrements ont lieu au démarrage. Réexporter des identifiants d'entités déjà enregistrés avec les mêmes types de propriétés ne nécessite pas, à lui seul, de nouveau redémarrage.

ResourcePackManager fonctionne-t-il sur BungeeCord / Velocity ?

Oui. Installez le même ResourcePackManager.jar sur le proxy et sur chaque backend qui fournit des packs de ressources. Le jar contient les points d'entrée Bukkit, Velocity et BungeeCord. Un backend derrière un proxy prépare une copie dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar s'il n'a pas reçu de clé réseau. Les autres serveurs enregistrés peuvent fonctionner sans RSPM ; la détection des backends les empêche de retarder la synchronisation des packs.

En s'exécutant comme plugin proxy, il fusionne le pack Bedrock converti de chaque backend et le sert aux clients Bedrock via le Geyser du proxy. La distribution du pack Java reste gérée directement par chaque backend — les clients Java voient les packs par backend.

Les étapes de configuration, de dépannage et de vérification se trouvent dans Réseaux proxy.