Zum Hauptinhalt springen

Resource Pack Manager – Fehlerbehebung

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

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

/rspm status

Es gibt Version, Deploy-Modus (eigenständig vs. network-backend), den maskierten Netzwerkschlüssel, 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).

Spieler erhalten das Ressourcenpaket nicht​

Prüfe zuerst Folgendes:

  • autoHost muss aktiviert sein, wenn ResourcePackManager automatisch eine URL senden soll
  • das zusammengeführte Paket muss existieren und mindestens ein Auslieferungspfad (Selbst-Hosting oder Remote) muss erfolgreich gewesen sein
  • Spieler erhalten das Paket nur beim Beitritt oder über die Erst-Upload-Mitteilung, die in dem Moment feuert, in dem das Hosting bereit wird

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. Führe /rspm reload aus, beobachte die Konsole auf Upload-/Selbst-Hosting-Testergebnisse und lass dann einen Testspieler erneut beitreten.

Wenn du über deine eigene externe Pipeline selbst hostest (autoHost: false), schiebt RSPM deine eigene URL nicht für dich aus. In dieser Konstellation brauchst du weiterhin einen eigenen serverseitigen Bereitstellungsablauf für das Paket.

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
  • lädt ResourcePackManager etwa 15 Sekunden später neu

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

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.

Das Plugin überspringt Pakete, die es nicht sauber extrahieren kann, und gibt in solchen Fällen Warnungen in der Konsole aus.

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 auf besondere Weise zusammengeführt: das höchste pack_format gewinnt, supported_formats-Bereiche werden erweitert (Integer-, Zwei-Integer-Array- und {min_inclusive, max_inclusive}-Objektform werden alle unterstützt), Overlay-Einträge werden kombiniert und nicht standardisierte Top-Level-Schlüssel 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. Auch die Quellen der Basis-Atlanten werden in die Overlay-Atlasdateien eingefügt, damit Overlays die Basis-Einträge nicht 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.

Selbst-Hosting-Plausibilitätsprüfungen fehlgeschlagen; fällt auf Remote-Hosting zurück​

Diese Meldung ist normales Verhalten, wenn preferSelfHost: true (Standard) und eine der drei Selbst-Hosting-Plausibilitätsprüfungen 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 (Localhost-Selbsttest) — eine HEAD-Anfrage an http://127.0.0.1:<port>/rspm.zip hat nicht 200 mit einem nicht leeren Body zurückgegeben. Fängt Port-Bind-Kollisionen oder fehlende Paketdateien ab.
  3. Ebene 3 (externer Erreichbarkeitstest) — magmaguy.com hat versucht, deine angekündigte URL abzurufen, und konnte sie nicht erreichen. Am häufigsten: Der HTTP-Port ist am Router/an der Firewall nicht weitergeleitet. Die Test-URL und der Grund werden protokolliert.

Lösungen (in der Reihenfolge der Bevorzugung): den HTTP-Port an deiner Firewall + deinem Router öffnen, selfHostExternalHost auf einen routbaren Hostnamen setzen oder preferSelfHost: false setzen, um Selbst-Hosting ganz zu überspringen.

Wenn der magmaguy.com-Test selbst nicht erreichbar ist (RSPM kann nicht mit ihm sprechen, um zu fragen), wird Selbst-Hosting beibehalten statt verworfen — die Begründung ist, dass der Fallback-Pfad ebenfalls magmaguy.com benötigt, sodass eine Verweigerung der Festlegung wegen Unfähigkeit zu testen paradox wäre.

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. deinen HTTP-Port öffnen und preferSelfHost: true beibehalten, sodass RSPM Selbst-Hosting verwendet, ohne magmaguy.com überhaupt zu benötigen (setze in diesem Szenario außerdem selfHostExternalHost auf deinen öffentlichen Hostnamen, damit der externe Test von Ebene 3 unnötig ist — RSPM behält Selbst-Hosting bei einer Test-IOException bei)

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

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 der Scanner hat null Items-Definitionen im zusammengeführten Paket gefunden, oder die Konvertierung hat eine Ausnahme geworfen. Durchsuche die Konsole nach [BedrockConverter]-Warnungen oder nach Generic scanner: 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. Der Pfad kann absolut oder relativ zum Verzeichnis plugins sein.

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-Spieler sehen gehaltene Items an der falschen Position​

Das ist ein Tuning-Problem, kein Konvertierungsfehler. Öffne plugins/ResourcePackManager/bedrock_display_offsets.yml und passe die entsprechende Achse an. Egoperspektive und Drittperson sind unabhängig — die eine zu tunen wirkt sich nicht auf die andere aus. Der Bedrock-Client lädt Attachable-JSON live nach, ohne neu zu starten, sodass die Iteration schnell geht. Die vollständige Liste der Stellschrauben und ihre Bedeutung findest du auf der Bedrock-Konvertierungs-Seite.

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: „Floodgate key.pem missing" beim Booten des Proxys​

Das Proxy-Plugin konnte plugins/floodgate/key.pem auf dem Proxy-Host nicht finden und ist in den Leerlauf gegangen. RSPM leitet die Netzwerkidentität aus dieser Datei ab, kann sich also ohne sie mit keinem Backend verbinden. Lösung:

  1. Installiere Floodgate auf dem Proxy. Es ist ohnehin erforderlich, damit Bedrock-Spieler den Proxy erreichen, du brauchst es also unabhängig von RSPM.
  2. Stelle sicher, dass plugins/floodgate/key.pem auf dem Proxy byteweise identisch mit derselben Datei auf jedem Backend ist. Kopiere eine kanonische key.pem auf jede Komponente (andere Backends + den Proxy) und starte alles neu. Floodgate verlangt dies ohnehin für die Bedrock-Authentifizierung, falls Bedrock-Spieler also derzeit über dein Netzwerk funktionieren, ist das bereits erledigt.

Proxy: „no merged pack" nach mehreren Poll-Zyklen​

Nach ~20 Sekunden leerer Poll-Zyklen (4 Zyklen × 5 s Standardintervall) auf dem Proxy protokolliert RSPM ein einmaliges Diagnose-Banner, das jedes gepollte Backend, die versuchte HTTP-URL und das Ergebnis (200 / 304 / 404 / CONNECT_FAILED / usw.) auflistet. Das Banner 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-Boot 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, nachdem das Backend Wrote merged Geyser mappings: N entries protokolliert hat. RSPM stellt beim Proxy-Boot die Mappings des vorherigen Laufs vorab bereit, sodass dies nur bei einer brandneuen Installation zum Problem wird — bei nachfolgenden Boots ist etwas bereit, bevor Geyser scannt.

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.