view-distance e simulation-distance controlam aspectos diferentes do alcance ao redor dos jogadores. Reduzir os dois valores indiscriminadamente pode aliviar uma carga e ao mesmo tempo tornar o mundo menos agradável: regiões aparecem com menos antecedência, fazendas funcionam a uma distância menor e tarefas de jogo podem deixar de acontecer longe dos jogadores.

Este guia explica como entender cada limite, localizar qual configuração prevalece no seu Paper e testar uma alteração usando uma cópia. O ponto de partida é verificar o problema medido; não existe um valor único que sirva a todas as comunidades, computadores e padrões de jogo.

Entenda o alcance visual

view-distance limita a distância a que o servidor envia chunks aos clientes, respeitando a configuração do cliente até o limite que o servidor permite. A referência do Paper descreve esse alcance como raio em chunks e informa um valor padrão no server.properties. A visão final percebida também depende das configurações do cliente e da rede.

Reduzir o valor pode diminuir o trabalho associado a fornecer regiões distantes, mas altera a experiência. Paisagem, construções e entidades deixam de ser enviadas tão longe. Uma comunidade que explora, fotografa mapas ou observa mecanismos a longa distância pode notar o efeito imediatamente.

Não confunda essa opção com a distância que o jogador definiu no computador. O servidor impõe seu teto; o cliente pode solicitar uma distância menor, mas não obrigar o servidor a enviar além do que permite.

Entenda a simulação

simulation-distance governa outro tipo de alcance ao redor de cada jogador: a região em que o servidor mantém atividades de jogo relevantes sendo simuladas. Entidades, fazendas e processos próximos podem depender dessa área. O resultado de uma redução pode aparecer em mecanismos de jogo sem que a paisagem visível mude do mesmo modo.

É comum manter simulação igual ou menor que visão, mas isso não elimina a necessidade de testar. Um jogador pode ver terreno distante sem que ele esteja sendo simulado da mesma forma que a região próxima. Registre o valor antes da mudança e escolha uma fazenda simples como exemplo para conferir o efeito.

Não trate quantidade de chunks como uma contagem exata de memória nem converta um valor em jogadores garantidos. Há sobreposição de regiões entre jogadores e custos que dependem do mundo. A medição da carga real deve incluir distâncias, localizações e ações dos jogadores.

Confira qual arquivo controla o valor

Em Paper, comece pelo server.properties. O arquivo spigot.yml também contém ajustes de view-distance e simulation-distance sob configurações por mundo, que podem usar o valor padrão ou sobrepor a configuração base.

Antes de alterar qualquer coisa, identifique os mundos e as entradas em world-settings. Uma opção definida como default ou -1 pode delegar ao valor do arquivo base. Uma substituição explícita pode fazer o Nether ou o lobby se comportar de maneira diferente do survival.

Faça uma cópia dos dois arquivos e anote valores atuais. Pare o servidor pelo painel antes de editar. Não troque o nome ou a estrutura de outras opções ao tentar inserir uma linha: um YAML com recuo incorreto pode fazer Paper ignorar uma seção ou registrar um aviso.

Meça o problema antes de escolher o ajuste

Observe uma situação real que cause lentidão, não somente uma tela vazia no lobby. Registre quantidade de jogadores, locais, exploração, MSPT e uso de recursos no intervalo. Use Spark para capturar o perfil enquanto o sintoma ocorre.

Se o problema for rede de envio de chunks, uma mudança de view distance pode ter relação. Se o tick principal estiver ocupado por plugin ou entidade, reduzir somente essa opção pode deslocar a experiência sem corrigir a causa. Em Paper, profiling com Spark ajuda a localizar trabalho durante o problema e a documentar a diferença entre dois cenários.

Faça uma hipótese específica: “A carga aumenta quando quatro jogadores geram terreno em lugares separados; reduzir view distance um passo no mundo de teste deve reduzir o trabalho de chunk send sem interromper as fazendas na região próxima”. Uma hipótese assim é verificável; “baixar tudo para otimizar” não define o que será medido.

Teste por etapas

  1. Copie os dados e configurações para uma instância separada.
  2. Confira se os valores não estão sobrescritos por mundo.
  3. Altere somente a opção associada à hipótese inicial.
  4. Inicie e leia os avisos do console; confirme que a configuração foi carregada.
  5. Repita a carga de teste com posições e atividades comparáveis.
  6. Confira MSPT, comportamento de fazendas e qualidade visual.
  7. Registre resultado e restaure o arquivo se a hipótese não se confirmar.

Se uma etapa melhorar a carga, preserve esse estado e teste a segunda distância separadamente. Alterar duas opções ao mesmo tempo impede identificar qual delas produziu o resultado. Evite aplicar um valor mais baixo do que o necessário sem avaliar a experiência dos jogadores.

Considere diferenças entre mundos

Lobby, survival, mundo de minijogo e arenas podem precisar de políticas diferentes. A referência de configuração do Paper descreve onde algumas opções por mundo podem ser sobrescritas. Use isso somente quando a necessidade for clara; cada exceção adiciona uma escolha que alguém terá de explicar e revisar.

Se jogadores alternam rapidamente de mundo, confirme que as regras esperadas se aplicam no destino. Uma fronteira de visão menor no lobby pode fazer sentido se o ambiente é simples; um mapa técnico ou uma área de evento pode requerer outra expectativa. Documente as diferenças para que uma correção global não as apague.

Diagnostique quando a mudança não funciona

Primeiro confira se Paper carregou o arquivo modificado e se há override no mundo relevante. Depois compare uma conta em um mundo específico e verifique se o cliente solicitou alcance menor. Não altere vários arquivos ao mesmo tempo tentando fazer o número da tela corresponder ao valor inserido.

Se uma fazenda parou, confirme onde estão o jogador e as entidades, como a mecânica depende de simulação e qual plugin ou datapack participa do processo. Se a paisagem parece curta, confira view distance, cliente e posicionamento. Guarde logs e reproduza em um teste antes de mudar outra opção.

Libere a mudança somente com benefício confirmado

Repita a medição em uma carga comparável e anote o efeito no jogo. Se o número melhorou mas a limitação visual prejudicou a comunidade, avalie outro caminho de diagnóstico. Se o número não mudou, reverta a alteração e investigue o perfil em vez de continuar baixando valores.

A documentação do Paper atualiza valores padrão e o comportamento por versão. Consulte server.properties, spigot.yml e a estrutura de configuração na versão instalada antes de fazer manutençã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.