A propriedade max-chained-neighbor-updates em server.properties limita atualizações encadeadas de vizinhos antes que atualizações subsequentes sejam ignoradas. Paper descreve o limite como proteção contra cadeias muito longas; valores negativos removem o teto. Isso pode evitar que uma máquina de redstone defeituosa monopolize o servidor, mas também pode alterar comportamento de construções que dependem de cascatas grandes.

Não reduza ou desative o limite para consertar uma máquina sem reproduzir o caso em staging. Um teto existe porque uma sequência sem controle pode provocar grande carga ou travamento. Investigue a fonte e valide o efeito para cada circuito ou mapa relevante.

O que é uma atualização de vizinho

Quando um bloco muda, blocos próximos podem atualizar estado, redstone, fluido, pistão ou outras regras. Uma mudança pode desencadear outra, criando cadeia de atualizações. Circuitos e mapas complexos podem produzir sequências extensas, especialmente se possuem feedback ou uma configuração de bloco que cria cascata contínua.

O parâmetro limita uma classe de atualizações encadeadas, não o número de entidades nem todos os ticks de bloco. Paper tem também limites como max-block-ticks e max-fluid-ticks na configuração por mundo. Cada controle atua sobre trabalho diferente; não os misture.

Se o limite é alcançado, algumas atualizações subsequentes podem ser ignoradas. O circuito pode parar em estado parcial ou não completar a cascata que o construtor espera. O impacto depende da mecânica e versão. Faça teste completo e não presuma que um limite maior sempre corrige tudo.

Identifique circuito ou plugin causador

Registre coordenadas, mundo, atividade, horário e mensagem associada. Verifique se ocorreu após ligar mecanismo, carregar chunk, ativar pistão ou executar comando de plugin. Reproduza numa cópia isolada, com seed e versão equivalentes, para não expor produção.

Use profiler durante a carga. Spark pode mostrar se thread do servidor trabalha com atualizações de bloco, redstone ou lógica de plugin. Captura depois que cascata terminou pode não revelar a origem. Preserve log completo e sequência de ações.

Plugins de proteção, geradores e mecanismos customizados podem causar mudanças de bloco. Desative integração apenas em staging e teste com conjunto mínimo. Não remova plugin de produção sem backup de seus dados.

Não confunda limite com taxa de redstone

O limite não é um clock ou atraso intencional para circuitos. Também não define velocidade de ticks em geral. Se uma farm está lenta, pode depender de chunk loading, spawn, simulation distance, redstone ou configuração do plugin. Identifique a mecânica específica antes de mexer em limite de cascata.

Uma cadeia longa pode ser defeito ou projeto legítimo. Se mapa de aventura usa muitos blocos atualizados em sequência, documente a necessidade e teste para não tornar servidor público vulnerável a build que trave outros jogadores.

Considere jogadores e regiões afetadas. Uma máquina isolada que exige retirar o limite pode colocar o mundo inteiro em risco; talvez simplificar o circuito seja melhor que remover proteção global.

Encontre arquivo e precedência

Paper lista o campo em server.properties. Confira instância e arquivo ativo, já que CLI como argumento após o JAR pode substituir algumas propriedades. Veja comando de startup e painel antes de concluir que valor salvo está em vigor.

Faça cópia do arquivo e anote o valor atual. Altere somente essa opção, preservando formato e comentários. Se painel recria arquivo, atualize a fonte do painel, não o arquivo temporário. Leia log e confira comportamento depois do boot.

Valores negativos retiram o limite conforme a descrição. Não use esse caminho em produção sem razão demonstrada; ele permite cadeia crescer sem o guardrail. Se uma versão usa nome ou semântica diferente, siga referência específica da versão instalada.

Teste circuito e estabilidade em staging

Monte cópia de mundo com o mecanismo, recursos e plugins relevantes. Teste ligar, desligar, chunk unload/reload, restart e estados de erro. Valide se pistões, redstone, portas, farms e itens ficam no estado esperado depois da cadeia.

Compare valor atual com um ajuste controlado, não com limite removido por padrão. Monitore MSPT, CPU e log. Se a cascata passa a funcionar, ainda teste se há uso alto quando mecanismo entra em loop ou fica preso.

Faça teste com vários circuitos e um jogador próximo e distante. Proteções podem depender de carga de chunk ou regras de mundo; a instância vazia não reproduz necessariamente produção.

Mitigue o projeto antes de ampliar o limite

Construtores podem separar cadeia em etapas, usar observer e repetidores, remover feedback que liga saída à entrada, ou reduzir atualização redundante. Toda mudança precisa preservar intenção do mecanismo. Teste com documentação de mecânica da versão e registre diferenças.

Se plugin ou mapa de terceiros exige comportamento especial, contate o autor com repro mínima, versão e perfil. Um limite maior não corrige bug de plugin que agenda updates infinitas. Atualize ou substitua componente conforme evidência.

Proteja acesso a construção de redstone em regiões públicas. Uma farm colocada por jogador pode afetar todos; use regras e claims para conter mecanismos de alto custo quando apropriado.

Promova com rollback e comunicação

Faça backup, programe manutenção, registre circuito e valor alterado. Reinicie e teste em produção controlada, com construtor e operador disponíveis. Observe log, TPS, MSPT e estado da construção.

Se há cascata persistente, lag ou estado parcial, reverta o valor e remova ou contenha circuito antes de reabrir. Não deixe watchdog desativado nem mantenha limite negativo como workaround sem prazo.

Comunique regras de redstone à comunidade. Avise se circuitos muito grandes podem ser limitados e como solicitar revisão. Documente exceções por mapa e retire-as após temporada quando não forem necessárias.

Revise após atualizações

Atualizações do Minecraft e Paper mudam mecânicas, defaults e estrutura de configurações. Compare referência da versão e execute testes dos circuitos principais depois da migração. Guarde snapshot pré-update porque dados de mundo podem avançar.

Registre valor ativo, razão, sistemas testados e evidência. Essa documentação ajuda a separar falha legítima de circuito de atualização de configuração e mantém proteção sem quebrar builds aprovadas.

Organize testes de compatibilidade para construtores

Prepare uma instância de redstone em que construtores possam validar portas, mecanismos e relógios sem afetar a população. Mantenha versão e limites próximos à produção, mas use mundo descartável. Isso revela circuitos que dependem de loops antes de eles chegarem a um mapa público.

Ao atualizar Paper, escolha circuitos de referência e teste pulse, observer, pistões, dispensers e atualização de bloco. Registre vídeo curto e coordenadas do projeto para comparar comportamento de forma repetível.

O limite deve ser comunicado junto às regras de construção. Se máquina aprovada excede a proteção, equipe pode colaborar com o autor para dividir sequência ou reduzir updates. A conversa tende a preservar a intenção da build sem enfraquecer segurança do servidor inteiro.

Faça contenção quando cadeia não termina

Se uma cadeia infinita causa lag, pare mecanismo de maneira localizada se for seguro, desligue bloco de comando ou remova combustível no staging. Em produção, use conta autorizada e procedimento que minimize alterações. Não execute comando massivo de blocos sem snapshot.

Se necessário, coloque o servidor em manutenção e pare novos acessos à dimensão afetada enquanto preserva log. Faça backup consistente antes de ferramenta de reparo. Após conter, reinicie normalmente e confira região, entidades e persistência.

Registre causa raiz e regra preventiva. Sem esse acompanhamento, o mesmo circuito pode voltar e a equipe tenderá a desativar o limite global em vez de corrigir origem.

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.