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

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

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, la conversion Bedrock activée sans pack Bedrock sur le disque — 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.

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), 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. 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 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é ou une URL invalide 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'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/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 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é
  • 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.

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)
  • 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.

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, 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 résout sa clé une seule fois : il lit son fichier network-key enregistré s'il en existe un, sinon il initialise la valeur depuis plugins/floodgate/key.pem si ce fichier existe (afin qu'un réseau existant conserve son identité après la mise à jour), sinon il en génère une neuve. Dans tous les cas, il enregistre le résultat dans network-key dans le dossier de données propre au plugin proxy et ne regarde plus jamais key.pem.
  • 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 cela. Il est requis pour que les joueurs Bedrock atteignent le proxy, mais un réseau uniquement Java peut utiliser les fonctionnalités proxy de RSPM sans lui.
  • 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 sur le proxy et le backend signifient que le lien est bon.

Pourquoi la console est-elle si silencieuse ? Fait-il seulement quelque chose ?​

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

Si vous voyez cette ligne, ça a fonctionné.

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 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 pas de jars proxy par plateforme distincts à construire ou extraire — et si vous oubliez la copie sur le proxy, un backend proxifié en prépare une pour vous dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar et le signale dans la console.

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.