Kapitel I, „Out of the Breach“, ist am 12. Oktober 2026 mit Update 7 erschienen, und viele Serverbetreiber standen beim Neustart vor demselben Problem: Der Server startet nicht mehr oder Mods werden nicht geladen. Dieser Leitfaden erklärt nicht die Installation von Mods, sondern liefert eine vollständige Fehlersuche, von der ersten Fehlermeldung bis zur Reparatur, und schützt dabei in jedem Schritt deine Welt.
Warum Kapitel I manche Mods kaputt macht
Update 7 ist mehr als ein Inhaltsupdate. Es verändert drei Ebenen, auf die Mods angewiesen sind:
- Das Netzwerkprotokoll hat eine neue Version. Client und Server müssen übereinstimmen: Ein Server, der noch auf Update 6 läuft, lehnt aktualisierte Spieler ab, und umgekehrt. Kein Mod umgeht diese Regel.
- Die Server-API wurde stark umgebaut. Die Entwicklerhinweise nennen zum Beispiel
TickProcedure.onTickmit geänderter Signatur,WorldChunk, das keineWorldmehr enthält, undDurabilityOperator, das jetztComparisonOperatorheißt. Ein Java-Mod (.jar-Datei), der für Update 6 gebaut wurde und diese Elemente nutzt, lädt eventuell nicht mehr oder stürzt im Spiel ab. - Die Spiel-Assets haben sich ebenfalls geändert. Die Pre-Release-Notes zu Update 7 nennen umbenannte Schlüssel (
ChargeAccelerationwurde zuChargeAccelerationDistance), Gleiter-Felder, die nachTemplate_Gliderverschoben wurden, IDs, die nicht mehr aufgelöst werden (Spectre_Void), und sogar umbenannte PNG-Dateien wieSpiwer_Web_Full.png, jetztSpider_Web_Full.png. Ein Pack, das auf etwas Verschwundenes verweist, kann an der Validierung scheitern.
Außerdem hat sich das Speicherformat geändert. Eine Welt wird beim ersten Laden durch einen Kapitel-I-Server automatisch konvertiert, und eine konvertierte Welt lässt sich mit einer älteren Version nicht mehr öffnen. Die Konvertierung ist also eine Einbahnstraße.
Bevor du etwas änderst: Backup
Stoppe den Server und kopiere mindestens:
- den Ordner
universe/(deine Welten); - den kompletten Ordner
mods/samt Konfigurationsordnern der Mods; - die Dateien
config.json,permissions.json,whitelist.jsonundbans.json.
Notiere außerdem die genaue Liste deiner Mods mit Versionsnummer, um sie mit den Seiten der Autoren abzugleichen. Wenn du schon mit Kapitel I gestartet hast, sichere trotzdem den aktuellen Stand, bevor du etwas änderst, und starte den Server nicht immer wieder neu in der Hoffnung, dass der Fehler von selbst verschwindet.
Schritt 1: Logs an der richtigen Stelle lesen
Konsole und Logs nennen fast immer den Mod, der Probleme macht, sofern du an der richtigen Stelle suchst:
| Situation | Wo suchen |
|---|---|
| Dedizierter oder gehosteter Server | Die Konsole im Panel, dann der Ordner logs/ des Servers (eine Datei pro Start, benannt nach Datum und Uhrzeit) |
| Einzelspielerwelt oder aus dem Spiel geteilte Welt | UserData/Saves/<Welt>/logs |
| Problem auf Client-Seite (Spiel) | UserData/logs |
Öffne das Log des letzten Starts und scrolle zum ersten Fehler; die folgenden sind oft nur Folgefehler. Suche nach Error, Exception und Failed sowie nach dem Namen jedes deiner Mods. Unter Linux reicht ein Befehl zum Filtern:
grep -inE "error|exception|failed" logs/*.log | head -n 40
Unter Windows erledigt PowerShell dasselbe:
Select-String -Path .\logs\*.log -Pattern "error","exception","failed" | Select-Object -First 40
Eine Meldung wie Failed to load manifest file! weist auf einen Mod hin, dessen manifest.json fehlt, falsch liegt oder nicht lesbar ist. Ein Java-Stacktrace mit einer nicht gefundenen Klasse oder Methode (zum Beispiel NoSuchMethodError) bedeutet fast immer einen Java-Mod, der gegen die alte API gebaut wurde.
Schritt 2: Fehlerart einordnen
Hast du die entscheidende Zeile gefunden, ordne sie ein. Die Lösung hängt von der Kategorie ab.
| Symptom | Wahrscheinliche Ursache | Maßnahme |
|---|---|---|
| Server stoppt beim Start und nennt einen Mod | Java-Mod nicht kompatibel mit der neuen API | Kapitel-I-Version des Mods installieren oder ihn vorübergehend entfernen |
| Asset-Validierungsfehler (unbekannter Schlüssel, ID nicht gefunden) | Pack verweist auf etwas Umbenanntes oder Entferntes | Update des Packs abwarten oder installieren |
| Mod lädt, aber ein Effekt funktioniert nicht mehr | Umbenannter Schlüssel, der nur eine Warnung auslöst | Dem Autor melden, Warnungen im Log prüfen |
| Mod wegen Abhängigkeit übersprungen | Abhängigkeit fehlt oder ist zu alt | Abhängigkeit installieren oder aktualisieren |
| Seltsames Verhalten, doppelte Gegenstände | Zwei Versionen desselben Mods in mods/ | Nur eine Datei behalten |
| Spieler können nicht verbinden | Client- und Serverversion unterschiedlich | Version und Update-Kanal (Patchline) angleichen |
Schritt 3: Duplikate entfernen
Die banalste Ursache und die, die am häufigsten übersehen wird. Beim Aktualisieren eines Mods lädt man die neue Datei hoch, ohne die alte zu löschen, und in mods/ liegen dann zwei Versionen desselben Mods. Liste den Ordner auf und achte auf ähnliche Namen:
ls -1 mods/ | sort
Siehst du zum Beispiel MeinMod-1.4.2.jar und MeinMod-1.5.0.jar, behalte nur die Version für Kapitel I. Achte auch auf Mods, die gleichzeitig als .zip-Pack und als entpackter Ordner vorhanden sind: Nur eines davon darf bleiben.
Schritt 4: Abhängigkeiten prüfen
Jeder Mod gibt in seiner manifest.json an, was er braucht; sie liegt im Stammverzeichnis der .jar, der .zip oder des Pack-Ordners. Zwei Felder sind wichtig:
Dependencies: Pflicht-Mods im FormatGruppe:Namemit einem Versionsbereich. Fehlt einer oder passt die Version nicht, lädt der Mod nicht.OptionalDependencies: optionale Mods. Fehlen sie, lädt der Mod trotzdem.
{
"Group": "Beispiel",
"Name": "MeinMod",
"Version": "1.5.0",
"ServerVersion": "...",
"Dependencies": {
"Beispiel:GemeinsameLib": ">=2.0.0"
},
"OptionalDependencies": {}
}
Die klassische Falle nach einem großen Update: Der Hauptmod hat schon seine Kapitel-I-Version, seine Bibliothek aber noch nicht. Dann nützt dir der Hauptmod nichts, bis die Abhängigkeit nachzieht. Auf den Download-Seiten zeigt der Reiter mit den Beziehungen, welche Abhängigkeiten Pflicht sind. Das Feld ServerVersion verrät, wenn es ausgefüllt ist, außerdem, für welche Serverversion der Mod veröffentlicht wurde; vergleiche es mit der Ausgabe von /version.
Schritt 5: Den fehlerhaften Mod vorübergehend entfernen
Gibt es keine kompatible Version, musst du entscheiden. Es gibt zwei sehr unterschiedliche Fälle:
Der Mod fügt keine Blöcke oder Gegenstände hinzu
Oberfläche, Minikarte, Admin-Befehle, Verwaltungswerkzeuge: Du kannst ihn gefahrlos entfernen. Stoppe den Server, verschiebe die Datei in einen separaten Ordner (zum Beispiel mods-deaktiviert/), statt sie zu löschen, und starte neu. Du kannst ihn auch im Abschnitt Mods der config.json des Servers deaktivieren, ebenfalls nur bei gestopptem Server: Der Server schreibt seine Konfigurationsdateien im laufenden Betrieb neu, Änderungen im Live-Betrieb können verloren gehen.
Der Mod fügt Blöcke, Gegenstände oder Kreaturen hinzu
Hier ist Vorsicht geboten. Entfernst du ihn, können die von ihm platzierten Blöcke als unbekannt erscheinen oder verschwinden, und die betroffenen Gegenstände können aus den Inventaren verloren gehen. Jede Welt speichert zudem in ihrer eigenen Konfiguration die Liste der Mods, die sie braucht: Fehlt einer, lädt die Welt möglicherweise nicht. Teste das Entfernen deshalb immer an einer Kopie der Welt, bevor du die Hauptwelt anfasst. Oft ist es am besten, den Server offline zu lassen oder eine vorübergehende Welt zu öffnen, bis der Mod aktualisiert ist.
Um den fehlerhaften Mod in einer langen Liste schnell zu finden, ist die Halbierungsmethode am effizientesten: Entferne die Hälfte der Mods, starte, und wiederhole das mit der Hälfte, in der der Fehler weiter auftritt. Bei 30 Mods reichen fünf Neustarts. In der Community-Dokumentation wird außerdem die Startoption --ignore-broken-mods erwähnt, mit der der Server trotz fehlerhaftem Mod startet, damit du ihn identifizieren kannst; prüfe mit --help, ob deine Version sie unterstützt, bevor du dich darauf verlässt, und nutze sie nie ohne Backup auf deiner Hauptwelt.
Schritt 6: Das Mod-Update abwarten (und verfolgen)
Bei Java-Mods kommt die Lösung fast immer vom Autor, der den Mod für die neue API neu bauen muss. Ein paar Gewohnheiten:
- prüfe die Seite jedes Mods und suche im Changelog gezielt nach „Chapter 1“ oder „Update 7“;
- der im Spiel integrierte Mod-Browser zeigt auf einen Blick, welche Mods deiner Bibliothek ein Update bekommen haben;
- lade keine „reparierte Version“ von Unbekannten herunter: Eine
.jar-Datei führt Code auf deinem Server aus; - ist ein Mod verwaist, such dir eine gepflegte Alternative, statt eine kaputte Version zu behalten.
Kompatibilitätstabelle nach Mod-Typ
Nicht jeder Mod trägt nach Kapitel I dasselbe Risiko. Diese Tabelle hilft dir, Prüfungen zu priorisieren:
| Mod-Typ | Risiko nach Update 7 | Was prüfen |
|---|---|---|
| Rein visuelles Pack (Texturen, Sounds) | Gering | Im Basisspiel umbenannte Dateien |
| Inhalts-Pack (Blöcke, Gegenstände, NPCs, Gleiter) | Mittel | Umbenannte oder entfernte Schlüssel und IDs |
Java-Servermod (.jar) | Hoch | Eine für Kapitel I kompilierte Version |
| Von anderen Mods genutzte Bibliothek | Hoch | Vor allen abhängigen Mods aktualisiert |
| Mod, der Strukturen oder Welten erzeugt | Mittel bis hoch | Test an einer Weltkopie, Kompatibilität mit dem neuen Speicherformat |
Nebenbei eine gute Nachricht: Seit Update 7 kann ein Mod ganze Welten enthalten, und eine aus einem Mod erstellte Welt bleibt erhalten, auch wenn der Mod entfernt wird.
Fehler, die nicht von Mods kommen
Bevor du deine Mods beschuldigst, schließe diese Ursachen aus, die ebenfalls mit Kapitel I zusammenhängen:
- Exit-Code 11 bei einem selbst gehosteten Server: Die Serverdaten liegen im Installationsordner des Launchers. Verschiebe den Server in einen eigenen Ordner.
- Warnung zu
MaxViewRadius: Die Sichtweite ist jetzt auf 32 Chunks begrenzt. Der Server startet trotzdem, korrigiere aber den Wert inconfig.json. - Abgelehnte Spieler: Client und Server laufen nicht auf derselben Version oder Patchline.
Kurze Checkliste
- Server stoppen und
universe/,mods/sowie die Konfigurationsdateien sichern. - Den ersten Fehler im neuesten Log lesen.
- Duplikate aus
mods/entfernen. - Abhängigkeiten vor den Mods aktualisieren, die sie nutzen.
- Mods ohne Kapitel-I-Version vorübergehend entfernen; bei Mods mit eigenen Blöcken zuerst an einer Kopie testen.
- Neu starten, prüfen, dass der Server läuft, und mit einem einzelnen Spieler testen, bevor alle wieder drauf dürfen.
FAQ
Kann ich zu Update 6 zurückkehren, wenn meine Mods nicht mehr laufen?
Nur mit einem Backup von vor dem Update. Eine Welt, die ein Kapitel-I-Server geöffnet hat, ist konvertiert und kann von einer älteren Version nicht mehr gelesen werden.
Mein Mod ist aktuell, aber der Server startet trotzdem nicht. Warum?
Prüfe seine Abhängigkeiten und ob noch eine alte Kopie desselben Mods in mods/ liegt. Schon eine Bibliothek, die noch auf dem Stand von Update 6 ist, blockiert das Laden.
Sind Texturpacks betroffen?
Selten, aber einige Dateien des Basisspiels wurden umbenannt. Ersetzt ein visuelles Pack eine Datei, deren Name sich geändert hat, greift diese Ersetzung nicht mehr.
Wie lange muss ich auf ein Mod-Update warten?
Das hängt ganz vom Autor ab, eine feste Frist gibt es nicht. Verfolge die Seite oder das Changelog des Mods; zeigt er keine Aktivität, halte eine Alternative bereit.