Paper separa opções gerais de opções específicas dos mundos. A configuração padrão do mundo vive em config/paper-world-defaults.yml; um arquivo paper-world.yml dentro de um mundo pode substituir apenas valores selecionados. Essa herança evita repetir uma configuração enorme e permite tratar um lobby de modo diferente do survival.
Um erro comum é copiar o arquivo padrão inteiro para cada mundo. Isso cria muitos valores duplicados que podem ficar desatualizados depois de uma atualização. Comece com uma cópia de segurança, identifique a chave exata e altere uma opção por vez.
Localize os arquivos corretos
No diretório de configuração, paper-world-defaults.yml contém valores padrão que se aplicam aos mundos sem substituição própria. Cada mundo pode ter seu paper-world.yml no diretório de dimensão correspondente. Em mundos customizados, as pastas podem seguir namespace e chave; o nome visível no jogo pode não coincidir com o caminho literal.
Não suponha que todos os arquivos de mundo já existem ou tenham uma lista completa de opções. A documentação informa que, por padrão, um arquivo por mundo pode conter somente a chave de versão. Use a estrutura indicada para sua versão, preserve `_version` e confira o nome do mundo pelo diretório real. Faça a descoberta em uma cópia quando os caminhos forem novos para você.
Entenda a herança
Um valor não definido no arquivo do mundo herda o valor de paper-world-defaults.yml. Se o padrão muda, todos os mundos sem override passam a usar esse valor novo; mundos com valor explícito mantêm a exceção. Isso significa que ausência e cópia explícita do mesmo número não são equivalentes durante manutenção futura.
Exemplo: se quase todos os mundos usam o padrão para reabastecimento de loot, mantenha a regra geral uma vez. Para uma dimensão de recurso, adicione somente a chave necessária ao arquivo daquele mundo. O restante continua herdado. Se copiar o arquivo todo, uma futura mudança de default deixa o mundo com uma versão antiga silenciosa.
Faça uma alteração pequena
Pare completamente o servidor antes de editar arquivos. Faça backup dos arquivos e dados relevantes. Em YAML, espaços e recuos definem a estrutura; tabulação, recuo no nível errado ou chave duplicada pode invalidar a opção ou produzir um valor inesperado. Preserve a hierarquia indicada pela referência.
Copie apenas o caminho da chave que pretende sobrescrever. Por exemplo, uma configuração de entidades pode estar dentro de blocos aninhados `entities`, `spawning` e `spawn-limits`. Um número colocado na raiz não será equivalente. O exemplo oficial mostra a forma e a hierarquia; compare caractere por caractere com a sua versão.
Planeje a exceção antes de criá-la
Uma exceção por mundo deve responder a uma necessidade distinta: regras de eventos, mecânicas diferentes ou perfil de uso. “Esse mundo parece pesado” ainda não diz qual opção deve mudar. Meça o sintoma e formule uma hipótese específica. Um lobby com poucos mobs pode justificar decisão diferente de um survival em que caça e fazendas fazem parte da progressão.
Mantenha uma lista breve de overrides, sua razão, responsável e data. Sem registro, a equipe pode não perceber que um mundo ignora o default e gastar horas tentando explicar diferença de comportamento. Um arquivo com poucas exceções documentadas é mais legível que dezenas de linhas copiadas.
Valide o resultado após reiniciar
Suba a cópia ou o servidor em janela de manutenção e inspecione o console desde o início. Procure avisos sobre configuração e confirme que o mundo correto foi carregado. Inicie uma sessão de teste nessa dimensão específica; observar outro mundo não verifica a exceção.
Para uma opção de comportamento, monte uma situação simples e repetível que mostre seu efeito. Compare um mundo que mantém o padrão com o mundo override. Para uma opção de performance, capture a métrica apropriada enquanto o sintoma está acontecendo e mantenha as demais variáveis constantes.
Saiba o que configuração por mundo não resolve
Nem todas as opções globais têm uma versão por mundo. A referência distingue configurações elegíveis de configurações armazenadas em outros arquivos. Não crie chaves por adivinhação; a presença de um nome em paper-world-defaults.yml não significa que toda propriedade de server.properties possa ser substituída pelo mesmo mecanismo.
Se a mudança pretendida pertence a distância de visão, autenticação ou outra opção controlada em arquivo diferente, use a página desse arquivo e verifique prioridade de linha de comando ou painel. Ter muitos valores em YAML não torna aquela opção aplicável a mundos. Evite misturar fontes para que sua equipe encontre o ajuste real.
Atualize a estrutura com cuidado
Depois de atualizar Paper, leia as notas e a referência correspondentes. Compare somente as opções que seu projeto substitui. Defaults novos podem alterar resultado em mundos que herdam, enquanto overrides explícitos preservam um estado anterior. Faça cópia prévia e verifique o comportamento em homologação, especialmente se o mundo contém construções dependentes de uma mecânica.
Não apague um arquivo de mundo para “voltar ao padrão” antes de entender o efeito sobre todas as opções locais. Uma cópia do arquivo permite rollback; uma lista de overrides ajuda a reconstituí-los. Teste a versão e os mundos que têm exceções antes de reabrir para todos.
Recomende mudanças com evidência
Ao pedir suporte, compartilhe apenas as seções relevantes, nome e versão do servidor e cenário reproduzível. Remova segredos e informações privadas dos arquivos. Explique qual é o comportamento esperado e o que ocorreu; uma pasta completa sem contexto dificulta revisão.
Use a documentação oficial de configuração e herança do Paper, consulte o catálogo de opções por mundo e siga o guia de diagnóstico quando uma alteração não tiver o efeito esperado. A estrutura e os defaults devem sempre ser comparados com a versão em execução.
Faça revisão de uma mudança em equipe
Antes de reiniciar produção, peça a outra pessoa para conferir caminho do arquivo, recuo e versão da chave. Uma revisão rápida ajuda a detectar que um `paper-world.yml` pertence à dimensão errada ou que uma chave foi copiada de uma release diferente. Compare o diff com a cópia anterior e mantenha somente as linhas intencionais.
Na homologação, anote o mundo testado e o resultado do caso de uso. Se o mesmo default serve para vários mundos, confirme dois sem override e um com exceção. Essa amostra demonstra se a herança está funcionando do modo esperado e torna a liberação mais confiável.
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.