Régler la distance de vue d’un serveur Minecraft Paper

Serveurs de jeux, Tutoriels -

La distance de vue d’un serveur Minecraft détermine la quantité de monde que le serveur envoie à chaque joueur connecté. Mal réglée, elle allonge le temps de calcul d’un tick et provoque des saccades que tout le monde ressent en même temps. Ce tutoriel explique comment ajuster view-distance et simulation-distance sur un serveur Paper en Minecraft Java 26.2, comment mesurer l’effet réel du changement, et comment revenir en arrière si le résultat ne convient pas.

Comptez une quinzaine de minutes, redémarrage compris. À la fin, vous saurez quelle valeur appliquer, dans quel fichier l’écrire, et comment vérifier que le serveur va réellement mieux plutôt que de le supposer.

Ce que règlent réellement ces deux paramètres

Les deux réglages vivent dans server.properties, le fichier de configuration principal d’un serveur Minecraft Java, et s’expriment en chunks. Un chunk est une colonne de 16 blocs sur 16 blocs qui va du fond du monde jusqu’à sa hauteur maximale. Point important : les valeurs sont des rayons autour du joueur, pas des diamètres.

view-distance fixe la quantité de données de monde que le serveur envoie au client. La référence server.properties de PaperMC indique une valeur par défaut de 10, un minimum de 3 et un maximum de 32. Ce réglage plafonne la distance d’affichage : un joueur qui pousse son client à 32 chunks ne verra jamais plus loin que la valeur du serveur.

simulation-distance fixe la distance maximale à laquelle les entités vivantes sont mises à jour par le serveur. Une entité est un objet mobile du monde : créature, objet au sol, projectile, wagonnet. Au-delà de ce rayon, la documentation précise que les entités ne sont plus tickées par le serveur ni visibles par les joueurs. Mêmes bornes que le précédent : 10 par défaut, 3 au minimum, 32 au maximum.

En pratique, view-distance pèse surtout sur le réseau et sur le chargement des chunks, tandis que simulation-distance pèse sur le temps processeur consacré aux entités et à la logique de jeu. Baisser l’un ne remplace pas l’autre.

Mesurer l’état du serveur avant d’y toucher

Il vous faut : un serveur Paper en 26.2, disponible sur la page de téléchargement officielle de PaperMC ; un accès au gestionnaire de fichiers ou au SFTP de votre panel d’hébergement ; le rang opérateur en jeu ou l’accès à la console ; et une fenêtre de redémarrage acceptée par vos joueurs.

Relevez d’abord l’état actuel. En console ou en jeu, /mspt affiche le temps moyen de calcul d’un tick en millisecondes et /tps le nombre de ticks par seconde. Un serveur sain tourne à 20 ticks par seconde, ce qui laisse 50 ms par tick : au-dessus de 50 ms affichées par /mspt, le serveur prend du retard. La documentation des commandes Paper précise que ces deux commandes fonctionnent toujours mais sont désormais supplantées par /spark, qui donne en plus la répartition du temps par tâche.

Faites cette mesure aux heures de pointe, avec des joueurs connectés. Un relevé effectué sur un serveur vide ne vous apprendra rien et fausse toute comparaison ultérieure.

Sauvegarde obligatoire. Avant toute modification, téléchargez une copie de server.properties et de spigot.yml, puis déclenchez une sauvegarde complète depuis votre panel. Ces fichiers ne détruisent pas le monde, mais une valeur invalide ou une indentation cassée peut empêcher le serveur de démarrer : garder la version d’origine évite d’avoir à la reconstituer de mémoire.

Choisir une valeur au lieu de recopier celle du voisin

Il n’existe pas de valeur universelle : deux serveurs avec le même nombre de joueurs peuvent avoir des besoins très différents selon leurs plugins, leurs fermes et leur nombre de mondes. Les seuls chiffres qui viennent de la documentation sont l’intervalle autorisé, 3 à 32, et la valeur par défaut, 10.

Procédez par paliers. Descendez de deux chunks à la fois, gardez la valeur pendant une session complète, puis comparez le /mspt à charge comparable. Deux changements simultanés rendent le résultat illisible : modifiez un seul paramètre par palier.

Par quel paramètre commencer ? Si le temps de tick grimpe quand la population de créatures augmente, ou quand des fermes automatiques tournent, commencez par simulation-distance. Si le problème apparaît surtout lorsque des joueurs explorent des zones neuves et éloignées les unes des autres, commencez par view-distance.

À garder en tête. Ces repères restent indicatifs. Le réglage utile varie selon la version du serveur, le nombre de joueurs connectés en même temps, les plugins installés, la taille des fermes à entités et le nombre de mondes chargés simultanément.

Modifier view-distance et simulation-distance

1

Arrêter le serveur

Arrêtez proprement le serveur depuis la console du panel. Le fichier n’est lu qu’au démarrage : une modification faite pendant que le serveur tourne reste sans effet, et risque d’être écrasée au moment de l’arrêt.

2

Ouvrir server.properties

Dans le gestionnaire de fichiers, ouvrez server.properties à la racine du dossier du serveur, au même niveau que le fichier .jar et que le dossier du monde.

3

Remplacer les deux valeurs

Repérez les lignes view-distance= et simulation-distance=. Écrivez un nombre entier, sans espace autour du signe égal et sans majuscule, en restant dans l’intervalle 3 à 32.

4

Enregistrer et redémarrer

Enregistrez le fichier, puis redémarrez le serveur et surveillez la console pendant le démarrage. Aucune erreur ne doit apparaître avant la ligne indiquant que le serveur est prêt.

view-distance=7
simulation-distance=5

Ces deux valeurs sont un exemple d’un premier palier depuis la configuration par défaut, pas une recommandation à recopier telle quelle.

Appliquer une valeur différente monde par monde

Un hub de mini-jeux et un monde survie n’ont pas les mêmes besoins. Paper permet de surcharger les deux réglages monde par monde dans spigot.yml. La référence spigot.yml de PaperMC indique que la surcharge se fait en créant, sous world-settings, une clé portant le nom du dossier du monde. Les deux options y valent default, ce qui renvoie à server.properties ; la valeur -1 produit le même résultat.

world-settings:
  default:
    view-distance: default
    simulation-distance: default
  hub:
    view-distance: 5
    simulation-distance: 4

Attention au piège : la clé default ne désigne pas un monde appelé « default ». Elle regroupe les valeurs appliquées à tous les mondes qui ne sont pas listés explicitement. Pour cibler un monde précis, utilisez le nom de son dossier sur le disque, celui défini par level-name.

Le fichier est en YAML : il n’accepte que des espaces pour l’indentation, jamais de tabulation. Un redémarrage reste nécessaire pour appliquer la surcharge.

Vérifier le gain et repérer les effets de bord

Relevez de nouveau /mspt à charge comparable : même créneau horaire, nombre de joueurs proche, activités équivalentes. Comparer un pic du samedi soir à un mardi après-midi ne prouve rien.

Côté joueur, la vérification est immédiate : poussez la distance de rendu du client au maximum. Si la limite des chunks chargés apparaît plus près qu’avant, la nouvelle valeur de view-distance est bien active.

Baisser simulation-distance a une conséquence directe sur le jeu, et c’est l’effet de bord le plus souvent découvert trop tard : les entités situées hors du rayon ne sont plus mises à jour. Une ferme à créatures, un circuit de redstone ou un tri automatique placé loin du joueur cesse de fonctionner tant que personne ne s’en approche. Sur un serveur survie établi, prévenez vos joueurs avant d’appliquer le changement.

Un troisième réglage documenté peut compléter l’ajustement sans toucher à la portée de simulation : entity-broadcast-range-percentage, réglé à 100 par défaut et acceptable entre 10 et 1000. Il contrôle la distance à laquelle les entités sont envoyées aux clients, exprimée en pourcentage de la valeur de référence. Le descendre allège ce que le serveur transmet, mais ne change pas ce qu’il calcule.

Erreurs fréquentes et retour arrière

  • Confondre distance de vue serveur et distance de rendu client. Le client peut afficher moins que le serveur, jamais plus.
  • Descendre sous 3 chunks ou dépasser 32 : ces valeurs sortent de l’intervalle documenté.
  • Éditer server.properties serveur allumé. La modification est ignorée, puis risque d’être écrasée à l’arrêt.
  • Renseigner world-settings.default en croyant cibler un monde nommé « default ».
  • Baisser view-distance pour régler un problème d’entités. Si le temps de tick suit la population de créatures, c’est simulation-distance et les fermes qu’il faut regarder.

Retour arrière : arrêtez le serveur, remettez view-distance=10 et simulation-distance=10, ou restaurez la copie du fichier faite avant modification, puis redémarrez. Si le serveur refuse de démarrer après une édition de spigot.yml, la cause la plus fréquente est une indentation invalide ; en cas de doute, restaurez la sauvegarde complète prise au début.

Ce réglage s’applique à n’importe quel serveur Paper, quel que soit l’hébergeur. Si vous cherchez une machine sur laquelle le mettre en pratique, les offres Minecraft Java de Koinswift donnent accès au gestionnaire de fichiers pour éditer server.properties et spigot.yml, à la sélection de version et aux sauvegardes, sur une infrastructure réseau sécurisée et filtrée, avec un support disponible 7 j/7.

Pour aller plus loin

Articles similaires

1er mois OFFERT avec le code FREE1, puis 6 mois à -50% avec le code KOIN50

Rejoindre la bêta
X
Retour en haut