Passo a passo: como o bot decide quem é Verificado (e quem leva bloqueio)

As metas de level por mundo, as vocações aceitas e o padrão de descrição são configurados no painel, na aba Verificado — sem comando de bot. Este post é o outro lado disso: o que acontece depois de configurar.

A pergunta que mais chega no suporte não é "como configuro" — é "por que o X não está Verificado?". A resposta está sempre em um destes oito passos.

O ciclo roda a cada 10 segundos, e não existe fila, cron ou janela de carência: se o membro está online, ele foi reavaliado agora.

O caminho principal, antes dos detalhes — staff isento (passo 5) e o congelamento por dado atrasado (passo 8) ficam de fora do desenho de propósito:

Passo 1 — o bot lista quem está online

O ciclo começa pedindo ao TeamSpeak a lista de clientes conectados, com os cargos de cada um. Só quem está online entra no ciclo.

Isso tem uma consequência honesta que vale dizer em voz alta: um membro que tem o cargo e nunca mais conecta não é alcançado. O bot não varre o banco de membros offline do TeamSpeak. Se você precisa limpar cargo de gente inativa, isso é trabalho de administração, não do ciclo automático.

Passo 2 — lê a descrição, ao vivo, e valida o formato

A descrição não vem de cache: ela é relida no mesmo ciclo. O bot verifica se o formato é o padrão configurado — Main é obrigatório e precisa ter valor; os outros rótulos aceitos são Nome, Bomba, Maker, Maker <Mundo>, um <Mundo> que exista no seu mapeamento, e o atalho m<inicial>.

O que separa "válido" de "inválido" aqui é forma, não identidade de mundo:

O caso do meio é a fronteira que mais gera dúvida: Maker Bellum: x passa com aviso, mas Bellum: x sozinho é recusado. Sem o prefixo Maker, não existe como distinguir Bellum: de Discord: — qualquer palavra seguida de dois-pontos seria aceita, e o padrão deixaria de ser padrão.

E se a descrição vier ilegível na leitura, o bot não pune: ele segura a decisão. Punir estado do bot em vez de estado do membro é o erro que a gente não comete de propósito.

Passo 3 — resolve os personagens declarados

Com a descrição interpretada, o bot sabe qual é o main e quais são os makers, por mundo. Aí ele cruza esses nomes com os dados de jogo que já tem em memória — level e vocação de cada um.

Nenhuma consulta nova ao TeamSpeak acontece nesse passo. É por isso que o ciclo cabe em 10 segundos sem sobrecarregar o servidor de voz.

Passo 4 — confere as três exigências do Verificado

Este é o passo que responde 90% dos "por que o X não está Verificado?". O cargo cheio de Verificado exige três coisas, e bater a meta é só a primeira:

1. A meta — level e vocação exigidos, por mundo, no modo que você escolheu (todos os mundos ou qualquer um deles).
2. A guild aliada — o main e os makers dos mundos que têm meta precisam estar na guild aliada daquele mundo. Mundos sem meta configurada não entram nessa conta. Se você não configurou guild aliada nenhuma, a exigência simplesmente não se aplica.
3. O cargo adicional — ao menos um dos cargos que você marcou como obrigatórios (na prática, coisas como Whatsapp ou Site). Lista vazia significa sem exigência.

Um membro que bateu a meta e está fora da guild aliada não fica Verificado. Um membro que bateu a meta e não tem o ícone do Site também não. Nos dois casos ele fica Linkado — e leva bloqueio.

Essa separação é intencional: bater a meta é uma coisa, pertencer à estrutura da guild é outra.

Passo 5 — escolhe um cargo de status

Cargo de status é exclusivo: exatamente um, nunca dois. A ordem de precedência é

exceção → provisório → Verificado → Linkado → nenhum

Staff nos grupos de exceção sai do fluxo de checagem por inteiro: aparece como Verificado sempre, e nunca leva bloqueio. Membro dentro da janela de provisório aparece como Provisório mesmo sem bater a meta. Quem só usou o !link aparece como Linkado.

Sobre o !link: ele é bônus, não requisito. Ninguém deixa de ser Verificado por não ter vinculado a conta. A única exceção é o provisório, que precisa da data do vínculo para saber quando a janela dele começou.

Passo 6 — decide o bloqueio de respawn, em paralelo

O bloqueio não substitui o cargo de status: ele é somado. Um Linkado que não bateu a meta continua Linkado e ganha o bloqueio.

Duas fontes independentes disparam bloqueio:

1. Meta não cumprida — quando você tem meta configurada e o membro não cumpre.
2. Descrição fora do padrão — o passo 2.

Um par que parece bug e não é: Provisório + bloqueio ao mesmo tempo. É legítimo. A regra da meta vale para todo mundo, e a janela de provisório dá tempo para se organizar, não isenção. Já um membro que cumpriu a meta e continua bloqueado é bug de verdade — se você vir isso, abra ticket.

Passo 7 — escreve os cargos, e só ele escreve

Todas as decisões dos passos anteriores são puras: elas calculam, não aplicam. A escrita acontece num único lugar, no fim do ciclo, na ordem exclusivo → obrigatório → remoção.

Isso é chato de explicar e importante de ter: quando dois mecanismos escrevem o mesmo cargo, você ganha cargo piscando a cada poucos segundos, e ninguém consegue dizer qual dos dois estava certo. Um escritor só é o que torna o resultado auditável.

Passo 8 — o que o bot se recusa a decidir

Este passo é o que mais protege a sua guild, e é invisível quando funciona.

Quando os dados de jogo estão atrasados (o RubinOT é um alvo hostil, isso acontece), um outage não tira cargo de ninguém e não distribui bloqueio em massa. A decisão é congelada até o dado voltar.

Mas o congelamento é assimétrico de propósito, e a razão é bonita: dado degradado só consegue subestimar a meta — um nome que o feed não resolveu lê como level 0, nunca como level alto demais. Então um veredito "bateu a meta" é confiável mesmo no meio de um outage, e é aplicado na hora. Na prática: o membro que corrige a descrição ganha o Verificado no mesmo ciclo, sem esperar o feed normalizar.

Duas outras recusas, pelo mesmo princípio:

• Vínculo não lido — se a consulta de vínculo falhou, o bot não decide sobre dado que ele não leu.
• Servidor recém-conectado — nos primeiros ~15 minutos, o bot segura apenas o rebaixamento de quem já tem Verificado. Ele não segura promoção.

E duas coisas atravessam todo congelamento, porque não dependem de feed nenhum: o bloqueio por descrição fora do padrão, e a retirada do Verificado de quem está sem descrição.

Sobre o bloqueio e a reserva de respawn

O cargo de bloqueio, por si só, é representativo. O que de fato impede reserva de respawn é a lista de cargos proibidos do módulo de claim — se você quiser um período de aviso antes de valer, exiba o bloqueio sem colocá-lo na lista.

Quando ele vale, barra pedido novo: !resp, !respnext, !respadd e a oferta de continuar depois que o tempo expira. O que ele não faz é derrubar hunt em andamento: quem já está no respawn termina, e quem reconecta com claim vivo mantém o dele.

Como auditar um membro específico

!verifyplayer <nome> (restrito a admin) devolve o diagnóstico do membro: o que ele cumpriu e o que falta — inclusive qual rótulo da descrição foi recusado, quando o problema é formato.

Pelo painel, a aba Atividade TS mostra o status de verificação membro por membro. É onde você responde "por que o X não está Verificado?" sem abrir o TeamSpeak.

O que isso significa para você

Não existe carência. Todo membro online é reavaliado a cada ciclo. Arrumou a descrição, o cargo aparece em segundos.

Outage não vira punição. Feed atrasado congela rebaixamento; nunca distribui bloqueio em massa.

"Bateu a meta" é auditável. A mesma função decide o cargo e o bloqueio, então os dois nunca discordam.

O bloqueio é seu para calibrar. Você escolhe se ele é sinalização ou trava de respawn.

Precisa de ajuda?

Abra um ticket no dashboard em tibiawatch.com/dashboard?hub=support — ou pelo TeamSpeak com !ticket.