Servidor Paper con un TPS que puedes explicar

El linaje es CraftBukkit, Spigot y Paper. Como Paper conserva la API de Bukkit y de Spigot, el jar de un plugin compilado para Spigot arranca sin recompilar. Por eso la base instalada de EssentialsX, LuckPerms, Vault y WorldGuard sigue funcionando tras el cambio.

Lo que Paper añade es implementación, no una API nueva incompatible: chunks reescritos, motor de luz, rastreo de entidades, tolvas. Nada de eso vuelve paralelo el tick, la ganancia viene de que cada tick cuesta menos. Cambiar el jar rinde una mejora real y limitada, y el resto depende de la configuración y de qué plugins aceptes cargar.

El TPS tiene techo en 20. Un servidor gastando 45 milisegundos por tick marca 20,0 y parece sano, cuando le quedan 5 milisegundos de holgura. Basta una explosión o alguien explorando terreno nuevo para pasar de 50 y que el número se desplome. Quien solo mira el TPS descubre el problema después que el jugador.

Mira la distribución, no la media. Mediana baja con percentil 95 alto indica pico periódico, y el sospechoso suele ser el autosave, una tarea programada o la generación de terreno. Media alta con distribución estrecha indica carga constante, casi siempre entidades, tolvas o código que se ejecuta en cada evento de movimiento.

Conviene además separar el lag de tick del lag de red. Si el mspt está cómodo y el jugador sigue notando retraso, ninguna clave de yml lo arregla.

A partir de Paper 1.19 la configuración se dividió en dos archivos dentro de la carpeta config: paper-global.yml, con lo que vale para todo el servidor, y paper-world-defaults.yml, con los valores por defecto de los mundos. Cada mundo todavía puede sobrescribir lo que quiera en su propio paper-world.yml. Los tutoriales antiguos siguen mandando editar un paper.yml en la raíz, que en esas versiones ya no existe.

En el archivo global casi todo se queda por defecto, y lo que justifica una edición es la integración con proxy, el limitador de paquetes y la carga de chunks. Las ganancias que la gente busca están en el archivo de mundo: rangos de despawn, mobs por jugador, colisión, tolvas e implementación de redstone.

La sobrescritura por mundo es el recurso más desaprovechado. Un mundo de minería aguanta despawn agresivo y simulación corta sin que nadie se queje, mientras el survival principal se queda conservador. Aplicar la misma configuración agresiva a todos los mundos convierte la optimización en un ticket de soporte.

Ese archivo optimizado que circula por los foros aplica decenas de cambios de golpe. Funciona en el servidor de quien lo escribió. En el tuyo, dos o tres de esas claves van a romper algo, y no tendrás forma de saber cuáles porque lo pegaste todo junto.

Los destrozos son previsibles. Un despawn muy corto sumado a un rango de spawn reducido genera la queja clásica de que no nacen mobs para farmear. Un rango de activación demasiado bajo hace que el mob deje de caminar y la granja se pare con él. Quitarles la inteligencia a los mobs de spawner mata mecánicas que dependen del movimiento. Un radio de fusión alto cambia cómo se agrupan los drops en el suelo. Y cambiar la implementación de redstone altera el orden de actualización de los cables, lo bastante para que una contraption sensible al timing cambie de comportamiento.

Acepta también que buena parte de la ganancia no está en ningún yml. El plugin pesado casi nunca es el del jar más grande, sino el que consulta la base de datos de forma síncrona en cada evento, recorre entidades en una tarea repetida o fuerza carga de chunks fuera del camino asíncrono.