As opções view-distance e simulation-distance controlam partes diferentes da experiência de um servidor Minecraft. A primeira define até onde dados do mundo são enviados ao cliente; a segunda limita a área em que entidades vivas são atualizadas pelo servidor. Confundir as duas pode gerar expectativas erradas: reduzir a simulação não significa necessariamente esconder todo o terreno, e aumentar a visualização não acelera a geração de chunks.
Ambas são definidas em server.properties, mas a configuração de mundo e os limites da instalação também importam. Paper permite configurações por mundo e propriedades de JVM que podem alterar limites. Antes de copiar valores de outra rede, confirme qual configuração efetivamente controla cada mundo na versão em uso.
O que view distance altera
view-distance mede o raio de chunks que o servidor envia aos clientes. A documentação do Paper descreve a unidade em chunks para cada direção do jogador, como raio em vez de diâmetro. Um valor alto permite enxergar terreno mais distante, mas pode aumentar trabalho de carregamento, tráfego de rede, uso de memória e esforço do cliente. O efeito depende de quantos jogadores estão espalhados por regiões diferentes e do quanto os chunks ainda precisam ser gerados.
Distância enviada não é sinônimo de distância de renderização escolhida localmente. O cliente pode renderizar menos que o limite do servidor, mas não pode receber além do que o servidor disponibiliza. Para investigar o que um usuário enxerga, considere também configurações gráficas, mods de cliente, geração pendente e barreiras de mundo.
Se chunks próximos demoram a aparecer ao correr, observe primeiro se são terrenos novos e se há pico de CPU ou disco durante a geração. Reduzir view distance pode diminuir a quantidade de dados que a instância precisa enviar, mas não corrige sozinho um gerador lento, armazenamento saturado ou plugin que força carregamento. Identificar o gargalo evita esconder um problema de geração com uma distância excessivamente curta.
O que simulation distance altera
simulation-distance define até onde entidades vivas podem estar para serem atualizadas pelo servidor. Fora dessa área, entidades não são tickadas e também não ficam visíveis para os jogadores segundo a referência atual de Paper. Isso pode afetar movimento e comportamento de mobs, fazendas, animais, projéteis e sistemas que dependem de entidades ativas.
A distância é diferente da área em que blocos e redstone funcionam: cada mecânica pode ter suas próprias regras de ticking, chunks carregados e alcance. Portanto, uma fazenda que deixa de operar não deve ser diagnosticada apenas pela distância. Confira documentação da versão, estado do chunk, dimensões, entidades e plugins que alteram carregamento.
Jogadores costumam notar a simulação reduzida quando mobs param de se movimentar mais cedo, animais deixam de avançar ou uma estrutura parece funcionar somente perto deles. Se a comunidade depende de farms, combine uma distância adequada com regras explícitas sobre chunk loaders e limites de entidades. Não prometa que toda construção funcionará em qualquer distância sem validar a mecânica.
Meça antes de alterar
Estabeleça uma linha de base em um horário de pico: número de jogadores, localização, MSPT, TPS, CPU, memória, tráfego e relatos de chunks demorando a carregar. Use profiling conforme a documentação do Paper e compare períodos com a mesma atividade. Um teste com três jogadores em um spawn vazio não representa uma noite com dezenas de jogadores explorando regiões novas.
Faça uma alteração por vez e anote o valor anterior. Se o problema é carga de geração durante exploração, teste uma pequena redução de view distance em staging e percorra terrenos conhecidos e novos. Se o problema envolve entidades ou farms, altere simulation distance isoladamente e verifique o comportamento em diferentes mundos. Comparar um conjunto de mudanças simultâneas impede saber qual ajuste ajudou ou prejudicou.
Registre também como o valor foi definido. Painéis podem reescrever server.properties no restart; arquivos por mundo podem sobrescrever valores globais, e um limite máximo pode recortar o valor. Leia as configurações após o boot e confira o log ou ferramentas administrativas disponíveis para saber o valor efetivo em runtime.
Escolha um perfil coerente com o servidor
Um lobby pequeno com jogadores concentrados pode tolerar configuração diferente de um survival exploratório com muita geração de terreno. Em um modo competitivo, visibilidade consistente e comportamento previsível podem valer mais que alguns pontos de desempenho. Em um servidor focado em exploração, limites curtos podem frustrar viagens e farms, mesmo que reduzam carga.
Não existe um par universal de valores. Comece próximo do que sua capacidade e comunidade exigem, depois faça testes reproduzíveis. A documentação lista limites permitidos no arquivo e o valor padrão depende da configuração e versão. Nunca conclua que “mais baixo sempre é melhor”: se a instância já é limitada por disco ou um plugin, o ajuste pode deslocar a experiência sem remover o gargalo.
Considere distribuição dos jogadores. Quando a população está espalhada, cada grupo pode induzir carregamento de uma área diferente. Quando todos ficam no mesmo hub, o perfil de chunks é mais concentrado. Eventos que teleportam muitos usuários para regiões diferentes também podem revelar picos que não aparecem no teste de rotina.
Considere configurações por mundo e sobrescritas
Paper separa configurações globais e configurações que podem ser definidas em cada mundo. Um mundo pode herdar padrões ou substituir opções, então uma mudança global não garante comportamento idêntico em survival, lobby, Nether, End ou mapas temporários. Revise os arquivos associados a cada mundo e a documentação da versão em que você executa.
Procure valores como view-distance ou simulation-distance em configurações legadas e específicas. Não edite um caminho antigo baseado num tutorial de outra versão. Paper reorganiza arquivos ao longo do tempo; use a referência de configuração atual e confira comentários gerados pelo próprio servidor. Faça cópia antes de editar YAML e preserve a indentação.
Também verifique se o painel injeta parâmetros de inicialização ou ativa limites por propriedade de JVM. Um teto de view distance pode impedir que um valor maior tenha efeito, enquanto outro arquivo pode reduzir a distância real. Anote cada origem para poder explicar o resultado e desfazer apenas a mudança necessária.
Teste a experiência, não somente a métrica
Depois de alterar, teste do ponto de vista de jogadores. Compare exploração a pé e em alta velocidade, veja o surgimento de terreno, observe mobs em diferentes raios e valide farms representativas. Peça a jogadores com computadores e conexões variados que experimentem; a taxa de quadros do cliente e a rede doméstica influenciam a percepção.
Repita medidas de MSPT e CPU durante cenário semelhante ao de referência. Uma melhora na métrica acompanhada de chunk pop-in ou mobs invisíveis pode não ser aceitável. Combine dados técnicos e feedback objetivo: local, horário, atividade e vídeo ou log quando a questão puder ser reproduzida.
Se o desempenho não mudar, restaure o valor anterior e continue a investigação. Não acumule ajustes sem evidência, nem aplique valores extremos em produção para “ver se resolve”. A distância é um controle de capacidade e experiência, não uma cura geral para lag.
Implemente com reversão pronta
Agende uma janela, faça backup dos arquivos de configuração e anote os valores atuais por mundo. Altere uma configuração, reinicie conforme a versão exigir e confirme o estado efetivo depois do boot. Tenha um plano de retorno: versão anterior dos arquivos, procedimento e pessoa responsável.
Comunique o que muda em linguagem de jogador: quantos chunks serão enviados ou até onde entidades serão simuladas, e o que isso pode alterar em farms. Se um modo de jogo exige distâncias distintas, explique a configuração por mundo e revise a experiência individualmente em vez de aplicar uma política invisível a toda a rede.
Após o período de observação, registre se o ajuste ficou, voltou ou mudou novamente. Isso cria histórico útil para a próxima atualização e impede que um valor experimental vire padrão esquecido. Acompanhe também a documentação do Paper, pois opções e comportamento podem mudar entre versões.
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.