Optimiser son serveur Vintage Story et réduire le lag

Des blocs qui réapparaissent après les avoir cassés, des créatures qui se téléportent, des chunks qui mettent une éternité à charger : votre serveur Vintage Story lag. Avant de tout réinstaller, ce guide vous aide à trouver la vraie cause puis à appliquer les bons réglages.

Étape 1 : diagnostiquer avant d’optimiser

Lag serveur ou lag réseau ?

Symptôme	Cause probable
Tous les joueurs lag en même temps	Serveur surchargé (CPU/RAM)
Un seul joueur lag	Sa connexion ou son PC
Lag uniquement en explorant de nouvelles zones	Génération de chunks
Lag qui s’aggrave au fil des jours	Mémoire saturée, redémarrage nécessaire
Lag depuis l’ajout d’un mod	Le mod en question

La commande /stats

/stats

Elle affiche l’état du serveur : tick rate, mémoire utilisée, joueurs connectés, chunks chargés. Le serveur vise 30 ticks par seconde (TickTime = 33,3 ms). Si le tick rate chute nettement en dessous et y reste, le serveur n’arrive plus à suivre.

Comparez avec le graphique CPU/RAM du panel de votre hébergeur :

• CPU d’un cœur au maximum → la simulation est trop lourde (distance de vue, créatures, mods)
• RAM au plafond → pas assez de mémoire pour vos joueurs et vos mods

Étape 2 : réduire la distance de vue

C’est le réglage le plus efficace. MaxChunkRadius limite la distance de vue maximale que les joueurs peuvent demander au serveur.

"MaxChunkRadius": 10

Valeur	Usage
12 (défaut)	Petit serveur sur une machine confortable
10	Bon compromis pour 5 à 15 joueurs
8	Serveur chargé ou modpack lourd

La charge augmente avec le carré du rayon : passer de 12 à 8 divise à peu près par deux le nombre de chunks à gérer par joueur. Arrêtez le serveur avant de modifier serverconfig.json (voir configurer serverconfig.json).

Étape 3 : limiter les créatures

Chaque créature a une IA et une physique. SpawnCapPlayerScaling augmente le plafond de créatures en fonction du nombre de joueurs connectés :

"SpawnCapPlayerScaling": 0.3

Défaut : 0.5. Le baisser réduit la population de créatures quand beaucoup de joueurs sont connectés. Sur un serveur très peuplé, c’est un gain notable.

Étape 4 : ajuster les ticks aléatoires de blocs

Les « random ticks » font pousser l’herbe, évoluer certains blocs, etc. autour des joueurs :

Clé	Défaut	Effet d’une baisse
BlockTickChunkRange	5	Moins de chunks mis à jour autour de chaque joueur
RandomBlockTicksPerChunk	16	Moins de mises à jour par chunk
MaxMainThreadBlockTicks	10000	Plafonne le travail par tick

Étape 5 : donner assez de RAM

La règle officielle : 1 Go + 300 Mo par joueur, plus la marge pour les mods.

Joueurs	Vanilla	Avec mods
1 à 4	2 à 3 Go	4 Go
5 à 10	4 à 5 Go	6 à 8 Go
10 à 20	6 à 8 Go	10 à 12 Go

Quand la RAM est saturée, le ramasse-miettes (.NET garbage collector) tourne en permanence et provoque des micro-freezes pour tout le monde. Si votre graphique RAM touche le plafond, passez à l’offre supérieure plutôt que de sacrifier la distance de vue.

Étape 6 : faire le tri dans les mods

Les mods sont la première cause de lag « inexpliqué ». Les plus gourmands :

• Mods de génération de monde (nouvelles structures, biomes)
• Mods ajoutant beaucoup de créatures
• Mods avec des blocs animés ou mécaniques en grand nombre

Méthode : sauvegardez, retirez la moitié des mods, testez. Si le lag disparaît, le coupable est dans cette moitié. Répétez. Détails dans installer des mods.

Étape 7 : maîtriser l’exploration

Générer de nouveaux chunks est l’opération la plus coûteuse du serveur. Cinq joueurs qui partent explorer dans cinq directions différentes, c’est cinq fronts de génération simultanés.

• Encouragez les voyages en groupe
• Limitez la taille du monde à la création (via le menu Customize en solo, puis importez le monde)
• Laissez PassTimeWhenEmpty à false si le serveur est souvent vide

Étape 8 : redémarrer régulièrement

Un redémarrage quotidien libère la mémoire et repart sur une base saine (guide complet : redémarrage automatique). Chez un hébergeur, programmez-le à une heure creuse depuis les tâches planifiées du panel. Prévenez les joueurs :

/announce Redémarrage quotidien dans 5 minutes !

Sur un VPS Linux, avec cron (voir installer sur VPS Linux) :

# Redémarrage tous les jours à 5h
0 5 * * * /usr/bin/systemctl restart vintagestory

(à placer dans la crontab de root : sudo crontab -e)

Étape 9 : le matériel, la vraie limite

Une fois les réglages faits, le facteur décisif reste le processeur : la boucle principale de Vintage Story dépend surtout de la performance mono-cœur. Un vieux Xeon à 2,2 GHz ne rattrapera jamais un Ryzen moderne, quels que soient les réglages.

Checklist matériel :

• ✅ CPU récent à haute fréquence
• ✅ SSD NVMe (génération et sauvegardes plus fluides)
• ✅ RAM dédiée suffisante
• ✅ Datacenter proche de vos joueurs

Plus de détails dans notre guide pour choisir son hébergeur Vintage Story.

Récapitulatif : réglages conseillés pour 10 joueurs

{
  "MaxClients": 10,
  "MaxChunkRadius": 10,
  "SpawnCapPlayerScaling": 0.4,
  "PassTimeWhenEmpty": false,
  "CompressPackets": true
}

Avec 6 Go de RAM et un redémarrage quotidien, c’est une base solide pour un serveur survie avec quelques mods.

Questions fréquentes

Pourquoi mon serveur Vintage Story lag ?

CPU trop faible en mono-cœur, RAM insuffisante, distance de vue trop élevée, exploration dans toutes les directions ou mods lourds. Commencez par /stats et le graphique CPU/RAM.

Quelle distance de vue régler ?

MaxChunkRadius vaut 12 par défaut. 8 à 10 réduit fortement la charge tout en restant confortable.

Combien de RAM faut-il pour éviter le lag ?

1 Go + 300 Mo par joueur, plus une marge pour les mods. Une RAM saturée provoque des micro-freezes pour tout le monde.

---

Marre du lag ? Nos serveurs tournent sur AMD Ryzen 9 5950X avec NVMe : voir les offres HebergTonServ.