Guias / Solução de problemas

Project Zomboid: como corrigir “O Arquivo Não Corresponde ao do Servidor”

É a forma mais frustrante de encerrar uma sessão antes de ela começar: todo mundo está na chamada do Discord, alguém clica em Entrar, e o Project Zomboid o devolve direto para fora com a mensagem de que um arquivo supostamente não corresponde ao do servidor. Nada está quebrado: o servidor está fazendo exatamente o que foi configurado para fazer. Este guia explica o que a verificação compara de fato, por que ela dispara, como corrigir cada causa do jeito certo e quando faz sentido desligá-la com DoLuaChecksum.

O que o erro significa de fato

Quando um cliente se conecta, o servidor do Project Zomboid compara o checksum dos arquivos Lua e de script que o cliente carregou com o dele. Se um único arquivo for diferente, a conexão é recusada e o jogador vê uma mensagem citando esse arquivo: “o arquivo não corresponde ao do servidor”, ou um dos parentes próximos dele, como “o arquivo não existe no cliente” e “Checksums de Lua/script não correspondem”.

A verificação é controlada pela configuração do servidor DoLuaChecksum, que está ativada por padrão. Seu papel é garantir que todos na sessão rodem o mesmo código: arquivos de jogo idênticos e mods idênticos. Isso importa porque o Project Zomboid roda grande parte da lógica em Lua dos dois lados, então um cliente com arquivos diferentes não vê algo levemente diferente: ele dessincroniza, gera erros e pode corromper o que grava de volta no mundo.

Duas coisas decorrem disso, e elas economizam muito tempo perdido:

• O arquivo citado raramente é o problema. É apenas a primeira diferença encontrada pela comparação. Caçar esse arquivo específico não leva a lugar nenhum; veja por que se os dois lados têm arquivos diferentes.
• É um sintoma, não uma falha. Algo de um lado está numa versão diferente. Encontre qual lado saiu do rumo e o erro some sozinho.

Causa 1: o cliente e o servidor estão em builds diferentes

Esta é a causa na esmagadora maioria dos casos. O Steam atualiza os clientes dos jogadores automaticamente, geralmente no momento em que um patch é lançado. Um servidor não: ele continua rodando a versão com que foi implantado. No dia em que a The Indie Stone publica uma nova build, todos os jogadores já estão nela até o fim da tarde e o servidor continua na da semana passada, então os checksums deixam de bater e ninguém consegue entrar.

Há duas formas de fechar a lacuna, e você só precisa de uma delas.

Avance o servidor (recomendado)

Em um servidor de Project Zomboid hospedado conosco, abra a aba Versão do Jogo no painel. Ela mostra a versão em que o servidor está e, quando um patch estável mais novo é publicado, oferece uma atualização com um clique. Uma atualização de patch mantém o mesmo plano, então seu mundo, seu servertest.ini e suas configurações sobrevivem a ela: só os arquivos do jogo são substituídos.

Na mesma aba você pode ativar “sempre executar a versão mais recente”. O servidor passa a seguir os novos lançamentos estáveis por conta própria e nunca mais fica para trás em relação aos seus jogadores. Essa é a configuração a usar se você prefere não pensar nisso de jeito nenhum, e o motivo pelo qual este erro é, em grande parte, um problema resolvido para os nossos clientes. Vale conhecer o custo: uma atualização automática pode chegar enquanto um mod de que você depende ainda não foi atualizado, então comunidades com muitos mods às vezes preferem atualizar manualmente depois de conferir a lista de mods.

Ou volte o cliente

Às vezes você quer deliberadamente que o servidor fique onde está: um mundo de longa duração, uma lista de mods fixada em uma build específica. Nesse caso, o jogador fixa o próprio cliente. No Steam, clique com o botão direito em Project Zomboid, abra Propriedades → Versões de jogo e betas e selecione a versão que corresponde ao servidor: legacy41 para um servidor Build 41, a versão pública padrão da Build 42 estável atual, ou um patch anterior específico, quando o Steam ainda o lista. O cliente baixa essa build e os checksums voltam a se alinhar.

Vale dizer com clareza, porque as pessoas perdem horas com isso: um cliente Build 42 não consegue entrar em um servidor Build 41, e nenhuma configuração de nenhum dos lados muda isso. As duas builds estão distantes o bastante para serem, no multijogador, jogos efetivamente diferentes. Se o seu grupo está dividido, escolha uma build e faça todos migrarem para ela. Nossos planos cobrem as duas: veja os requisitos do servidor para comparar.

Causa 2: mods da Oficina fora de sincronia

A segunda causa são os mods, e ela se comporta exatamente do mesmo jeito: um item da Oficina atualizado de um lado e não do outro. Os autores de mods publicam no próprio cronograma, o Steam envia a atualização para os jogadores inscritos imediatamente, e um servidor em execução mantém a cópia que baixou na inicialização. Um jogador que não terminou de baixar, ou um servidor que não reiniciou desde a atualização, basta para disparar a divergência.

• Reinicie o servidor depois de uma leva de atualizações da Oficina. Os mods são baixados durante a inicialização, então uma reinicialização é o que traz as versões atuais. Fazer isso antes de uma sessão, e não durante, evita o problema inteiro.
• Peça que o jogador afetado cancele e refaça a assinatura. Cancele a assinatura dos mods do servidor, dê ao Steam um minuto para remover os arquivos de fato, depois assine de novo e espere o download terminar antes de entrar. Um mod baixado pela metade produz exatamente este erro.
• Verifique se o mod está listado corretamente no servidor. Cada mod precisa do seu ID numérico da Oficina em WorkshopItems e do seu Mod ID em texto em Mods. Nosso guia de mods da Oficina Steam cobre esse par em detalhes: o Gerenciador de Mods do painel escreve os dois para você.
• Desconfie primeiro da adição mais recente. Se o erro começou logo depois que um mod foi adicionado, remova-o, reinicie e veja se consegue entrar. Alguns itens da Oficina trazem arquivos que nunca chegam ao cliente de forma limpa.

Causa 3: arquivos do cliente corrompidos ou atualizados pela metade

Menos comum, mas fácil de descartar. Se um jogador específico recebe o erro enquanto todos os outros na mesma build entram sem problema, a instalação local dele é a diferente. Peça que ele abra o Steam, clique com o botão direito em Project Zomboid e use Propriedades → Arquivos instalados → Verificar integridade dos arquivos do jogo. O Steam baixa de novo tudo o que não corresponde, inclusive um arquivo Lua deixado por uma atualização interrompida. Se a verificação sozinha não resolver, apagar a pasta media/lua dentro do diretório do jogo e verificar de novo força um novo download limpo exatamente dos arquivos que o checksum cobre.

Causa 4: o falso positivo do Linux

Existe uma peculiaridade antiga em que um Servidor dedicado Linux pode relatar divergência mesmo quando os arquivos do cliente e do servidor de fato concordam. Servidores dedicados, inclusive os nossos, rodam em Linux, então vale saber que isso existe. Não é o caso comum, e você só deve concluir que caiu nisso depois das verificações acima: mesma build dos dois lados, mods sincronizados de novo, arquivos do cliente verificados, e o erro continua disparando.

Esta é a situação em que desligar a verificação é a escolha certa, e não um atalho, porque não há mais nada a corrigir: os arquivos batem e a comparação é que está errada.

O último recurso: desativar DoLuaChecksum

Definir DoLuaChecksum=false desativa a comparação, então o servidor para de recusar clientes por diferenças de arquivo. É o paliativo que você vai encontrar citado em todo lugar, e ele funciona.

Em um servidor hospedado conosco você não precisa editar nada à mão: abra a aba Configurações do Servidor e desative Verificação de arquivos Lua em Acesso e Administração. O painel para o servidor, grava a configuração e o reinicia: o Project Zomboid reescreve a própria configuração ao desligar, e por isso a mudança precisa ser aplicada desse jeito. Hospedagem própria? A linha fica em servertest.ini:

DoLuaChecksum=false

Antes de fazer isso, entenda o que você está abrindo mão. A verificação é o que mantém todas as sessões com código idêntico. Com ela desativada:

• Divergências reais passam. Em vez de uma expulsão limpa na porta, você tem dessincronizações, itens se comportando de forma diferente para jogadores diferentes e travamentos do cliente no meio da sessão: muito mais difícil de diagnosticar do que o erro que você acabou de silenciar.
• Arquivos de cliente modificados não são mais detectados. A verificação também é o que percebe um jogador rodando Lua alterado. Em um servidor público, isso importa.
• Ela não compensa diferenças reais de versão. Desativar a verificação em um servidor muito desatualizado não faz um servidor antigo funcionar com um cliente novo: só troca uma mensagem de erro clara por um comportamento imprevisível. Entre a Build 41 e a Build 42, isso não ajuda em nada.

A recomendação honesta: use para o falso positivo do Linux, ou como desbloqueio temporário para o seu grupo jogar hoje enquanto você resolve a divergência real, e depois ative de novo. É uma ferramenta válida, só não é a primeira a pegar.

Como evitar que isso aconteça de novo

• Deixe o servidor acompanhar o jogo. Ative “sempre executar a versão mais recente” na aba Versão do Jogo, e a causa mais comum deste erro deixa de existir.
• Reinicie antes das sessões, não durante elas. Uma reinicialização é o que traz as atualizações dos mods da Oficina. Agendá-la antes do horário de jogo do seu grupo evita que a divergência de mods atrapalhe a sua noite.
• Acerte a lista de mods. Quanto mais mods, mais cronogramas independentes de atualização você fica exposto. Comunidades que atualizam mods de forma deliberada, em lotes, sentem isso muito menos do que as que adicionam mods o tempo todo.
• Escolha uma build com o grupo. Decida com o grupo entre Build 42 ou Build 41 e garanta que todo jogador esteja no branch Steam correspondente.

Um servidor que se mantém alinhado sozinho

Todo servidor de Project Zomboid implantado na Flux vem com as ferramentas em que este guia se apoia: um aba Versão do Jogo para atualizações de patch com um clique e rastreamento automático da versão mais recente, um editor de Configurações do Servidor com a verificação de Lua exposta como um botão simples, um Gerenciador de Mods que resolve IDs da Oficina e de Mod para você, além de RCON, console, navegador de arquivos e backups. A implantação leva cerca de 30 segundos, com recursos dedicados e proteção DDoS em uma rede de nós em 50+ países. Veja os seção de preços para os planos atuais, ou a guia de configuração se o seu servidor ainda não estiver no ar.

FAQ

O que significa “o arquivo não corresponde ao do servidor”?

O servidor comparou os arquivos Lua e de script que o seu cliente carregou com os dele, encontrou uma diferença e recusou a conexão. O arquivo citado é apenas a primeira diferença encontrada, não a causa.

Como corrigir?

Coloque os dois lados na mesma build: atualize o servidor pela aba Versão do Jogo (ou ative as atualizações automáticas), ou fixe o cliente na build do servidor no Steam em Versões de jogo e betas. Se as builds já forem iguais, sincronize de novo os mods da Oficina e verifique os arquivos do jogo do cliente.

O que é DoLuaChecksum?

A configuração do servidor, ativada por padrão, que faz essa verificação. Defini-la como false a desativa. Na Flux, é o botão Verificação de arquivos Lua na aba Configurações do Servidor.

É seguro desligar?

É um paliativo, não uma correção. Ela deixa passar arquivos de cliente realmente divergentes ou modificados, trocando uma expulsão limpa por dessincronizações e travamentos. É a resposta certa para o falso positivo do Linux, e um desbloqueio temporário razoável nos outros casos.

Um cliente Build 42 pode entrar em um servidor Build 41?

Não, e nenhuma configuração do servidor muda isso. Todos precisam estar na mesma build: mova o servidor para a Build 42 ou faça os jogadores mudarem para o branch legacy41 no Steam.

Implante um servidor de Project Zomboid que se atualiza sozinho →