Valheim 1.0: Was sich auf der Platte wirklich ändert, gemessen

Valheim 1.0 ändert, wie das Spiel Welten schreibt. Iron Gate sagt es in zwei Sätzen in den Patchnotes; wir wollten die Dateien sehen. Diese Seite ist das rohe Messprotokoll, mit der Methode zum Nachmachen.

Nichts hiervon ist einer Pressemitteilung entnommen: alles wurde am 6. September 2026 auf einer für den Anlass gemieteten Maschine gemessen, vor der öffentlichen Veröffentlichung.

Die Methode, damit du sie ablehnen kannst

Das neue Format lebt seit Mai 2026 auf Valheims öffentlichem Testzweig — es ist also vor dem 9. September beobachtbar. Zugang gibt der Steam-Code yesimadebackups, und das Server-Image lloesche/valheim-server erreicht ihn mit PUBLIC_TEST=true.

Gemessen wurde auf einer Maschine mit 2 geteilten vCPU und 4 GB RAM bei Hetzner in Falkenstein. Eine Welt wurde auf dem stabilen Zweig (0.221.12) erzeugt, saubermachend beendet, damit sie geschrieben wird, und dann wurde dasselbe Datenverzeichnis auf dem Testzweig neu gestartet. Dieser Wechsel zeigt die Konvertierung.

Vorher: zwei Dateien

Auf 0.221.12 ist eine gespeicherte Welt ein flaches Paar:

worlds_local/
  tickserv.db                              322 596 B
  tickserv.fwl                                  49 B
  tickserv.fwl.old                              49 B
  tickserv_backup_auto-20260906114306.fwl       49 B

Zwei Dinge, die wir nicht erwartet hatten und die zählen, wenn du eine Welt von Hand umziehst. Die .fwl ist 49 Byte groß und existiert ab dem Moment der Welterzeugung: die .db erscheint erst beim ersten Speichern. Ein Ordner mit nur einer .fwl ist also keine leere Welt, sondern eine Welt, die nie gespeichert wurde. Und das Spiel legt seine eigenen Kopien neben die Welt, mit dem Präfix _backup_auto- — sie liegen in dem Ordner, den du kopierst, ohne dass es irgendwo steht.

Nachher: ein Ordner, und Stücke

Auf 0.221.13 neu gestartet, wird aus derselben Welt das:

worlds_local/
  tickserv/
    _main.1.fwl2                     49 B
    _main.1.db2                 133 435 B
    _main.1.chunks                   32 B
    _main.1.ok                        4 B
    00_00__0_1.chunk              1 464 B
    00_01__0_1.chunk                  6 B
  tickserv_backup_20260906-115918.db   322 596 B
  tickserv_backup_20260906-115918.fwl       49 B

Das Entscheidende: die Endung ändert sich. Es ist nicht mehr .fwl, sondern .fwl2, und aus der .db wird .db2 samt .chunk-Dateien. Ein Werkzeug, das nach *.db und *.fwl sucht — ein Backup-Skript, der Importer eines Anbieters — findet auf einer 1.0-Welt nichts. Und das stillschweigend: kein Fehler, nur eine fehlende Welt.

Der Name der Welt lebt im Ordnernamen. Die Dateien darin sind generisch, und ihre Nummer steigt mit jedem Speichern (_main.1.*, dann _main.2.*).

Die Konvertierung behält eine vollständige Kopie und kostet 42 %

Das Serverprotokoll sagt Moved old World save into backup!. Das ursprüngliche Paar bleibt unverändert erhalten, umbenannt zu <welt>_backup_<zeitstempel>. Gemessenes Ergebnis:

Also +42 %, nicht die Verdopplung, die man befürchten könnte: die konvertierte Welt (133 kB) ist deutlich kleiner als die daneben liegende Kopie der alten (322 kB). Diese Kopie ist auch dein einziger Ausweg, wenn die Konvertierung schiefgeht — das Spiel kann eine Welt nicht selbst zurückrollen.

Was sich nicht ändert: der Download

Der dedizierte Server ist genauso groß wie vorher. Aus der SteamCMD-Ausgabe auf dem Testzweig gelesen: 1 761 753 577 Byte, also etwa 1,76 GB. Wenn du eine Maschine für 1.0 umdimensionierst, ist der Download nicht das, was sich bewegt hat.

Die Netzwerkversion geht von 36 auf 37

Der Server meldet Valheim version: l-0.221.13 (network version 37), gegen network version 36 auf 0.221.12. Diese Zahl entscheidet, ob ein Spieler hereinkommt. Da Steam die Clients von allein aktualisiert, wird ein Server, der noch nicht gewechselt hat, zum Release ein Server, in den niemand mehr hineinkommt — bis er sich aktualisiert.

Die Backups des Spiels gehen nicht mit denen des Images aus

Eine Hosting-Falle. Das lloesche-Image hat eine BACKUPS-Einstellung für seine eigenen stündlichen Archive. Sie hat keine Wirkung auf die Backups, die das Spiel selbst anlegt, und der Server sagt es in seinem Protokoll:

Considering autobackup for World. […] short time: 7200, long time: 43200, backup count: 4

Das sind die drei von Iron Gate dokumentierten Standardwerte (-backups 4, -backupshort 7200, -backuplong 43200): bis zu vier Kopien, eine nach zwei Stunden, dann drei im Abstand von zwölf Stunden. Sie liegen in worlds_local, also in jedem Archiv, das du von diesem Ordner machst. Auf einem Server, der nur wenige Stunden am Stück läuft, greifen die drei „langen" nie — -backups 1 verliert also fast nichts.

Eine Welt umzubenennen funktioniert, in beiden Formaten

Nützlich beim Umzug: Valheim lädt eine umbenannte Welt, es baut keine neue. In beiden Formaten geprüft, und der Richter ist eine Protokollzeile — Done generating locations erscheint nur bei einer neuen Welt.

In beiden Fällen waren die Bytes der Welt nach dem Umbenennen unversehrt.

Was wir nicht gemessen haben

RAM und CPU eines 1.0-Servers mit Spielern darauf: dafür braucht es echte Spieler, und wir wollten keine Schätzung als Messung ausgeben. Da der Deep North nur auf unerkundetem Gelände erscheint, stellt sich die Frage ohnehin erst nach einigen Erkundungssitzungen.

Das Verhalten der Konvertierung mit Mods wurde ebenfalls nicht getestet — Iron Gate schreibt ausdrücklich, dass das neue Speichersystem es nicht wurde.

Diese Messungen stammen aus unserem eigenen Betrieb von Valheim-Servern. Wenn du dich damit nicht beschäftigen willst: Valheim ansehen.