Aller au contenu principal

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), la surface de commandes implémentée dans le code est :

  • /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 reload — reconstruit et réhéberge le pack fusionné
  • /rspm status — vidage de diagnostic complet (état du pack, mode d'hébergement, clé réseau, intégrations)
  • /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. Une poignée de sous-commandes partagées MagmaCore/Nightbreak (par ex. /rspm recommendedplugins, /rspm downloadall) sont également enregistrées et sont celles vers lesquelles pointent les boutons du menu de configuration.

Permissions du backend :

  • /rspm setup nécessite resourcepackmanager.setup et est réservée aux joueurs (elle ouvre une interface graphique d'inventaire).
  • /rspm reload, /rspm status, /rspm itemsadder <configure|dismiss> et /rspm data_compliance_request nécessitent toutes 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.

Les commandes du proxy vérifient resourcepackmanager.command.status ou resourcepackmanager.*. La console dispose toujours des deux ; les joueurs doivent se les voir accorder via votre plugin de permissions. La sortie peut être partagée sans risque — la clé réseau est masquée 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.

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 enfin recharger ResourcePackManager (~15 s plus tard)
  • 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. Placez votre fichier .zip 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.

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 est fusionné de manière spéciale : le pack_format le plus élevé l'emporte, les plages supported_formats sont élargies pour couvrir tous les packs (les formats entier, tableau de deux entiers et objet {min_inclusive, max_inclusive} sont pris en charge), les entrées d'overlay sont combinées et les clés de premier niveau non standard (par ex. sodium) sont préservées. Les entrées d'overlay sont normalisées pour la compatibilité 1.21.9+ en ajoutant les champs min_format/max_format lorsqu'ils sont absents.

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.

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. »

Le chien de garde tient-il compte de l'initialisation des plugins ?​

Oui. Le chien de garde est conscient 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 se recharge alors que le chien de garde est en cours d'exécution, il détecte le changement d'état, se met en pause, réinitialise tout le suivi de stabilité et attend que le plugin termine sa réinitialisation.
  • 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), RSPM choisit automatiquement un chemin de distribution et pousse cette URL à chaque joueur qui se connecte. L'arbre de décision est :

  1. Si selfHostForce: true, toujours auto-héberger (saute toutes les sondes — principalement pour les tests).
  2. Sinon, si preferSelfHost: true (par défaut), essayer d'abord l'auto-hébergement, exécuter trois vérifications de cohérence (hôte résolu non-LAN, sonde locale localhost, sonde d'accessibilité externe via magmaguy.com), et s'engager dans l'auto-hébergement si les trois réussissent.
  3. Si l'auto-hébergement échoue ou est désactivé, téléverser le pack vers magmaguy.com/rsp/ et annoncer cette URL.

Une fois une URL en main, RSPM utilise l'API multi-packs sur Minecraft 1.20.3+ afin de coexister avec d'autres packs envoyés par le serveur. Sur les versions plus anciennes, il revient à l'ancienne méthode mono-pack, qui remplace toute attribution de pack de ressources serveur existante.

Si autoHost: 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'auto-hébergement 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 d'hôte stockées ?​

Oui. Utilisez :

/rspm data_compliance_request

Si l'auto-hébergement distant magmaguy.com a une session active, ResourcePackManager télécharge la réponse dans :

plugins/ResourcePackManager/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 auto-héberge 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é
  • 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.

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 (défaut) auto-dérive comme mcPort + networkHttpOffset-v2. Réglez-le sur n'importe quel entier positif pour forcer un port explicite.
  • 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 (défaut) = détection automatique via api.ipify.org / checkip.amazonaws.com.
  • 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)

Un second fichier, plugins/ResourcePackManager/bedrock_display_offsets.yml, expose douze paramètres réglables par l'utilisateur pour ajuster finement la position des items tenus en main vue par les joueurs Bedrock par rapport à leur main (six pour la première personne, six pour la troisième personne). Voir Conversion Bedrock pour plus de détails.

Il n'existe intentionnellement aucune option de configuration network-key. La clé qui relie le proxy à ses backends est auto-dérivée de plugins/floodgate/key.pem sur chaque JVM. Floodgate exige déjà que ce fichier soit identique sur tout le réseau pour l'authentification Bedrock, donc la clé dérivée correspond automatiquement partout.

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 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 ajustements de textures et de modèles sur les items personnalisés existants prennent effet pour le prochain joueur Bedrock qui se connecte — RSPM sert le pack Bedrock en direct par session via l'API de Geyser. Un redémarrage n'est requis que lorsque l'ensemble des items personnalisés change (ajout de nouveaux items ou suppression d'items existants), car Geyser enregistre ses identifiants d'items personnalisés au démarrage.

ResourcePackManager fonctionne-t-il sur BungeeCord / Velocity ?​

Oui — c'est une topologie prise en charge de première classe. C'est le même ResourcePackManager.jar partout : mettez-le sur chaque backend, et mettez-en une copie sur le proxy. Le jar unique regroupe les points d'entrée Bukkit, Velocity et BungeeCord/Waterfall, de sorte qu'il se charge correctement que l'hôte soit un backend ou un proxy. Il n'y a plus de jars proxy séparés ni de dossier proxy-extension/.

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.