Multiverse permite manter mundos com objetivos diferentes no mesmo servidor Paper. Um portal pode mandar jogador de lobby para survival, evento ou mundo privado. O acesso envolve pelo menos duas perguntas: o grupo pode usar aquele portal? E pode entrar no mundo de destino? Liberar uma sem outra pode gerar acesso negado ou uma permissão ampla demais.
Este guia foca no controle de acesso, não em criar portais. Os nomes de nodes e configuração devem ser conferidos na versão atual de Multiverse-Core, Multiverse-Portals e LuckPerms. Teste com conta comum em cada origem e destino.
Liste mundos e rotas
Registre nome interno de cada mundo, finalidade, quem deve acessar e como chegar: comando, portal, NPC ou teleporte de staff. O nome de pasta pode diferir do nome que jogadores veem. Uma lista evita conceder wildcard porque uma porta específica não funcionou.
Desenhe origem, destino, grupo e permissão esperada para cada rota. Considere retorno também. Um jogador pode conseguir entrar no mundo pelo comando mesmo sem usar o portal, se outro node estiver concedido. Verifique as duas superfícies.
Diferencie permissão do portal e do mundo
Multiverse-Portals pode criar ou usar node para acesso a portal específico, enquanto Multiverse-Core controla permissão de acesso ao mundo. O projeto documenta que uma permissão de portal não substitui acesso ao destino; sem node de mundo requerido, jogador será negado ao atravessar.
Esse comportamento é uma boa camada de defesa, mas adiciona duas verificações. Conceda somente portal e mundo necessários. Se um jogador deve entrar no evento apenas por convite, certifique-se de que comando `/mvtp`, outro portal ou plugin de teleporte não contorna a política.
Confirme grafia e contexto de nodes
Use nomes exatos indicados pela documentação. Alguns nomes de portais podem ser tratados sem distinção entre maiúsculas e minúsculas, mas não generalize isso para nomes de mundo ou outros plugins. Consulte estado do node no LuckPerms e grupos herdados.
Evite `multiverse.access.*` ou acesso global a todos os portais se o requisito é liberar uma única rota. Wildcard pode conceder entrada futura em mundos criados depois. Quando a lista cresce, grupo específico por função costuma ser mais simples de revisar do que exceções negativas acumuladas.
Configure pela equipe e teste fora do OP
Use conta sem operador e grupo semelhante ao jogador final. Teste portal permitido, portal negado, comando de teleporte permitido e negado, mundo de origem e destino. OP pode ignorar ou alterar resultado e não serve como prova de que jogador comum está limitado.
Depois de conceder node, reconecte se necessário e confira de onde vem permissão efetiva. Um grant em grupo pai pode manter acesso. Quando editar portal ou mundo, leia nome retornado pelo plugin e compare ao registro; apontar permissão para nome diferente é erro comum.
Considere grupos de staff por responsabilidade
Staff que constrói evento pode precisar de acesso temporário a mundo em edição, mas moderadores não necessariamente precisam. Defina um grupo de build e prazo de expiração ou tarefa de revogação. Teste que o jogador normal não herda acesso por associação secundária.
Não compartilhe conta OP e não use console para fazer jogadores atravessarem regras sem registro. A equipe deve ter procedimento de entrada emergencial com autorização e log. Revise permissões quando evento encerra ou mundo passa de teste para produção.
Planeje comportamento de retorno e falha
Teste o que ocorre quando destino fica indisponível, portal é removido ou jogador morre. Rotas de retorno devem existir e apontar a mundo que o grupo pode acessar. Um usuário que entra num mundo privado e não pode sair precisa de ajuda administrativa, mesmo que a porta de entrada esteja correta.
Se recurso usa cobrança ou exceção, documente a regra antes. Teste grupo com e sem benefício e verifique se mudança de mundo mantém permissão. Evite depender de um único moderador com OP para resgatar jogadores de evento.
Audite e reverta mudanças
Registre portal, destino, nodes, grupo, responsável e caso de teste. Se mudança abre acesso indevido, remova grant e examine herança. Restaure configuração anterior do portal se for preciso, mas não apague mundo. Confirme retorno em uma conta de jogador e em outra com acesso autorizado.
Use o guia oficial de permissões Multiverse, a página de permissões de portal e a documentação de LuckPerms. A regra efetiva combina node do portal, acesso ao mundo, grupo e eventuais plugins adicionais.
Confira mundo destino após atualização
Quando um mundo é renomeado, recriado ou movido, valide o destino que portal usa e os nodes em LuckPerms. O portal pode continuar apontando a um identificador antigo, enquanto grupo mantém acesso a mundo novo. Teste rota de ida e volta com jogador comum depois de reiniciar Multiverse e confirme que o mapa abre na área correta.
Revise caminho alternativo por comando
Uma proteção por portal não impede comando de teleporte se o grupo tem permissão de Multiverse ou de outro plugin. Liste comandos de viagem disponíveis em EssentialsX, Multiverse e menus, e teste todos os caminhos que jogador conhece. Remova grants globais quando a intenção é exigir rota controlada.
Confira limites das regiões dos portais
Teste blocos de entrada e saída nas bordas da região. Uma seleção pode permitir atravessar de uma direção, mas bloquear retorno ou interação. Registre coordenadas e mundo de cada extremo e confirme que criação do portal sobrevive ao restart antes de liberar para usuários.
Defina testes de ida, retorno e negação
Registre resultado esperado em três casos: usuário autorizado atravessa portal, usuário sem permissão recebe bloqueio claro e ambos conseguem sair conforme a regra. Refaça após mudança de nome do mundo, versão de Multiverse ou atualização de LuckPerms. Um teste só de acesso positivo não identifica portal público por engano.
Documente recuperação de acesso
Tenha uma rota de suporte para quem não consegue atravessar o portal: responsável da equipe, mundo seguro de retorno e comando verificado em console. Não resolva concedendo wildcard permanente; identifique se falta portal, mundo, contexto de servidor ou permissão de teleporte de outro plugin.
Valide o destino depois de copiar mundo
Se restaura ou duplica mundo, confira se plugin reconhece nome interno e que portal aponta ao destino que jogadores devem acessar. A cópia pode ter permissões próprias herdadas do servidor ou perfil diferente. Teste teleporte, spawn e retorno com conta regular e não deixe a equipe depender de OP para consertar rota quebrada.
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.