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

Also: Das Ausbleiben von Warnungen ist kein Beleg dafür, dass nichts passiert ist, und das Vorhandensein der Ergebniszeile bedeutet, dass Spieler ein Paket bekommen. Bevor du einen Hosting- oder Merge-Fehler meldest, schalte die Erzählung ein:

/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 nur beim Beitritt oder über die Erst-Upload-Mitteilung, die in dem Moment feuert, in dem das Hosting bereit wird
• 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, versucht RSPM es für diese Spieler-Session automatisch bis zu dreimal erneut. Eine Ablehnung durch den Spieler oder ein INVALID_URL wird nicht wiederholt; aufgebrauchte Wiederholungsversuche und ungültige URLs werden als echte Fehler protokolliert.

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.

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.

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

Lies das so, wie es gemeint ist: Spieler bekommen jetzt ein Paket, dem der Inhalt dieses Plugins fehlt. 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 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.

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

Das ist normales Verhalten, wenn preferSelfHost: true (Standard) und eine der drei Selbst-Hosting-Plausibilitätsprüfungen fehlgeschlagen ist. RSPM warnt nicht davor — der Rückfall auf Remote-Hosting ist ein erfolgreiches Ergebnis, daher wird die fehlgeschlagene Prüfung auf Detailebene mit einem ausdrücklichen „This is OK." protokolliert und bleibt verborgen, sofern nicht verboseLogging: true gesetzt ist. Die einzige Zeile, die du standardmäßig bekommst, ist Resource pack is live via automatic hosting — ....

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 (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 ein Grundcode (PRIVATE_HOST_REJECTED, CONNECT_TIMEOUT, ECONNREFUSED, RATE_LIMITED, ...) werden unter verboseLogging ausgegeben.

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, selfHostExternalHost auf deinen öffentlichen Hostnamen setzen und preferSelfHost: true beibehalten. Der explizite Hostname überspringt die automatische Erkennung der öffentlichen IP, aber RSPM versucht weiterhin den Test von Ebene 3. Ist der Testdienst selbst nicht erreichbar, behält RSPM Selbst-Hosting bei, statt diesen Kommunikationsfehler als Beweis dafür zu werten, dass deine URL nicht erreichbar ist.

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

Das ist ein Tuning-Problem, kein Konvertierungsfehler. Öffne plugins/ResourcePackManager/bedrock_display_offsets.yml, passe die entsprechende Achse an, führe /rspm reload aus und verbinde den Bedrock-Testclient neu, damit der nächste Beitritt das neu gebaute Paket erhält. Egoperspektive und Drittperson sind unabhängig — die eine zu tunen wirkt sich nicht auf die andere aus. 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: 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 reitet auf einer Spielerverbindung mit.
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 bedeuten, dass die Verbindung steht; der Schlüssel selbst wird nie ausgegeben.

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

Proxy: „Could not save the network key"

Der Proxy hat einen Schlüssel aufgelöst, konnte ihn aber nicht in seine network-key-Datei schreiben. Dieser Boot funktioniert trotzdem. Beim nächsten Neustart wird ein anderer Schlüssel erzeugt, und jedes bereits versorgte Backend behält den alten und lehnt den neuen ab — das gesamte Netzwerk koppelt sich stillschweigend ab.

Korrigiere die Dateisystemberechtigungen des Datenordners des Proxy-Plugins, bevor du neu startest.

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, sobald der Proxy Merged Bedrock pack published at ... 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.