Resource Pack Manager – FAQ

Falls deine Frage hier nicht beantwortet wird, sieh zuerst die anderen ResourcePackManager-Seiten in der Seitenleiste durch.

Welche Befehle stellt ResourcePackManager derzeit bereit?

Auf dem Backend (Paper / Spigot) umfasst die im Code hinterlegte Befehlsoberfläche:

• /rspm setup — öffnet ein In-Game-GUI-Einrichtungsmenü (Plugin-Update-Status, empfohlene Plugins, Umschalter für automatische Updates, Links zu Wiki / Discord / Nightbreak-Konto)
• /rspm recommendedplugins — zeigt das gemeinsame Nightbreak-Menü der empfohlenen Plugins (oder in der Konsole eine Textliste)
• /rspm downloadpluginupdate — lädt ein verfügbares ResourcePackManager-Update für den nächsten Neustart herunter
• /rspm downloadall — lädt jedes von diesem Plugin bereitgestellte verfügbare Update herunter (derzeit das ResourcePackManager-Update)
• /rspm applypluginupdate — Teil des gemeinsamen Nightbreak-Befehlssatzes; RSPM verweigert ihn immer, weil seine Updates einen Serverneustart benötigen (seine Geyser-Erweiterung wird nur beim Start von Geyser geladen)
• /rspm reload — baut das zusammengeführte Paket neu auf und stellt es erneut bereit
• /rspm status — vollständiger Diagnose-Dump (Paket-Status, Hosting-Modus, Fingerabdruck des Netzwerkschlüssels, Integrationen)
• /rspm verbose [on|off] — schaltet die detaillierte Diagnose-Protokollierung ein oder aus. Ohne Argument wird umgeschaltet. Das Ergebnis wird nach verboseLogging in die config.yml zurückgeschrieben und übersteht damit Neustarts. Wird auch als /rspm verboselogging akzeptiert.
• /rspm itemsadder configure — konfiguriert ItemsAdder für das Hosting durch RSPM
• /rspm itemsadder dismiss — verwirft die ItemsAdder-Warnung für deine Spieler-UUID dauerhaft
• /rspm data_compliance_request — lädt alle remote gespeicherten Daten für diesen Server herunter

Der Hauptbefehl ist /resourcepackmanager, mit /rspm als Alias. Die obigen Update- und Empfohlene-Plugins-Befehle sind gemeinsame MagmaCore-/Nightbreak-Befehle, die von RSPM registriert werden.

MagmaCore registriert außerdem diese Befehle der obersten Ebene, die keine /rspm-Unterbefehle sind:

• /nightbreaklogin <token> und /nightbreaklogout speichern bzw. löschen den gemeinsamen Nightbreak-Konto-Token des Servers. Beide erfordern nightbreak.login (Standard: OP). Siehe Nightbreak-Kontoverknüpfung.
• /nightbreak plugins durchsucht den Nightbreak-Plugin-Katalog und erfordert nightbreak.plugins (Standard: OP).
• /logify lädt das aktuelle Server-Log zu mclo.gs hoch und erfordert logify.* (Standard: OP).
• /resourcepackmanagerchangelog [dismiss|disable] zeigt Administratoren die ResourcePackManager-Release-Notes, die sie noch nicht gelesen haben. Siehe Changelog-Benachrichtigungen.

Das zuerst geladene Nightbreak-Plugin registriert /nightbreaklogin, /nightbreaklogout, /nightbreak und /logify für den gesamten Server.

Backend-Berechtigungen:

• /rspm setup und /rspm recommendedplugins erfordern resourcepackmanager.setup. /rspm setup ist nur für Spieler nutzbar, weil es eine Inventar-GUI öffnet.
• /rspm downloadpluginupdate, /rspm downloadall, /rspm applypluginupdate, /rspm reload, /rspm status, /rspm verbose, /rspm itemsadder <configure|dismiss> und /rspm data_compliance_request erfordern resourcepackmanager.*.

Auf dem Proxy-Plugin (Velocity / BungeeCord) existieren nur Diagnosebefehle:

• /rspm status — Momentaufnahme der Proxy-Seite: Backend-Liste, Abrufergebnisse pro Backend, Status des zusammengeführten Pakets, Geyser-/Floodgate-Erkennung
• /rspm debug bedrock [on|off] — Velocity und BungeeCord. Schaltet ausführliche [RSPM-BedrockDebug]-Protokollzeilen des GeyserBinder um, um Fälle vom Typ „Bedrock-Spieler ist beigetreten, sah aber das Paket nicht" zu diagnostizieren. Wird bei einem Proxy-Neustart auf „aus" zurückgesetzt. Ohne Argument ausgeführt gibt der Befehl den aktuellen Zustand aus.

Auf Velocity akzeptieren Proxy-Befehle resourcepackmanager.command.status oder resourcepackmanager.*. BungeeCord registriert exakt den Knoten resourcepackmanager.command.status; ein Berechtigungs-Plugin kann ihn dennoch über Wildcard-Erweiterung erfüllen. Die Konsole kann die Befehle ausführen. Die Ausgabe kann gefahrlos geteilt werden — der Netzwerkschlüssel erscheint nur als kurzer Einweg-Hash-Fingerabdruck, nie der Schlüssel selbst, und es werden keine Tokens ausgegeben — daher sind großzügige Vergaben unproblematisch.

Welche Plugins werden derzeit unterstützt?

ResourcePackManager liefert vorgefertigte Integrationseinträge für folgende Plugins:

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

Diese Integrationen wirken nur, wenn das Plugin installiert ist und der dort konfigurierte lokale Pfad oder die Remote-URL nutzbar ist.

Jede Integration hat ihre eigene YAML-Konfigurationsdatei unter plugins/ResourcePackManager/compatible_plugins/. Dort kannst du pro Plugin isEnabled, pluginName, localPath, url, zips, cluster, additionalLocalPath und reloadCommand anpassen. Die Option cluster weist ResourcePackManager an, den lokalen Pfad als Verzeichnis mit mehreren Unterordnern für Ressourcenpakete zu behandeln, die alle zusammen zusammengeführt werden sollen.

Wie schließe ich eine automatische Plugin-Integration aus?

Setze in der Datei dieser Integration unter plugins/ResourcePackManager/compatible_plugins/ isEnabled: false und führe dann /rspm reload aus (oder starte neu). RSPM entfernt die Ressourcenpaket-Eingaben, die es für diese Integration erzeugt oder registriert hat, einschließlich der erzeugten Mixer-Kopien. Das Plugin aus priorityOrder zu entfernen schließt es nicht aus; es verschiebt dieses Paket nur auf die niedrigste Priorität. Um eine von Hand hinzugefügte ZIP auszuschließen, entferne oder verschiebe die ZIP aus dem Ordner mixer.

Ist ResourcePackManager mit ItemsAdder kompatibel?

Ja. ResourcePackManager enthält einen integrierten Helfer- und Warnablauf für ItemsAdder.

Wenn ItemsAdder installiert ist und noch für das Hosting durch ResourcePackManager angepasst werden muss, erhalten OP-Spieler einige Sekunden nach dem Beitritt eine klickbare Warnung. Spieler, die die Warnung dauerhaft verworfen haben, sehen sie nicht mehr. Von dort aus kannst du:

• /rspm itemsadder configure ausführen, um resource-pack.hosting.no-host.enabled: true zu setzen, alle drei protect-file-from-unzip-Einstellungen zu deaktivieren, compress-json-files: false zu setzen, /iareload und dann /iazip auszuführen und darauf zu warten, dass RSPM den neu erzeugten Export zusammenführt (es meldet, ob der Merge gelingt oder fehlschlägt; RSPM wird dabei nicht neu geladen)
• /rspm itemsadder dismiss ausführen, um die Warnung für deine Spieler-UUID dauerhaft zu verwerfen

Wenn ItemsAdder bereits so konfiguriert ist, dass es sein eigenes Paket über einen seiner Hosting-Modi bereitstellt, überschreibt der Helfer-Befehl das nicht automatisch. Er weist dich an, das ItemsAdder-Hosting zuerst selbst zu deaktivieren.

Kann ich mein eigenes Paket zum Merge hinzufügen?

Ja, und je nachdem, was du hast, gibt es zwei Orte dafür.

Eine fertige .zip gehört nach:

plugins/ResourcePackManager/mixer

Wenn du steuern möchtest, welches Paket bei Dateikonflikten gewinnt, trage den exakten Dateinamen inklusive .zip in priorityOrder in plugins/ResourcePackManager/config.yml ein.

Ein entpackter Paketordner (ein assets/-Baum plus pack.mcmeta) gehört nach:

plugins/ResourcePackManager/resource_pack

RSPM zippt diesen Ordner selbst und führt ihn unter dem Eintrag ResourcePackManager in priorityOrder zusammen, der ganz oben in der Standardliste steht — standardmäßig gewinnen seine Dateien also Konflikte gegen jedes Plugin-Paket. Verschiebe ResourcePackManager weiter nach unten, wenn es lieber verlieren soll.

Der zugehörige Ordner plugins/ResourcePackManager/blueprint enthält die pack.png und pack.mcmeta, die RSPM zu jedem Merge beisteuert. Bearbeite diese beiden Dateien, um das Symbol des zusammengeführten Pakets oder seine Beschreibung im Menü zu ändern; der Ordner wird bei jedem Start neu zu blueprint.zip gezippt.

Beispiel:

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

Wie funktioniert die Priorität?

priorityOrder ist oben die höchste Priorität und unten die niedrigste.

Bei nicht mergebaren Dateien ersetzt das Paket mit höherer Priorität die Datei des Pakets mit niedrigerer Priorität. Bei mergebaren JSON-Dateien führt ResourcePackManager die Inhalte zusammen, statt sie stumpf zu ersetzen.

Der Code behandelt derzeit Folgendes als mergebar:

• sounds.json
• Sprachdateien unter lang oder languages
• Vanilla-Item-Model-JSON unter minecraft/models/item (diese erhalten einen nicht rekursiven Merge: nur das overrides-Array wird über Pakete hinweg kombiniert, während der Rest der Datei „höchste Priorität gewinnt" folgt)
• Atlas-Dateien
• Schriftdateien
• Item-Modelldefinitionen im Format 1.21.4+ unter items/ (formatbewusstes Mergen: lässt Prädikatsbäume intakt und steigt nicht blind in andere Knotentypen ab)

Für pack.mcmeta gelten besondere Regeln: Das höchste pack_format gewinnt, und die angegebenen Formatbereiche werden zusammengeführt. Overlay-Einträge für unterschiedliche Verzeichnisse werden kombiniert; bei gleichem Verzeichnis gewinnt der Eintrag mit höherer Priorität. Jedes Overlay behält die vom Autor angegebenen Werte für formats, min_format, max_format und zusätzliche Metadaten. Die einzige Ergänzung: Minecraft 1.21.9+ lehnt eine Overlay-Liste ab, in der ein Overlay bis Paketformat 64 oder niedriger reicht und ein anderes keine formats angibt. Enthält eine zusammengeführte Liste ein solches Overlay, gibt RSPM daher jedem Eintrag, der nur min_format/max_format angibt, einen gleichwertigen formats-Bereich. Darüber hinaus schreibt RSPM Overlay-Bereiche nicht um. Zusätzliche Felder in pack, overlays und dem obersten Objekt bleiben erhalten, sofern sie keinem Wert mit höherer Priorität widersprechen.

Nach dem Mergen aller Pakete führt ResourcePackManager die Quellen der Basis-Atlanten in die Overlay-Atlasdateien ein. Dadurch wird verhindert, dass Overlays die Basis-Atlaseinträge versehentlich verdecken, wenn Minecraft ein Overlay aktiviert (z. B. ItemsAdders ia_overlay_modern_atlas / ia_overlay_legacy_atlas).

Andere JSON-Dateien werden ersetzt, nicht zusammengeführt.

Pakete, die nicht in priorityOrder aufgeführt sind, werden trotzdem in den Merge einbezogen, erhalten aber die niedrigste Priorität.

Byteweise identische vollständige ZIP-Eingaben werden vor dem Mergen dedupliziert, wobei die erste (höchstpriorisierte) Kopie behalten wird. Nach dem Merge repariert RSPM außerdem zwei häufige Java-Modellfehler: Es ergänzt eine fehlende particle-Textur, wo möglich, aus der ersten konkreten Textur des Modells, und begrenzt ungültige UV-Koordinaten von Modellen auf Minecrafts Bereich 0..16.

Wird das Paket bei Änderungen automatisch neu erstellt?

Ja. Er überwacht die Quellen unterstützter Pakete auf Änderungen.

Wenn ein überwachtes Paket 3 Sekunden lang nicht mehr geändert wurde, markiert ResourcePackManager es als stabil. Sobald alle überwachten Pakete stabil sind, erfolgt der Remix sofort. Während dieses Übergangs werden Online-OP-Spieler benachrichtigt: „All resource packs are stable. Mixing and sending now."

Ein Remix, dessen Eingaben byteweise identisch mit dem letzten sind, führt nicht neu zusammen. RSPM bildet einen Fingerabdruck der geordneten Liste der Quellpakete (Name, Größe, Inhalts-Hash) und legt ihn neben der Ausgabe als .rspm_mix_fingerprint ab; stimmt der Fingerabdruck überein und sind alle erwarteten Ausgabedateien noch vorhanden, veröffentlicht RSPM die vorhandene ZIP erneut, statt sie neu zu bauen. Alles Zweifelhafte — eine fehlende Ausgabe, ein unlesbarer Fingerabdruck, eine zusammengeführte ZIP, deren SHA-1 nicht mehr übereinstimmt — führt zu einem vollständigen Mix. Deshalb kann ein /rspm reload, das nichts ändert, praktisch sofort fertig sein und die bestehende Hosting-Registrierung wiederverwenden.

Sind die Java-Eingaben unverändert, muss aber die Bedrock-Seite neu erstellt werden (aktivierte Bedrock-Konvertierung ohne Bedrock-Paket auf der Festplatte, eine Änderung von bedrockConversionEnabled oder des Bedrock-Ziels oder ein Konverter-Update, das die Bedrock-Ausgabe ändert), behält RSPM die geprüfte Java-ZIP und wiederholt nur den Bedrock-Schritt, sodass Bytes und SHA-1 des Java-Pakets gleich bleiben.

Beim Start prüft RSPM den gespeicherten Fingerabdruck und den SHA-1 der zusammengeführten ZIP, bevor die überwachten Plugins ihre Initialisierung abgeschlossen haben. Stimmen sie überein, startet das Java-Hosting sofort mit dem gespeicherten Paket. Der Watchdog führt trotzdem einen Remix durch, wenn sich danach ein Quellpaket ändert.

Berücksichtigt der Watchdog die Plugin-Initialisierung?

Ja. Der Watchdog kennt die Magmacore-Initialisierungszustände von Plugins.

• Er wartet, bis alle überwachten Plugins ihre Magmacore-Initialisierung abgeschlossen haben, bevor er mit den Stabilitätsprüfungen beginnt.
• Wechselt ein Plugin bei laufendem Watchdog in den Zustand INITIALIZING, pausiert der Watchdog und setzt die Stabilitätserfassung zurück, bis die Initialisierung abgeschlossen ist. Fehlgeschlagene oder nicht initialisierte optionale Integrationen halten den gesamten Mixer nicht unbegrenzt auf.
• Damit werden falsche „instabil"-Erkennungen vermieden, die sonst bei normalen Plugin-Start- oder Reload-Sequenzen aufträten.

Wie erhalten Spieler das endgültige Paket?

Wenn autoHost aktiviert ist (Standard) oder wenn selfHostForce es ausdrücklich übersteuert, wählt RSPM einen Auslieferungspfad und schiebt diese URL an jeden beitretenden Java-Spieler. Der Entscheidungsbaum lautet:

1. Bei selfHostForce: true Selbst-Hosting ohne Erreichbarkeitsprüfungen versuchen, hauptsächlich für Tests. URL-Prüfung und Listener-Start müssen weiterhin erfolgreich sein.
2. Andernfalls bei preferSelfHost: true (Standard) und selfHostEnabled: true die Hostadresse prüfen, Paketstichproben von localhost und der genauen Spieler-URL vergleichen und externe Erreichbarkeit über magmaguy.com verlangen. Selbst-Hosting nur auswählen, wenn alle Prüfungen bestehen.
3. Scheitert Selbst-Hosting oder ist es deaktiviert, das Paket unter magmaguy.com/rsp/ erneut verwenden oder hochladen und diese URL bekannt geben. Ein Remote-Fehler kann auf aktiviertes Selbst-Hosting zurückfallen, muss aber dieselben Prüfungen bestehen. Ein nicht verfügbarer externer Prüfdienst verhindert automatisches Selbst-Hosting; scheitern beide Pfade, wird keine neue Auslieferungs-URL angekündigt.

Sobald eine URL vorliegt, verwendet RSPM die Multi-Pack-API, sodass es mit anderen vom Server gesendeten Paketen koexistiert. Der aktuelle Bukkit-Plugin-Deskriptor verlangt Minecraft 1.21.4 oder neuer.

Das Beitrittsangebot wird um etwa eine Sekunde verzögert. Eine Antwort FAILED_DOWNLOAD oder DISCARDED wird automatisch wiederholt, bis zu drei Versuche pro Spieler-Session; ein abgelehntes Paket, eine ungültige URL oder FAILED_RELOAD (das eigene Neuladen der Ressourcen im Client ist fehlgeschlagen; prüfe die latest.log dieses Clients) wird nicht wiederholt. Floodgate-Spieler werden hier übersprungen, weil ihr Bedrock-Paket stattdessen über Geyser ausgeliefert wird.

Wenn autoHost: false und selfHostForce: false, schiebt RSPM keine URL — es wird erwartet, dass du die ZIP-Datei aus plugins/ResourcePackManager/output/ nimmst und über deine eigene Pipeline ausspielst.

Siehe Selbst-Hosting für den vollständigen Auslieferungs-Entscheidungsbaum.

Kann ich selbst hosten, statt das eingebaute Auto-Hosting zu nutzen?

Ja — und seit RSPM v2 ist der eingebaute HTTP-Server der empfohlene Selbst-Hosting-Weg. selfHostEnabled: true und preferSelfHost: true sind beide standardmäßig aktiviert.

Wenn du die ZIP-Datei stattdessen über deinen eigenen, bestehenden Webserver hosten möchtest (also keinen der beiden eingebauten Wege):

• Setze autoHost: false.
• Setze optional resourcePackRerouting auf einen vorhandenen Ordnerpfad relativ zum Verzeichnis plugins.
• Nimm das zusammengeführte Paket aus plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip und hoste es selbst.

Wenn resourcePackRerouting gesetzt ist, schreibt RSPM außerdem eine Kopie dieser ZIP-Datei in den Reroute-Ordner. Dieser Reroute-Pfad wird relativ zum Verzeichnis plugins aufgelöst, und der Zielordner muss bereits existieren.

Gibt es einen Befehl, um gespeicherte Host-Daten anzufordern?

Ja. Verwende:

/rspm data_compliance_request

Wenn das magmaguy.com-Remote-Auto-Hosting eine aktive Sitzung hat, lädt ResourcePackManager die Antwort herunter nach:

plugins/ResourcePackManager/data_compliance/data.zip

RSPM schreibt außerdem eine ReadMe.md in denselben Ordner data_compliance.

Wenn keine aktive Remote-Sitzung besteht (z. B. weil du selbst hostest), meldet der Befehl, dass keine Remote-Daten angefordert werden können.

Welche Konfigurationsoptionen sind verfügbar?

In plugins/ResourcePackManager/config.yml stehen folgende Einstellungen zur Verfügung:

Allgemein

• priorityOrder — Liste, die steuert, welche Pakete bei Dateikonflikten gewinnen (höchste Priorität zuerst)
• autoHost — ob ResourcePackManager das zusammengeführte Paket automatisch hostet und sendet (boolean, Standard true)
• forceResourcePack — ob Spieler gezwungen werden sollen, das Paket anzunehmen (boolean, Standard false)
• resourcePackPrompt — die Hinweisnachricht, die beim Anbieten des Pakets angezeigt wird (Standard "Use recommended resource pack?")
• resourcePackRerouting — optionaler Ordnerpfad (relativ zu plugins), um eine zusätzliche Kopie der zusammengeführten ZIP-Datei zu schreiben
• verboseLogging — gibt jeden Schritt der Paketvorbereitung und des Hosting-Handshakes aus (boolean, Standard false). Standardmäßig aus, damit die Konsole nur das Endergebnis zeigt; schalte es ein, wenn du ein Merge- oder Hosting-Problem untersuchst. /rspm verbose on|off schaltet zur Laufzeit denselben Schlüssel um und speichert ihn. Getrennt von bedrockConverterDebug, das die Bedrock-Pipeline abdeckt.
• nightbreak.autoDownloadPluginUpdates — ob RSPM beim Start seine eigenen Plugin-Updates automatisch herunterlädt (boolean, Standard false; ein Neustart ist weiterhin erforderlich, um ein heruntergeladenes Update anzuwenden). Dies ist ein verschachtelter Schlüssel unter dem Abschnitt nightbreak:, kein Top-Level-Schlüssel — wenn du in der config.yml nach einer nackten Zeile autoDownloadPluginUpdates suchst, findest du sie nur eingerückt unter nightbreak:. Dies ist derselbe Umschalter, der auch in der /rspm setup-GUI bereitgestellt wird. Automatische Plugin-Downloads benötigen einen gültigen Nightbreak-Konto-Token und eine aktive Supporter-Patreon-Mitgliedschaft. RSPM schreibt den gemeinsamen Schlüssel nightbreak.applyPluginUpdatesWithoutRestart nicht und wendet ein heruntergeladenes Update nie ohne Neustart an, weil seine Geyser-Erweiterung nur beim Start von Geyser geladen wird.

Selbst-Hosting

• selfHostEnabled — ob der eingebaute HTTP-Server verwendet werden darf (boolean, Standard true)
• selfHostPort — Port des Selbst-Hosting-HTTP-Servers. -1 (Standard) berechnet ihn als mcPort + networkHttpOffset-v2. Explizite und berechnete Ports müssen zwischen 1 und 65535 liegen.
• networkHttpOffset-v2 — Fallback-Offset, der zum Minecraft-Server-Port addiert wird, wenn selfHostPort = -1. Standard 1 (z. B. MC 25565 → HTTP 25566). In einem Netzwerk musst du dies nicht mehr mit dem Proxy synchron halten: Das Backend kündigt dem Proxy automatisch den genauen HTTP-Port an, an den es tatsächlich gebunden hat, und der Proxy verwendet sein eigenes network-http-offset-v2 nur als Vermutung, bis diese Ankündigung eintrifft.
• selfHostExternalHost — öffentlicher Hostname oder IP, über den Clients deinen Selbst-Hosting-Server erreichen. Leer (Standard) = automatische Host-Erkennung.
• selfHostExternalUrl — optionale vollständige öffentliche HTTP- oder HTTPS-URL einschließlich Pfad für einen Reverse Proxy. Leer (Standard) = URL aus Host und Port erzeugen. Überschreibt die veröffentlichte URL, ohne den eingebauten HTTP-Listener zu ändern; URLs mit Zugangsdaten oder Fragmenten werden abgelehnt.
• selfHostForce — überspringt alle Plausibilitätsprüfungen UND den Remote-Upload, hostet immer selbst (boolean, Standard false — für Tests).
• preferSelfHost — zuerst Selbst-Hosting mit Plausibilitätsprüfungen versuchen, bevor auf den Remote-Upload zurückgefallen wird (boolean, Standard true).

Bedrock

• bedrockConversionEnabled — das zusammengeführte Java-Paket in ein Bedrock-Paket für GeyserMC umwandeln (Standard true)
• bedrockAutoDeployToGeyser — die Datei mit den benutzerdefinierten Geyser-Mappings in den erkannten Geyser-Ordner kopieren (Standard true)
• bedrockGeyserFolder — manuelle Pfadüberschreibung für den Geyser-Ordner; leer = automatische Erkennung
• bedrockConverterDebug — ausführliche Protokollzeilen der Bedrock-Pipeline pro Item / pro Bone (Standard false)
• geyserExtensionAutoInstall — die universelle ResourcePackManager.jar als Geyser-Erweiterung installieren und aktualisieren, damit benutzerdefinierte Bedrock-Entities gerendert werden (Standard true). Auf false zu setzen stoppt künftige Installationen und Update-Bereitstellungen; es löscht nicht eine Erweiterungs-Jar, die bereits dort liegt — die entfernst du von Hand, während Geyser gestoppt ist. Das Proxy-Plugin hat denselben Schalter unter einem anderen Namen: geyser-extension-auto-install.

Frühere Versionen hatten außerdem plugins/ResourcePackManager/bedrock_display_offsets.yml mit Offset-Einstellungen für gehaltene Items. Diese Datei wird nicht mehr gelesen: Die Posen gehaltener Items auf Bedrock stammen jetzt aus den display-Transformationen des Java-Modells. Siehe Posen gehaltener Items.

Es gibt absichtlich keine network-key-Konfigurationsoption, weder auf dem Backend noch auf dem Proxy. Einen Schlüssel von Hand einzufügen war die mit Abstand größte Quelle für Fehlkonfigurationen — ein Tippfehler zerstörte die Proxy↔Backend-Verbindung stillschweigend, ohne dass irgendwo ein Fehler auftauchte.

Stattdessen besitzt der Proxy den Netzwerkschlüssel und verteilt ihn:

• Der Proxy liest zuerst einen gültigen gespeicherten network-key, versucht dann die Ableitung aus plugins/floodgate/key.pem und erzeugt andernfalls einen Zufallsschlüssel. Er speichert das Ergebnis in seinem Datenordner. Spätere Starts verwenden den gespeicherten Schlüssel, solange er gültig ist. Geht er verloren, wird der Ablauf wiederholt und kann denselben Floodgate-Schlüssel ergeben. Siehe Wiederherstellung des Netzwerkschlüssels.
• Jedes Backend erhält diesen Schlüssel über den Plugin-Kanal rspm:network, sobald zum ersten Mal ein Spieler dorthin verbindet, und speichert ihn dann in seiner eigenen data.yml. Ein Backend, das bereits einen Schlüssel hat, ignoriert spätere Zuweisungen — ein Backend auf ein anderes Netzwerk umzulenken ist eine Betreiberhandlung, nichts, was eine Nachricht erledigen kann.
• Floodgate ist für die RSPM-Verknüpfung nicht erforderlich. Die Bedrock-Authentifizierung richtet sich nach dem gewählten Geyser-Authentifizierungsmodus; siehe Floodgate und Online-Authentifizierung.
• Ein eigenständiger (nicht proxied) Server erzeugt und behält seinen eigenen Schlüssel, weil er sein eigenes Ein-Server-Netzwerk ist.

/rspm status gibt auf beiden Seiten einen kurzen Einweg-Hash-Fingerabdruck des Schlüssels aus, nie den Schlüssel selbst. Übereinstimmende Fingerabdrücke auf Proxy und Backend bestätigen eine gemeinsame Netzwerkidentität; Paketabruf und Auslieferung müssen zusätzlich geprüft werden.

Warum ist die Konsole so still? Passiert überhaupt etwas?

So gewollt. Ein Paket vorzubereiten ist eine lange Pipeline — das Paket jedes beitragenden Plugins bereitstellen, Cluster zusammenführen, warten bis sie sich nicht mehr ändern, mixen, für Bedrock konvertieren, das Ergebnis an einen Host übergeben. Das alles zu erzählen erzeugte rund sechzig Konsolenzeilen pro Start und begrub die einzigen beiden Dinge, die überhaupt jemand liest: ob Spieler das Paket bekommen und was zu tun ist, wenn nicht.

Ein normaler Boot gibt daher eine Zeile aus:

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

Diese Zeile bestätigt, dass eine Auslieferungs-URL veröffentlicht wurde. Verbinde dich mit einem Client und prüfe bekannte benutzerdefinierte Inhalte, um Download und Darstellung zu bestätigen.

RSPM warnt außerdem bewusst nicht vor Zuständen, die es selbst behebt. Wenn ein Selbst-Hosting-Test fehlschlägt und RSPM auf Remote-Hosting zurückfällt, ist das ein Erfolg — die Konsole meldet das Ergebnis, nicht den Umweg. Vor etwas zu warnen, das bereits behandelt wurde, wirkt wie ein Fehler und schickt Leute auf die Jagd nach einem Nicht-Problem.

Um die vollständige Erzählung zu sehen, führe /rspm verbose on aus (oder setze verboseLogging: true in der config.yml) und dann /rspm reload. Für den Bedrock-Konverter im Speziellen verwende stattdessen bedrockConverterDebug: true.

Können andere Plugins ihre Pakete per Code registrieren?

Ja. ResourcePackManager stellt eine Java-API für die programmatische Paketregistrierung bereit. Details siehe API-Seite.

Funktioniert die Bedrock-Konvertierung nur für FreeMinecraftModels?

Nein, nicht mehr. Der aktuelle Konverter verarbeitet rekursiv jedes Plugin, dessen Paket Items-Definitionen im Format 1.21.4+ unter assets/<namespace>/items/**/*.json mitliefert. Das deckt FreeMinecraftModels-Bone-Modelle, EliteMobs-Ausrüstung, Oraxen-/Nexo-Custom-Items, eigene Rüstungssets und jedes Paket ab, das du selbst in diesem Format zusammenstellst. Reine 2D-Custom-Items werden als flache Bedrock-Symbole ausgegeben; 3D-Custom-Items erzeugen Bedrock-Geometrie/Attachables und ein softwaregerendertes Inventarsymbol.

Muss ich den Server bei jeder Änderung des Bedrock-Pakets neu starten?

Textur- und Modelländerungen an bestehenden Custom-Items werden für den nächsten beitretenden Bedrock-Spieler wirksam — RSPM stellt das Bedrock-Paket live pro Session über Geysers API bereit.

Starte den Prozess, in dem Geyser läuft, neu, wenn sich Custom-Item-Mappings ändern oder neue benutzerdefinierte Entity-Identifikatoren beziehungsweise Property-Typen registriert werden müssen. Diese Registrierungen erfolgen beim Start. Ein erneuter Export bestehender Identifikatoren mit unveränderten Property-Typen erfordert für sich allein keinen Neustart.

Funktioniert ResourcePackManager auf BungeeCord / Velocity?

Ja. Installiere dieselbe ResourcePackManager.jar auf dem Proxy und jedem Backend, das Ressourcenpakete bereitstellt. Die Jar enthält die Einstiegspunkte für Bukkit, Velocity und BungeeCord. Ein Backend hinter einem Proxy legt eine Kopie unter plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar ab, wenn es noch keinen Netzwerkschlüssel erhalten hat. Andere registrierte Server können ohne RSPM laufen; die Backend-Erkennung verhindert, dass sie die Paketsynchronisierung verzögern.

Als Proxy-Plugin ausgeführt, führt es das konvertierte Bedrock-Paket jedes Backends zusammen und liefert es über das Geyser des Proxys an Bedrock-Clients aus. Die Java-Paketauslieferung erfolgt weiterhin direkt durch jedes Backend — Java-Clients sehen pro Backend ein eigenes Paket.

Einrichtungs-, Fehlerbehebungs- und Verifizierungsschritte findest du unter Proxy-Netzwerke.