Floodgate permite que contas Bedrock autenticadas por esse fluxo entrem numa rede Java compatível sem possuir conta Java, quando Geyser e proxy estão configurados conforme documentação. O servidor precisa reconhecer a identidade encaminhada. Prefixo de nome e UUID fazem parte dessa identidade prática: mudar como nome chega pode afetar permissões, whitelist, inventário e dados vinculados.

Por isso, não trate a opção de prefixo como cosmética. Faça backup dos mundos e bancos, inventarie jogadores afetados e teste um cenário completo antes de atualizar, trocar topologia ou remover prefixo.

Entenda o que o prefixo protege

O prefixo diferencia nomes Bedrock das contas Java que podem ter o mesmo nome textual. Em ambientes mistos, essa distinção ajuda plugins e operadores a identificar a origem da conta. A sintaxe e configuração do prefixo pertencem ao Floodgate; confira a documentação da versão instalada.

Remover o prefixo pode simplificar chat, mas também cria colisões visuais ou inconsistência de identificação. Um jogador Java e um Bedrock com nomes correspondentes ainda são entidades distintas, e o servidor deve usar UUID recebido pelo fluxo de autenticação para determinar dados persistentes.

Preserve UUID e dados do jogador

Mundos Java guardam progresso em estruturas ligadas a identificadores. Permissões, inventários e plugins também podem mapear UUID, nome ou ambos. Se o método de geração de identidade muda ao atualizar Floodgate ou mover plugin para proxy, o mesmo jogador pode parecer uma nova conta e entrar sem seus dados anteriores.

Antes de fazer alteração, liste serviços afetados: playerdata, whitelist, bans, LuckPerms, economia, claims, homes, estatísticas e sincronização Discord. Descubra qual chave cada plugin usa. Não suponha que trocar o nome mostrado migra automaticamente UUID e histórico.

Faça inventário dos Bedrock existentes

Identifique membros Bedrock conhecidos e compare nome visível, UUID observado, prefixo atual e última conexão. Use ferramentas de consulta e backups em modo leitura quando possível. Evite publicar XUID ou identificadores de conta em documentação pública.

Se o servidor tem histórico antigo com prefixo diferente, compare arquivos e registros de plugins numa cópia. Crie uma tabela interna de mapeamento sob acesso limitado. Só migre dados depois de verificar que origem e destino correspondem à mesma pessoa e que não existe colisão com outra conta.

Planeje uma mudança de prefixo

Registre valor atual e valor pretendido, confira recomendação de versão e confirme quando a alteração passa a valer. O FAQ do Floodgate alerta que servidores Paper mais antigos ou forks podem manter nome antigo em cache `usercache.json`; não use essa instrução como primeiro passo sem validar versão, dados e backup.

Em ambiente de teste, altere prefixo, entre com uma conta Bedrock e confira nome, UUID, permissões, inventário e banimentos. Depois reconecte para garantir que identidade persiste. Teste também conta Java com nome semelhante; ela não deve herdar dados ou acesso do jogador Bedrock.

Atualize proxy e backend em conjunto

Quando Floodgate roda no proxy, o backend precisa confiar no forwarding e interpretar dados da forma documentada. Confira se a instalação corresponde à plataforma, se Geyser está configurado para usar Floodgate e se segredo/proxy information forwarding está alinhado. Um componente atualizado sozinho pode impedir o login ou mudar o nome reconhecido.

Faça backup de `velocity.toml`, segredo e configuração do Paper, sem incluir os valores secretos em registro público. Teste conexão via proxy e confirme que Paper não pode ser acessado diretamente. Identidade válida não substitui proteção de rede nem configurações de autenticação.

Atualize whitelist e permissões conscientemente

Se identidade recebida muda, uma entrada de whitelist antiga pode não corresponder ao jogador. Verifique saída do console e use comandos suportados para gerenciar a lista. Não edite JSON diretamente. Faça mudanças individuais e confirme entrada e remoção para uma conta de teste.

LuckPerms e outros plugins podem guardar contexto por UUID. Não apague usuários antigos até que a equipe valide migração e recuperação. Faça backup do banco de permissões e registre quais registros foram associados ao novo identificador para que rollback continue possível.

Prepare rollback e comunicação

Mantenha cópia do mundo e dados de plugin da mesma janela. Se jogador aparecer sem progresso, pare novas escritas desse usuário, registre UUID ativo e restaure somente com plano que não sobrescreva progresso recente legítimo. Não copie playerdata manualmente para conta ativa sem entender consistência e plugins adicionais.

Avise a comunidade sobre manutenção que pode afetar login ou aparência do nome. Diga onde reportar perda de progresso e que dados são necessários sem pedir credenciais. A equipe precisa ter fluxo de suporte para comparar identidade com evidência segura.

Audite após a mudança

Teste uma conta Bedrock nova e outra antiga, Java sem conflito de nome, whitelist, banimento, permissões e inventário. Leia logs dos componentes Geyser, Floodgate, Velocity e Paper. Observe se username e UUID permanecem estáveis depois do restart e troca de servidor.

Use a FAQ oficial do Floodgate para comportamento de prefixo e cache, confira recursos do Floodgate e siga o guia do setup Geyser. Faça alterações de identidade em homologação antes de aplicá-las a contas com progresso salvo.

Investigue colisão de nomes sem trocar UUID

Em servidor híbrido, duas contas podem parecer semelhantes no chat ou em logs. Use UUID e método oficial de identidade para distinguir origem; não associe inventário por nome visível. Se precisa renomear apresentação, mantenha a identidade e faça a troca de maneira suportada.

Use amostra e controle de migração

Selecione alguns usuários antigos com histórico em plugins diferentes e valide numa cópia. Faça backup dos dados de jogador antes de executar ferramenta de migração. Compare permissão, saldo, homes, claims e inventário antes e depois, e registre o mapeamento de origem para poder desfazer se duas contas forem unificadas incorretamente.

Verifique skins e grupos sem tratar como prova de identidade

Skins e prefixos visuais ajudam apresentação, mas não são a chave de conta persistente. Confira UUID e integração que cada plugin usa. Uma mudança visual correta pode coexistir com dado perdido se armazenamento associa ao identificador antigo; valide progresso, não somente nome no chat.

Preserve histórico de mudança em produção

Antes de alterar whitelist ou prefixo, guarde os valores de identidade usados na cópia de homologação e determine quem valida cada jogador antigo. Se update troca a conta percebida, pare a migração e registre UUID anterior e atual. Essa pausa protege progresso até que a equipe confirme o vínculo sem sobrescrever novos dados.

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.