Como configurar níveis de permissão de staff no MU Online

Definir níveis de permissão de staff é o que separa um servidor de MU Online administrado com profissionalismo de um que vive à beira do desastre. Sem uma hierarquia clara, ou você dá poder de Admin para todo mundo — e um dia alguém cria itens perfeitos e quebra a economia — ou centraliza tudo numa pessoa só, que vira gargalo e ponto único de falha. O caminho certo é desenhar uma escala de níveis, mapear cada função da equipe para um nível, e configurar isso tanto no banco quanto no config do servidor, com log e auditoria por cima. Este tutorial mostra como fazer esse desenho e implementá-lo, lembrando que nomes de campos, valores de ctl_code e nomes de comando são exemplos que variam por season/emulador.

Pré-requisitos

• Acesso ao banco de dados (SSMS para MSSQL, phpMyAdmin/HeidiSQL para MySQL) para editar o campo de nível das contas.
• Acesso ao arquivo de comandos e ao config do GameServer, onde vive a GMList e o nível mínimo de cada comando.
• Conhecimento do modelo do seu emulador: se ele usa só ctl_code, só GMList, ou os dois combinados.
• Uma equipe mapeada: saber quantas pessoas há e o que cada uma faz (moderar chat, organizar evento, banir hacker, administrar economia).
• Ambiente de teste para validar a hierarquia antes de aplicá-la na produção.
• Um servidor já funcional. Se ainda está montando a base, veja primeiro como criar um servidor de MU Online.

Por que hierarquia importa

Numa comunidade viva, as tarefas administrativas têm riscos muito diferentes. Silenciar um flamer é reversível e de baixo impacto. Criar um item perfeito ou creditar coin é irreversível e afeta a economia de todos. Se essas ações moram no mesmo nível de acesso, você não consegue confiar num moderador novato sem lhe entregar poder de destruir o servidor. A hierarquia resolve isso separando poder de moderação de poder de geração de valor. Quanto mais alto o risco de uma ação, mais alto o nível exigido e menos pessoas o possuem.

Passo 1 — Desenhar a escala de níveis

Antes de tocar em qualquer arquivo, desenhe a escala no papel. Um modelo enxuto e eficaz de exemplo:

Repare que cada nível herda o que o anterior pode fazer e acrescenta poder. Um Admin pode tudo que um GM Sênior pode, e mais. Evite criar níveis demais no começo: três a cinco cobrem quase todos os servidores. Você sempre pode adicionar um nível intermediário depois.

Passo 2 — Mapear comandos para níveis

Com a escala pronta, decida qual nível mínimo cada comando exige. Esta é a parte que mais protege o servidor. Exemplo de mapeamento (nomes de comando variam por season/emulador):

A regra de ouro: nenhum comando gerador de valor abaixo do nível de Admin. Criar item, dar zen, creditar coin ou alterar resets em massa são poderes que, nas mãos erradas, arruínam a economia e a confiança da comunidade.

Passo 3 — Configurar no banco de dados

O nível de cada conta vive no campo ctl_code (ou equivalente). Configure cada membro da staff no nível mapeado:

USE MuOnline;

-- Definir níveis da equipe (valores de exemplo)
UPDATE MEMB_INFO SET ctl_code = 1 WHERE memb___id = 'helper_ana';
UPDATE MEMB_INFO SET ctl_code = 2 WHERE memb___id = 'gm_carlos';
UPDATE MEMB_INFO SET ctl_code = 3 WHERE memb___id = 'gmsr_marina';
UPDATE MEMB_INFO SET ctl_code = 8 WHERE memb___id = 'adm_bruno';

-- Auditar a hierarquia atual
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

Os valores numéricos de ctl_code que correspondem a cada papel variam por emulador — em alguns 8 é Admin, em outros a escala é diferente. Confira o que a sua build reconhece como Admin antes de aplicar.

Passo 4 — Configurar a GMList e os níveis de comando

Muitos emuladores exigem, além do ctl_code, uma GMList no config do GameServer, e definem o nível mínimo de cada comando em um arquivo próprio. Exemplo (ini):

[GMList]
; nick = nível (varia por emulador)
helper_ana   = 1
gm_carlos    = 2
gmsr_marina  = 3
adm_bruno    = 8

[CommandLevels]
; comando = nível mínimo de acesso
Move        = 1
Post        = 2
Mute        = 2
Disconnect  = 3
Ban         = 3
CreateItem  = 8
AddCoin     = 8

[GMConfig]
LogGMCommands = 1   ; registrar toda ação de GM

Mantenha ctl_code, GMList e CommandLevels coerentes entre si. Uma inconsistência — conta com nível alto no banco mas nível baixo na GMList — costuma ser a causa de "meu GM não consegue banir mesmo sendo sênior".

Passo 5 — Aplicar o menor privilégio

O princípio do menor privilégio é o coração de uma boa hierarquia: cada pessoa recebe exatamente o que precisa, nada além. Um organizador de eventos precisa abrir Blood Castle e anunciar, não precisa criar itens. Um moderador de Discord que ajuda no jogo precisa mover e silenciar, não precisa banir contas. Ao aplicar isso, você reduz o número de contas capazes de causar dano crítico — o que diminui a superfície de ataque e simplifica a auditoria. Sempre que estiver na dúvida entre dois níveis, comece pelo mais baixo e suba se necessário.

Passo 6 — Habilitar log e auditoria

Uma hierarquia sem log é só uma sugestão. Configure o LogServer ou os logs do GameServer para registrar toda ação sensível: quem baniu quem, quem criou qual item, quem creditou coin, quando e para quem. Além disso:

1. Revise diariamente os logs de comandos de nível 4 (geradores de valor) nos primeiros meses.
2. Faça auditoria mensal das contas com ctl_code > 0 para pegar acessos esquecidos.
3. Cruze picos de itens raros ou zen na economia com os logs administrativos.
4. Guarde os logs por tempo suficiente para investigar incidentes retroativos.

Passo 7 — Documentar a política de staff

Escreva um documento interno curto que diga, para cada nível: o que pode, o que não pode, e a quem se reporta. Isso evita mal-entendidos e serve de referência quando alguém pede "mais acesso". Inclua o procedimento de promoção (como um GM vira GM Sênior) e o de revogação (o que acontece quando alguém sai). Uma equipe que conhece as próprias fronteiras abusa menos e trabalha melhor.

Revogação e mudanças de nível

Permissão é dinâmica. Promova, rebaixe ou revogue conforme a equipe muda:

-- Rebaixar um GM Sênior de volta a GM
UPDATE MEMB_INFO SET ctl_code = 2 WHERE memb___id = 'gmsr_marina';

-- Revogar acesso de quem saiu da equipe
UPDATE MEMB_INFO SET ctl_code = 0 WHERE memb___id = 'gm_que_saiu';

Ao revogar, lembre-se de remover o nick da GMList também e de trocar qualquer senha que tenha sido compartilhada. Faça isso no mesmo dia da saída — acesso administrativo esquecido é um risco silencioso.

Erros comuns e soluções

Boas práticas

• Comece com poucos níveis (3 a 5) e evolua conforme a equipe cresce.
• Nunca deixe comandos geradores de valor abaixo do nível de Admin.
• Aplique menor privilégio: na dúvida, o nível mais baixo.
• Mantenha ctl_code, GMList e níveis de comando sempre sincronizados.
• Log obrigatório em toda ação sensível, com auditoria periódica.
• Documente a política de cada nível e o fluxo de promoção/revogação.
• Revogue acesso no mesmo dia em que alguém deixa a equipe.

Checklist de lançamento

• Escala de níveis desenhada e documentada
• Funções da equipe mapeadas para níveis
• Cada comando com nível mínimo definido
• Comandos geradores de valor restritos ao nível de Admin
• ctl_code aplicado por conta com menor privilégio
• GMList e níveis de comando sincronizados com o banco
• Log de comandos de GM habilitado e testado
• Hierarquia validada em staging, incluindo negação de comando acima do nível
• Política de staff escrita e compartilhada com a equipe
• Procedimento de promoção e revogação definido
• Auditoria periódica de contas com acesso agendada

Perguntas frequentes