Do problema à decisão

Casos de uso técnicos

Seis situações, cada uma ligada ao comportamento documentado de um plugin: o problema, o que o plugin decide, o resultado e os limites.

Cada fluxo é um exemplo escrito a partir da documentação do plugin. É uma ilustração simplificada, não dados ao vivo de um servidor nem uma promessa para qualquer configuração.

Detecte uma incompatibilidade de Java antes de reiniciar

PluginGuardLançado
Problema inicial
Uma atualização de plugin agora é compilada para um Java mais novo do que o do seu servidor. A JVM se recusaria a carregá-lo, e a causa fica enterrada em um longo log de inicialização.
O que o plugin decide
O PluginGuard lê a versão do arquivo de classe em cada jar de plugins/ e a compara com o Java informado pelo servidor. Nunca executa nem altera um jar.
Resultado
A varredura relata um achado crítico JAVA_VERSION_TOO_NEW para esse plugin, e a lista de correções diz para usar um Java mais novo ou uma versão feita para o seu.
Limites para ter em mente
O PluginGuard roda dentro de um servidor que já está no ar. Faça a varredura depois de copiar o jar e antes de reiniciar; ele não ajuda um servidor que não inicia mais.

Fluxo de exemploIlustração, não dados ao vivo

  1. Copie o novo jar para plugins/
  2. Execute /pluginguard scan
  3. Achado crítico: versão de Java nova demais

Diferencie uma queda de uma expulsão por moderador

VelorFailoverLançado
Problema inicial
O Velocity gera o mesmo evento para um backend que caiu, uma expulsão por moderador e um banimento. Redirecionar por esse evento mandaria jogadores banidos para o lobby.
O que o plugin decide
O VelorFailover faz ping no servidor. Se ele responde, o Velocity trata a expulsão como de costume. Só um ping que falha, com um servidor reserva que responde, move os jogadores.
Resultado
Após uma queda real, os jogadores esperam no servidor reserva e voltam quando o servidor passa o número configurado de verificações consecutivas.
Limites para ter em mente
Se o servidor reserva também estiver fora do ar, nada é redirecionado. Paradas planejadas só são reconhecidas quando a sua mensagem de parada contém um texto configurado.

Fluxo de exemploIlustração, não dados ao vivo

  1. Um jogador é expulso de survival
  2. Ping em survival: resposta ou sem resposta
  3. Resposta: expulsão normal. Sem resposta: mover para lobby

Segure uma recompensa suspeita para revisão

ReferralTrackAguardando aprovação
Problema inicial
Dois jogadores no mesmo endereço indicam um ao outro, e a recompensa de boas-vindas seria paga automaticamente.
O que o plugin decide
Com a revisão de fraude opcional ativada, o ReferralTrack pontua sinais explicáveis (mesmo IP, indicação mútua, primeira entrada recente, pouco tempo de jogo) e segura a indicação quando a pontuação atinge o seu limite.
Resultado
Uma indicação retida não pode ser validada nem liberar recompensas até que a equipe a aprove ou rejeite com um motivo, e a decisão é gravada em um registro de auditoria.
Limites para ter em mente
A revisão de fraude vem desativada por padrão. Os sinais definem a prioridade de revisão; eles não provam contas alternativas.

Fluxo de exemploIlustração, não dados ao vivo

  1. Uma indicação é criada
  2. Os sinais são pontuados contra o seu limite
  3. Retida para a equipe: aprovar ou rejeitar com um motivo

Reverta uma atualização que falha na verificação de comandos

VeloRoadAguardando aprovação
Problema inicial
Você substitui um plugin ao vivo. A nova versão é ativada, mas os comandos dela nunca são registrados.
O que o plugin decide
O VeloRoad faz verificações prévias, cria um backup verificado com SHA-256, carrega o novo jar e compara os comandos registrados com o descritor.
Resultado
Se o carregamento, a ativação ou a verificação de comandos falhar, a versão verificada anterior é restaurada automaticamente quando existe um backup.
Limites para ter em mente
Uma reinicialização completa continua sendo a escolha mais segura para plugins críticos e para plugins que mantêm referências vivas profundas.

Fluxo de exemploIlustração, não dados ao vivo

  1. Verificação prévia e backup verificado
  2. Carregar o novo jar e checar seus comandos
  3. A checagem falha: versão anterior restaurada

Um arquivo YAML, três superfícies de menu

CrossMenuAguardando aprovação
Problema inicial
Jogadores de Java e de Bedrock precisam da mesma loja, e manter três menus separados sincronizados dá trabalho.
O que o plugin decide
O CrossMenu lê uma única definição de menu e a mostra como baú no Java, como diálogo nativo onde o servidor oferece a API de diálogos e como formulário nativo para jogadores de Geyser ou Floodgate.
Resultado
Cada jogador recebe, a partir do mesmo arquivo, a superfície nativa do seu cliente.
Limites para ter em mente
Formulários do Bedrock são estáticos depois de abertos. Diálogos de Java precisam de suporte à API de diálogos; servidores mais antigos voltam ao menu de baú. É necessário Minecraft 1.20.5 ou mais novo.

Fluxo de exemploIlustração, não dados ao vivo

  1. Escreva um único arquivo de menu
  2. O CrossMenu detecta o cliente
  3. Baú, diálogo ou formulário do Bedrock é exibido

Migre dados com simulação e caminho de volta

MigrateEm breve

Este plugin ainda não foi lançado. Não há link de compra até que seja.

Problema inicial
Você está trocando de um plugin para outro e quer manter homes, warps, saldos ou punições.
O que o plugin decide
O Migrate foi projetado para planejar a execução, mostrá-la em uma simulação, gravar um backup verificado, gravar os dados, relê-los para verificar e manter reversível o que gravou.
Resultado
Um relatório lista o que foi migrado e o que foi ignorado, e por quê.
Limites para ter em mente
O Migrate não foi lançado. Plugins, versões e plataformas suportados serão anunciados com o lançamento; nenhum é prometido aqui.

Fluxo de exemploIlustração, não dados ao vivo

  1. Simulação: veja o que mudaria
  2. Backup, gravação, releitura e verificação
  3. Relatório; reverter se necessário

Não sabe qual precisa?

Responda a oito perguntas curtas e receba até três sugestões.