Resource Pack Manager – Fehlerbehebung

Diese Seite beschreibt nur Verhalten, das aktuell in der ResourcePackManager-Codebasis bestätigt ist.

Der nützlichste erste Schritt bei jedem RSPM-Problem ist:

/rspm status

Es gibt Version, Deploy-Modus (eigenständig vs. network-backend), einen kurzen, nicht geheimen Fingerabdruck des Netzwerkschlüssels samt Herkunft dieses Schlüssels, den Status des Java- + Bedrock-Pakets, den aktiven Auslieferungspfad mit URL, den aufgelösten externen Host + die automatisch erkannte öffentliche IP, alle relevanten Konfigurations-Flags, einen Hinweis zur Proxy-Bereitstellung (die Netzwerk-Proxy-Jar ist dieselbe ResourcePackManager.jar) und die Floodgate-/Geyser-Spigot-Erkennung aus. Denselben Befehl gibt es, wenn die Jar auf einem Proxy läuft, und er gibt dann die proxy-seitigen Entsprechungen aus (Backend-Liste, Abrufergebnisse pro Backend, Status des zusammengeführten Pakets).

Die Konsole schweigt absichtlich

RSPM gibt jedes Mal, wenn es einen Auslieferungspfad frisch initialisiert, eine Zeile aus — das Ergebnis:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip
[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

Alles andere — jedes bereitgestellte Paket, jeder zusammengeführte Cluster, jede Stabilitätsprüfung, jeder Selbst-Hosting-Test und dessen Ergebnis — wird standardmäßig unterdrückt. Ein Zustand, von dem sich RSPM selbst erholt, wird nicht als Warnung gemeldet. Wenn ein Selbst-Hosting-Test fehlschlägt und RSPM still auf Remote-Hosting wechselt, ist das ein Erfolg, kein Fehler, und die Konsole sagt nichts dazu.

Die Ergebniszeile bedeutet, dass RSPM eine Auslieferungs-URL ausgewählt und veröffentlicht hat. Sie beweist nicht, dass ein bestimmter Client das Paket heruntergeladen oder dargestellt hat. Prüfe dies mit einem beitretenden Spieler und einem bekannten benutzerdefinierten Item oder Modell. Bevor du einen Hosting- oder Merge-Fehler meldest, aktiviere die ausführliche Protokollierung:

/rspm verbose on

dann /rspm reload. Dieser Befehl schreibt verboseLogging: true für dich in plugins/ResourcePackManager/config.yml, und die Einstellung übersteht Neustarts — also /rspm verbose off, wenn du fertig bist. Den Schlüssel von Hand zu bearbeiten macht dasselbe. Der Bedrock-Konverter hat einen separaten Schalter, bedrockConverterDebug, der nur über die Konfiguration steuerbar ist.

Warnungen, die du legitim sehen kannst, sind echte Fehler: wiederholt fehlgeschlagene Paketauslieferung an einen bestimmten Spieler, ein Client, der INVALID_URL meldet, ein HTTP-Port, der nicht gebunden werden konnte, beide Auslieferungspfade fehlgeschlagen oder ein Proxy, der mehrere Zyklen gepollt hat, ohne dass ein Backend Inhalt produziert.

Spieler erhalten das Ressourcenpaket nicht

Prüfe zuerst Folgendes:

• autoHost muss aktiviert sein, wenn du die normale automatische Auslieferung willst (selfHostForce ist die explizite Test-Übersteuerung)
• das zusammengeführte Paket muss existieren und mindestens ein Auslieferungspfad (Selbst-Hosting oder Remote) muss erfolgreich gewesen sein
• Spieler erhalten das Paket beim Beitritt. Spieler, die beigetreten sind, während kein Paket veröffentlicht war, erhalten es, sobald das Hosting bereit ist, auch wenn das Hosting später in der Session neu registriert wird (zum Beispiel nach einer abgelaufenen Remote-Sitzung)
• Floodgate-Spieler werden von der Java-Auslieferung absichtlich übersprungen, weil Geyser ihre Bedrock-Paket-Session besitzt

Falls nötig:

1. Führe /rspm status aus und sieh dir den Abschnitt „Hosting" an. Active delivery zeigt, ob derzeit Selbst-Hosting, Remote oder keines verwendet wird.
2. Wenn „active delivery: not yet ready" — der Mix oder Upload läuft noch. Das Plugin gibt dies laut in der Konsole aus, wenn ein Spieler zu früh beitritt, und sendet das Paket automatisch in dem Moment, in dem die Auslieferung bereit ist.
3. Wenn „active delivery: none — hosting disabled or failed" — autoHost ist aus, oder sowohl die Selbst-Hosting-Tests als auch der Remote-Upload sind fehlgeschlagen. Siehe „Selbst-Hosting-Plausibilitätsprüfungen fehlgeschlagen" und „Auto-Hosting erreicht den Remote-Server nicht" unten.
4. Setze verboseLogging: true, führe /rspm reload aus, beobachte die Konsole auf die Upload-/Selbst-Hosting-Testergebnisse und lass dann einen Testspieler erneut beitreten. (Ohne dieses Flag werden die Testschritte nicht ausgegeben — nur die abschließende Ergebniszeile „Resource pack is live via ...".)

Das Beitrittsangebot wird um etwa eine Sekunde verzögert. Wenn ein Java-Client FAILED_DOWNLOAD oder DISCARDED meldet, wiederholt RSPM die Auslieferung automatisch, bis zu insgesamt drei Versuchen pro Spieler-Session. Eine Ablehnung durch den Spieler, ein INVALID_URL oder ein FAILED_RELOAD wird nicht wiederholt; wiederholt ausgeschöpfte Versuche und ungültige URLs werden als echte Fehler protokolliert.

FAILED_RELOAD bedeutet, dass der Client das Paket heruntergeladen hat, sein eigenes Neuladen der Ressourcen aber fehlgeschlagen ist; ein erneuter Download desselben Pakets kann daher nicht helfen. RSPM protokolliert Client <name> reported FAILED_RELOAD for the resource pack. Check that client's latest.log for the resource reload error; not retrying. Lies die latest.log des Clients dieses Spielers, um das Asset oder die Paketmetadaten zu finden, die der Client abgelehnt hat.

Wenn eine andere Pipeline Hosting und Auslieferung übernimmt (autoHost: false), sendet RSPM seine URL nicht. Für einen HTTPS-Reverse-Proxy vor RSPM lässt du stattdessen autoHost: true gesetzt und verwendest selfHostExternalUrl. Damit bleiben die automatische Auslieferung an Spieler und der Remote-Host-Fallback erhalten.

ItemsAdder ist installiert, aber seine Inhalte fehlen im endgültigen Paket

Das bedeutet meist, dass ItemsAdder noch so konfiguriert ist, dass ResourcePackManager seine Ausgabe nicht lesen oder hosten kann.

Verwende:

/rspm itemsadder configure

Dieser Befehl bewirkt derzeit:

• aktiviert resource-pack.hosting.no-host.enabled
• deaktiviert protection_1, protection_2 und protection_3
• setzt resource-pack.zip.compress-json-files: false
• führt /iareload, dann /iazip aus
• wartet, bis RSPM den neu erzeugten ItemsAdder-Export zusammengeführt hat, und meldet, ob der Merge gelungen ist

ResourcePackManager wird dabei nicht neu geladen. Prüfe nach der Merge-Meldung das Hosting mit /rspm status.

Wenn der Befehl meldet, dass ItemsAdder bereits sein eigenes Paket hostet, deaktiviere das ItemsAdder-Hosting zuerst manuell und führe den Befehl erneut aus.

Das zusammengeführte Paket ist ungültig oder lässt sich nicht hochladen

Die Auto-Host-Integration von ResourcePackManager behandelt explizit folgende serverseitigen Fehlertypen:

• fehlende erforderliche Dateien
• Datei zu groß
• ungültiges Dateiformat
• fehlende Sitzung
• Remote-Server nicht erreichbar

RSPM prüft die Größenbeschränkung vor dem Hochladen selbst: Ein Java-Paket über 50.000 KiB (51.200.000 Bytes) wird nicht hochgeladen, und die Konsole gibt Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes. aus. RSPM versucht dann stattdessen geprüftes Selbst-Hosting. Siehe Selbst-Hosting.

Wenn einer davon auftritt:

1. Führe /rspm reload aus, um das Paket neu zu bauen.
2. Prüfe, ob eines der Quellpakete fehlerhaft, verschlüsselt oder anderweitig unlesbar ist.
3. Prüfe, ob das endgültig zusammengeführte Paket im Wurzelverzeichnis weiterhin eine gültige pack.mcmeta und pack.png enthält.

Wenn ein aktiviertes Paket nicht extrahiert oder bereitgestellt werden kann, bricht der aktuelle Mix ab und die Konsole nennt das fehlerhafte Paket. Repariere das Paket, entferne eine manuell hinzugefügte ZIP oder setze in seiner automatischen Integrations-Konfiguration isEnabled: false, bevor du neu lädst.

Overlay-Metadaten und Archivstruktur

Die abschließende Zusammenführung bewahrt die vom Autor festgelegten Overlay-Formatangaben, einschließlich formats, min_format, max_format und zusätzlicher Metadaten. Verwenden mehrere Pakete dasselbe Overlay-Verzeichnis, gewinnt der Eintrag mit höherer Priorität.

Eine Umschreibung wird vorgenommen. Minecraft 1.21.9 und neuer lehnt die gesamte pack.mcmeta ab, wenn irgendein Overlay der Liste bis Paketformat 64 oder niedriger reicht und ein anderes Overlay keine formats angibt. Zwei Pakete, die jeweils für sich gültig sind, können diese Regel verletzen, sobald ihre Overlay-Listen kombiniert werden. Enthält eine zusammengeführte Liste ein Overlay, dessen Untergrenze 64 oder niedriger ist, ergänzt RSPM bei jedem Eintrag, der nur min_format und max_format angibt, einen formats-Bereich. Der Bereich deckt dieselben Clients ab wie die eigenen Grenzen des Eintrags und wird bei 64 gekappt, wenn er bei 64 oder darunter beginnt. Das Kollisionsprotokoll vermerkt Added the formats range to N overlay entries. Einträge, die bereits formats angeben oder deren Grenzen sich nicht auswerten lassen, bleiben unverändert. Darüber hinaus gleicht RSPM keine Bereiche verschiedener Client-Generationen an und repariert keine ungültigen Angaben; korrigiere inkompatible Metadaten im Quellpaket.

RSPM prüft, ob das Overlay-Verzeichnis ein nicht leerer relativer Pfad ist, der innerhalb des zusammengestellten Pakets bleibt. Absolute Pfade, nach der Normalisierung aus dem Paket führende Pfade und ungültige Pfade werden abgelehnt. Eine bestandene Prüfung garantiert nicht, dass Minecraft den Namen oder die Formatmetadaten des Overlays akzeptiert.

Eine ZIP mit Pack Name/assets/ und Pack Name/pack.mcmeta hat ein zusätzliches äußeres Verzeichnis. RSPM warnt davor; archiviere die Inhalte erneut, sodass assets/ und pack.mcmeta direkt im ZIP-Wurzelverzeichnis liegen. Inhaltsdeduplizierte Archive werden über ihr zentrales Verzeichnis gelesen, damit Einträge mit gemeinsam genutzten komprimierten Daten einschließlich Texturanimations-Metadaten erhalten bleiben.

Texturen im Blocks-Atlas

Der zusammengeführte Blocks-Atlas löst Verzeichnisquellen in die konkreten PNG-Ressourcen des zusammengeführten Pakets auf. Dabei bleiben Quellreihenfolge und Sprite-IDs erhalten. Für Pakettexturen, deren Animationsframe-Abmessungen für die erforderlichen Mipmap-Stufen ungeeignet sind, werden deterministische Kopien per Nearest-Neighbor-Skalierung unter resourcepackmanager_internal:mip_safe/ erzeugt. Die Originaldateien bleiben für Schrift- und andere Loader unverändert.

Erstelle keine Inhalte im reservierten Namespace resourcepackmanager_internal. Kollisionen werden abgelehnt. Dieses Verfahren ist keine Java-zu-Bedrock-Konvertierung und garantiert keine Unterstützung für jeden benutzerdefinierten Client-Shader oder jede Atlas-Erweiterung.

Ein kaputtes Paket blockiert nicht mehr für immer alles

Ein Paket, das nicht bereitgestellt werden kann, scheitert bei jedem Versuch auf dieselbe Weise — sich selbst überlassen würde es die Auslieferung dauerhaft blockieren: Der Merge schließt nie ab und derselbe Fehler wiederholt sich endlos. Nach drei aufeinanderfolgenden Fehlschlägen derselben Datei nimmt RSPM dieses Paket aus dem Merge, damit die übrigen Pakete ausgeliefert werden können, und sagt das einmal, deutlich:

[ResourcePackManager] Resource pack X.zip failed to stage 3 times in a row and has been excluded
from the merge so the remaining packs can be delivered. The merged pack is now INCOMPLETE ...

Die Meldung ist wörtlich gemeint: Dem veröffentlichten Paket fehlen die Inhalte dieses Plugins. Die übliche Ursache ist eine beschädigte oder unvollständig geschriebene ZIP.

Der Ausschluss hebt sich von selbst auf. Der Fehlereintrag ist an Größe und Änderungszeit der Datei gebunden, sodass das Reparieren oder Ersetzen der Datei die Quarantäne automatisch beendet und das Paket beim nächsten Merge wieder dabei ist — kein Befehl, kein Neustart. /rspm reload setzt außerdem alle Quarantäne-Einträge von Grund auf zurück. Fehlerzähler, die nie drei erreicht haben, werden nach jedem erfolgreichen Mix verworfen, sodass sich unzusammenhängende, vorübergehende Aussetzer über eine lange Laufzeit nicht zu einem Ausschluss aufsummieren können.

Bei einem SESSION_NOT_FOUND-Fehler vom Remote-Auto-Host löscht RSPM seine Sitzungs-UUID und initialisiert sich beim nächsten Keep-Alive-Tick neu — kein manuelles Eingreifen erforderlich.

Die Assets eines Plugins überschreiben die eines anderen

Das wird über priorityOrder gesteuert in:

plugins/ResourcePackManager/config.yml

Höhere Einträge gewinnen gegen niedrigere.

Bei nicht mergebaren Dateien ersetzt ResourcePackManager die Datei mit niedrigerer Priorität. Bei mergebaren JSON-Dateien werden die Inhalte stattdessen zusammengeführt. Die derzeit mergebaren JSON-Kategorien sind:

• sounds.json
• Sprachdateien
• Vanilla-Item-Model-JSON in minecraft/models/item (nicht rekursiver Merge: nur das overrides-Array wird über Pakete hinweg kombiniert, der Rest der Datei folgt „höchste Priorität gewinnt")
• Atlas-Dateien
• Schriftdateien
• Item-Modelldefinitionen im Format 1.21.4+ in items/ (formatbewusster Merge, der die Prädikatsbaumstruktur respektiert)

pack.mcmeta wird ebenfalls gesondert zusammengeführt: Das höchste pack_format gewinnt und deklarierte Paketformatbereiche werden kombiniert. Overlay-Einträge behalten ihre ursprünglichen Bereiche und zusätzlichen Metadaten; bei doppelten Verzeichnissen gewinnt der Eintrag mit höherer Priorität. Die einzige Ergänzung ist ein formats-Bereich bei Einträgen, die ihn brauchen, damit die kombinierte Liste auf Clients ab 1.21.9 geladen wird (siehe Overlay-Metadaten). Darüber hinaus repariert RSPM keine inkompatiblen Angaben des Autors. Weitere konfliktfreie Metadaten bleiben erhalten. Quellen des Basis-Atlas werden in die Overlay-Atlasdateien übernommen, damit Overlays keine Basiseinträge verdecken.

Wenn du nachvollziehen möchtest, was beim letzten Merge passiert ist, sieh dir an:

plugins/ResourcePackManager/collision_log.txt

GUI-Text oder schriftbasierte Elemente sehen falsch aus

Schriftdateien gehören zu den JSON-Kategorien, die ResourcePackManager zusammenführt, aber das garantiert nicht, dass zwei unterschiedliche Schriftsysteme in Minecraft gut zusammenarbeiten.

Wenn ein schriftgestütztes Menü oder HUD falsch aussieht:

1. Ändere priorityOrder so, dass das Paket, das gewinnen soll, weiter oben steht.
2. Führe /rspm reload aus.
3. Prüfe collision_log.txt, um zu bestätigen, dass die Kollisionen dort stattfanden, wo du es erwartet hast.

Änderungen am Ressourcenpaket erscheinen nicht sofort

ResourcePackManager hat einen Watchdog für die Quellen unterstützter Pakete.

Er wartet, bis ein geändertes Paket 3 Sekunden lang unverändert bleibt; sobald alle überwachten Pakete stabil sind, erfolgt der Remix sofort.

Wenn du gerade aktiv das Paket eines anderen Plugins regenerierst, gib ihm einige Sekunden nach dem Ende der Dateischreibvorgänge. Im Zweifel führe /rspm reload aus, nachdem das vorgelagerte Plugin fertig ist.

/rspm status meldet Remote-Hosting, obwohl ich Selbst-Hosting erwartet habe

Das kann bei preferSelfHost: true (Standard) nach einer fehlgeschlagenen Selbst-Hosting-Prüfung passieren. Erreichbarkeitsprüfungen werden auf Detailebene protokolliert und bleiben ohne verboseLogging: true verborgen; einige Meldungen enthalten „This is OK.“. Bei erfolgreichem Remote-Hosting lautet das Ergebnis Resource pack is live via automatic hosting — .... Ungültige Einstellungen, Listener-Fehler und Remote-Kommunikationsfehler können weiterhin Warnungen erzeugen.

Führe /rspm verbose on aus (oder setze verboseLogging: true) und dann /rspm reload, um zu sehen, welche der drei Ebenen fehlgeschlagen ist:

1. Ebene 1 (Heuristik) — der aufgelöste externe Host ist RFC1918 / Loopback / Link-Local. Setze entweder selfHostExternalHost auf deinen echten öffentlichen Hostnamen oder stelle sicher, dass das Plugin api.ipify.org / checkip.amazonaws.com erreichen kann.
2. Ebene 2 (lokaler Download und angekündigte URL) — RSPM lädt bis zum ersten KiB von http://127.0.0.1:<port>/rspm.zip und der genauen Spieler-URL herunter und vergleicht beide Stichproben mit dem lokalen Paket. Erforderlich sind HTTP 200 oder 206, passende angegebene Längen und bei 206 der erwartete Content-Range. Weiterleitungen, falsche Bytes, fehlende Dateien und serverseitige NAT-Loopback-Fehler verhindern Selbst-Hosting.
3. Ebene 3 (externer Erreichbarkeitstest) — magmaguy.com muss die angekündigte URL mit HTTP 200 oder 206 als erreichbar melden. Ein geschlossener HTTP-Port, eine fehlgeschlagene Anfrage oder ein nicht verfügbarer Prüfdienst verhindert automatisches Selbst-Hosting. Status und vorhandener Grundcode werden mit verboseLogging ausgegeben.

Lösungen in der empfohlenen Reihenfolge: den HTTP-Port an Firewall und Router öffnen, selfHostExternalHost auf einen routbaren Hostnamen setzen oder preferSelfHost: false setzen, um zuerst Remote-Hosting zu versuchen. Setze zusätzlich selfHostEnabled: false, wenn Selbst-Hosting auch als Fallback ausgeschlossen sein soll, und lasse selfHostForce: false gesetzt.

Ist der Prüfdienst nicht erreichbar, bleibt Selbst-Hosting unverifiziert und RSPM versucht Remote-Hosting. Der Fallback nach einem Remote-Fehler muss dieselben Selbst-Hosting-Prüfungen bestehen. Nur selfHostForce: true umgeht die Verifikation; scheitern beide automatischen Pfade, kann RSPM keine neue Auslieferungs-URL ankündigen. Erfolgreiche Prüfungen belegen weiterhin keinen vollständigen Download und keine Paketannahme aus jedem Spielernetzwerk.

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

Auto-Hosting erreicht den Remote-Server nicht

Der eingebaute Remote-Host von ResourcePackManager kommuniziert mit:

https://magmaguy.com/rsp/

Wenn diese Verbindung fehlschlägt, gibt das Plugin Kommunikationswarnungen aus und kann den Remote-Fallback erst wieder verwenden, sobald es sich erfolgreich neu verbunden hat.

Deine Optionen sind:

1. die ausgehende HTTPS-Konnektivität des Servers reparieren
2. warten, bis der Remote-Dienst wieder erreichbar ist
3. autoHost deaktivieren und die erzeugte ZIP-Datei selbst hosten
4. den HTTP-Port öffnen, selfHostExternalHost auf den öffentlichen Hostnamen setzen und preferSelfHost: true beibehalten. Der explizite Name überspringt die automatische öffentliche IP-Erkennung, aber die lokale Prüfung, der Download der angekündigten URL und die externe Prüfung müssen weiterhin bestehen. Ein nicht erreichbarer Prüfdienst verhindert die automatische Auswahl von Selbst-Hosting.

Ich möchte das zusammengeführte Paket über meinen eigenen Webserver hosten

Die im Code unterstützte Einrichtung ist:

1. Setze autoHost: false.
2. Setze resourcePackRerouting, wenn ResourcePackManager eine zusätzliche Kopie in einen vorhandenen Ordner schreiben soll.
3. Hoste ResourcePackManager_RSP.zip selbst.

resourcePackRerouting wird relativ zum Verzeichnis plugins aufgelöst, und der Zielordner muss bereits existieren.

Wenn du stattdessen den eingebauten Selbst-Hosting-HTTP-Server von RSPM nutzen möchtest (etwas anderes — dieselbe JVM wie das Plugin), siehe Selbst-Hosting.

Ich möchte prüfen, welche Remote-Daten für diesen Server gespeichert sind

Verwende:

/rspm data_compliance_request

Wenn eine aktive Remote-Hosting-Sitzung besteht, 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 Remote-Sitzung besteht (z. B. weil du Selbst-Hosting verwendest), meldet der Befehl, dass keine Remote-Daten angefordert werden können.

Das Bedrock-Paket wird nicht erzeugt

bedrockConversionEnabled ist standardmäßig auf true gesetzt, sollte also automatisch laufen. Führe zuerst /rspm status aus — der Abschnitt „Bedrock Pack" sagt dir, warum das Paket nicht auf der Festplatte liegt:

• „No Bedrock target detected" — kein lokales Geyser-Spigot, kein lokales Floodgate und nicht im Netzwerkmodus. Die Konvertierung wird absichtlich übersprungen. Installiere Floodgate (für Proxy-Setups) oder Geyser-Spigot (für eigenständige Setups) und führe /rspm reload aus.
• „Network mode is active so this backend SHOULD produce a Bedrock pack. The file is missing" — meist ist der erste Mix-Zyklus noch nicht abgeschlossen (warte ~30 s nach dem Booten), oder die Konvertierung hat weder konvertierbare Item-Mappings noch erlaubte Entity-Bundles gefunden, oder die Konvertierung hat eine Ausnahme geworfen. Durchsuche die Konsole nach [BedrockConverter]-Warnungen. Mit bedrockConverterDebug: true protokolliert der Scanner außerdem Generic scanner: discovered N item definitions; ein Wert von 0 bedeutet, dass das zusammengeführte Paket keine konvertierbaren Item-Definitionen enthält. (Die Statusdiagnose zitiert diese Zeile als discovered 0 items definition files.)

Wenn die automatische Geyser-Erkennung fehlschlägt:

1. Setze bedrockGeyserFolder in der config.yml auf den Pfad deines Geyser-Datenordners (z. B. Geyser-Spigot).
2. Absolute Pfade funktionieren. Ein relativer Pfad wird zuerst vom Arbeitsverzeichnis des Servers aus versucht, danach relativ zum Verzeichnis plugins.

Der Konverter erkennt Geyser automatisch in plugins/Geyser-Spigot/, in jeder Variante plugins/Geyser-*/ oder in config/Geyser-*/ für Fabric/NeoForge-Setups.

Für Protokollausgaben pro Item / pro Bone setze bedrockConverterDebug: true und lade neu.

Bedrock: Live-Provider übersprungen, weil ein altes Paket existiert

Wenn die Konsole Legacy RSPM Bedrock pack detected meldet, hat Geyser beim Booten bereits eine alte ResourcePackManager_Bedrock.zip aus seinem Paketverzeichnis gescannt. Diese Datei zu löschen, während der Prozess läuft, würde Geyser mit einem In-Memory-Codec für einen Pfad zurücklassen, den es nicht mehr gibt, daher überspringt RSPM für diesen Boot bewusst seinen Live-Paket-Provider.

Fahre den Server vollständig herunter, lösche nur genau den von RSPM ausgegebenen Altpfad und starte den Server dann wieder. Verwende für diese Migration kein /reload. Das aktuelle Paket bleibt in plugins/ResourcePackManager/output/ und wird pro Session ausgeliefert; es gehört nicht in Geysers Verzeichnis packs/.

Bedrock-Spieler sehen gehaltene Items an der falschen Position

Prüfe zunächst, ob das beabsichtigte Modell und das neueste Paket geladen wurden: Verbinde den Bedrock-Client erneut, damit er das aktuelle Paket erhält. RSPM leitet die Haltepose aus den Transformationen display.firstperson_righthand und display.thirdperson_righthand des Java-Modells ab. Eine Pose, die auch auf Java falsch ist, wird daher im Java-Modell korrigiert. Sieht es auf Java richtig aus und auf Bedrock nicht, melde es zusammen mit der Modelldatei.

bedrock_display_offsets.yml und seine Offset-Einstellungen wurden entfernt und werden nicht mehr gelesen; das Bearbeiten einer alten Kopie hat keine Wirkung. Siehe Posen gehaltener Items.

Texturen benutzerdefinierter Rüstung fehlen bei Bedrock-Spielern

Benutzerdefinierte Rüstung wird auf Bedrock dargestellt, indem die Vanilla-Rüstungsgeometrie mit der Java-Textur als sichtbarer Schicht kombiniert wird. Damit das funktioniert, muss das Paket des Quellplugins neben der Items-Definition eine Equipment-Datei unter assets/<namespace>/equipment/<material>.json definieren. Wenn das Konvertierungs-Log das Item zeigt, aber im Spiel keine Rüstungstextur erscheint, prüfe, ob diese Datei im zusammengeführten Paket vorhanden ist.

Proxy: Ein Backend meldet, es habe keinen Netzwerkschlüssel

Auf dem Backend zeigt /rspm status Network key source: not set — the proxy sends one when a player next connects here, und die Konsole wiederholt „This backend is behind a proxy but has no network key yet".

Eine fehlende plugins/floodgate/key.pem ist nicht die Ursache — diese Datei ist inzwischen optional. Der Proxy besitzt den Schlüssel: Er lädt seine eigene network-key-Datei, initialisiert sich einmalig aus Floodgates key.pem, falls vorhanden, oder erzeugt einen frischen Schlüssel und schiebt ihn dann an jedes Backend, sobald dort ein Spieler verbindet.

Prüfe der Reihe nach:

1. Hat sich seit dem Start des Proxys ein Spieler mit diesem Backend verbunden? Die Zuweisung wird über eine Spielerverbindung übertragen.
2. Liegt ResourcePackManager.jar tatsächlich auf dem Proxy? Das Backend legt für dich eine Kopie seiner eigenen Jar unter plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar ab und gibt diesen Pfad aus — kopiere sie in den plugins/-Ordner des Proxys und starte den Proxy neu.
3. Stimmt auf Velocity mit modernem Forwarding das Forwarding-Secret des Backends mit dem des Proxys überein? Ein Backend mit modernem Forwarding lehnt eine unsignierte oder falsch signierte Zuweisung absichtlich ab; sein Log nennt den Fall. Korrigiere das Secret auf beiden Seiten, die nächste Spielerverbindung versucht es von selbst erneut.
4. Vergleiche die Zeilen Network key fingerprint aus /rspm status auf beiden Seiten. Identische Fingerabdrücke zeigen dieselbe Netzwerkidentität an; prüfe die Abrufergebnisse, um die Verbindung zu bestätigen. Der Schlüssel selbst wird nie ausgegeben.

Siehe Proxy-Netzwerke für die vollständige Abfolge.

Wenn /rspm status stattdessen NetworkSync isn't running meldet und auf eine fehlende Floodgate-Datei key.pem verweist, lies den vorherigen Startfehler. Dieser Hinweis in Klammern ist veraltet: Der aktuelle Proxy kann seinen eigenen Netzwerkschlüssel ohne Floodgate erzeugen und speichern. Initialisierungsfehler, Dateisystemberechtigungen und die Erreichbarkeit der Backends bestimmen den nächsten Schritt. Fehlt der Proxy-Befehl /rspm vollständig, prüfe das Startprotokoll auf einen Fehler bei der Netzwerkidentität.

Unvollständige Wiederherstellung nach Veröffentlichung

Scheitert die Veröffentlichung eines Bedrock-Pakets, Proxy-Eingangs oder zusammengeführten Pakets und lassen sich die vorherigen Dateien nicht vollständig wiederherstellen, bewahrt RSPM Wiederherstellungskopien auf und protokolliert deren Verzeichnis sowie die betroffenen Ziele. Es versucht außerdem, den unvollständigen Dateisatz aus der Nutzung zu nehmen. Bewahre das protokollierte Verzeichnis auf, behebe die Dateisystemfehler und prüfe vor einem erneuten Versuch, ob Paket und Zuordnungen zusammenpassen. Eine fehlgeschlagene Wiederherstellung ist keine erfolgreiche Veröffentlichung.

Proxy: „Could not establish persistent RSPM network identity“

Aktuelle Releases laufen nicht mit einem ungespeicherten Schlüssel. Kann der Proxy einen neu ermittelten Schlüssel nicht in network-key speichern oder eine vorhandene network-key-Datei nicht lesen, stoppt die Proxy-Rolle beim Start mit Could not establish persistent RSPM network identity: ... oder Cannot read established RSPM network identity. Netzwerksynchronisierung, Bedrock-Auslieferung und der Proxy-Befehl /rspm starten nicht, sodass die Backends ihre bestehenden Schlüssel behalten, statt mit einem Schlüssel verknüpft zu werden, der sich beim nächsten Neustart ändern könnte.

Korrigiere die Dateisystemberechtigungen des Datenordners des Proxy-Plugins (plugins/resourcepackmanager/ auf Velocity, plugins/ResourcePackManager/ auf BungeeCord) und starte den Proxy dann neu. Eine fehlerhafte, aber lesbare network-key-Datei wird automatisch ersetzt.

Proxy: „no merged pack“ nach mehreren Poll-Zyklen

Prüfe zuerst die Anzahl bestätigter RSPM-Teilnehmer in /rspm status. Ein neuer Proxy ohne bestätigte Teilnehmer setzt die Backend-Erkennung fort, ohne jeden registrierten Server als ausgefallenes RSPM-Backend zu behandeln. Unbestätigte Server verzögern die Paketsynchronisierung nicht.

Nach vier aufeinanderfolgenden leeren Abfragezyklen mit bestätigten Teilnehmern zeigt RSPM eine Diagnose mit den Teilnehmern, den versuchten HTTP-URLs und ihren Ergebnissen. Das Standardintervall beträgt fünf Sekunden; Netzwerkoperationen können die verstrichene Zeit verlängern. Die Diagnose erklärt die häufigsten Lösungen:

• CONNECT_FAILED bei jedem Backend → der Proxy kann den HTTP-Port des Backends nicht erreichen. Prüfe, ob die Adresse in velocity.toml / config.yml eine ist, die der Proxy tatsächlich erreichen kann (nicht z. B. ein Docker-interner Name, der aus dem Netzwerk des Proxys nicht aufgelöst wird), und dass der angekündigte HTTP-Port des Backends zwischen Proxy und Backend offen ist. Das Banner gibt die genaue versuchte URL aus; bevor ein Backend seinen Port angekündigt hat, fällt der Proxy auf mcPort + network-http-offset-v2 zurück, sodass ein frühes CONNECT_FAILED auch bedeuten kann, dass dieser Fallback-Port noch nicht erreichbar ist.
• NOT_FOUND_404 bei jedem Backend → die Backends laufen, produzieren aber kein Bedrock-Paket. Führe /rspm status auf jedem Backend aus; der Diagnoseblock für das Bedrock-Paket sagt dir, warum.

Das Banner feuert einmal pro Hänger-Phase, und eine Zeile „NetworkSync: recovered" wird protokolliert, sobald mindestens ein Backend wieder Inhalt zurückgibt. Siehe Proxy-Netzwerke für mehr.

Proxy: Bedrock-Spieler sehen beim ersten Proxy-Start keine Modelle

Geyser registriert seine Custom-Item-Tabelle nur beim Proxy-Start. Wenn der Proxy gestartet wurde, bevor ein Backend ein Bedrock-Paket produziert hat, läuft Geyser mit einer leeren Mappings-Tabelle und bleibt für den Rest der Session so.

Die Lösung ist, den Proxy neu zu starten, sobald er Merged Bedrock pack published at ... protokolliert hat. RSPM stellt beim Proxy-Start die Mappings des vorherigen Laufs vorab bereit, damit spätere Starts die gespeicherten Mappings registrieren können. Neue Identifikatoren, die nach dem Start hinzukommen, können diesen Neustart erneut erforderlich machen.

Backend: „Backend HTTP server failed to bind on port X“

Im Netzwerkmodus stellt das Backend seine Bedrock-Ausgaben über einen kleinen HTTP-Server bereit. Wenn der Port belegt oder nicht verfügbar ist, siehst du einen mehrzeiligen [ERROR]-Block in der Konsole. Lösungen:

• Setze selfHostPort in der config.yml auf einen anderen positiven Wert.
• Oder ändere networkHttpOffset-v2, um den automatisch abgeleiteten Port von der Kollision wegzuschieben (z. B. RCON auf mcPort + 1? Setze ihn auf 2 oder 3). Du musst den Proxy nicht zur Übereinstimmung aktualisieren: Sobald das Backend erfolgreich gebunden hat, kündigt es dem Proxy automatisch seinen tatsächlichen HTTP-Port an, sodass das eigene network-http-offset-v2 des Proxys nur als Vor-Ankündigungs-Vermutung relevant ist.

Während der Backend-HTTP-Server ausgefallen ist, erreicht das Bedrock-Paket dieses Backends den Proxy nicht über den direkten Abruf. Der magmaguy.com-Relay-Fallback funktioniert weiterhin (das Backend schiebt seine Dateien an das Relay und der Proxy holt sie dort ab).

Eine veraltete v1-Konfiguration aufräumen

Betreiber, die von RSPM v1 aktualisieren, haben möglicherweise einen toten networkHttpOffset-Schlüssel (ohne -v2) in ihrer config.yml. RSPM v2 liest den alten Schlüssel absichtlich nicht — du erhältst beim nächsten Booten automatisch den v2-Standard (1) in die Konfiguration geschrieben. Der tote v1-Schlüssel sitzt als harmloses Artefakt in deiner Konfiguration, bis du ihn von Hand aufräumst.