A opção max-block-ticks na configuração de mundo do Paper define o máximo de ticks de bloco processados em um tick do servidor. A referência apresenta esse limite como proteção contra travamento quando há grande número de atualizações de bloco. Um limite evita trabalho sem fim num único ciclo, mas, se atingido, pode alterar mecânicas ou deixar parte do processamento pendente conforme versão.

Não aumente o teto para resolver lag sem descobrir qual bloco, plugin ou máquina gera a carga. O valor padrão é uma proteção, não um alvo de desempenho. Aumentá-lo pode permitir que mais trabalho se concentre no tick e amplie a pausa percebida.

Entenda ticks de bloco

Blocos podem agendar atualizações para crescimento, redstone, fogo, fluidos e outras mecânicas. O servidor processa uma fila por tick. Uma máquina ou alteração em massa pode criar volume enorme. `max-block-ticks` limita o quanto é processado por tick; não define quantidade total de blocos no mundo nem frequência normal de updates.

Paper também possui max-fluid-ticks para ticks de fluido e propriedade global max-chained-neighbor-updates para outro tipo de cadeia. Estes limites não são intercambiáveis. Uma inundação de água pode precisar de análise de fluid ticks, enquanto uma cascata de vizinhos tem mecanismo diferente.

Quando um teto entra em jogo, comportamento de farms, redstone, mapas customizados e mecanismos pode mudar. Faça teste com versão exata e preserve mundo; não assuma que valores de tutorial ou de outra versão produzem o mesmo resultado.

Encontre a origem da cascata

Registre mundo, coordenadas, ações, número de jogadores, mensagem do log e horário. Veja se o problema ocorre ao carregar chunk, explodir bloco, ativar redstone, plantar, fluir água/lava ou executar ferramenta de plugin. Faça backup e reproduza em staging.

Capture spark enquanto a lentidão acontece. Verifique se a thread principal está em atualização de bloco, lógica de redstone ou plugin que altera o mundo. Perfil não ativo no momento do problema não identifica método dominante.

Investigue construções que criam loop, máquinas de bloco, duplicação de updates e plugins de geração. Isole a região por cópia e desligue integração em staging uma de cada vez. Não remova blocos ou plugins de produção antes de preservar estado.

Não confunda lag com perda de update

TPS baixo indica que ciclos normais estão lentos; teto de block ticks se refere à quantidade processada dentro de um tick. Se uma fazenda produz menos, pode haver lag geral, chunk descarregado, mobcap, random tick ou limite de update. O sintoma precisa ser testado em mais de um cenário.

Compare mundo ativo com cópia sem o circuito. Observe se blocos e pistões ficam em estado inesperado, se atualizações recuperam depois ou se log informa proteção ativada. Não corrija mexendo em ticks sem identificar o tipo exato.

Use ferramentas de comando e debug do Paper com cuidado. Algumas saídas são destinadas a desenvolvedores e podem conter detalhes difíceis de interpretar; compartilhe o contexto e versão quando buscar suporte.

Localize configuração por mundo

A propriedade fica em configuração Paper por mundo, em defaults globais e possíveis overrides. Confirme caminho da versão atual e se mundo herda default ou define valor próprio. Modificar arquivo global não altera um mundo que tem override.

Faça cópia de `paper-world-defaults.yml` e `paper-world.yml`, preserve indentação e copie só a chave necessária. Não copie o arquivo inteiro para cada mundo: Paper orienta colocar apenas overrides usados. Após reiniciar, confira log e comportamento real.

Verifique se host ou painel regenera configs e se a instância ativa usa outro diretório. Leia startup command e CLI settings antes de editar. Mantenha inventário dos mundos e dimensões importantes.

Teste valor e circuito juntos

Em staging, execute sequência controlada: gerar atividade, observar TPS/MSPT, carregar/descarregar região, reiniciar e repetir. Compare valor existente com um ajuste modesto se há justificativa, mantendo o mesmo circuito. Aumentar muito pode esconder problema até que outro jogador ativa algo maior.

Valide redstone, crescimento, pistões, fluidos, pistões pegajosos, observers e interações de plugin. O modo precisa funcionar em estado normal e de falha. Teste com vários chunks ativos, porque fila total e interação podem variar.

Defina critério de parada: tick ultrapassa meta, watchdog dispara, TPS não recupera ou conteúdo fica inconsistente. Pare teste antes de saturar host e preserve logs.

Corrija mecanismo e plugins na origem

Para circuitos, reduza updates redundantes, elimine feedback involuntário e limite escala. Para plugin, atualize ou reporte com reprodução mínima. Um limite mais alto não torna código síncrono eficiente; pode permitir maior travamento.

Se evento de plugin atualiza milhares de blocos, use mecanismos suportados para dividir operação no tempo e permitir cancelamento. Não altere mundo assíncronamente se API não é segura. Desenvolvedores devem seguir scheduler e documentação da API.

Estabeleça regras de construção em áreas públicas e contenha máquinas caras com regiões, sem impedir projetos permitidos. Combine moderação técnica com processo transparente de aprovação.

Promova e reverta com segurança

Faça backup integral, desligue corretamente, aplique configuração testada e reinicie. Observe logs e métricas durante atividades que antes causavam problema. Tenha cópia original e gatilho de rollback fácil de seguir.

Se comportamento não melhora ou passa a concentrar mais trabalho por tick, restaure valor anterior e remova causa. Não desative watchdog junto com limite de block ticks para esconder consequências. Esse conjunto pode deixar servidor travado por mais tempo.

Avise a equipe que uma alteração pode impactar redstone e farms. Registre o mundo, versão, valor anterior e atual, cenário de teste e resultado. Revise após updates do Paper.

Proteja o mundo e a experiência

Mantenha backups e ensaios de restauração. Se updates ignoradas ou circuitos alteraram mundo, preserve logs e snapshot antes de reparar. Não use ferramentas destrutivas no original durante investigação.

A configuração adequada permite ao servidor sobreviver a cascatas sem cortar mecanicamente a experiência normal. O resultado vem de limite documentado, causa identificada e teste com construções reais da comunidade.

Inspecione chunks e construções com comandos

Use comandos de Paper como `/paper chunkinfo` e ferramentas de profiling para entender estado e quantidade de chunks, mas leia ajuda da versão: alguns dumps são destinados a desenvolvedores. Não compartilhe arquivos de diagnóstico com caminhos, nomes ou detalhes privados sem revisão.

Compare chunk que hospeda mecanismo com chunks vizinhos e veja se quantidade de atualizações coincide. Desative mecanismo por cópia, não por edição da única versão ativa. Correlacione com logs e coordenadas, lembrando que build pode atravessar fronteiras de chunk.

Se o incidente está em uma região de jogador, envolva equipe de moderação para proteger construção e explicar contenção. Não apague área sem comunicar dono e sem cópia.

Estabeleça política de escala

Defina limites de entidades, circuitos contínuos e máquinas de bloco em regras de construção. Uma política previsível reduz incentivos a designs que dependem de valores extremos. Ofereça ambiente de redstone separado para testar mecanismos de alto custo.

Crie processo para aprovação de máquinas que afetam vários jogadores, com staging e medição. Reavalie após mudar Paper ou configuração. Uma construção aprovada numa versão pode exigir teste de regressão depois de atualização.

Explique como reportar construção que causa lag, preservando coordenadas para equipe e evitando acusação pública sem evidência. A equipe pode desativar circuito temporariamente e revisar logs com o construtor.

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.