Skip to content
Pular para o conteúdo
Voltar ao Blog
Snap: Executando Plugins Legados do BungeeCord

Snap: Executando Plugins Legados do BungeeCord

Alexandru Maftei
Alexandru Maftei
@ice
Atualizado
26 visualizações
TL;DR:Snap é um adaptador Java que permite executar plugins do BungeeCord no Velocity. Saiba o que funciona, o que não funciona, e se é a solução certa para sua migração de servidor.
🐧 Projeto Minecraft de código aberto

Phoenix616/Snap

Ferramenta experimental para executar plugins do BungeeCord no Velocity

⭐ 134 estrelas💻 Java📄 LGPL-3.0
Ver no GitHub ↗

Você tem um servidor Velocity. Quer migrar do BungeeCord. Mas metade dos seus plugins ainda não tem versões para Velocity, e reescrever tudo parece exagerado. Snap é um plugin adaptador Java que executa plugins do BungeeCord diretamente no Velocity traduzindo chamadas da API em tempo real. Não vai resolver todos os problemas de compatibilidade, mas em certas configurações pode economizar o trabalho árduo de substituir ou reescrever plugins dos quais você ainda depende.

O que é o Snap, Realmente?

Snap é um plugin Velocity que funciona como uma camada de compatibilidade entre duas arquiteturas de proxy. Carrega plugins do BungeeCord dentro do Velocity e intercepta suas chamadas de API, convertendo-as em equivalentes do Velocity em tempo real. Pense nele como um tradutor em tempo real entre seus plugins legados e um proxy moderno.

A história de origem importa aqui. Esse mantedor, Phoenix616, começou tentando documentar as diferenças entre as APIs do BungeeCord e Velocity. Isso evoluiu para construir um adaptador real que pudesse carregar plugins de um proxy no outro. O resultado é inteligente em conceito, mas tem compensações reais - funciona, mas é menos eficiente que plugins Velocity nativos porque cada chamada de método é traduzida.

Para uma ferramenta de nicho resolvendo um problema específico, é bem ativa. 134 estrelas no GitHub, manutenção recente, e a versão mais recente (1.2-pre1) suporta Velocity 3.3.0 com compatibilidade com Bungee 1.20.x. O projeto é licenciado sob LGPL-3.0, então você pode usá-lo livremente desde que compartilhe qualquer modificação de volta.


O Que Funciona (E O Que Definitivamente Não Funciona)

A maioria das tarefas básicas de proxy funcionam bem. Conexões de jogadores, alternância de servidor, escuta de eventos, verificações de permissões - tudo lá. O mantedor é refrescantemente honesto no README: "A maioria disso (esperançosamente)." Eles não exageram.

Mas vários recursos não se traduzem para Velocity de forma alguma:

  • O sistema de grupos e permissões integrado do BungeeCord não existe no Velocity. O projeto recomenda usar LuckPerms, que funciona em ambos.
  • Funcionalidade de reconexão de servidor. BungeeCord tem isso integrado, Velocity não expõe.
  • Suporte a placar. Velocity não tem uma API para isso, e Snap não está construindo uma.
  • Algumas configurações de ProxyConfig retornam padrões sensatos mas não são espelhos exatos do comportamento do Bungee.
  • Comandos registrados após um plugin ser carregado podem não aparecer no registro de comandos.
  • A detecção de transferência só funciona se o servidor está em modo online.

Se seu plugin depende fortemente de qualquer um desses recursos, Snap não vai salvá-lo. Hora de escrever um plugin Velocity nativo.

É aqui que o Snap fica prático: você pode configurar o que acontece quando algo não é suportado. Defina `throw-unsupported-exception` para `true` (o padrão) e você verá exceções registradas para saber exatamente o que quebrou. Defina para `false` e métodos não suportados retornam valores padrão, deixando seus plugins continuarem funcionando apesar das limitações.


Instalação e Configuração

A instalação é direta se você já trabalhou com Velocity antes.

Primeiro, pegue o arquivo snap.jar do sistema de compilação CI do projeto (vinculado na página de lançamentos). Requer Java 17 ou mais recente, então certifique-se de que seu servidor atenda a esse requisito mínimo.

bash
# Coloque o snap.jar na pasta de plugins do Velocity
cp snap.jar /path/to/velocity/plugins/

# Crie o diretório de plugins do Snap
mkdir -p /path/to/velocity/plugins/Snap/

# Mova seus plugins do BungeeCord para lá
cp /path/to/bungee/plugins/*.jar /path/to/velocity/plugins/Snap/

Reinicie o Velocity (ou recarregue o plugin) e o Snap se inicializa, carrega todos os plugins do BungeeCord daquela pasta e registra quaisquer problemas encontrados. Se algo não carregar, os logs dirão o porquê.

Uma dica prática de testes: comece com apenas Snap e um plugin do BungeeCord. Confirme que carrega. Depois adicione mais gradualmente. Você detectará problemas de incompatibilidade muito mais rápido do que despejando tudo de uma vez e depois se perguntando qual plugin está causando o problema.


Quando Você Usaria Isso

O Snap faz sentido em algumas situações específicas.

Você tem um plugin do BungeeCord que não é mais mantido e não tem um equivalente em Velocity. Talvez seja um utilitário de equipe legado ou um módulo de análise customizado. Reescrever parece desperdiçador. O Snap permite que você continue usando-o sem uma reescrita completa.

Você está migrando uma rede mas não quer migrar tudo de uma vez. Executar o Snap em seu novo servidor Velocity permite que você traga plugins antigos enquanto você gradualmente escreve ou encontra substituições em Velocity.

Você está executando uma rede de teste e quer tentar o Velocity sem se comprometer em migrar todo seu ecossistema de plugins ainda.

O que não faz sentido: usar isso em produção. O projeto em si avisa contra isso sem testes extensivos. E mesmo assim, você está apostando em software experimental. A maioria das redes de produção é melhor migrar corretamente.

Se a maioria dos seus plugins já tem versões Velocity mantidas, pule o Snap inteiramente. Apenas migre. Você terá menos surpresas e melhor desempenho.


Compromissos de Desempenho e Armadilhas

A tradução adiciona sobrecarga. Cada chamada de API é capturada e convertida para trás e para frente. Para plugins que fazem milhares de chamadas por segundo, você pode ver impacto na CPU. Para plugins normais fazendo trabalho básico de proxy, provavelmente não.

O tratamento de conexão é a parte mais complicada. Os eventos podem disparar um pouco diferente do BungeeCord. Se seu plugin faz manipulação pesada de conexões de jogadores ou depende de tempo específico de eventos, é melhor reescrever para Velocity em vez de tentar fazê-lo funcionar através da camada de tradução do Snap.

Também há um teto de escala. Se você está executando uma rede massiva com milhares de jogadores simultâneos, a ineficiência do Snap se agravará. Nesse tamanho, é melhor migrar corretamente.

Observe sua CPU e memória durante o tráfego máximo. Se você ver picos que correlacionam com atividade de plugin, pode ser a camada de tradução lutando. Esse é seu sinal para migrar o plugin ou procurar uma alternativa em Velocity.


Alternativas Reais

Suas opções para executar plugins antigos do BungeeCord no Velocity são realmente bastante limitadas, razão pela qual o Snap existe em primeiro lugar.

Escreva um plugin Velocity. É a escolha certa a longo prazo e o caminho à prova de futuro. Dependendo da complexidade, pode levar apenas um fim de semana.

Fique no BungeeCord ou Waterfall. Velocity é mais rápido e melhor arquitetado, mas não é a única opção. Se seu ecossistema de plugins inteiro depende do BungeeCord, ficar lá é válido até que você esteja pronto para migrar tudo junto.

Redesenhe em torno da funcionalidade faltante. Você realmente precisa desse plugin legado? Talvez um sistema de permissões moderno como LuckPerms resolva seus problemas sem o plugin. Talvez você possa simplificar sua infraestrutura.


Antes de Instalar

Teste isso em um ambiente de testes primeiro. Execute seus plugins através de todos os recursos que se importa. Depois observe por uma semana e procure por comportamento estranho. Verifique logs regularmente. Procure por problemas de desempenho.

Entenda as limitações de antemão. Snap funciona para certos plugins e casos de uso específicos. Veja - não funcionará para tudo. Quanto mais seus plugins dependem de recursos específicos do Bungee (especialmente grupos de permissões, manipulação de placar ou sequestro de conexão), mais provável que o Snap o decepcione.

Não execute isso em produção sem essa fase de testes em ambiente de testes. O projeto é explícito: este é um software experimental. Resolve um problema específico para pessoas específicas. E isso pode não resolver seu problema.

E se você está gerenciando uma rede de servidores Minecraft, você provavelmente também tem construtores e jogadores. Eles podem apreciar a ferramenta Block Search do minecraft.how para localizar materiais específicos, ou a Calculadora do Portal do Nether para planejamento de infraestrutura.

Sobre o autor
Alexandru Maftei
Alexandru MafteiRedator-chefe

Lead writer at minecraft.how. Long-time Minecraft player running a small SMP server, testing every build, mod, and seed before writing about it.

Comentários

Nenhum comentário ainda. Seja o primeiro a compartilhar sua opinião!

We use cookies to improve your experience. By continuing to use this site, you agree to our use of cookies. Read our Privacy Policy