Format de sauvegarde Valheim 1.0 : le fichier .fwl2 expliqué

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 vient de serveurs Valheim 1.0 que nous exploitons (l-1.0.7), et d'un ancien monde qu'on a regardé se convertir.

Si tu préfères ne pas gérer de machine toi-même, tu peux héberger un serveur Valheim à l'heure : la facturation se fait à l'heure entamée, sans compter le démarrage, et un serveur éteint ne coûte rien.

La méthode, pour que tu puisses la refuser

Deux relevés, deux sources. La forme des fichiers est lue dans les archives de nos propres serveurs 1.0 : on ouvre l'archive d'un monde, on liste ce qu'elle contient, on regarde les octets des petits fichiers — aucune interprétation. La conversion d'un ancien monde a été observée à part, sur une machine louée pour l'occasion (2 vCPU partagés, 4 Go de RAM, en Allemagne) : un monde généré à l'ancien format, arrêté proprement pour qu'il s'écrive, puis le même dossier de données redémarré avec le nouveau système de sauvegarde. C'est cette bascule qui montre la conversion, et c'est de là que viennent les octets du tableau plus bas.

Avant : deux fichiers

À l'ancien format, 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é avec le nouveau système de sauvegarde, 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 — et aussi, on le verra plus bas, à l'intérieur du .fwl2. Les fichiers 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 : 1 761 753 577 octets, soit environ 1,76 Go — le même ordre de grandeur que les 1,75 Go relevés chez nous avant la 1.0. Si tu redimensionnes une machine pour la 1.0, ce n'est pas le téléchargement qui bouge.

La version réseau : 39 en 1.0

Le serveur s'annonce Valheim version: l-1.0.7 (network version 39), là où il disait network version 36 avant la 1.0. 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é est 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.

Le nom du monde est écrit DANS le fichier — mais c'est le dossier qui décide

Le _main.<n>.fwl2 ne fait pas 49 octets comme l'ancien .fwl : 179 à 232 octets sur nos serveurs, parce qu'il porte le nom du monde, sa graine, et la liste des joueurs connus (identifiant, pseudo, jeton). Ses huit premiers octets sont deux entiers 32 bits — la longueur de tout ce qui suit, puis le numéro de format du système de sauvegarde (41, le même dans le _main.<n>.ok et en tête du .chunks). Vient ensuite le nom, précédé de sa longueur, puis la graine :

e4 00 00 00   29 00 00 00   08 't','i','c','k','s','e','r','v'   0a 'R','b','j',…
 └ 228 = la     └ 41 = le      └ 8 + le nom                        └ 10 + la graine
   suite du       format du
   fichier        sauvegarde

Et pourtant c'est le DOSSIER qui décide du chargement. Un monde dont le .fwl2 annonce MaPartie, placé dans un dossier tickserv/, est chargé sans broncher par un serveur lancé avec -world tickserv — c'est le cas d'un monde apporté par un joueur et rangé sous le nom que le serveur ouvre. Le serveur le dit lui-même, et il nomme les deux :

ZNet.LoadWorld: MaPartie (tickserv), save number 8
ZoneSystem.Load => Loaded 12 327 locations

C'est la ligne à chercher quand tu veux savoir si un serveur a chargé TON monde ou en a fabriqué un autre : le premier nom est celui de ton monde, le second celui que le serveur a demandé. Le compteur save number monte à chaque sauvegarde — utile pour vérifier qu'un monde vit toujours.

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.