Monate an Arbeit stecken in so einer Festung: Stachel-Trichter, ein Treppenhaus, das absichtlich nirgendwo hinführt, ein Dach, das den siebten Tag aushält. Dann liegt ein neuer Stable-Build im Steam-Client, und in den Threads steht wieder dieselbe Frage. Wer seine 7 Days to Die Basis mitnehmen will, findet in den Changelogs zu V3.3.0 und V3.4.0 allerdings keine einzige Zeile über einen erzwungenen Wipe — dafür mehrere über Ordner, Serverkonfiguration und einen Indexfehler, der ausgerechnet den Rucksack trifft.

Stand dieser Angaben: 8. November 2026

V3.4.0 ist seit dem Hotfix-Build b9 vom 26. Oktober auf allen Plattformen stabil, die Experimental-Fassung erschien am 23. Oktober, V3.3.0 am 5. Oktober. Spätere Updates können die hier beschriebenen Wege verändern.

7 Days to Die Basis mitnehmen: Was zu V3.3 und V3.4 tatsächlich dokumentiert ist

Beide Changelogs schweigen zur Welt. Kein Satz zur Kompatibilität alter Spielstände, kein Hinweis auf einen Neustart, keine Warnung an Serverbetreiber. Was stattdessen drinsteht, betrifft das Inventar: V3.3.0 ersetzt das alte 9×5-Raster durch ein 8×6-Raster mit 48 Feldern, davon zwei Reihen überladen, und stellt einen eigenen Rucksackplatz daneben, der bis auf 96 Felder in einem 8×12-Raster aufmacht. Die Einzelheiten dazu stehen im Beitrag zu V3.3.

Genau daraus wird in V3.4.0 ein Datenproblem. The Fun Pimps führt unter den bekannten Fehlern auf, dass beim Beitritt auf einen Dedicated- oder P2P-Server ab Build b6 Ressourcen aus einem 3.3-Inventar in andere Gegenstände umgewandelt werden können — ein einmaliger Indexierungsfehler, wie das Studio es nennt. Die Mauern sind dabei nie das Thema. Gefährdet ist, was die Spielfigur am Leib trägt. Was V3.4.0 sonst bringt, steht in der Übersicht zum Update.

Aufschlussreicher ist der Blick zurück auf V3.0. In den Release Notes zum „Dead Hot Summer" richtet sich ein ganzer Abschnitt an Serveradmins, die ihren V2.6-Spielstand weiterführen wollen: Sie müssen ihre alten Einstellungen aus der serverconfig.xml über das Sandbox-Menü im Spiel nachbauen und den erzeugten SandboxCode eintragen. Das Studio geht dort also selbstverständlich davon aus, dass die alte Welt weiterläuft. Die Arbeit steckt in der Konfiguration, nicht im Gelände.

Spielfigur verteidigt sich nachts hinter Holzspitzen gegen eine Horde Zombies in einer RuinenstadtQuelle
Was in einer Basis an Arbeit steckt, zeigt sich in der Blutmondnacht - und genau die will beim Versionswechsel niemand zweimal machen.

Saves, GeneratedWorlds und der Ordner, den keiner sichert

Ein Spielstand besteht laut offiziellem Support-Artikel aus zwei Teilen. Unter Windows liegt beides in %appdata%\7DaysToDie: In Saves stehen das lokale Profil und die Einzelspieler-Spielstände, in SavesLocal die lokal abgelegten Daten der Server, auf denen man gespielt hat, und in GeneratedWorlds die gespeicherten Weltdaten je Karte, benannt nach dem Namen der erzeugten Karte.

Wer eine Welt umzieht, braucht beide Hälften. Den Weg dorthin öffnet der Spiele-Launcher über „Open savegame folder". Wer mehrere Versionsstände nebeneinander halten will, legt in den Steam-Startoptionen mit -UserDataFolder=PFAD je Fassung einen eigenen Ordner an — ein Hinweis aus dem Hilfeartikel des Studios, kein Modder-Trick.

Auf einem gemieteten Server wird daraus eine Liste von Feldern, die zusammenpassen müssen. Die Weltdaten landen unter Data/Worlds, der Spielstand unter userdata/Saves, und in der Serverkonfiguration müssen Weltname, Seed, Weltgröße und Spielname exakt dem entsprechen, was hochgeladen wurde. Jede Abweichung führt dazu, dass der Server den Spielstand als neu behandelt und eine frische Welt erzeugt — so beschreibt es der Hoster Host Havoc in seiner deutschsprachigen Anleitung. Ob sich ein eigener Server überhaupt rechnet, ist eine Rechnung für sich.

Zerstoerte Innenstadt bei Regen mit Hochhaeusern, Wracks und mehreren Zombies zwischen TruemmernQuelle
Eine Welt in 7 Days to Die besteht aus zwei getrennten Teilen: den Weltdaten im Ordner GeneratedWorlds und dem Spielstand im Ordner Saves.

Wann ist ein Weltneustart unvermeidlich?

Hier gehen die Aussagen auseinander, und nicht nur zwischen Spielern und Hostern.

Im offiziellen Forum zitiert ein Nutzer im April 2025 eine Frage-und-Antwort-Passage aus einer Release-Ankündigung: Wegen der technischen Architektur der Engine müssten Spieler mit jedem großen Update ein neues Spiel beginnen, irgendwann werde das nicht mehr nötig sein. Das Original ist im Thread nicht verlinkt, die Passage stammt aus der Zeit vor 1.0 — und steht als Zitat bis heute im Forum.

Hoster lesen die Lage umgekehrt. WinterNode schreibt in seiner Update-Anleitung, ein Update ersetze die Spieldateien des Servers und nicht den Spielstand, und beantwortet die Frage nach einer neuen Welt mit „nicht bei den meisten Updates". Im selben Text steht aber die Einschränkung: Große Versionssprünge können mehr verändern, und das Backup bleibt liegen, bis die Welt nachweislich geladen hat.

Dazu kommt eine Zeile von The Fun Pimps selbst, die quer zu beidem liegt: Im Hilfeartikel zu Mods rät das Studio bei der Fehlersuche ausdrücklich dazu, ein neues Spiel zu beginnen, weil ein vorhandener Spielstand dabei beschädigt werden könne. Gemeint ist der Modfall, nicht der Normalbetrieb — aber es ist dieselbe Firma, die ein paar Artikel weiter erklärt, wie ein V2.6-Spielstand weiterbetrieben wird.

Eine belastbare Regel geben diese Quellen nicht her. Belegt ist nur das Negative: Für V3.3.0 und V3.4.0 hat niemand einen Pflicht-Wipe angekündigt.

Der Prefab-Editor rettet den Bauplan, nicht den Fortschritt

Bleibt der Weg, der die Welt gar nicht erst mitnimmt. Das offizielle Wiki beschreibt, wie ein selbst gebautes Bauwerk im Prefab-Editor als Vorlage gespeichert und später in einer anderen Welt gesetzt wird: Easy Anti-Cheat im Launcher abschalten, über die Editing Tools in den Prefab Editor, im Prefab Browser ein neues Prefab anlegen, bauen, die Auswahl mit Shift+Z über alle Blöcke ziehen, die Bounds aktualisieren, speichern. Für den Import braucht die Zielwelt den Cheat Mode, dazu dm in der Konsole, eine Blockauswahl mit Z und das Eigenschaften-Menü unter K.

Zwei Einschränkungen gehören dazu. Erstens trägt genau diese Wiki-Seite seit September 2022 einen Veraltet-Hinweis und beschreibt den Stand ab Alpha 17 — Tastenbelegung und Menüwege können in V3.4 anders aussehen. Zweitens wandert hier ein Bauwerk, kein Spielstand: Blöcke und Form ziehen um, der Inhalt der Kisten nicht, die laufenden Werkbänke nicht, die Fertigkeitspunkte schon gar nicht. Für alle, die an der Festung hängen und den Rest loslassen können, ist das der sauberste Weg — wer den Fortschritt meint, ist hier falsch.

Spielfigur im verschneiten Biom vor einem hoelzernen Wachturm und einer Baracke mit FahnenmastQuelle
Der Prefab-Editor speichert ein Bauwerk als Vorlage: Bloecke und Form ziehen in die neue Welt um, der Inhalt der Kisten bleibt zurueck.

Leg eine Kopie an, bevor du den Branch wechselst

Die Reihenfolge aus den offiziellen Artikeln ist unspektakulär und wird trotzdem ständig übersprungen. Beim Aufräumen alter Versionsreste, so der Artikel zur Fehlersuche, bleiben im Datenordner ausgerechnet Saves und GeneratedWorlds stehen. Diese beiden gehören gesichert, bevor irgendetwas anderes passiert.

Danach gilt: Branch umstellen, die alte Welt laden, Backup erst danach wegräumen. Auf einem Server kommt hinzu, dass er gestoppt sein muss, bevor Dateien hochgeladen werden — ein laufender Server schreibt weiter und kann die Welt dabei beschädigen. Und wer mit Mods spielt, prüft vorher, ob sie zum neuen Versionsstand passen; das Studio weist selbst darauf hin, dass nicht jeder Mod gepflegt wird.

Was in keiner dieser Quellen steht, ist ausgerechnet der Fall, der die meisten Gruppen betrifft: eine Welt, die seit V2.6 läuft, mit einer Basis, die über drei Versionssprünge gewachsen ist. Dafür gibt es keine offizielle Aussage, nur Erfahrungsberichte — und die widersprechen sich. Wer so eine Welt hat, kopiert sie, bevor er sie anfasst, und kann danach erzählen, was tatsächlich passiert ist. Genau diese Berichte fehlen bisher.

Quellen