Un serveur Paper avec un TPS que vous savez expliquer

La lignée, c’est CraftBukkit, Spigot puis Paper. Comme Paper préserve l’API de Bukkit et de Spigot, le jar d’un plugin compilé pour Spigot démarre sans recompilation. C’est pourquoi le parc installé d’EssentialsX, LuckPerms, Vault et WorldGuard continue de fonctionner après le changement.

Ce que Paper ajoute, c’est de l’implémentation, pas une nouvelle API incompatible : chunk réécrit, moteur de lumière, suivi d’entité, entonnoirs. Rien de tout cela ne rend le tick parallèle, le gain vient de ce que chaque tick coûte moins cher. Changer de jar apporte une amélioration réelle mais bornée, et le reste dépend de la configuration et des plugins que vous acceptez de charger.

Le TPS plafonne à 20. Un serveur qui dépense 45 millisecondes par tick affiche 20,0 et paraît en bonne santé, alors qu’il lui reste 5 millisecondes de marge. Il suffit d’une explosion ou de quelqu’un qui explore du terrain neuf pour dépasser 50 et voir le chiffre s’effondrer. Qui ne suit que le TPS découvre le problème après le joueur.

Regardez la distribution, pas la moyenne. Une médiane basse avec un 95e centile élevé signale un pic périodique, et le suspect habituel est l’autosave, une tâche planifiée ou la génération de terrain. Une moyenne haute avec une distribution serrée signale une charge constante, presque toujours des entités, des entonnoirs ou du code exécuté à chaque événement de déplacement.

Il vaut aussi la peine de séparer le lag de tick du lag réseau. Si le mspt est confortable et que le joueur ressent toujours du retard, aucune clé de yml n’y changera rien.

À partir de Paper 1.19, la configuration a été scindée en deux fichiers dans le dossier config : paper-global.yml, pour ce qui vaut pour tout le serveur, et paper-world-defaults.yml, pour les valeurs par défaut des mondes. Chaque monde peut encore surcharger ce qu’il veut dans son propre paper-world.yml. Les vieux tutoriels demandent toujours d’éditer un paper.yml à la racine, qui n’existe plus dans ces versions.

Dans le fichier global, presque tout reste par défaut, et ce qui justifie une édition, c’est l’intégration au proxy, le limiteur de paquets et le chargement de chunk. Les gains que tout le monde cherche sont dans le fichier de monde : plages de despawn, mobs par joueur, collision, entonnoirs et implémentation de la redstone.

La surcharge par monde est la ressource la plus sous-exploitée. Un monde minier encaisse un despawn agressif et une simulation courte sans que personne ne se plaigne, pendant que le survival principal reste conservateur. Appliquer la même configuration agressive à tous les mondes transforme l’optimisation en ticket de support.

Ce fichier optimisé qui circule sur les forums applique des dizaines de changements d’un coup. Il fonctionne sur le serveur de celui qui l’a écrit. Sur le vôtre, deux ou trois de ces clés vont casser quelque chose, et vous n’aurez aucun moyen de savoir lesquelles puisque vous avez tout collé d’un bloc.

Les dégâts sont prévisibles. Un despawn trop court ajouté à une portée de spawn réduite produit la plainte classique : plus de mobs à farmer. Une portée d’activation trop basse fait cesser les déplacements du mob, et la farm s’arrête avec lui. Retirer l’intelligence aux mobs de spawner tue les mécaniques qui dépendent du mouvement. Un rayon de fusion élevé change la façon dont les drops se regroupent au sol. Et changer l’implémentation de la redstone modifie l’ordre de mise à jour des fils, assez pour qu’une contraption sensible au timing change de comportement.

Acceptez aussi qu’une bonne part du gain ne se trouve dans aucun yml. Le plugin lourd n’est presque jamais celui au jar le plus gros, c’est celui qui interroge la base de données de façon synchrone à chaque événement, balaie les entités dans une tâche répétée ou force du chargement de chunk hors du chemin asynchrone.