A propriedade level-seed em server.properties fornece a semente usada para gerar terreno quando chunks novos são criados. Alterar a seed não reconstrói chunks que já existem. O mundo pode então conter regiões antigas de uma semente e regiões recém-geradas seguindo outra, criando transição visível ou diferenças na distribuição de biomas e estruturas.

Se quer mapa coerente com seed nova, a decisão mais segura costuma ser criar mundo separado e planejar migração de conteúdo, não editar seed em produção e explorar na expectativa de que tudo mude. Preserve seed, versão, datapacks e configurações que contribuíram para gerar o mapa.

O que uma seed determina

A seed é uma entrada da geração, mas resultado depende também da versão do Minecraft, datapacks, tipo de mundo, geradores de plugin e parâmetros de configuração. A mesma seed em versões distintas pode produzir terreno ou estruturas diferentes. Registre versão completa e geradores usados para reproduzir uma área.

Seeds podem ser numéricas ou textuais conforme parser e versão. A documentação do Paper descreve o campo e o valor vazio que usa seed aleatória. Não publique uma seed se a comunidade considera descoberta do mapa parte do jogo; seeds podem permitir localizar recursos e estruturas.

Datapacks e plugins de geração podem mudar biomas e estruturas. Se existe gerador customizado, consulte documentação e preserve JAR/configuração. Mudar só `level-seed` não substitui o gerador nem converte regiões já gravadas.

Por que chunks existentes não se transformam

Chunks salvos permanecem como arquivos de região. Ao explorar além do terreno já gerado, o servidor cria novos chunks usando configuração atual. A fronteira entre antigo e novo pode ser observada por relevo, rios, biomas, estruturas ou mudanças de geração entre versões.

Essa mistura não significa necessariamente corrupção, mas pode ser indesejável em mapa de temporada ou projeto de construção. Não use ferramenta para apagar regiões no diretório original antes de saber quais coordenadas contêm construções. Um arquivo de região pode incluir várias colunas de chunks e remover o arquivo inteiro destrói mais que uma borda.

Se o mundo foi gerado por versão anterior, há também migração de formato e regras. Usar seed original não garante regeneração idêntica. O processo deve considerar data version, datapacks e status dos dados.

Escolha entre manter e criar um mapa novo

Se a intenção é mudar apenas as novas fronteiras de exploração, avalie se uma transição de chunks é aceitável. Defina uma linha clara e comunique que terreno já gerado mantém a forma. Faça cópia completa e teste a exploração numa borda de staging.

Se a comunidade quer um mundo inteiro baseado em outra seed, crie nova instância ou pasta de mundo. Combine data, regras, inventário e economia entre temporadas. Decida se jogadores podem levar itens, quais builds serão arquivadas e como o mundo antigo ficará acessível.

Para um mapa competitivo com recursos, registre seed em local restrito até o momento apropriado. Gere e valide terreno antes de evento, garanta que todos jogam na mesma versão e não compartilhe vantagem com membros da equipe.

Faça backup antes de explorar nova geração

Desligue Paper e copie mundo inteiro, dimensões, datapacks, configurações e dados dos geradores/plugins. Guarde fora do volume principal e teste restauração em staging. Não apenas duplique a pasta enquanto o servidor continua escrevendo sem mecanismo de snapshot consistente.

Registre level-seed anterior, nova seed, versão, tipo de mundo, datapacks e nome da pasta. Preserve configuração de plugins. Isso facilita reproduzir e voltar à configuração sem adivinhar por que terreno parece diferente.

Nunca rode duas instâncias ao mesmo tempo na mesma pasta para comparar seed. Use cópias separadas, portas isoladas e serviços de plugin desativados. Banco compartilhado pode misturar progresso e gerar efeito colateral.

Teste geração em cópia controlada

Crie novo mundo ou cópia descartável e percorra coordenadas de interesse. Valide spawn, biomas, estruturas, cavernas, Nether e End. Compare com ferramenta de mapa ou cliente compatível, observando versão exata. Se usa datapack de geração, confirme ordem e ativação no mundo.

Se mudar a seed de mundo existente em staging, gere novos chunks ao lado da fronteira conhecida e analise costuras. Faça rollback ao snapshot se o resultado não serve. Verifique performance e tamanho do mundo; nova geração pode consumir CPU e disco.

Teste plugins: teleporte, claims, mapa web, warps e regeneração de mundo. Plugins podem armazenar nomes, UUIDs ou coordenadas e não atualizar automaticamente ao trocar pasta ou seed.

Explique o impacto na comunidade

Antes de reset, publique prazo, mapa que será mantido, dados que serão apagados ou migrados e como recuperar construções. Faça enquete ou decisão transparente quando envolve progresso coletivo. Exporte imagens ou esquemas de builds que deixarão de existir, respeitando autoria e privacidade.

Defina janela para copiar estruturas aprovadas e limite de itens transferidos entre temporadas. Staff deve seguir as mesmas regras para evitar vantagem. Um mapa novo pode corrigir desgaste, mas também apagar anos de construção; trate como decisão editorial e comunitária.

Após abrir, monitore fronteiras, geração e denúncias de diferença entre regiões. Se o resultado depende de plugins, mantenha versões e configurações registradas para equipe poder reproduzir.

Documente para recuperação

Mantenha registro de seed, versão do Minecraft/Paper, nome de mundo, datapacks, gerador, borda e data de criação. Proteja seed se ela revelar recursos estratégicos. Armazene backups e teste restauração de forma isolada.

Ao atualizar versão, consulte guia de migração de Paper. Não volte ao JAR anterior sem backup anterior à conversão quando dados tiverem avançado. Seed não corrige incompatibilidade de chunk e não reverte migração.

Trate a seed como parâmetro de geração futura e o mundo salvo como dados existentes. Essa diferença evita reset acidental e ajuda a planejar novo mapa com controle, backup e expectativas alinhadas.

Valide a seed com ferramentas compatíveis

Mapas de seed na internet podem usar versão diferente, gerador padrão ou datapack distinto. Confira versão do Minecraft e ferramenta antes de confiar em coordenadas de aldeias e biomas. Faça teste no jogo em mundo de staging e percorra coordenadas para confirmar.

Se mantém seed secreta, cuidado com screenshots de coordenadas, logs, mapas web e comandos de debug. A seed pode revelar recursos e estruturas, afetando a economia ou competição. Controle acesso a dados de mapa e use política igual para a equipe.

Se a seed está vazia no arquivo, o servidor pode escolher valor aleatório ao criar o mundo. Guarde a seed revelada pelo comando administrativo autorizado e registre junto à versão se for importante reconstruir terreno. Faça isso sem publicar informação estratégica.

Prepare uma nova temporada de forma justa

Gere mapa antecipadamente e inspecione spawn, terreno próximo, biomas, estruturas e rotas de recursos. Se há competição, escolha método imparcial e documente quem tem acesso antes da abertura. Evite que construtores tenham acesso ao mapa completo enquanto jogadores não podem explorar.

Defina tamanho de borda e política de exploração, backups, horário de abertura e migração de itens. Gere novos chunks antes do pico quando o objetivo é evitar worldgen ao vivo. Teste teleporte, portais e plugin de mapas na cópia.

Ao migrar construções escolhidas, use ferramentas conhecidas e trabalhe em cópia. Verifique blocos customizados, entidades, inventários e orientação. A colagem de uma área pode depender de plugins e de versão; não presuma que todas as propriedades são portáveis.

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.