LuckPerms permite expressar permissões em grupos, usuários e contextos. Contexto limita onde uma concessão se aplica, por exemplo a um mundo chamado nether ou servidor hub. Essa precisão evita conceder poderes de construção em toda a rede quando a equipe só precisa atuar numa área.

Uma permissão contextual depende da plataforma, contexto ativo e herança do grupo. Planeje antes de editar, use o web editor ou comandos conforme a versão instalada, e teste como um jogador sem OP. O nome parecido entre mundos não assegura que as chaves de contexto sejam idênticas.

Descreva escopo e resultado esperado

Escreva a necessidade como regra: “moderadores podem usar comando de teleporte no lobby e survival, mas não no mundo de evento”. Liste servidores, mundos, grupos e permissões envolvidas. Contextos podem incluir chaves e valores adicionais fornecidos por plugins; não adivinhe identificadores de instância.

Confirme quais contextos sua plataforma envia e como o LuckPerms os mostra. Uma rede com vários backends pode usar nome de servidor definido no arquivo do proxy ou plugin. Se houver um erro de digitação no nome, a permissão pode simplesmente não se aplicar sem erro óbvio.

Entenda herança antes de adicionar override

Grupos podem herdar de outros grupos e usuários podem ter nodes próprios. Uma permissão concedida no grupo pai continua relevante mesmo se você adicionar uma negativa mais específica. Veja a árvore de herança e valores resolvidos antes de tentar “consertar” acesso criando mais entradas.

Defina arquitetura simples: grupo base com permissões comuns, cargos derivados e exceções localizadas. Evite copiar todos os nodes de um cargo em cada servidor. Exceção contextual deve ser uma diferença intencional e documentada, não uma fuga para contornar um grupo confuso.

Escolha contexto de mundo ou de servidor

O contexto de mundo restringe o node ao mundo correspondente, e o contexto de servidor restringe à instância nomeada. Os dois podem compor o escopo. A documentação do editor web explica como adicionar contextos e nota que uma permissão pode ter somente um valor de mundo e um de servidor de cada vez.

Não confunda dimensão Nether com nome de servidor “nether”. Uma dimensão num backend pode chamar-se world_nether enquanto o servidor da rede se chama survival-2. Confirme os valores observados na consulta de permissões. Um contexto errado pode aparentar falha do plugin em vez de configuração de LuckPerms.

Edite com revisão e cópia

Se usar editor web, gere sessão no console e faça as alterações no grafo. Confira as diferenças antes de salvar e aplique alterações. A sessão de editor é credencial temporária; não publique o link nem o compartilhe fora da equipe. Para ambiente sensível, faça backup da configuração e use processo de revisão por outra pessoa.

Adicione poucos nodes por vez. Anote grupo, permissão, valor, contexto e motivo. Se houver muitas mudanças, divida por objetivo para identificar qual conjunto mudou o comportamento. Confirme que a instância conectou ao mesmo armazenamento e que os dados persistiram após aplicar.

Teste negativo e positivo

Crie ou use conta de teste com o grupo real, sem OP, e conecte ao servidor correto. Confirme que o jogador não consegue executar comando fora do escopo e que consegue onde a regra foi concedida. Troque de mundo, conecte em outra instância e repita o teste.

Uma permissão resolvida no comando de check ajuda a mostrar de onde vem o resultado e quais contextos estão ativos. Leia a saída completa e inspecione a herança. Se a negação vem de outro grupo ou usuário, remover apenas o node contextual não resolve causa raiz.

Considere wildcard e permissões negativas

Wildcards podem conceder uma família ampla de nodes que uma configuração local não pretende liberar. Antes de adicionar permissão explícita, veja se ela já vem de wildcard em grupo pai. Negativas podem ser úteis, mas aumentam complexidade da árvore e dificultam uma futura auditoria se usadas para mascarar concessões excessivas.

Prefira remover o grant amplo na origem e reconstruir um conjunto mínimo de permissões. Se a comunidade depende de comportamento compatível legado, documente a negativa, o node de origem e a razão do escopo. Teste após qualquer atualização do plugin, porque nomes e padrões de permissão pertencem aos próprios plugins.

Valide em rede com armazenamento compartilhado

Se proxy usa múltiplos backends e armazenamento comum, teste a sincronização ao mudar servidor. Confirme que todos executam versões compatíveis e observam os mesmos nomes de servidores. Contexto de uma instância não deve vazar para outra por causa de nome duplicado ou configuração diferente.

Não edite banco diretamente. Use interface documentada para preservar formato e sincronização. Depois de alterar contexts, reconecte a conta de teste, porque alguns plugins armazenam estado de sessão ou cache. Consulte o console e a saída de permissão antes de atribuir falha ao armazenamento.

Reverta e registre

Se um jogador ganha poder fora do esperado, remova o node indevido e revise grupo pai antes de reabrir uma área sensível. Teste de novo em instância e mundo de destino. Mantenha log de mudanças com quem autorizou e como validou o resultado.

Consulte a documentação de uso e permissões, o guia do editor web e a referência de grupos padrão. Verifique valores de contexto realmente emitidos pelo seu servidor e teste com conta comum após cada alteração.

Trate servidor e mundo como contextos cumulativos

Um node concedido somente no servidor `hub` e no mundo `spawn` precisa corresponder aos dois valores ativos naquele ponto. Se o jogador sai do spawn e entra em outro mundo no mesmo backend, a permissão pode desaparecer como planejado. Se troca de backend, o contexto de servidor pode mudar independentemente do mundo.

Desenhe uma pequena matriz de testes: servidor correto/incorreto e mundo correto/incorreto. A combinação esperada ajuda a encontrar um valor contextual largo demais. Inclua um grupo pai na análise, porque a concessão herdada sem contexto pode continuar valendo em todos os lugares apesar do override local.

Evite permissões residuais após promoção

Uma promoção pode adicionar um grupo novo sem retirar o grupo antigo, deixando dois caminhos de herança ativos. Revise se o usuário está em mais de um grupo e identifique cada grant efetivo, principalmente os que não têm contexto. Faça a troca numa conta de teste, aplique e reconecte para confirmar o estado depois de sincronizar entre backends.

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.