Guías / Solución de problemas

Project Zomboid: cómo solucionar «File Does Not Match the One on the Server»

Es la forma más frustrante de acabar una sesión antes de que empiece: todos están en la llamada de Discord, alguien pulsa Unirse y Project Zomboid lo echa directamente con un archivo que supuestamente no coincide con el del servidor. Nada está roto: el servidor hace exactamente lo que se le indicó. Esta guía explica qué compara realmente la comprobación, por qué salta, cómo arreglar cada causa como es debido y cuándo es razonable desactivarla con DoLuaChecksum.

Qué significa realmente el error

Cuando un cliente se conecta, el servidor de Project Zomboid compara los checksum de los archivos Lua y de script que el cliente ha cargado con los suyos. Si un solo archivo difiere, la conexión se rechaza y el jugador ve un mensaje que nombra ese archivo: «file does not match the one on the server», o uno de sus parientes cercanos como «file doesn't exist on the client» y «Lua/script checksums do not match».

La comprobación se controla con el ajuste del servidor DoLuaChecksum, que está activado por defecto. Su función es garantizar que todos los de la sesión ejecutan el mismo código: archivos de juego idénticos y mods idénticos. Importa porque Project Zomboid ejecuta gran parte de su lógica en Lua en ambos lados, así que un cliente con archivos distintos no ve simplemente algo ligeramente diferente: se desincroniza, lanza errores y puede corromper lo que escribe de vuelta en el mundo.

De ahí se derivan dos cosas que ahorran mucho tiempo perdido:

• El archivo que nombra rara vez es el problema. Es solo la primera diferencia que encontró la comparación. Perseguir ese archivo concreto no lleva a ninguna parte; mira por qué los dos lados tienen archivos distintos.
• Es un síntoma, no un fallo. Algo de uno de los lados es de otra versión. Encuentra qué lado se ha desfasado y el error desaparece solo.

Causa 1: el cliente y el servidor están en builds distintas

Esta es la causa en la gran mayoría de los casos. Steam actualiza los clientes de los jugadores automáticamente, normalmente en cuanto sale un parche. Un servidor no: sigue ejecutando la versión con la que se desplegó. El día que The Indie Stone publica una build nueva, todos los jugadores la tienen por la tarde y el servidor sigue en la de la semana pasada, así que los checksums dejan de coincidir y nadie puede unirse.

Hay dos maneras de cerrar la brecha, y solo necesitas una de ellas.

Mueve el servidor hacia delante (recomendado)

En un servidor de Project Zomboid alojado con nosotros, abre la pestaña Versión del juego del panel. Muestra la versión en la que está el servidor y, cuando se ha publicado un parche estable más nuevo, ofrece una actualización con un clic. Una actualización de parche mantiene el mismo plan, así que tu mundo, tu servertest.ini y tus ajustes la sobreviven: solo se reemplazan los archivos del juego.

En la misma pestaña puedes activar «ejecutar siempre la última versión». Entonces el servidor sigue por sí solo las nuevas versiones estables y nunca vuelve a quedarse por detrás de tus jugadores. Es el ajuste que debes usar si prefieres no pensar en esto en absoluto, y la razón por la que este error es en gran medida un problema resuelto para nuestros clientes. Conviene conocer la contrapartida: una actualización automática puede llegar cuando un mod del que dependes aún no se ha actualizado, así que las comunidades con muchos mods a veces prefieren actualizar a mano tras revisar su lista de mods.

O devuelve el cliente a una versión anterior

A veces quieres que el servidor se quede donde está a propósito: un mundo de larga duración, una lista de mods fijada a una build concreta. En ese caso es el jugador quien fija su cliente. En Steam, haz clic derecho en Project Zomboid, abre Propiedades → Versiones y betas del juego y selecciona la versión que coincide con el servidor: legacy41 para un servidor de Build 41, la versión pública por defecto para la Build 42 estable actual, o un parche anterior concreto cuando Steam todavía lo lista. El cliente descarga esa build y los checksums vuelven a coincidir.

Conviene decirlo claramente, porque la gente pierde horas con esto: un cliente de Build 42 no puede unirse a un servidor de Build 41, y ningún ajuste en ninguno de los lados lo cambia. Las dos builds están tan separadas que en multijugador son prácticamente juegos distintos. Si tu grupo está dividido, elegid una build y que todos se pasen a ella. Nuestros planes cubren ambas; consulta los requisitos del servidor para ver cómo se comparan.

Causa 2: mods de Workshop desincronizados

La segunda causa son los mods y se comporta exactamente igual: un elemento de Workshop actualizado en un lado y no en el otro. Los autores de mods publican según su propio calendario, Steam envía la actualización a los jugadores suscritos de inmediato, y un servidor en marcha conserva la copia que descargó al arrancar. Basta con un jugador que no haya terminado de descargar, o con un servidor que no se haya reiniciado desde la actualización, para provocar la discrepancia.

• Reinicia el servidor tras una oleada de actualizaciones de Workshop. Los mods se descargan durante el arranque, así que un reinicio es lo que trae las versiones actuales. Hacerlo antes de una sesión y no durante ella evita todo el problema.
• Pide al jugador afectado que se desuscriba y se vuelva a suscribir. Desuscríbete de los mods del servidor, dale a Steam un minuto para eliminar realmente los archivos, vuelve a suscribirte y espera a que termine la descarga antes de unirte. Un mod a medio descargar produce exactamente este error.
• Comprueba que el mod esté listado correctamente en el servidor. Cada mod necesita su ID numérico de Workshop en WorkshopItems y su ID de mod en texto en Mods. Nuestra Guía de mods de Steam Workshop cubre ese par en detalle; el gestor de mods del panel escribe ambos por ti.
• Sospecha primero de la última incorporación. Si el error empezó justo después de añadir un mod, quítalo, reinicia y comprueba si ya puedes unirte. Algunos elementos de Workshop incluyen archivos que nunca llegan limpios al cliente.

Causa 3: archivos del cliente dañados o a medio actualizar

Menos común, pero fácil de descartar. Si un jugador concreto recibe el error mientras todos los demás de la misma build se unen sin problema, su instalación local es la que desentona. Pídele que abra Steam, haga clic derecho en Project Zomboid y use Propiedades → Archivos instalados → Verificar la integridad de los archivos del juego. Steam vuelve a descargar todo lo que no coincide, incluido un archivo Lua que dejó una actualización interrumpida. Si la verificación sola no basta, borrar la carpeta media/lua dentro del directorio del juego y verificar de nuevo fuerza una descarga limpia de exactamente los archivos que cubre el checksum.

Causa 4: el falso positivo de Linux

Hay una peculiaridad de larga data por la que un Servidor dedicado en Linux puede informar de una discrepancia aunque los archivos del cliente y del servidor coincidan realmente. Los servidores dedicados, los nuestros incluidos, se ejecutan en Linux, así que conviene saber que esto existe. No es el caso común, y solo debes concluir que lo has encontrado tras las comprobaciones anteriores: misma build en ambos lados, mods vueltos a sincronizar, archivos del cliente verificados y el error sigue saltando.

Esta es la situación en la que desactivar la comprobación es la decisión correcta y no un atajo, porque ya no queda nada que arreglar: los archivos coinciden y la comparación es errónea.

El último recurso: desactivar DoLuaChecksum

Poner DoLuaChecksum=false desactiva la comparación, así que el servidor deja de rechazar clientes por diferencias de archivos. Es el truco que encontrarás citado en todas partes, y funciona.

En un servidor alojado con nosotros no necesitas editar nada a mano: abre la pestaña Ajustes del servidor y desactiva Comprobación de archivos Lua en Acceso y administración. El panel detiene el servidor, escribe el ajuste y lo reinicia; Project Zomboid reescribe su propia configuración al apagarse, y por eso el cambio hay que aplicarlo así. ¿Lo alojas tú mismo? La línea está en servertest.ini:

DoLuaChecksum=false

Antes de hacerlo, entiende a qué renuncias. La comprobación es lo que mantiene todas las sesiones con código idéntico. Con ella desactivada:

• Las discrepancias reales pasan. En lugar de una expulsión limpia en la puerta, obtienes desincronizaciones, objetos que se comportan de forma distinta para jugadores distintos y cierres inesperados del cliente a mitad de sesión, mucho más difíciles de diagnosticar que el error que acabas de silenciar.
• Los archivos de cliente modificados dejan de detectarse. La comprobación también es lo que detecta a un jugador que ejecuta Lua alterado. En un servidor público eso importa.
• No salva diferencias reales de versión. Desactivar la comprobación en un servidor muy desactualizado no hace que un servidor antiguo funcione con un cliente nuevo: solo cambia el fallo de un mensaje claro a un comportamiento impredecible. Entre Build 41 y Build 42 no ayuda en absoluto.

La recomendación honesta: úsalo para el falso positivo de Linux, o como desbloqueo temporal para que tu grupo pueda jugar esta noche mientras resuelves la discrepancia real, y luego vuelve a activarlo. Es una herramienta válida, pero no la primera a la que recurrir.

Cómo evitar que vuelva a ocurrir

• Deja que el servidor siga al juego. Activa «ejecutar siempre la última versión» en la pestaña Versión del juego y la causa más común de este error deja de existir.
• Reinicia antes de las sesiones, no durante ellas. Un reinicio es lo que recoge las actualizaciones de mods de Workshop. Programarlo antes de la hora de juego de tu grupo mantiene la deriva de mods fuera de tu noche.
• Cierra la lista de mods. Cuantos más mods, más calendarios de actualización independientes tienes encima. Las comunidades que actualizan los mods de forma deliberada y por lotes ven esto mucho menos que las que añaden mods continuamente.
• Acordad una sola build. Decidid en grupo si usáis Build 42 o Build 41 y aseguraos de que cada jugador está en la rama de Steam correspondiente.

Un servidor que se mantiene alineado solo

Todos los servidores de Project Zomboid desplegados en Flux incluyen las herramientas en las que se apoya esta guía: un pestaña Versión del juego para actualizaciones de parches con un clic y seguimiento automático de la última versión, un editor de Ajustes del servidor con la comprobación de archivos Lua expuesta como un simple interruptor, un Gestor de mods que resuelve por ti los ID de Workshop y de mod, además de RCON, una consola, un explorador de archivos y copias de seguridad. El despliegue tarda unos 30 segundos, con recursos dedicados y protección DDoS en una red de nodos en más de 50 países. Consulta la sección de precios para ver los planes actuales, o la guía de configuración si tu servidor aún no está en marcha.

Preguntas frecuentes

¿Qué significa «file does not match the one on the server»?

El servidor comparó los archivos Lua y de script que cargó tu cliente con los suyos y encontró una diferencia, así que rechazó la conexión. El archivo que nombra es solo la primera diferencia encontrada, no la causa.

¿Cómo lo soluciono?

Pon ambos lados en la misma build: actualiza el servidor desde la pestaña Versión del juego (o activa las actualizaciones automáticas), o fija el cliente a la build del servidor en Steam, en Versiones y betas del juego. Si las builds ya coinciden, vuelve a sincronizar los mods de Workshop y verifica los archivos de juego del cliente.

¿Qué es DoLuaChecksum?

El ajuste del servidor, activado por defecto, que realiza esta comprobación. Ponerlo en false la desactiva. En Flux es el interruptor Comprobación de archivos Lua de la pestaña Ajustes del servidor.

¿Es seguro desactivarlo?

Es un parche, no una solución. Deja pasar archivos de cliente realmente distintos o modificados, cambiando una expulsión limpia por desincronizaciones y cierres inesperados. Es la respuesta correcta para el falso positivo de Linux y un desbloqueo temporal razonable en otros casos.

¿Puede un cliente de Build 42 unirse a un servidor de Build 41?

No, y ningún ajuste del servidor lo cambia. Todos tienen que estar en la misma build: pasad el servidor a Build 42, o haced que los jugadores cambien a la rama legacy41 en Steam.

Despliega un servidor de Project Zomboid que se actualiza solo →