Servidor Paper com um TPS que 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 arranca sem recompilar. É por isso que a base instalada de EssentialsX, LuckPerms, Vault e WorldGuard continua a funcionar 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, funis. Nada disso torna o tick paralelo, o ganho vem de cada tick custar menos. Trocar o jar rende uma melhoria real e limitada, e o resto depende da configuração e de que plugins aceita carregar.

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

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

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

A partir do Paper 1.19 a configuração foi dividida em dois ficheiros 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 pode ainda sobrepor o que quiser no próprio paper-world.yml. Tutorial antigo continua a mandar editar um paper.yml na raiz, que nessas versões já não existe.

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

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

Aquele ficheiro otimizado que circula no fórum aplica dezenas de alterações de uma vez. Funciona no servidor de quem o escreveu. No seu, duas ou três daquelas chaves vão partir alguma coisa, e não terá como saber quais porque colou tudo junto.

Os estragos são previsíveis. Despawn demasiado curto somado a alcance de spawn reduzido gera a queixa clássica de que não nascem mobs para farmar. Alcance de ativação baixo demais faz o mob deixar de andar e a farm parar com ele. Tirar a inteligência aos mobs de spawner mata mecânicas que dependem de movimento. Raio de junção alto muda a forma como o drop se agrupa no chão. E trocar a implementação de redstone altera a ordem de atualização dos fios, o suficiente para uma contraption sensível ao 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, é o que consulta a base de dados de forma síncrona a cada evento, varre entidades numa task repetida ou força carregamento de chunk fora do caminho assíncrono.