ResourcePackManager (RSPM)
ResourcePackManager détecte, fusionne, héberge et distribue les packs de ressources des plugins pris en charge ainsi que les packs fournis manuellement. Il peut également convertir le pack Java fusionné en pack de ressources Bedrock afin que les joueurs GeyserMC voient le même contenu personnalisé que les joueurs Java. Il prend aussi en charge les réseaux proxy BungeeCord et Velocity.
Fonctionnalités
- détecte les packs des plugins pris en charge et les fusionne selon
priorityOrder - exécute son propre serveur HTTP intégré pour pouvoir auto-héberger le pack fusionné (aucun hôte de fichiers externe requis)
- peut utiliser l'hébergement gratuit de MagmaGuy (hébergement automatique) lorsque l'auto-hébergement n'est pas viable
- peut forcer l'utilisation du pack ou la proposer en option
- surveille les modifications des packs et refusionne automatiquement lorsque les sources se stabilisent
- convertit le pack Java fusionné en pack de ressources Bedrock pour GeyserMC
- enregistre auprès de Geyser de véritables entités Bedrock personnalisées via une extension Geyser intégrée, afin que les entités modélisées (par ex. FreeMinecraftModels, EliteMobs) s'affichent et s'animent pour les joueurs Bedrock
- fonctionne sur les réseaux proxy : les backends participants produisent des packs Bedrock ; le proxy les découvre, fusionne leurs packs et sert le résultat via Geyser
- relie un réseau sans aucune clé à coller : le proxy possède la clé réseau, l'enregistre dans son propre fichier
network-keyet la transmet automatiquement à chaque backend la première fois qu'un joueur s'y connecte - peut se tenir à jour à l'échelle d'un réseau : les backends proposent le jar de plugin universel via une route authentifiée ; le proxy valide sa structure et sa version, refuse les rétrogradations, vérifie les octets transférés par SHA-256 et le prépare pour le prochain arrêt
Aperçu de l'architecture
RSPM v2 est un build Maven multi-module, mais il est livré sous forme de jar unique : ResourcePackManager.jar. Ce jar unique contient à la fois le plugin Bukkit/Paper, le plugin Velocity et le plugin BungeeCord — Minecraft charge le point d'entrée correspondant à la plateforme sur laquelle il s'exécute. Il n'y a plus de fichiers ResourcePackManager-Velocity.jar / ResourcePackManager-BungeeCord.jar séparés à extraire.
Le dossier proxy-extension/ existe toujours, mais son rôle a changé : lorsqu'un backend détecte qu'il est derrière un proxy et qu'aucune clé réseau ne lui a jamais été remise, il prépare une copie strictement identique de son propre jar en cours d'exécution dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar et vous demande de copier ce fichier sur le proxy. Cette copie du jar existant facilite l'installation ; ce n'est pas un fichier distinct pour chaque plateforme.
Le même jar joue deux rôles selon l'endroit où vous le déposez :
- En tant que plugin backend (sur chaque backend Paper/Spigot) — fusionne les packs Java, exécute le convertisseur Bedrock, héberge le pack, expose un petit serveur HTTP et pousse les packs aux clients Java.
- En tant que plugin proxy (sur un proxy Velocity ou BungeeCord) — récupère le pack Bedrock et les mappings de chaque backend, les fusionne en un seul pack à l'échelle du réseau et le sert aux clients Bedrock via le Geyser du proxy.
Un serveur autonome n'a besoin que du jar sur le backend. Un réseau proxy utilise le même jar sur le proxy et sur les backends qui fournissent des packs de ressources. Les serveurs enregistrés sans RSPM ne retardent pas la synchronisation des packs. Voir la découverte des backends.
Le même jar fait également office d'extension Geyser. Lorsque le backend détecte une installation Geyser-Spigot locale, il installe exactement ce même ResourcePackManager.jar universel dans Geyser-Spigot/extensions/ afin que Geyser puisse rendre les entités Bedrock personnalisées de RSPM ; le rôle proxy fait de même pour le Geyser du proxy. (Les anciennes versions livraient un ResourcePackManager-GeyserBridge.jar séparé — ce fichier est retiré et remplacé automatiquement via la file de mise à jour de Geyser.) Voir Extension Geyser et entités personnalisées.
Options d'hébergement
La distribution du pack Java suit cet ordre de priorité :
- Auto-hébergement forcé (
selfHostForce: true) — remplaceautoHostetselfHostEnabled, ignore les sondes et le téléversement distant. Principalement pour les tests. La validation de l'URL et le démarrage HTTP doivent réussir avant son annonce. - Avec
autoHost: true,preferSelfHost: trueetselfHostEnabled: true, RSPM essaie d'abord l'auto-hébergement sur les serveurs autonomes et les backends de proxy. Il vérifie l'adresse, compare des échantillons du pack téléchargés via localhost et l'URL exacte du joueur, et exige l'accessibilité externe avant d'annoncer l'URL. Une vérification échouée ou indisponible entraîne le repli distant. Le proxy continue de récupérer les artefacts Bedrock sur le serveur HTTP du backend. - Hébergement distant de secours — si l'auto-hébergement est désactivé ou si la vérification échoue, RSPM réutilise ou téléverse le pack sur
magmaguy.com/rsp/et annonce cette URL. Un échec distant peut revenir à l'auto-hébergement avecselfHostEnabled: true, sous réserve des mêmes vérifications. Si les deux voies automatiques échouent, aucune nouvelle URL de distribution n'est annoncée.
Si autoHost: false et selfHostForce: false, RSPM écrit le zip fusionné dans plugins/ResourcePackManager/output/ sans pousser d'URL.
Voir Auto-hébergement pour l'arbre de décision de distribution complet, la résolution du port et la détection de l'hôte externe.
selfHostExternalUrl permet à un proxy inverse d'exposer le pack Java à une URL HTTP ou HTTPS complète tout en conservant la distribution automatique de RSPM. Le proxy inverse gère TLS et transmet les requêtes à la route intégrée /rspm.zip.
Conversion Java vers Bedrock
Le convertisseur Bedrock n'est plus réservé à FreeMinecraftModels. Il parcourt récursivement chaque fichier de définition d'items 1.21.4+ (assets/<namespace>/items/**/*.json) du pack fusionné et produit la géométrie Bedrock, les attachables et les icônes d'inventaire pour le plugin qui les a fournis :
- Les joueurs Bedrock voient les items 3D, les armures personnalisées et les équipements modélisés pour tout plugin dont le pack utilise le format de définition d'items 1.21.4+.
- Les textures d'armure personnalisée s'affichent sur les joueurs Bedrock en utilisant la géométrie d'armure vanilla avec la texture Java comme couche visible.
- Les icônes d'inventaire pour les items 3D sont rendues par logiciel à partir du modèle Java via la transformation
display.gui. - Le pack Bedrock est servi en direct par session Bedrock via l'API de Geyser, de sorte que les ajustements de textures et de modèles atteignent le prochain joueur Bedrock qui se connecte sans redémarrage du serveur. Les mappings d'items personnalisés nécessitent toujours un redémarrage car Geyser les enregistre au démarrage.
- Les items 3D tenus en main prennent leurs poses à la première et à la troisième personne des transformations
display.firstperson_righthandetdisplay.thirdperson_righthanddu modèle Java, appliquées au squelette de joueur Bedrock vanilla. Il n'y a aucun décalage à régler. - Les items 3D tenus en main dont le plugin fournit un fichier annexe de particules, comme les items FreeMinecraftModels dotés d'effets de particules, jouent ces particules pour les joueurs Bedrock. Les ensembles d'entités peuvent aussi fournir des fichiers de particules Bedrock.
Intégrations actuelles
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
Chaque intégration ne s'active que si le plugin est installé et que son chemin local ou son URL distante configurés sont exploitables. Le plugin détecte également Geyser au démarrage, qu'il s'agisse de Geyser-Spigot sur un backend ou de Geyser-Velocity / Geyser-BungeeCord sur un proxy, et y raccorde la distribution du pack Bedrock.
Pour continuer
- Installation — procédure d'administration d'un serveur autonome
- Réseaux proxy — configuration étape par étape pour BungeeCord / Velocity
- Auto-hébergement — serveur HTTP intégré, résolution du port, détection de l'hôte externe
- Conversion Bedrock / Geyser — ce qui est converti et comment
- Extension Geyser et entités personnalisées — comment l'extension intégrée est installée, versions de Geyser requises
- FAQ — questions fréquentes
- Dépannage — quoi vérifier quand quelque chose ne fonctionne pas
- API — enregistrer des packs depuis votre propre plugin