Jouer à 7 Days to Die entre amis : comprendre et paramétrer sa partie multijoueur

Le fichier serverconfig.xml 7 Days to Die est le fichier XML qui pilote tous les paramètres d'une partie hébergée : nom de la session, mot de passe, visibilité, seed du monde, difficulté et règles des hordes. C'est lui qui transforme une simple exécutable serveur en session jouable à plusieurs, à condition de savoir quels champs modifier et quels ports rendre accessibles à tes amis.

Le fichier serverconfig.xml 7 Days to Die : structure et rôle

Le serverconfig.xml se présente comme une liste de balises property, chacune associée à un nom et une valeur. Il se charge au démarrage via le paramètre -configfile passé au script de lancement, et toute modification nécessite un redémarrage du processus pour être prise en compte.

Sur une installation classique, le fichier se trouve dans le dossier racine de l'exécutable serveur, souvent nommé 7DaysToDieServer_Data ou directement à côté du binaire. En passant par un panel comme NexusPanel, il est accessible via WebFTP ou un éditeur intégré, sans avoir besoin d'un client FTP tiers.

Pour comprendre comment ce fichier s'articule avec l'infrastructure complète, consulte la page dédiée à l'hébergement 7 Days to Die, qui détaille les ressources allouées au processus serveur.

Où trouver et modifier le fichier

La modification se fait avec un éditeur de texte classique. Chaque ligne suit le même schéma :

<property name="ServerName" value="Session Amis"/>
<property name="ServerPassword" value="motdepasse"/>
<property name="ServerMaxPlayerCount" value="8"/>

Il suffit de changer la valeur entre guillemets, sans toucher au nom de la propriété ni à la syntaxe XML environnante.

Paramètres essentiels à connaître

Propriété	Rôle
ServerVisibility	0 = hors ligne, 1 = amis uniquement, 2 = public sur la liste Steam
GameDifficulty	Niveau de difficulté global, de 0 (facile) à 5
DayNightLength	Durée en minutes d'un cycle jour/nuit
BloodMoonEnabled	Active ou désactive les hordes de sang
EACEnabled	Active EasyAntiCheat côté serveur

Quels ports ouvrir pour jouer en multijoueur

7 Days to Die communique principalement en UDP sur un bloc de ports autour du port de jeu principal. Sans ouverture correcte, les joueurs voient la session dans leur liste mais n'arrivent jamais à s'y connecter, ou restent bloqués sur l'écran de chargement.

Port	Protocole	Usage
26900	TCP/UDP	Port de jeu principal, défini par ServerPort
26901	UDP	Requête et découverte de la session
26902	UDP	Requête secondaire pour la liste Steam
8081	TCP	Telnet, si TelnetEnabled est actif

Sur un environnement mutualisé ou géré via panel, ces ports sont généralement mappés automatiquement à la création de l'instance. La protection anti-DDoS reste active en permanence au niveau du réseau, ce qui limite l'exposition liée à l'ouverture de ces ports vers l'extérieur.

Génération et gestion du monde partagé

Le champ GameWorld détermine si la partie utilise Navezgane, la carte fixe fournie avec le jeu, ou RWG pour une génération procédurale. Ce choix se fait avant le premier lancement : changer GameWorld en cours de partie force la création d'un nouveau monde.

Choisir une seed et une taille de carte

Avec RWG, deux propriétés comptent particulièrement. WorldGenSeed fixe la graine de génération, partageable entre amis pour reproduire un monde identique ailleurs. WorldGenSize définit la taille en tuiles, typiquement 6144 pour un petit groupe et jusqu'à 10240 pour une communauté plus large avec davantage de biomes explorables.

<property name="GameWorld" value="RWG"/>
<property name="WorldGenSeed" value="valleedesmorts"/>
<property name="WorldGenSize" value="8192"/>

Basculer sur Navezgane

Pour une partie plus prévisible, avec des points d'intérêt fixes déjà connus de la communauté, il suffit de passer GameWorld sur Navezgane. Aucune graine n'est nécessaire dans ce cas, puisque la carte est identique à chaque génération.

Sauvegardes automatiques et restauration d'une partie

Les fichiers de sauvegarde sont rangés dans un dossier Saves, organisé par GameWorld puis par GameName. Ils contiennent les chunks explorés, les conteneurs placés et l'état des joueurs, et grossissent rapidement au fil des sessions actives.

Une coupure pendant l'écriture d'un chunk peut corrompre la sauvegarde en cours. C'est pour cette raison qu'un système de sauvegarde automatique planifié, indépendant du fichier de jeu lui-même, reste la meilleure protection contre une perte de progression après un crash ou une mise à jour ratée.

Restaurer un monde après un crash

La restauration consiste à couper le processus, remplacer le dossier GameName par la version sauvegardée, puis redémarrer le serveur avec le même serverconfig.xml. Il faut vérifier que la seed et le GameName correspondent exactement, sinon le jeu tentera de générer un nouveau monde plutôt que de charger l'ancien.

Installer des mods sans casser la compatibilité entre joueurs

7 Days to Die accepte des mods côté serveur via le dossier Mods, chargés au démarrage du processus. Certains modifient uniquement le comportement serveur (loot, difficulté des zombies), d'autres nécessitent que chaque joueur possède le même mod côté client pour éviter les erreurs de synchronisation.

EasyAntiCheat et mods côté client

Quand EACEnabled est actif, certains mods qui modifient les fichiers du jeu peuvent être bloqués par EasyAntiCheat. Pour un groupe de connaissances qui joue exclusivement en mods, il est courant de désactiver EAC côté serveur afin d'éviter les déconnexions liées à des vérifications d'intégrité trop strictes.

Synchroniser les mods pour tout le groupe

Le plus simple reste de centraliser l'archive de mods dans un espace partagé (Discord, cloud commun) et de demander à chaque joueur de l'installer avant la première connexion. Un décalage de version entre le dossier Mods serveur et les fichiers clients provoque des erreurs de chargement de monde.

Administrer la session au quotidien

L'administration passe surtout par Telnet, activé via TelnetEnabled et sécurisé par TelnetPassword. Cette console texte permet d'envoyer des commandes à distance : kick, ban, changement de météo, ou rechargement de la configuration sans redémarrage complet.

Telnet, whitelist et droits d'administration

La whitelist et les droits d'administrateur se gèrent dans un fichier serveradmin.xml séparé, où chaque compte Steam reçoit un niveau de permission. Un mot de passe Telnet robuste, jamais partagé au delà des personnes de confiance, évite qu'un tiers prenne le contrôle complet de la session.

<property name="TelnetEnabled" value="true"/>
<property name="TelnetPort" value="8081"/>
<property name="TelnetPassword" value="MotDePasseSolide123"/>

Sur un panel qui intègre une console live, ces commandes s'exécutent directement depuis l'interface, sans avoir besoin d'ouvrir un client Telnet séparé sur son poste.

Conclusion

Pour un groupe d'amis, la combinaison qui fonctionne le mieux reste RWG avec une seed partagée, EAC désactivé si des mods sont utilisés, et un mot de passe Telnet distinct du mot de passe de connexion. L'erreur la plus courante à éviter : modifier le serverconfig.xml sans redémarrer le processus, ce qui laisse croire qu'un changement n'a aucun effet.

FAQ

Pourquoi mon monde 7 Days to Die se régénère à chaque redémarrage ?

Cela arrive quand le GameName ou la seed change entre deux lancements, même légèrement. Le jeu considère alors qu'il s'agit d'un monde différent et en crée un nouveau. Il faut garder exactement les mêmes valeurs de GameWorld, GameName et WorldGenSeed dans le serverconfig.xml pour recharger la même sauvegarde à chaque démarrage.

Combien de RAM demande une session 7 Days to Die avec des mods ?

Une partie vanille pour un petit groupe tourne avec des ressources modestes, mais l'ajout de mods de loot ou de vehicules pousse rapidement la consommation mémoire à la hausse. Il faut compter une marge supplémentaire par rapport à une partie sans mod, surtout si plusieurs mods modifient le comportement des zombies simultanément.

Comment savoir si mes ports 7 Days to Die sont correctement ouverts ?

Le test le plus fiable consiste à demander à un joueur externe au réseau local de tenter la connexion directe via l'adresse IP et le port ServerPort. Si la session apparaît dans la liste Steam mais que la connexion échoue, le souci vient généralement d'un des ports UDP secondaires (26901 ou 26902) non redirigé.