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

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 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 anschließend ResourcePackManager neu zu laden (~15 s später)
• /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)

pack.mcmeta wird auf besondere Weise zusammengeführt: das höchste pack_format gewinnt, supported_formats-Bereiche werden so erweitert, dass sie alle Pakete abdecken (unterstützt die Integer-, Zwei-Integer-Array- und {min_inclusive, max_inclusive}-Objektform), Overlay-Einträge werden kombiniert und nicht standardisierte Top-Level-Schlüssel (z. B. sodium) werden beibehalten. Overlay-Einträge werden für 1.21.9+ kompatibel normalisiert, indem die Felder min_format/max_format ergänzt werden, falls sie fehlen.

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 ResourcePackManager bei Paketänderungen automatisch neu gebaut?

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, aktivierte Bedrock-Konvertierung ohne Bedrock-Paket auf der Festplatte — 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.

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.
• Wenn ein Plugin neu lädt, während der Watchdog läuft, erkennt der Watchdog die Zustandsänderung, pausiert, setzt das gesamte Stabilitätstracking zurück und wartet, bis das Plugin seine Neuinitialisierung abgeschlossen hat.
• 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. Wenn selfHostForce: true, immer selbst hosten (überspringt alle Prüfungen — hauptsächlich für Tests).
2. Andernfalls, wenn preferSelfHost: true (Standard), zuerst Selbst-Hosting versuchen, drei Plausibilitätsprüfungen durchführen (aufgelöster Nicht-LAN-Host, Localhost-Selbsttest, externer Erreichbarkeitstest über magmaguy.com) und sich auf Selbst-Hosting festlegen, wenn alle drei bestehen.
3. Wenn das Selbst-Hosting fehlschlägt oder deaktiviert ist, das Paket auf magmaguy.com/rsp/ hochladen und diese URL ankündigen.

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 oder eine ungültige URL 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.

Selbst-Hosting

• selfHostEnabled — ob der eingebaute HTTP-Server verwendet werden darf (boolean, Standard true)
• selfHostPort — Port für den Selbst-Hosting-HTTP-Server. -1 (Standard) leitet ihn automatisch als mcPort + networkHttpOffset-v2 ab. Auf eine beliebige positive Ganzzahl setzen, um einen expliziten Port zu erzwingen.
• 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 Erkennung über api.ipify.org / checkip.amazonaws.com.
• 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.

Eine zweite Datei, plugins/ResourcePackManager/bedrock_display_offsets.yml, stellt zwölf benutzerseitig einstellbare Stellschrauben zur Feinjustierung der Position bereit, an der Bedrock-Spieler gehaltene Items relativ zu ihrer Hand sehen (sechs für die Egoperspektive, sechs für die Drittperson). Details siehe Bedrock-Konvertierung.

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 löst seinen Schlüssel einmalig auf: Er liest seine gespeicherte network-key-Datei, falls vorhanden, initialisiert den Wert andernfalls aus plugins/floodgate/key.pem, falls diese Datei existiert (sodass ein bestehendes Netzwerk seine Identität über das Upgrade hinweg behält), und erzeugt andernfalls einen frischen. In jedem Fall speichert er das Ergebnis in network-key im eigenen Datenordner des Proxy-Plugins und sieht key.pem nie wieder an.
• 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 dafür nicht erforderlich. Es wird benötigt, damit Bedrock-Spieler den Proxy überhaupt erreichen, aber ein reines Java-Netzwerk kann RSPMs Proxy-Funktionen ohne Floodgate nutzen.
• 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 bedeuten, dass die Verbindung steht.

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

Wenn du diese Zeile siehst, hat es funktioniert.

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. Ein Neustart ist nur erforderlich, wenn sich das Set der Custom-Items ändert (neue hinzukommen oder bestehende entfernt werden), da Geyser seine Custom-Item-Identifikatoren beim Start registriert.

Funktioniert ResourcePackManager auf BungeeCord / Velocity?

Ja — das ist eine erstklassig unterstützte Topologie. Es ist überall dieselbe ResourcePackManager.jar: Lege sie auf jedes Backend und lege eine Kopie auf den Proxy. Die eine Jar bündelt die Einstiegspunkte für Bukkit, Velocity und BungeeCord/Waterfall, sodass sie korrekt lädt, egal ob der Host ein Backend oder ein Proxy ist. Es gibt keine separaten plattformspezifischen Proxy-Jars zu bauen oder zu extrahieren — und wenn du die Kopie für den Proxy vergisst, legt ein proxied Backend eine für dich unter plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar ab und sagt das in der Konsole.

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.