Servidores y mods de Project Zomboid tras la Build 42

Montar un servidor de Project Zomboid es la parte fácil: un comando de SteamCMD, un script de arranque y dos puertos UDP. Lo que se te come el fin de semana es que Project Zomboid ahora ejecuta tres versiones incompatibles de sí mismo bajo una única entrada de Steam, y tu servidor, tus jugadores y cada mod de tu lista tienen que ponerse de acuerdo sobre cuál están usando. Cuando no coinciden, el juego rara vez lo dice en voz alta.

La Build 42.20 llegó a la rama estable pública el 29 de julio de 2026, diecinueve meses después de que la Build 42 se abriera como beta inestable el 17 de diciembre de 2024. El multijugador en línea no volvió a la Build 42 hasta la 42.13.0, así que la mayoría de las comunidades asentadas pasaron todo ese periodo en la Build 41. Ahora se enfrentan a una ruptura de partidas guardadas, a una ruptura del formato de mods y a una decisión de rama que hay que tomar una sola vez, para todos, antes de que nadie toque un archivo de configuración. Esta guía trata sobre esa decisión y sobre los ajustes que deciden si el servidor sobrevive a ella.

Elige la rama antes de elegir el hardware

La lista Versiones del juego y betas (Game Versions & Betas) de Steam, tanto para el juego como para la herramienta del servidor dedicado, ofrece ahora legacy41 (Build 41.78.19), 42.19 y la versión pública por defecto, que es la 42.20. Las partidas guardadas no cruzan esa lista. Las partidas de la Build 41 no se abrirán en la Build 42 y, como la 42.20 añadió contenido de mapa, ni siquiera las partidas de la Unstable 42.19 se abrirán en la 42.20. The Indie Stone publicó ambos canales de reserva antes del lanzamiento y avisó a los dueños de servidores de Build 41 de que podían cambiarse con antelación para minimizar el trastorno.

La herramienta del servidor dedicado tiene la misma lista de ramas que el juego: 42.19, legacy41 y la versión pública por defecto, la 42.20.

Si instalas mediante SteamCMD, la rama es un argumento:

app_update 380870 -beta legacy41 validate

Quita el flag -beta y obtienes la 42.20. Elijas la que elijas, cada jugador tiene que elegir la misma en su propia copia del juego: haz clic derecho en Project Zomboid en la biblioteca de Steam, elige Propiedades, abre Versiones del juego y betas (Game Versions & Betas) y selecciona el canal correspondiente. Esto no es una cortesía opcional. DoLuaChecksum=true expulsa a cualquier cliente cuyos archivos de juego no coincidan con los del servidor, así que un jugador que se quede en la rama por defecto no puede entrar en tu servidor legacy41, y el mensaje de expulsión no se lo va a explicar.

Hay una razón honesta para quedarse en la 41 y otra para dar el salto. Quedarse es donde tu mundo actual y tu lista de mods actual ya funcionan, hoy, sin esfuerzo por parte de nadie. Moverse es donde viven el mapa reelaborado de Knox Country, los sótanos, la cría de animales y la artesanía renovada, y es la única rama que se va a parchear: el estudio ha comprometido el resto de 2026 a una Build 42 Support Update que cubre optimización, soporte adicional para mods y el pulido que no llegó al corte de la estable, además de trabajo continuo en el multijugador. Quedarse en la 41 significa elegir dejar de recibir correcciones.

Tu primer arranque fallará por memoria, no por zombis

El servidor dedicado es la app de Steam 380870, disponible como herramienta en tu biblioteca o a través de SteamCMD con login anonymous. Instálalo y luego no lo lances desde Steam: si lo haces, verifica los archivos del servidor antes de volver a intentarlo. Ejecuta StartServer64.bat en Windows o start-server.sh en Linux directamente.

StartServer64.bat viene con -Xms16g -Xmx16g. En cualquier máquina que no tenga 16 GB de sobra, eso es un cierre inmediato con un error de memoria, y corta el primer arranque mucho antes de la generación del mundo. Abre el archivo, ajusta ambos valores a lo que realmente tiene la máquina y deja el resto de la línea en paz: el flag -XX:+UseZGC que hay ahí es deliberado. Java 21 recomienda oficialmente combinar ZGC con -XX:+AlwaysPreTouch si quieres otro parámetro que tocar.

En Linux, ejecuta el servidor como usuario sin privilegios dentro de tmux para que una sesión SSH caída no se lleve el mundo por delante; tmux a devuelve la consola. Una unidad de systemd también funciona, aunque los desarrolladores la desaconsejan explícitamente. Si vas por ahí, apunta la unidad a un socket de control FIFO para que systemctl stop pueda enviar save, esperar y luego quit en lugar de matar el proceso a mitad de una escritura.

La primera ejecución pide por consola una contraseña de administrador y crea con ella la cuenta de admin. Cuando estás automatizando todo el proceso —contenedores, systemd, una máquina nueva cada vez—, -adminusername y -adminpassword configuran esa cuenta de antemano y se saltan la pregunta.

Los puertos son 16261/UDP y 16262/UDP. Una segunda instancia en la misma máquina necesita su propio par, su propio usuario del sistema y su propio -cachedir, o los dos servidores se pelearán por una única carpeta Zomboid.

Hay un fallo de migración que conviene conocer de antemano. Si alguna vez ha corrido un servidor de Build 41 en esta máquina, una instalación de Build 42 puede morir con Assertion Failed: Illegal termination of worker thread. La causa son restos de estado anterior. Comprueba que steam_appid.txt, en el directorio del servidor, contenga exactamente una línea con 108600. Después copia toda la carpeta Zomboid de tu perfil de usuario a un sitio seguro, borra la original, arranca Build 42 una vez para que reconstruya la carpeta desde cero, ciérralo y vuelve a copiar dentro tus archivos .ini, .lua y Saves. La carpeta que crea Build 42 está vacía: el mundo solo vuelve si lo devuelves tú.

Cuatro archivos sostienen el servidor, y solo uno es el .ini

Todo lo configurable vive en %USERPROFILE%\Zomboid\Server en Windows o en ~/Zomboid/Server en Linux, en cuatro archivos que llevan el nombre del servidor: servertest.ini, servertest_SandboxVars.lua, servertest_spawnpoints.lua y servertest_spawnregions.lua. El .ini guarda las reglas ajenas a la jugabilidad: puertos, jugadores, PvP, casas seguras, mods. El archivo SandboxVars guarda el apocalipsis en sí: población zombi, reaparición y migración, multiplicadores de botín por categoría y cuántos días pasan antes de que el agua y la electricidad se corten para siempre. Spawnpoints y spawnregions deciden dónde aparecen los supervivientes nuevos, que es como abres o cierras Rosewood o Louisville a los recién llegados sin tocar el mapa.

-servername MyWorld renombra los cuatro archivos y la carpeta de guardado bajo Saves/Multiplayer. Así es como se ejecutan dos mundos desde una sola instalación, y como se retira un mundo sin borrarlo.

Puedes editar el .ini con el servidor en marcha. Guarda el archivo y ejecuta reloadoptions en la consola para enviar el cambio a los clientes. showoptions imprime lo que el servidor cree de verdad, que no siempre es lo que creías haber escrito. changeoption OptionName "value" aplica un único cambio en caliente; para cualquier cosa que quieras conservar, edita el archivo.

Dos valores de ese archivo merecen estar en una copia de seguridad fuera del servidor: ResetID y ServerPlayerID. Son la forma que tiene el servidor de decidir que un personaje que se conecta pertenece a este mundo y, si cambian, todos los jugadores se ven obligados a crear uno nuevo. Y tampoco cuentes con la salida de emergencia integrada: -Dsoftreset no funciona a fecha de la 42.20.

Activa ya las opciones de copia de seguridad: BackupsOnStart=true, BackupsOnVersionChange=true, BackupsCount=5 y un BackupsPeriod distinto de cero te cuestan disco y nada más. BackupsOnVersionChange es la que se gana el sueldo, porque salta justo en el momento en que Steam le cambia la build a un mundo en marcha.

Las reglas solo existen si están en el .ini

Un mensaje de reglas en tu Discord es una declaración de intenciones. El .ini es lo que las hace cumplir, y ambos deberían coincidir.

Empieza por quién entra. Open=true deja que cualquiera se conecte y cree una cuenta; Open=false convierte el servidor en una lista blanca y las cuentas las creas a mano con adduser "name" "password". Password= añade un secreto compartido encima de cualquiera de las dos. DropOffWhiteListAfterDeath=true es lo que hace que un servidor con lista blanca sea de muerte permanente de verdad: la cuenta se elimina al morir en lugar de reaparecer como un superviviente nuevo.

MaxPlayers viene por defecto en 32 y acepta hasta 100. Ese margen es una trampa: pasado 32, el número más grande en el navegador de servidores te cuesta streaming del mapa y te compra desincronización. Los administradores no cuentan para el límite.

El PvP son dos ajustes, no uno. PVP=true lo habilita siquiera. SafetySystem=true significa entonces que a un jugador solo se le puede hacer daño cuando al menos uno de los dos ha activado el modo PvP, con SafetyToggleTimer y SafetyCooldownTimer impidiendo que nadie entre y salga a mitad de golpe. PVPMeleeDamageModifier y PVPFirearmDamageModifier vienen por defecto en 30 y 50 sobre una escala que va de 0 a 500, así que el daño entre jugadores se ajusta con independencia de todo lo demás: bajarlos convierte las peleas en palizas en vez de en ejecuciones.

El bloque de casas seguras es donde vive de verdad el contrato social de un servidor.

Este último merece una segunda mirada, porque invierte la función: una base reclamada queda sellada mientras su dueño está fuera y es un edificio corriente cuando está en casa.

La Build 42 añadió encima una guerra de facciones. Faction=true permite las facciones, condicionadas por FactionDaySurvivedToCreate y FactionPlayersRequiredForTag, mientras que War, WarStartDelay (600 segundos), WarDuration (3600 segundos) y WarSafehouseHitPoints (3) convierten un conflicto declarado en un evento cronometrado con un límite duro de daño a las casas seguras, en lugar de en un estado de asedio permanente.

La moderación también es configuración, y casi toda es inútil de forma retroactiva: actívala antes de la discusión, no después.

Cinco niveles de acceso, y dos de ellos aún pueden usar la radio

Ascender a alguien es un solo comando: /setaccesslevel "PlayerName" "moderator" en el chat, o lo mismo sin la barra en la consola del servidor. Hay cinco niveles en orden descendente —admin, moderator, overseer, gm, observer— y none los revoca.

El juego no publica una matriz de permisos para esos cinco, así que lee en su lugar los sitios donde los trata de forma distinta. La radio es el más ruidoso. DisableRadioAdmin y DisableRadioGM vienen por defecto en true, mientras que DisableRadioModerator y DisableRadioOverseer vienen en false. De fábrica, tus administradores (admin) y tus game masters (gm) no pueden transmitir por la radio del juego, y tus moderadores (moderator) y supervisores (overseer) sí: una inversión de la jerarquía que te va a morder la primera vez que un moderador narre un evento que estabas montando en silencio. DisableRadioInvisible=true cierra ese mismo canal para cualquiera que esté usando /invisible.

Para dirigir eventos, las herramientas son /invisible, /noclip, /godmode, /teleportto x,y,z, /createhorde 150 "PlayerName", /chopper y /startstorm. Para hacer cumplir las normas son /kick "name" -r "reason" y /banuser "name" -ip -r "reason", con /banid y /banip cuando necesitas banear un SteamID o una dirección en lugar de una cuenta. /players y /servermsg cubren el día a día.

RCONPort viene por defecto en 27015 y RCONPassword viene vacío. Una contraseña vacía en un puerto accesible es acceso sin autenticar a la consola de tu servidor, lo que significa que cualquiera que lo encuentre puede banear a tus jugadores y cerrar tu mundo. Pon una contraseña fuerte antes de exponer el puerto, y limítalo por firewall a las direcciones que de verdad lo necesitan.

El anticheat son diez reglas separadas —seguridad, velocidad, no-clip, golpes, excepciones de paquetes, permisos, XP, casa segura, jugador y checksum— y cada una puede banear, expulsar, registrar o no hacer nada. La tentación en un servidor con mods es desactivar las diez la primera vez que un mod dispara una. Pon la regla infractora en modo registro, usa el registro para averiguar qué mod lo está provocando y deja las otras nueve en paz.

Una lista de mods de Build 41 no carga nada en Build 42

La Build 42 cambió la forma que tiene un mod en disco. Con la Build 41, un mod era una carpeta que contenía media/, mod.info y poster.png. Con la Build 42, esa carpeta contiene en su lugar un directorio common/ obligatorio —que puede estar vacío— más uno o más directorios de versión con el nombre de la build del juego: 42/, 42.1/, y así sucesivamente, con media/, mod.info y poster.png movidos dentro del directorio de versión.

Los elementos del Workshop se pueden añadir por ID desde este panel, o escribirse directamente en la línea WorkshopItems del .ini.

Un mod solo se reconoce en el juego si tiene al menos una carpeta de versión o una carpeta common/. Un mod de Build 41 sin portar no tiene ninguna de las dos, así que la Build 42 no lo carga, no te avisa y no lo lista.

La carga tiene un orden: primero common/, luego la carpeta de versión más cercana a la build en ejecución, cuyos archivos sobrescriben a los comunes. Los nombres de carpeta ignoran el tercer número —42.1.5 se trata como 42.1, y un 42 a secas como 42.0—, así que no necesitas una carpeta por parche. Un mismo mod puede llevar ambos formatos a la vez, porque la estructura de la Build 42 se sitúa un nivel más abajo que la de la Build 41 y las dos quedan aisladas entre sí. Así es como un elemento bien mantenido de Steam Workshop sirve a legacy41 y a la 42.20 desde una única suscripción.

En el servidor, dos ajustes hacen trabajos distintos y necesitas los dos. WorkshopItems= acepta IDs numéricos de Steam Workshop separados por puntos y coma y le dice al servidor qué descargar. Mods= acepta IDs de carga —el que declara cada mod en su propio mod.info— y le dice al servidor qué activar. Un solo elemento del Workshop puede contener varios mods, que es justamente por lo que las dos listas rara vez tienen la misma longitud. Los mods de mapa necesitan un tercer ajuste, Map=, que nombra la carpeta dentro del media/maps/ de ese mod. Las descargas aterrizan en Steam/steamapps/workshop/content/108600/<workshopID>, que es adonde vas a leer el mod.info que necesitas; y en Build 42 ese archivo está un directorio más adentro de lo que recuerdas, dentro de la carpeta de versión.

Las copias duplicadas de un mismo mod chocan y se sobrescriben de forma impredecible, y acabar con dos es fácil: una suscripción del Workshop que el servidor descarga, más una copia manual dejada en Zomboid/mods/. -modfolders workshop,steam,mods es la palanca. Esas tres son las únicas carpetas de mods que lee el juego; el flag declara cuáles se cargan y en qué orden, y todo lo que dejes fuera queda desactivado.

Ejecuta checkModsNeedUpdate en la consola cuando algo se rompa de la noche a la mañana; escribe en el registro si un mod ha cambiado bajo tus pies, que es la explicación habitual de un servidor que ayer funcionaba. Y añade los mods de uno en uno a un servidor que ya hayas confirmado que arranca limpio, para que una mala incorporación tenga exactamente un sospechoso.

Los modders tienen su propia versión de este problema. La 42.20 convirtió los archivos de traducción language.txt en JSON language.json y restringió getFileWriter a escribir .ini, .cfg, .txt y .log, así que un mod que se portaba bien en la 42.19 no está automáticamente bien en la 42.20. The Indie Stone ha dicho que llegará una extensa guía de modding junto con el lanzamiento de WorldZed, TileZed y su herramienta interna de animación AnimZed, así que el ecosistema debería asentarse. Todavía no se ha asentado.

Hasta que lo haga, haz una cosa antes de pegar un solo ID en WorkshopItems=: abre la carpeta de cada mod y busca un directorio 42/ o uno common/. Todo lo que no tenga ninguno de los dos pertenece a un servidor legacy41, no a este.