Project Zomboid Build 42 est passé sur la branche stable le mercredi 29 juillet 2026. La version 42.20.0 est désormais celle que Steam installe par défaut, sans étape de test intermédiaire. Pour une partie solo, c’est une mise à jour de plus. Pour un serveur dédié, c’est un changement de socle : les mondes créés sur la branche de test 42.19 ne sont pas repris, et la liste des mods doit être revérifiée avant de rouvrir aux joueurs.
Ce que The Indie Stone a publié entre le 24 et le 29 juillet
Le 24 juillet 2026, le studio annonce que la version 42.20 arrivera « directement sur la branche publique stable, le mercredi 29 juillet ». L’annonce sert aussi à dévoiler une nouvelle bande-annonce Build 42 pour la page Steam du jeu (annonce « Build 42 stable plans »).
Le 27 juillet, un second billet, « 42.20: The Big Glow Up », précise le contenu principal de cette version : une refonte importante de la Knox Event Exclusion Zone, la région fictive du Kentucky où se déroule le jeu, qui va au-delà de ce que les testeurs de la branche instable avaient déjà parcouru.
Le 29 juillet, l’annonce « Build 42.20.0 Stable Released » confirme la mise en ligne, publiée en début d’après-midi heure de Paris. Elle ajoute une information plus discrète : un correctif de sécurité a également été livré pour les Build 41 et 42.19, après un signalement responsable attribué à Jorge Escabias. Le studio précise que ce changement « a une faible probabilité d’affecter certains mods » (annonce de sortie officielle).
Branche stable : sur Steam, un même jeu peut proposer plusieurs versions installables, appelées branches. La branche stable est celle installée par défaut ; une branche « Unstable » sert aux tests avant validation. Jusqu’au 29 juillet, Build 42 n’était disponible que sur cette branche de test.
Une zone d’exclusion de Knox largement remaniée
Le cœur de cette version est un travail de carte. Le studio décrit des quartiers retravaillés pour paraître plus habités et plus crédibles, sur une zone que les joueurs de la branche instable connaissaient déjà en partie. Les annonces Steam ne donnent pas de comparatif chiffré : l’ampleur exacte de la refonte, en surface ou en nombre de bâtiments, reste à vérifier dans le billet complet publié par le studio.
Avant la sortie, The Indie Stone avait listé les chantiers en cours sur cette version : apparition des personnages, prise en charge des manettes, rendement de viande des crochets de boucher, remorquage de véhicules, et deux points spécifiquement multijoueur — la suppression automatique des zombies (« zombie culling ») et le chargement des morceaux de carte pendant la conduite. Ce sont ces deux derniers points qui pèsent le plus sur un serveur partagé, où les déplacements de plusieurs joueurs se cumulent.
Sauvegardes : pourquoi un monde 42.19 ne repart pas en 42.20
C’est le point à retenir avant toute mise à jour de serveur. Dans son billet du 9 juillet 2026, le studio indiquait qu’en raison d’une importante mise à jour de contenu, les sauvegardes 42.19 ne seraient pas transférables vers la 42.20. Il ajoutait que la 42.19 resterait accessible sur une branche dédiée, désignée à l’époque « outdatedunstable », pour terminer une partie en cours (billet « Next steps » du 9 juillet).
Sauvegarde de monde : sur un serveur dédié, le monde est stocké dans un dossier distinct des fichiers du jeu. Une nouvelle version peut modifier la structure de ces fichiers : le monde devient alors illisible pour le serveur, même si aucun fichier n’a été perdu.
En pratique, trois gestes suffisent : copier le dossier du monde avant la mise à jour, prévoir un monde neuf plutôt qu’une conversion, et annoncer la date de remise à zéro aux joueurs. Un panel d’hébergement rend les deux premiers immédiats, avec un gestionnaire de fichiers pour récupérer le dossier et une sauvegarde pour en garder une copie datée. La méthode ne change pas d’un jeu à l’autre : elle est la même que celle décrite pour la 1.0 de Valheim, ou pour les versions de test de Minecraft.
Mods et outils : ce qui bouge autour du serveur
Le correctif de sécurité livré le 29 juillet pour les Build 41 et 42.19 peut, de l’aveu du studio, toucher certains mods. Sur un serveur, un mod qui ne se charge pas suffit à bloquer les connexions : passer la liste en revue, un mod après l’autre, reste l’étape la plus longue d’une migration, et la plus difficile à déléguer.
The Indie Stone a aussi décrit ce qui suit ce passage en stable : d’abord les correctifs rapides jugés nécessaires, puis un patch d’ajustements orienté fin de partie, la publication de ses outils de cartographie (WorldZed, TileZed) et de son éditeur d’animations interne AnimZed, et enfin, sur le reste de 2026, une « Build 42 Support Update » consacrée à l’optimisation, au support du moddage et à des demandes de joueurs restées de côté.
Côté ressources, le projet de carte officiel a été réécrit et prend désormais en charge Build 41, Build 42 et les versions antérieures. C’est un outil utile pour repérer les zones remaniées ou fixer un point de départ commun avant de relancer une partie à plusieurs.
L’impact probable pour les serveurs dédiés
Les éléments qui suivent relèvent de l’analyse, et non d’annonces officielles.
Le premier réflexe utile est d’attendre. Une bascule en branche stable est presque toujours suivie de correctifs rapides, et un serveur mis à jour le jour même peut devoir être redémarré plusieurs fois dans la même semaine. Décaler la migration de quelques jours après le 29 juillet limite ce risque, à condition de prévenir les joueurs plutôt que de les laisser découvrir une erreur de connexion.
Vient ensuite l’alignement des versions : client et serveur doivent tourner sur la même version pour que la connexion aboutisse. Un serveur laissé en 42.19 devient inaccessible aux joueurs déjà passés en 42.20, et l’inverse est vrai aussi. Une fonction de sélection de version, lorsqu’elle est proposée dans le panel, sert exactement à gérer ce décalage le temps d’une transition.
Enfin, aucune donnée officielle sur les besoins en processeur ou en mémoire de la 42.20 n’a été publiée à ce stade. Les données disponibles ne permettent pas encore de confirmer si la nouvelle carte modifie sensiblement la charge d’un serveur : mieux vaut observer le comportement de son propre serveur après migration que d’ajouter des ressources à l’aveugle.
Ce qu’il reste à confirmer
- Le nom exact des branches permettant de rester sur une version antérieure : le billet du 9 juillet cite « outdatedunstable » pour la 42.19, mais ces libellés peuvent avoir évolué le jour de la sortie.
- Le sort des mondes créés en Build 41 : la communication officielle porte sur les sauvegardes 42.19. Tant que ce point n’est pas tranché, un monde neuf reste l’hypothèse prudente.
- Le rythme des correctifs des premiers jours, qui déterminera la bonne date de migration pour un serveur communautaire.
- L’ampleur chiffrée de la refonte de carte, absente des annonces Steam consultées.
Pour aller plus loin
- Annonce « Build 42.20.0 Stable Released » (29 juillet 2026) : la publication officielle de la version, avec la mention du correctif de sécurité.
- Annonce « Build 42 stable plans » (24 juillet 2026) : le calendrier annoncé et la bande-annonce Build 42.
- Billet « Next steps » (9 juillet 2026) : la feuille de route du studio jusqu’à la fin 2026, sauvegardes comprises.
- Préparer un serveur Valheim avant la 1.0 : la même méthode de sauvegarde et de reset appliquée à un autre jeu.
- Serveur Enshrouded avant la 1.0 : comment anticiper un changement de version majeur sans perdre sa communauté.
