Valheim 1.0: lo que realmente cambia en el disco, medido

La 1.0 de Valheim cambia la forma en que el juego escribe sus mundos. Iron Gate lo anuncia en dos frases en sus notas de parche; nosotros quisimos ver los archivos. Esta página es la lectura en bruto, con el método para repetirla.

Nada aquí procede de un comunicado: todo viene de servidores Valheim 1.0 que gestionamos nosotros mismos (l-1.0.7), y de un mundo antiguo que vimos convertirse.

El método, para que puedas rechazarlo

Dos lecturas, dos fuentes. La forma de los archivos se lee en los archivos comprimidos de nuestros propios servidores 1.0: se abre el archivo de un mundo, se lista lo que contiene, se miran los bytes de los archivos pequeños — sin ninguna interpretación. La conversión de un mundo antiguo se observó por separado, en una máquina alquilada para la ocasión (2 vCPU compartidas, 4 GB de RAM, Hetzner en Falkenstein): un mundo generado en el formato antiguo, detenido de forma limpia para que se escribiera, y luego la misma carpeta de datos reiniciada con el nuevo sistema de guardado. Ese cambio es lo que muestra la conversión, y de ahí vienen los bytes de la tabla de más abajo.

Antes: dos archivos

En el formato antiguo, un mundo guardado cabe en un par, en plano:

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

Dos cosas que no esperábamos y que importan si mueves un mundo a mano. El .fwl pesa 49 bytes y existe desde el momento en que se crea el mundo: el .db, por su parte, solo aparece en el primer guardado. Una carpeta que solo contenga un .fwl no es por tanto un mundo vacío, es un mundo que nunca se guardó. Y el juego coloca sus propias copias junto al mundo, con el prefijo _backup_auto- — están dentro de la carpeta que copias, sin que nada lo indique.

Después: una carpeta, y fragmentos

Reiniciado con el nuevo sistema de guardado, el mismo mundo se convierte en esto:

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

El punto a retener: la extensión cambia. Ya no es .fwl sino .fwl2, y el .db se convierte en .db2 acompañado de archivos .chunk. Una herramienta que busque *.db y *.fwl — un script de copia de seguridad, un importador de un proveedor — no encontrará nada en un mundo 1.0. Y es silencioso: sin error, solo un mundo ausente.

El nombre del mundo vive en el nombre de la carpeta — y también, como veremos más abajo, dentro del .fwl2. Los archivos son genéricos, y su número sube con cada guardado (_main.1.* y luego _main.2.*).

La conversión conserva una copia completa, y pesa un 42 % más

El registro del servidor dice Moved old World save into backup!. El par original se conserva tal cual, renombrado <mundo>_backup_<marca de tiempo>. Resultado medido:

Es decir +42 %, y no la duplicación que se podía temer: el mundo convertido (133 KB) es bastante más pequeño que la copia del antiguo (322 KB) que queda al lado. Esa copia es también tu única salida si la conversión sale mal — el juego no sabe volver atrás por sí solo.

Lo que no cambia: la descarga

El servidor dedicado pesa lo mismo que antes. Leído en la salida de SteamCMD: 1 761 753 577 bytes, es decir unos 1,76 GB — el mismo orden de magnitud que los 1,75 GB registrados con nosotros antes de la 1.0. Si redimensionas una máquina para la 1.0, no es la descarga lo que cambia.

La versión de red: 39 en la 1.0

El servidor se anuncia como Valheim version: l-1.0.7 (network version 39), cuando antes decía network version 36 antes de la 1.0. Es ese número el que decide si un jugador puede entrar. Como Steam actualiza los clientes por su cuenta, un servidor que aún no ha cambiado es un servidor en el que ya no entra nadie — hasta que se actualiza.

Las copias de seguridad del juego no se apagan con las de la imagen

Una trampa de alojamiento, esta. La imagen lloesche tiene un ajuste BACKUPS para sus propios archivos horarios. No tiene ningún efecto en las copias de seguridad que el propio juego realiza, y el servidor lo dice en su registro:

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

Son los tres valores por defecto documentados por Iron Gate (-backups 4, -backupshort 7200, -backuplong 43200): hasta cuatro copias, una a las dos horas y luego tres con doce horas de intervalo. Viven en worlds_local, así que en cualquier archivo que hagas de esa carpeta. En un servidor que solo funciona unas horas seguidas, las tres «largas» nunca se disparan — -backups 1 apenas pierde nada, por tanto.

Renombrar un mundo funciona, en ambos formatos

Útil si te mudas: Valheim carga un mundo renombrado, no fabrica uno nuevo. Comprobado en ambos formatos, y el juez es una línea de registro — Done generating locations aparece solo en un mundo nuevo.

En ambos casos los bytes del mundo estaban intactos tras el renombrado.

El nombre del mundo está escrito DENTRO del archivo — pero es la carpeta la que decide

El _main.<n>.fwl2 no pesa 49 bytes como el antiguo .fwl: de 179 a 232 bytes en nuestros servidores, porque lleva el nombre del mundo, su semilla, y la lista de jugadores conocidos (identificador, nombre, token). Sus primeros ocho bytes son dos enteros de 32 bits — la longitud de todo lo que sigue, y luego el número de formato del sistema de guardado (41, el mismo en el _main.<n>.ok y al principio del .chunks). Luego viene el nombre, precedido de su longitud, y después la semilla:

e4 00 00 00   29 00 00 00   08 't','i','c','k','s','e','r','v'   0a 'R','b','j',…
 └ 228 = el     └ 41 = el       └ 8 + el nombre                     └ 10 + la semilla
   resto del      formato de
   archivo        guardado

Y sin embargo es la CARPETA la que decide qué se carga. Un mundo cuyo .fwl2 anuncia MiPartida, colocado en una carpeta tickserv/, se carga sin protestar por un servidor lanzado con -world tickserv — es exactamente el caso de un mundo traído por un jugador y guardado bajo el nombre que el servidor abre. El propio servidor lo dice, y nombra ambos:

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

Es la línea que hay que buscar cuando quieres saber si un servidor ha cargado TU mundo o ha fabricado otro: el primer nombre es el de tu mundo, el segundo el que el servidor ha pedido. El contador save number sube con cada guardado — útil para comprobar que un mundo sigue vivo.

Lo que no hemos medido

La RAM y la CPU de un servidor 1.0 con jugadores encima: haría falta jugadores reales, y no quisimos publicar una estimación haciéndola pasar por una medición. Como el Deep North solo aparece en terreno inexplorado, la cuestión no se planteará de verdad hasta pasadas algunas sesiones de exploración.

El comportamiento de la conversión con mods tampoco se ha probado — Iron Gate escribe explícitamente que el nuevo sistema de guardado no lo ha sido.

Estas mediciones provienen de nuestra propia gestión de servidores de Valheim. Si prefieres no ocuparte de nada de esto: ver Valheim.