Valheim 1.0 : ce qui change vraiment sur le disque, mesuré

La 1.0 de Valheim change la façon dont le jeu écrit ses mondes. Iron Gate l'annonce en deux phrases dans ses notes de patch ; nous avons voulu voir les fichiers. Cette page est le relevé brut, avec la méthode pour le refaire.

Rien ici n'est repris d'un communiqué : tout a été relevé le 6 septembre 2026 sur une machine louée pour l'occasion, avant la sortie publique.

La méthode, pour que tu puisses la refuser

Le nouveau format vit sur la branche de test publique de Valheim depuis mai 2026 — donc il est observable avant le 9 septembre. On y accède avec le code Steam yesimadebackups, et l'image serveur lloesche/valheim-server l'atteint avec PUBLIC_TEST=true.

Le relevé s'est fait sur une machine à 2 vCPU partagés et 4 Go de RAM, chez Hetzner à Falkenstein. Un monde a été généré sur la branche stable (0.221.12), arrêté proprement pour qu'il s'écrive, puis le même dossier de données a été redémarré sur la branche de test. C'est cette bascule qui montre la conversion.

Avant : deux fichiers

Sur 0.221.12, un monde sauvegardé tient dans une paire, à plat :

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

Deux choses qu'on n'attendait pas et qui comptent si tu déplaces un monde à la main. Le .fwl fait 49 octets et il existe dès la création du monde : le .db, lui, n'apparaît qu'à la première sauvegarde. Un dossier qui ne contient qu'un .fwl n'est donc pas un monde vide, c'est un monde jamais sauvegardé. Et le jeu range ses propres copies à côté du monde, préfixées _backup_auto- — elles sont dans le dossier que tu copies, sans que rien ne le dise.

Après : un dossier, et des morceaux

Redémarré sur 0.221.13, le même monde devient ceci :

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

Le point à retenir : l'extension change. Ce n'est plus .fwl mais .fwl2, et le .db devient .db2 accompagné de fichiers .chunk. Un outil qui cherche *.db et *.fwl — un script de sauvegarde, un import d'hébergeur — ne trouvera rien sur un monde 1.0. C'est silencieux : pas d'erreur, juste un monde absent.

Le nom du monde vit dans le nom du dossier. Les fichiers à l'intérieur sont génériques, et leur numéro monte à chaque sauvegarde (_main.1.* puis _main.2.*).

La conversion garde une copie complète, et pèse 42 %

Le journal du serveur dit Moved old World save into backup!. La paire d'origine est conservée telle quelle, renommée <monde>_backup_<horodatage>. Résultat mesuré :

Soit +42 %, et non le doublement qu'on pouvait craindre : le monde converti (133 ko) est bien plus petit que la copie de l'ancien (322 ko) qui reste à côté. Cette copie est aussi ta seule porte de sortie si la conversion tourne mal — le jeu ne sait pas revenir en arrière tout seul.

Ce qui ne change pas : le téléchargement

Le serveur dédié pèse le même poids qu'avant. Relevé dans la sortie de SteamCMD sur la branche de test : 1 761 753 577 octets, soit environ 1,76 Go. Si tu redimensionnes une machine pour la 1.0, ce n'est pas le téléchargement qui bouge.

La version réseau passe de 36 à 37

Le serveur s'annonce Valheim version: l-0.221.13 (network version 37), contre network version 36 sur 0.221.12. C'est ce nombre-là qui décide si un joueur entre. Comme Steam met les clients à jour tout seul, un serveur qui n'a pas encore basculé devient, à la sortie, un serveur où plus personne n'entre — le temps qu'il se mette à jour.

Les sauvegardes du jeu ne s'éteignent pas avec celles de l'image

Un piège d'hébergement, celui-là. L'image lloesche a un réglage BACKUPS pour ses propres archives horaires. Il n'a aucun effet sur les sauvegardes que le jeu prend lui-même, et le serveur le dit dans son journal :

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

Ce sont les trois défauts documentés par Iron Gate (-backups 4, -backupshort 7200, -backuplong 43200) : jusqu'à quatre copies, une à deux heures puis trois à douze heures d'intervalle. Elles vivent dans worlds_local, donc dans toute archive que tu ferais de ce dossier. Sur un serveur qui ne tourne que quelques heures d'affilée, les trois « longues » ne se déclenchent jamais — -backups 1 ne perd donc presque rien.

Renommer un monde marche, dans les deux formats

Utile si tu déménages : Valheim charge un monde renommé, il n'en fabrique pas un neuf. Vérifié dans les deux formats, et le juge est une ligne de journal — Done generating locations n'apparaît que pour un monde neuf.

Dans les deux cas les octets du monde étaient intacts après le renommage.

Ce qu'on n'a pas mesuré

La RAM et le CPU d'un serveur 1.0 avec des joueurs dessus : il faudrait des joueurs réels, et nous n'avons pas voulu publier une estimation en la faisant passer pour une mesure. Le Deep North n'apparaissant que sur le terrain inexploré, la question ne se posera vraiment qu'après quelques sessions d'exploration.

Le comportement de la conversion avec des mods n'a pas été testé non plus — Iron Gate écrit explicitement que le nouveau système de sauvegarde ne l'a pas été.

Ces relevés viennent de notre propre exploitation de serveurs Valheim. Si tu veux un serveur sans t'occuper de tout ça : voir Valheim.