Guides / Dépannage

Project Zomboid : comment corriger « le fichier ne correspond pas à celui du serveur »

C'est la manière la plus frustrante de mettre fin à une session avant même qu'elle commence : tout le monde est dans l'appel Discord, quelqu'un clique sur Rejoindre, et Project Zomboid le renvoie aussitôt avec un fichier qui ne correspondrait pas à celui du serveur. Rien n'est cassé : le serveur fait exactement ce qu'on lui a demandé. Ce guide explique ce que compare réellement la vérification, pourquoi elle se déclenche, comment corriger proprement chaque cause, et quand il est raisonnable de la désactiver avec DoLuaChecksum.

Ce que signifie réellement l'erreur

Lorsqu'un client se connecte, le serveur Project Zomboid compare les somme de contrôle des fichiers Lua et de script chargés par le client aux siens. Si un seul fichier diffère, la connexion est refusée et le joueur voit un message qui nomme ce fichier : « le fichier ne correspond pas à celui du serveur », ou l'un de ses proches comme « le fichier n'existe pas sur le client » et « Les sommes de contrôle Lua/script ne correspondent pas ».

La vérification est contrôlée par le réglage serveur DoLuaChecksum, qui est activé par défaut. Son rôle est de garantir que tout le monde dans la session exécute le même code : fichiers de jeu et mods identiques. C'est important, car Project Zomboid exécute une grande partie de sa logique en Lua des deux côtés : un client avec des fichiers différents ne voit pas simplement quelque chose de légèrement différent, il se désynchronise, génère des erreurs et peut corrompre ce qu'il réécrit dans le monde.

Deux conséquences en découlent, et elles font gagner beaucoup de temps :

• Le fichier qu'elle désigne est rarement le problème. C'est simplement la première différence rencontrée par la comparaison. Traquer ce fichier précis ne mène nulle part ; regardez plutôt pourquoi si les deux côtés ont vraiment des fichiers différents.
• C'est un symptôme, pas une panne. Un élément d'un côté est une version différente. Trouvez quel côté a dérivé et l'erreur disparaîtra d'elle-même.

Cause 1 : le client et le serveur ne sont pas sur la même version

C'est la cause dans l'immense majorité des cas. Steam met à jour automatiquement les clients des joueurs, généralement dès qu'un patch sort. Un serveur, lui, ne se met pas à jour : il continue de tourner avec la version avec laquelle il a été déployé. Le jour où The Indie Stone publie une nouvelle version, tous les joueurs l'ont le soir même alors que le serveur est toujours sur celle de la semaine précédente : les sommes de contrôle ne correspondent plus et personne ne peut rejoindre.

Il existe deux façons de combler l'écart, et vous n'en avez besoin que d'une.

Faites avancer le serveur (recommandé)

Sur un serveur Project Zomboid hébergé chez nous, ouvrez l'onglet Version du jeu du tableau de bord. Il indique la version sur laquelle se trouve le serveur et, lorsqu'un patch stable plus récent est publié, propose une mise à jour en un clic. Une mise à jour de patch conserve la même offre, donc votre monde, votre servertest.ini et vos réglages survivent à la mise à jour : seuls les fichiers du jeu sont remplacés.

Dans le même onglet, vous pouvez activer « toujours exécuter la dernière version ». Le serveur suit alors seul les nouvelles versions stables et ne prend plus jamais de retard sur vos joueurs. C'est le réglage à utiliser si vous préférez ne pas y penser du tout, et la raison pour laquelle cette erreur est en grande partie résolue pour nos clients. Le compromis mérite d'être connu : une mise à jour automatique peut arriver alors qu'un mod sur lequel vous comptez n'a pas encore été mis à jour ; les communautés très modées préfèrent donc parfois mettre à jour manuellement après avoir vérifié leur liste de mods.

Ou faites revenir le client en arrière

Parfois, vous voulez délibérément que le serveur reste où il est : un monde de longue durée, une liste de mods figée sur une version précise. Dans ce cas, c'est le joueur qui fixe son client. Dans Steam, faites un clic droit sur Project Zomboid, ouvrez Propriétés → Versions et bêtas du jeu et sélectionnez la version qui correspond au serveur : legacy41 pour un serveur Build 41, la version publique par défaut de la version stable actuelle de Build 42, ou un patch plus ancien précis lorsque Steam en propose encore un. Le client télécharge cette version et les sommes de contrôle se réalignent.

À dire clairement, car cela fait perdre des heures : un client Build 42 ne peut pas rejoindre un serveur Build 41, et aucun réglage des deux côtés n'y change rien. Les deux versions sont suffisamment éloignées pour être, en multijoueur, de véritables jeux différents. Si votre groupe est divisé, choisissez une version et faites passer tout le monde dessus. Nos offres couvrent les deux : voir la configuration requise des serveurs pour comparer.

Cause 2 : mods Workshop désynchronisés

La seconde cause concerne les mods, et elle se comporte exactement de la même façon : un élément Workshop mis à jour d'un côté et pas de l'autre. Les auteurs de mods publient selon leur propre calendrier, Steam transmet la mise à jour immédiatement aux joueurs abonnés, et un serveur en marche conserve la copie téléchargée au démarrage. Un seul joueur qui n'a pas fini de télécharger, ou un serveur qui n'a pas redémarré depuis la mise à jour, suffit à provoquer la non-concordance.

• Redémarrez le serveur après une vague de mises à jour Workshop. Les mods sont récupérés au démarrage, donc c'est le redémarrage qui charge les versions actuelles. Le faire avant une session, plutôt que pendant, évite tout le problème.
• Demandez au joueur concerné de se désabonner puis de se réabonner. Désabonnez-vous des mods du serveur, laissez une minute à Steam pour supprimer réellement les fichiers, puis réabonnez-vous et attendez la fin du téléchargement avant de rejoindre. Un mod téléchargé à moitié produit exactement cette erreur.
• Vérifiez que le mod est correctement listé côté serveur. Chaque mod a besoin de son ID Workshop numérique dans WorkshopItems et de son ID de mod textuel dans Mods. Notre Guide des mods Steam Workshop détaille ce couple : le Gestionnaire de mods du tableau de bord écrit les deux pour vous.
• Soupçonnez d'abord le dernier ajout. Si l'erreur est apparue juste après l'ajout d'un mod, retirez-le, redémarrez et vérifiez si la connexion fonctionne. Certains éléments Workshop livrent des fichiers qui n'arrivent jamais proprement au client.

Cause 3 : fichiers client corrompus ou mis à jour à moitié

Moins fréquent, mais facile à écarter. Si un joueur précis reçoit l'erreur alors que les autres joueurs de la même version rejoignent sans problème, son installation locale est la seule à faire exception. Demandez-lui d'ouvrir Steam, de faire un clic droit sur Project Zomboid et d'utiliser Propriétés → Fichiers installés → Vérifier l'intégrité des fichiers du jeu. Steam retélécharge tout ce qui ne correspond pas, y compris un fichier Lua laissé par une mise à jour interrompue. Si la vérification seule ne suffit pas, supprimer le dossier media/lua dans le répertoire du jeu puis refaire la vérification force un nouveau téléchargement propre exactement des fichiers couverts par la somme de contrôle.

Cause 4 : le faux positif Linux

Il existe un défaut ancien : un serveur dédié Linux peut signaler une non-concordance alors que les fichiers du client et du serveur concordent réellement. Les serveurs dédiés, les nôtres compris, tournent sous Linux, il est donc utile de savoir que ce cas existe. Ce n'est pas le cas courant, et vous ne devez conclure que vous êtes tombé dessus qu'après les vérifications ci-dessus : même version des deux côtés, mods resynchronisés, fichiers client vérifiés, et l'erreur se déclenche encore.

C'est le cas où désactiver la vérification est le bon choix et non un raccourci, car il n'y a plus rien à corriger : les fichiers concordent et la comparaison est erronée.

Le dernier recours : désactiver DoLuaChecksum

Régler DoLuaChecksum=false désactive la comparaison, si bien que le serveur cesse de refuser des clients à cause de différences de fichiers. C'est le contournement que vous trouverez partout, et il fonctionne bel et bien.

Sur un serveur hébergé chez nous, vous n'avez rien à modifier à la main : ouvrez l'onglet Paramètres du serveur et désactivez Lua File Check dans la section Accès et administration. Le tableau de bord arrête le serveur, écrit le réglage et le redémarre : Project Zomboid réécrit sa propre configuration à l'arrêt, c'est pourquoi le changement doit être appliqué de cette façon. Vous l'auto-hébergez ? La ligne se trouve dans servertest.ini :

DoLuaChecksum=false

Avant de le faire, comprenez ce que vous abandonnez. Cette vérification garantit que chaque session utilise un code identique. Sans elle :

• Les vraies incohérences passent. Au lieu d'une expulsion propre à l'entrée, vous obtenez des désynchronisations, des objets qui se comportent différemment selon les joueurs et des plantages du client en pleine session : bien plus difficiles à diagnostiquer que l'erreur que vous venez de faire disparaître.
• Les fichiers client modifiés ne sont plus détectés. La vérification est aussi ce qui détecte un joueur qui utilise du Lua modifié. Sur un serveur public, cela compte.
• Cela ne comble pas les vrais écarts de version. Désactiver la vérification sur un serveur très obsolète ne permet pas à un vieux serveur de fonctionner avec un nouveau client : cela remplace simplement un message d'erreur clair par un comportement imprévisible. Entre Build 41 et Build 42, cela n'aide absolument pas.

La recommandation honnête : utilisez-la pour le faux positif Linux, ou comme déblocage temporaire pour que votre groupe puisse jouer ce soir pendant que vous réglez la vraie non-concordance, puis réactivez-la. C'est un outil valable, simplement pas le premier à sortir.

Comment éviter que cela se reproduise

• Laissez le serveur suivre le jeu. Activez « toujours exécuter la dernière version » dans l'onglet Version du jeu, et la cause la plus fréquente de cette erreur disparaît.
• Redémarrez avant les sessions, pas pendant. Un redémarrage permet de récupérer les mises à jour des mods Workshop. Le programmer avant le temps de jeu de votre groupe évite que les mods ne se désynchronisent pendant votre soirée.
• Stabilisez la liste de mods. Plus il y a de mods, plus vous êtes exposé à des calendriers de mise à jour indépendants. Les communautés qui mettent à jour leurs mods délibérément, par lots, rencontrent ce problème bien moins souvent que celles qui en ajoutent en continu.
• Mettez-vous d'accord sur une seule version. Choisissez Build 42 ou Build 41 en groupe et assurez-vous que chaque joueur est sur la branche Steam correspondante.

Un serveur qui reste aligné tout seul

Chaque serveur Project Zomboid déployé sur Flux est livré avec les outils sur lesquels ce guide s'appuie : un Onglet Version du jeu pour les mises à jour de patch en un clic et le suivi automatique de la dernière version, un éditeur Paramètres du serveur où la vérification des fichiers Lua est proposée sous forme d'option simple, un Gestionnaire de mods qui résout pour vous les ID Workshop et les ID de mod, ainsi que RCON, une console, un explorateur de fichiers et des sauvegardes. Le déploiement prend environ 30 secondes, avec des ressources dédiées et une protection DDoS sur un réseau de nœuds dans 50+ pays. Consultez la section des tarifs pour les offres actuelles, ou la guide d'installation si votre serveur n'est pas encore en ligne.

FAQ

Que signifie « le fichier ne correspond pas à celui du serveur » ?

Le serveur a comparé les fichiers Lua et de script chargés par votre client à ses propres fichiers, a trouvé une différence et a donc refusé la connexion. Le fichier désigné n'est que la première différence trouvée, pas la cause.

Comment le corriger ?

Mettez les deux côtés sur la même version : mettez à jour le serveur depuis l'onglet Version du jeu (ou activez les mises à jour automatiques), ou fixez le client sur la version du serveur dans Steam, sous Versions et bêtas du jeu. Si les versions correspondent déjà, resynchronisez les mods Workshop et vérifiez les fichiers de jeu du client.

Qu'est-ce que DoLuaChecksum ?

Le réglage serveur, activé par défaut, qui effectue cette vérification. Le passer à false la désactive. Sur Flux, il s'agit de l'option Lua File Check dans l'onglet Paramètres du serveur.

Est-il sans risque de le désactiver ?

C'est un contournement, pas une solution. Il laisse passer les fichiers client réellement non concordants ou modifiés, en échangeant une expulsion propre contre des désynchronisations et des plantages. C'est la bonne réponse pour le faux positif Linux, et un déblocage temporaire raisonnable dans les autres cas.

Un client Build 42 peut-il rejoindre un serveur Build 41 ?

Non, et aucun réglage serveur ne change cela. Tout le monde doit être sur la même version : passez le serveur sur Build 42, ou demandez aux joueurs de basculer sur la branche legacy41 dans Steam.

Déployez un serveur Project Zomboid qui se met à jour tout seul →