Servidor Paper com TPS que você consegue explicar

A linhagem é CraftBukkit, Spigot e Paper. Como o Paper preserva a API do Bukkit e do Spigot, o jar de um plugin compilado para Spigot sobe sem recompilar. É por isso que a base instalada de EssentialsX, LuckPerms, Vault e WorldGuard continua funcionando depois da troca.

O que o Paper acrescenta é implementação, não uma API nova incompatível: chunk reescrito, motor de luz, rastreio de entidade, hopper. Nada disso torna o tick paralelo, o ganho vem de cada tick custar menos. Trocar o jar rende uma melhora real e limitada, e o resto depende da configuração e de quais plugins você aceita carregar.

O TPS tem teto em 20. Um servidor gastando 45 milissegundos por tick marca 20,0 e parece saudável, quando tem 5 milissegundos de folga. Basta uma explosão ou alguém explorando terreno novo para passar de 50 e o número despencar. Quem acompanha só o TPS descobre o problema depois do jogador.

Olhe a distribuição, não a média. Mediana baixa com percentil 95 alto indica pico periódico, e o suspeito costuma ser autosave, task agendada ou geração de terreno. Média alta com distribuição estreita indica carga constante, quase sempre entidade, hopper ou código que executa em todo evento de movimento.

Vale ainda separar lag de tick de lag de rede. Se o mspt está confortável e o jogador continua sentindo atraso, nenhuma chave de yml resolve.

A partir do Paper 1.19 a configuração foi dividida em dois arquivos dentro da pasta config: paper-global.yml, com o que vale para o servidor inteiro, e paper-world-defaults.yml, com os padrões dos mundos. Cada mundo ainda sobrescreve o que quiser no próprio paper-world.yml. Tutorial antigo continua mandando editar um paper.yml na raiz, que nessas versões não existe mais.

No arquivo global quase tudo fica no padrão, e o que justifica edição é integração com proxy, limitador de pacote e carregamento de chunk. Os ganhos que o pessoal procura estão no arquivo de mundo: faixas de despawn, mob por jogador, colisão, hopper e implementação de redstone.

A sobrescrita por mundo é o recurso mais subaproveitado. Um mundo de mineração aguenta despawn agressivo e simulação curta sem que ninguém reclame, enquanto o survival principal fica conservador. Aplicar a mesma configuração agressiva em todos os mundos transforma otimização em ticket de suporte.

Aquele arquivo otimizado que circula em fórum aplica dezenas de mudanças de uma vez. Ele funciona no servidor de quem escreveu. No seu, duas ou três daquelas chaves vão quebrar alguma coisa, e você não terá como saber quais porque colou tudo junto.

Os estragos são previsíveis. Despawn muito curto somado a alcance de spawn reduzido gera a reclamação clássica de que não nasce mob para farmar. Alcance de ativação baixo demais faz o mob parar de andar e a farm parar junto. Tirar a inteligência dos mobs de spawner mata mecânica que depende de movimento. Raio de junção alto muda como o drop se agrupa no chão. E trocar a implementação de redstone altera a ordem de atualização dos fios, o bastante para uma contraption sensível a timing mudar de comportamento.

Aceite também que boa parte do ganho não está em yml nenhum. O plugin pesado quase nunca é o de jar maior, e sim o que consulta banco de forma síncrona a cada evento, varre entidades numa task repetida ou força carregamento de chunk fora do caminho assíncrono.