Schnellfinder

Was suchst du?

⌘/Ctrl + K öffnet den Finder · Esc schließt ihn
Gameserver

Project Zomboid Build 42 Server Update: Branches, Backups und Mod-Kompatibilität

Project-Zomboid-Server auf Build 42 aktualisieren: Stable 42.20.x, legacy41, 42.19-Branch, SteamCMD-Update, Backups und Mod-Kompatibilität sicher planen.

Inhalt dieses Guides
Kurz erklärt

Project-Zomboid-Server auf Build 42 aktualisieren: Stable 42.20.x, legacy41, 42.19-Branch, SteamCMD-Update, Backups und Mod-Kompatibilität sicher planen.

Interaktiv

Server-Arbeitsmodus

Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.

0/5erledigt
Bei aktiviertem JavaScript werden Fortschritt und Auswahl nur lokal in diesem Browser gespeichert.

Serverupdates bei Project Zomboid sind nicht nur ein app_update-Befehl. Entscheidend ist, welche Welt du weiterführen willst und welcher Branch dazu kompatibel ist. Seit dem Stable-Start von Build 42 ist das besonders wichtig.

Aktuellen Stable-Stand zuerst prüfen

The Indie Stone weist derzeit 42.20.4 als Stable aus. Diese Information kann sich jederzeit ändern. Prüfe vor einem Wartungsfenster immer die aktuelle Build-Seite und nicht nur eine alte Anleitung oder den Build eines einzelnen Clients.

Build 41 bleibt separat

Bestehende Build-41-Welten können über den Branch legacy41 weiter betrieben werden. Ein Versionssprung ist kein normaler Hotfix. Plane Migration oder Neustart bewusst und behalte ein unverändertes Backup.

42.19-Welten ebenfalls nicht blind öffnen

Die 42.20-Veröffentlichung brachte Kartenänderungen, weshalb 42.19-Saves nicht direkt kompatibel waren. Dafür existiert ein eigener 42.19-Branch. Das zeigt: „gleiche Hauptversion“ reicht für Save-Kompatibilität nicht immer.

Sauberer Updateablauf

  1. Wartungsfenster ankündigen.
  2. Server kontrolliert stoppen.
  3. Vollständiges Backup erstellen.
  4. Serverdateien über Steam/SteamCMD aktualisieren.
  5. Mod-/Workshop-Status prüfen.
  6. Server starten und Logs kontrollieren.
  7. Mit Testclient auf demselben Build verbinden.

Mods nach Update als erste Verdächtige behandeln

Wenn der Vanilla-Server startet, aber die produktive Instanz nicht, sind Workshop-Abhängigkeiten, veraltete Lua-Mods oder Kartenmods häufige Kandidaten. Entferne nicht sofort Weltdateien; arbeite mit Backup und kontrollierter Testkopie.

Rollback ist eine Betriebsfunktion

Ein echtes Rollback bedeutet mehr als „alte EXE kopieren“. Serverbuild, Weltstand und Modstand müssen zueinander passen. Dokumentiere daher im Backupnamen mindestens Datum und aktiven Branch.

Automatisierung mit Sicherheitsbremse

Automatische Updates sind bequem, sollten einen Server aber nicht ungeprüft direkt nach jedem Patch wieder hochfahren. Für modded Server ist ein manueller Freigabeschritt oft sinnvoller als maximale Aktualisierungsgeschwindigkeit.

Staging statt Patchen auf Verdacht

Für große Community-Server lohnt eine zweite Testinstanz. Spiele dort das Serverupdate und die aktuelle Workshop-Liste ein, lade eine Kopie der Welt und führe mindestens einen Join-, Fahr- und Kartenwechseltest durch. Erst wenn dieser Pfad stabil ist, wird die Produktivinstanz gewartet.

Branch-Namen in der Betriebsdokumentation festhalten

Notiere neben der Spielversion auch den verwendeten Steam-Branch. „Build 42“ ist zu ungenau, wenn parallel Stable, Legacy- und Übergangsbranches existieren. Das vereinfacht spätere Restore-Entscheidungen erheblich.

Quellen

Nächster Schritt

Passend dazu