A opção entity-broadcast-range-percentage em server.properties controla a que distância entidades precisam estar para serem enviadas aos clientes. Ela afeta visibilidade e tráfego de pacotes. Não remove mobs do mundo, não os impede de executar comportamento e não substitui simulation-distance. Entender essa diferença evita reduzir a visibilidade esperando uma queda garantida de CPU.

Na documentação do Paper, o valor é expresso como porcentagem do alcance padrão, com limites permitidos definidos pela referência. Por exemplo, reduzir a porcentagem diminui o alcance de envio. O cliente ainda aplica suas próprias configurações gráficas, e o servidor pode combinar outros limites de distância e configurações de mundo.

Entenda o que os jogadores vão notar

Com alcance menor, mobs, projéteis ou outras entidades podem deixar de ser mostrados quando estão mais longe. Ao se aproximar, o cliente recebe os dados e passa a renderizá-los; ao se afastar, eles deixam de ser enviados conforme as regras do servidor. A experiência pode parecer menos povoada e entidades importantes podem surgir de forma mais abrupta.

Nem toda entidade se comporta igual e plugins podem criar objetos ou alterar rastreamento. Teste categorias relevantes para o seu modo de jogo: mobs hostis, animais, itens no chão, veículos, projéteis e entidades especiais de plugins. Em um modo PvP, ver um oponente tarde demais pode prejudicar equidade; em um survival, desaparecerem animais de uma fazenda pode gerar confusão.

A opção não controla até onde o mundo em blocos é carregado, nem a distância de tick das entidades. Aumentar ou reduzir essa configuração não deve ser usado como atalho para view distance. Separe três perguntas: qual terreno o cliente recebe, quais entidades são atualizadas e quais entidades são transmitidas.

Quando o ajuste pode ajudar

Uma população de entidades enviada a muitos clientes pode consumir rede e trabalho de preparação de dados. Se a captura de perfil e as métricas apontam para esse tipo de carga, um alcance menor pode reduzir o que cada cliente precisa receber. O ganho depende da atividade, versão, número de jogadores e natureza dos plugins; não é garantido pela mudança isolada.

Antes de mexer, use profiling para identificar se os ticks de entidades são o problema ou se o gargalo está em geração de chunks, disco, redstone, plugin ou rede. Se o MSPT alto vem de lógica de mobs, limitar transmissão talvez reduza tráfego, mas a entidade pode continuar sendo processada no servidor. Uma mudança sem relação com a causa costuma apenas mudar o sintoma visual.

Considere o caso de uso. Um lobby com muitos NPCs cosméticos pode se beneficiar de visibilidade curta se o design aceitar isso. Uma arena competitiva pode precisar de valores maiores e consistentes. Um servidor técnico com farms precisa explicar que transmissão não equivale a atividade: o mob pode existir, ser tickado em certo alcance e ainda não aparecer no cliente distante.

Meça em cenário comparável

Registre valor atual, versão, quantidade de jogadores, quantidade aproximada de entidades e comportamento de rede. Escolha uma área representativa: um spawn, uma arena ou uma região de farms. Compare com os mesmos jogadores e ações, na mesma distância, antes e depois. Evite medir com um mundo vazio e concluir sobre uma rede cheia.

Use uma instância de teste quando possível. Em um cliente de teste, observe quando entidades aparecem e somem, se há flicker ao cruzar um limite e se o jogo permanece justo. Compare estatísticas de saída de rede e métricas do servidor. Peça feedback específico: entidade, coordenada aproximada, distância e atividade; “parece estranho” não basta para localizar a configuração culpada.

Altere uma variável por vez. Primeiro ajuste o alcance em uma margem modesta, reinicie se necessário e verifique o valor ativo. Se os jogadores não percebem diferença e a métrica não melhora, reverta. Se o resultado técnico melhora, mas a jogabilidade sofre, decida com critérios do modo e não esconda o trade-off.

Confira sobrescritas e escopo

Leia server.properties da instância realmente iniciada. Painéis frequentemente mantêm pastas e configurações distintas por servidor, e algumas instalações podem regenerar o arquivo no boot. Verifique o diretório de trabalho, a configuração efetiva e as demais distâncias do Paper antes de diagnosticar que o valor “não funcionou”.

Procure plugins que mudam visibilidade, escondem jogadores ou entidades, criam NPCs ou implementam modos de vanish. Um plugin pode ocultar uma entidade por permissão ou mundo, independentemente do limite de broadcast. Faça teste sem ele apenas em staging e usando cópias de dados; remover plugins em produção pode apagar informações ou interromper integrações.

Se o ajuste for planejado para mundos distintos, confirme o que Paper permite configurar por mundo na versão instalada e se a opção específica é global ou herdada. Não invente uma chave YAML de um tutorial não oficial. Consulte as páginas oficiais e os comentários do arquivo gerado pelo servidor.

Proteja competitividade e acessibilidade

Alcance de entidades interfere em informação compartilhada entre clientes. Para PvP, minigames ou eventos, mantenha as mesmas regras para todos e documente o comportamento. Verifique combate, perseguição, veículos e projéteis em diferentes direções; um ajuste pode mudar quando a ameaça se torna visível e afetar a percepção de segurança.

Jogadores com conexões lentas podem se beneficiar de menos tráfego, enquanto outros dependem de visibilidade antecipada para orientação. Avalie o servidor como produto: métricas, feedback e regras do jogo. Não force todos os modos a usar o mesmo valor se os objetivos diferem e se a configuração puder ser administrada com clareza.

Se uma mecânica acessível depende de perceber entidades distantes, ofereça instruções ou sinais adicionais. Evite que mudanças de desempenho removam pistas necessárias para participar. A documentação técnica explica o controle, mas a decisão envolve a experiência que a comunidade espera.

Faça a mudança com um plano de retorno

Salve uma cópia de server.properties e registre o valor anterior e a data. Aplique a mudança durante manutenção, reinicie pelo método normal e confira o log. Teste com uma conta sem permissões especiais, já que ferramentas administrativas podem mostrar entidades de maneira diferente ou contornar configurações visuais.

Comunique o efeito antes de aplicá-lo e observe a comunidade após a mudança. Defina quando rever: por exemplo, depois de um evento e um período de pico. Se aparecer problema, restaure o valor e registre o caso antes de tentar outra alteração.

Mantenha perfil de desempenho, configurações e plugins associados à decisão. Esse histórico distingue um ajuste medido de uma recomendação genérica e facilita repetir os resultados depois que Paper ou plugins forem atualizados.

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.