Mods cassés sur un serveur Project Zomboid : les causes
« Mon serveur tournait très bien, j’ai mis à jour, et maintenant les mods ne chargent plus. » C’est devenu la question la plus fréquente sur les serveurs Project Zomboid depuis l’été 2026 — et il y a une raison précise à cela, en plus des causes classiques.
Ce guide traite les cinq causes réelles, dans l’ordre dans lequel il faut les vérifier.
Sur un serveur Project Zomboid HebergTonServ, la console est consultable en direct et les mods se gèrent depuis le panel ou en SFTP, ce qui facilite le diagnostic mod par mod.
Cause n°1 : la 42.20.4 a supprimé loadstring et loadstream
C’est la nouveauté de l’été, et elle explique une vague entière de mods cassés.
Le hotfix 42.20.4 du 26 août 2026 corrige des failles de sécurité, et dans le cadre de ce correctif, les méthodes Lua loadstring et loadstream ont été retirées du jeu. Tout mod qui les utilisait — notamment pour exécuter du code envoyé par le serveur — cesse de fonctionner.
Comment le reconnaître
- Le mod fonctionnait avant fin août 2026 et plus après.
- Les logs mentionnent une méthode
nilou une erreur Lua au chargement du mod. - Le mod n’a pas reçu de mise à jour Workshop depuis août.
Que faire
- Vérifiez la date de dernière mise à jour du mod sur le Workshop. Un mod maintenu a été corrigé dans les jours qui ont suivi le hotfix.
- Mettez à jour le mod côté serveur (et côté clients).
- Si le mod est abandonné, il n’y a pas de contournement côté serveur : le remplacer est la seule option. Notre sélection à jour : meilleurs mods pour un serveur Project Zomboid Build 42.
Ne revenez pas en arrière sur la version du serveur pour faire fonctionner un mod. La 42.20.4 est un correctif de sécurité : rester sur une build antérieure expose votre serveur, et les clients à jour ne pourront de toute façon plus s’y connecter.
Cause n°2 : Mods= et WorkshopItems= désynchronisés
C’est l’erreur de configuration la plus classique, et elle donne exactement le même symptôme : des mods qui ne se chargent pas alors que « tout est bien renseigné ».
Deux clés distinctes de servertest.ini, deux valeurs différentes :
| Clé | Contenu | Où trouver la valeur |
|---|---|---|
WorkshopItems= | Les ID Workshop, numériques, séparés par des points-virgules | Dans l’URL de la page Workshop du mod |
Mods= | Les ID de mod, textuels | Dans info.txt du mod, champ id= |
WorkshopItems=514427485;513111049
Mods=Brita_2;Brita;ModManagerLes pièges habituels :
- un ID Workshop mis dans
Mods=, ou l’inverse : rien ne se charge ; - un mod qui contient plusieurs ID de mod dans un seul élément Workshop — il faut alors déclarer chacun d’eux dans
Mods=; - un espace parasite après un point-virgule ;
- un point-virgule final manquant ou en trop selon les cas.
Vue d’ensemble du fichier : installer des mods sur un serveur Project Zomboid.
Cause n°3 : l’ordre de chargement
Mods= est une liste ordonnée. Un mod qui dépend d’un autre doit être déclaré après lui.
Symptôme typique : le serveur démarre, mais un mod précis se comporte comme s’il était absent, ou provoque une erreur Lua au chargement alors qu’il fonctionne seul.
Règle pratique : les bibliothèques et frameworks d’abord (gestionnaires de mods, bibliothèques communes), les mods de contenu ensuite, les mods de carte en dernier.
Cause n°4 : le décalage entre serveur et clients
Project Zomboid vérifie que les fichiers Lua du client correspondent à ceux du serveur :
DoLuaChecksum=trueQuand cette option est active — et elle doit l’être pour la sécurité — un client dont les mods diffèrent de ceux du serveur est expulsé.
Trois situations fréquentes :
- Le serveur a mis à jour un mod, pas le joueur : le client doit relancer Steam pour récupérer la nouvelle version.
- Le joueur a un mod en plus qui modifie les mêmes fichiers Lua.
- Le serveur n’a pas redémarré après une mise à jour Workshop : il tourne encore sur l’ancienne version en mémoire.
Le hotfix 42.20.1 a précisément amélioré la validation du checksum Lua pour l’anti-triche multijoueur. Les expulsions liées à des mods désynchronisés sont donc plus strictes qu’avant.
Cause n°5 : le mod n’a jamais été compatible Build 42
Beaucoup de mods très populaires ont été écrits pour Build 41 et n’ont jamais été portés. Build 42 a changé en profondeur l’artisanat, les compétences et l’inventaire : un mod B41 non maintenu ne fonctionnera pas, même sans erreur visible.
Vérifiez sur la page Workshop :
- la mention explicite de Build 42 ;
- la date de la dernière mise à jour ;
- les commentaires récents, souvent plus fiables que la description.
Si votre serveur tourne encore sur legacy41, c’est l’inverse : les mods B42 ne fonctionneront pas chez vous. Voir passer son serveur Project Zomboid en Build 42.
La méthode de diagnostic, dans l’ordre
- Sauvegardez le monde. Un mod de contenu retiré peut supprimer des objets posés dans le monde. Voir sauvegarder et restaurer un serveur PZ.
- Lisez
server-console.txtet cherchez la première erreur, pas la dernière : les suivantes en découlent souvent. Voir logs d’un serveur Project Zomboid. - Démarrez sans aucun mod : videz
Mods=etWorkshopItems=. Si le serveur tourne, le problème vient bien des mods. - Réintroduisez-les par petits groupes, en redémarrant à chaque fois, jusqu’à isoler le coupable.
- Vérifiez la date du mod fautif sur le Workshop : s’il n’a pas bougé depuis août 2026, la cause
loadstringest très probable.
FAQ
Pourquoi mes mods Project Zomboid ne fonctionnent plus depuis la mise à jour ?
Le hotfix 42.20.4 du 26 août 2026 a supprimé les méthodes Lua loadstring et loadstream dans le cadre d’un correctif de sécurité. Tout mod qui les utilisait doit être mis à jour par son auteur pour refonctionner.
Peut-on revenir à une version antérieure pour récupérer un mod ?
C’est fortement déconseillé : 42.20.4 corrige des failles de sécurité, et vos joueurs à jour ne pourraient plus se connecter à un serveur en version antérieure. Mieux vaut remplacer le mod.
Quelle est la différence entre Mods= et WorkshopItems= ?
WorkshopItems liste les ID numériques des éléments Workshop à télécharger ; Mods liste les ID textuels des mods à activer, trouvables dans le fichier info.txt de chaque mod. Un même élément Workshop peut contenir plusieurs mods.
Mes joueurs sont expulsés à la connexion depuis l’ajout d’un mod
C’est la vérification de checksum Lua (DoLuaChecksum=true). Les clients doivent avoir exactement les mêmes mods, dans les mêmes versions, que le serveur. Faites-leur relancer Steam pour forcer la mise à jour du Workshop.
Comment savoir quel mod fait planter mon serveur ?
Démarrez sans aucun mod, puis réintroduisez-les par groupes en redémarrant à chaque étape. C’est plus long qu’une lecture de log, mais c’est la seule méthode fiable quand l’erreur n’indique pas de nom de mod.
Retirer un mod peut-il casser mon monde ?
Oui, si le mod ajoutait des objets ou des bâtiments désormais posés dans le monde. Sauvegardez avant toute suppression, et prévenez vos joueurs : les objets du mod disparaîtront de leurs coffres.
Faut-il redémarrer le serveur après une mise à jour de mod ?
Oui. Un mod mis à jour sur le Workshop n’est pris en compte qu’au redémarrage du serveur. Tant qu’il n’a pas redémarré, il tourne sur l’ancienne version et expulse les clients déjà à jour.
Conclusion
Depuis le hotfix 42.20.4, la première hypothèse face à un mod cassé sur Project Zomboid n’est plus la configuration : c’est la suppression de loadstring et loadstream, qui a mis hors service tous les mods non maintenus. Viennent ensuite les causes classiques — Mods= et WorkshopItems= mélangés, ordre de chargement, checksum Lua, mod resté en Build 41.
Pour un hébergeur Project Zomboid avec console en direct, gestion des mods depuis le panel et sauvegardes automatiques avant chaque mise à jour, HebergTonServ démarre à 25,90 €/mois.
