A configuração de mundo max-fluid-ticks do Paper limita quantas atualizações de fluido podem ser processadas em um tick do servidor. A referência descreve o teto como proteção contra travamento quando há um número grande de atualizações. Água e lava podem gerar atividade extensa em cascatas, redstone e mudanças de blocos, então o limite serve de contenção quando algo sai do controle.

Aumentar o teto pode permitir mais trabalho de fluido no mesmo tick e ampliar uma pausa; reduzir pode alterar como uma cascata se propaga. Não trate o número como taxa de fluidez ou solução universal para lag. Encontre o trecho que gera o fluxo e teste em cópia antes de mudar.

Como fluido gera trabalho

Ao mudar de posição, fluidos verificam blocos próximos, atualizam estados e podem desencadear novos ticks. Uma fonte simples pode ser barata; uma coluna extensa com milhares de blocos e mecanismos que removem/recolocam fluido pode criar volume alto. Lava, água, dispensers, pistões e plugins podem interagir.

O limite se aplica por tick do servidor e vive na configuração de mundo. Se trabalho excede teto, servidor se protege contra processamento ilimitado no ciclo. Consequência concreta para cada construção depende da versão e do tipo de update; valide em staging.

Não confunda com max-block-ticks, que limita outro conjunto de atualizações. Se log não identifica qual teto atua, colete perfil e reproduza. Mudar ambos ao mesmo tempo retira clareza do diagnóstico.

Encontre o fluxo responsável

Registre mundo, coordenadas, horário, ação e mensagem do log. Descubra se cascata é natural, criada por jogador, redstone, plugin ou comando. Faça cópia e reproduza com a menor construção que preserva o problema.

Use spark durante o pico. Perfil pode revelar thread principal ocupada em scheduled fluid ticks, atualização de bloco ou plugin. Se problema ocorre quando uma máquina inicia, compare perfil com mecanismo desligado. Não faça benchmark com água ou lava em produção sem plano de limpeza e backup.

Verifique proteção de regiões, claims e permissões de redstone. Em evento, construtor pode ter colocado máquina sem revisão. Audite mods e plugins que simulam fluidos, geram blocos ou transferem dados.

Confirme escopo por dimensão

Overworld, Nether e mundos customizados podem ter configurações por mundo distintas. Leia defaults e `paper-world.yml` da versão Paper. Um override pode prevalecer sobre configuração global. Determine qual mundo contém a cascata e edite somente o escopo necessário.

Seções YAML precisam preservar indentação. Faça cópia antes, altere apenas max-fluid-ticks e reinicie. Paper não aplica necessariamente toda opção com reload; siga procedimento oficial para a versão e não use comando `/reload` como atalho.

O painel pode recriar arquivos ou iniciar outra instância. Confira diretório e logs. Depois do boot, verifique se configuração foi aceita e teste de novo com cenário autorizado.

Avalie custo e comportamento em staging

Execute o fluxo em cópia de mundo com mesmo Paper, plugins e regras. Observe MSPT, TPS, CPU, logs e o resultado da construção. Altere um valor por vez e compare várias repetições para separar variabilidade de efeito.

Teste fluido em chunks já carregados e com unload/reload. Confirme se farm, redstone, proteção e plugin continuam corretos. Observe se updates são atrasadas, não processadas ou continuam em ticks posteriores conforme comportamento da versão.

Defina limites de teste e pare antes do watchdog. Se há grande inundação, contenha origem primeiro. Um benchmark não deve provocar perda ou dados corrompidos para provar que um teto é alto.

Mitigue projeto antes de subir teto

Remova loops ou atualizações redundantes, limite volume de fluido, use fonte controlada e revise temporizadores de dispensers. Em plugin, distribua operações e permita cancelamento com API segura. Corrija em origem para manter proteção em todo o servidor.

Se um mapa legítimo requer fluxos extensos, documente o mundo e as coordenadas, teste capacidade e mantenha exceção de escopo restrito se a configuração suportar. Não relaxe limites globais para acomodar uma única construção sem compreender risco.

Adote regras para máquinas que possam causar cascatas. Explique limite, processo de aprovação e responsabilidade pela manutenção. Isso reduz novos incidentes e ajuda construtores a projetar dentro das capacidades.

Promova com backup e reversão

Faça snapshot integral e guarde configuração anterior. Aplique mudança em janela, reinicie e monitore cenário real. Tenha responsável capaz de reverter e parar mecanismo rapidamente se o perfil degradar.

Se o teto aumentado não melhora fluidez ou causa picos maiores, restaure o valor e remova origem. Não desative watchdog e não adicione mais flags ao mesmo tempo. Uma reversão de dados só é segura se mundo e bancos estão no mesmo ponto de restauração.

Avise equipe e comunidade quando farms ou mecanismos podem mudar. Registre valor por dimensão, motivo, evidência e data de revisão.

Revise após atualização

Atualizações podem alterar implementação de fluidos e formato de configurações. Leia notas e defaults novos, compare overrides e reteste construções centrais. Remova tuning temporário que não é mais necessário.

O limite protege o tick, mas não elimina a causa de uma cascata. Controle de fluxo, profiling, configuração por mundo e recuperação validada mantêm o serviço estável sem escolhas cegas.

Evite testes destrutivos em mapas ativos

Uma parede de água ou lava em produção pode alterar terreno, claims e construções mesmo depois de a carga diminuir. Reproduza a estrutura numa cópia isolada e use uma área descartável. Antes de remover fluido em produção, confirme dono, backup e alcance de região.

Plugins de rollback registram blocos em ritmos diferentes e não substituem snapshot de mundo. Uma cascata extensa pode criar milhões de alterações e lotar log de rollback. Informe equipe, limite região e confirme que ferramenta consegue restaurar antes de limpar.

Não use WorldEdit ou comando massivo de blocos sem testar. A própria ferramenta pode agendar atualizações de fluidos e causar nova cascata. Faça operação em etapas, monitore TPS e mantenha comando para interromper.

Organize incidentes de fluido

Se inundação começa, contenha origem de forma segura e pause mecanismos que a alimentam. Preserve log e coordenadas, comunique jogadores próximos e impeça que novos chunks carreguem a área se isso aumenta a propagação. Não desligue bruscamente serviço durante gravação sem avaliar risco.

Após conter, verifique blocos adjacentes, redstone, spawners e plugins de região. Faça backup e compare estado antes de aplicar rollback. Se os dados continuam mudando, pare a instância de forma controlada para proteger cópia consistente.

Uma resposta ensaiada reduz custo: equipe conhece permissões, ferramentas e comunicação. Documente causa, prevenção e critérios para impedir repetição.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.