CombatLogX: Como Parar o Logout de Combate no Seu Servidor

Imagine: você persegue alguém pela metade do mapa em uma luta PvP, acerta o golpe final, e eles desaparecem. Desconectados. Sem drops, sem vitória, nada para mostrar pelo esforço. Isso é logout de combate, e CombatLogX é o plugin projetado para acabar com isso.

O que CombatLogX faz

CombatLogX é um plugin Spigot (também funciona em Paper e Folia) baseado em uma regra inquebrantável: se você está em uma luta, não pode sair de lá de forma covarde. O momento em que um jogador ataca ou leva um golpe, o plugin "marca"-o como em combate por uma janela de tempo definida. Se desconectar enquanto a marca estiver ativa resulta em punição, geralmente significando que o personagem morre ali mesmo e solta tudo, exatamente como se tivesse perdido a luta honestamente.

Escrito em Java, de código aberto sob licença GPL-3.0, e com aproximadamente 154 estrelas no GitHub. O mantenedor, SirBlobman, mantém o plugin atualizado por anos e suporta versões do Minecraft até 26.1.2. Esse histórico importa mais do que qualquer contagem de estrelas quando você deixa um plugin controlar as regras de combate do seu servidor.

Isso é o esqueleto. O que mantém os administradores leais a ele, no entanto, é o sistema de expansões, e chegaremos lá.

Por que os proprietários de servidores o utilizam

O logout de combate é o tipo de problema que silenciosamente envenena um servidor PvP. Um jogador descobre que pode apertar Alt+F4 no momento em que sua barra de saúde fica assustadora, e dentro de uma semana, todos estão fazendo o mesmo. As lutas param de significar algo. Por que arriscar equipamentos de diamante se você pode simplesmente puxar o cabo Ethernet?

Servidores de facções são o lar óbvio para isso. Pra falar a verdade, também são servidores de sobrevivência com PvP aberto, configurações hardcore, e qualquer coisa onde o loot esteja em jogo. Se os seus jogadores podem perder itens na morte, alguém vai tentar evitar essa morte desconectando.

E não é apenas sobre punição. Um setup anti-logout justo faz com que o combate se sinta honesto, o que é metade da razão pela qual as pessoas se juntam a um servidor PvP para começar. Lutas justas mantêm os jogadores por perto. Escapes baratos os afastam.

É um plugin pequeno resolvendo um problema social genuinamente irritante. Esse é o meu tipo favorito de mod.

Instalando no seu servidor

Aviso antes de começar: CombatLogX precisa do Java 25, um servidor rodando Spigot, Paper, ou Folia (qualquer versão de 1.19.4 a 26.1.2), e uma biblioteca companions chamada BlueSlimeCore, versão 2.9.9 ou mais nova. Faltar o BlueSlimeCore faz com que o plugin simplesmente não carregue, o que atrapalha muitos iniciantes.

Você pode pegar o último build da página de recursos do SpigotMC, ou do servidor Jenkins do mantenedor se quiser builds beta. O lançamento atual é v11.4.0.0.1156. Uma vez que você tenha o zip, o fluxo geral parece com isso:

# 1. Pare o servidor primeiro
stop

# 2. Deixe esses arquivos na pasta /plugins/
# CombatLogX.jar
# BlueSlimeCore.jar

# 3. Coloque os jars de expansão na pasta
# /plugins/CombatLogX/expansions/

# 4. Reinicie o servidor e, em seguida, recarregue os configs dentro do jogo
/clx reload

O zip vem com o jar principal, a dependência core, e um bundle de jars de expansão que você copia para a pasta de expansões. Edite os arquivos de configuração e linguagem conforme desejar, execute /clx reload, e pronto. Nenhia reinicialização total necessária para a maioria das configurações, o que é honestamente útil quando você está ajustando a duração das tags.

Tangente rápida enquanto estamos no assunto de setup de servidor: se você estiver testando isso em uma caixa fresca e quiser um endereço limpo para dar aos amigos, nossa ferramenta de DNS gratuita para Minecraft dá um domínio arrumado em vez de fazer com que todos memorizem um IP. De volta ao plugin.

Expansões, onde as coisas ficam interessantes

Aqui está a parte que separa CombatLogX de um script anti-logout básico. A maioria das suas funcionalidades não está embutida no jar core. São expansões, módulos pequenos que você deixa na pasta de expansões, cada um em seu próprio arquivo jar. Quer uma funcionalidade? Adicione o jar. Não quer? Deixe-o. Esse é o modelo inteiro.

O mantenedor mantém a lista completa na documentação, mas as categorias cobrem o que você esperaria que um administrador PvP quisesse: impedir que os jogadores executem certos comandos enquanto marcados, bloquear teletransportes fora de uma luta, manter combatentes fora de zonas seguras, temporizadores na tela para que os jogadores vejam quanto tempo ainda têm, e janelas de proteção para jogadores novos para que eles não sejam explorados assim que nascem.

Você controla os controles no config também: quanto dura a marca de combate, o que conta como combate, quem está isento. Defina muito curto e os jogadores escambram; muito longo e as pessoas reclamam de ficar presos. Algo em torno de quinze a trinta segundos geralmente se sente certo, embora isso dependa inteiramente do ritmo do seu servidor.

O abordagem modular tem um lado positivo real. O plugin core permanece leve, e você só executa código para recursos que realmente usa. Um pequeno servidor skyblock e uma vasta rede de facções podem ambos rodar CombatLogX sem um deles carregar bagunça morta.

Um toque agradável: cada pasta de expansão vem com seu próprio README, então você não está voando cego quando ativa algo.

Onde as pessoas ficam presas

O requisito de Java 25 é o grande. Um número surpreendente de hosts de orçamento e configurações mais antigas ainda rodam Java mais antigo, e CombatLogX simplesmente não inicia sem o Java 25. Verifique o seletor de versão de Java no painel do seu host antes de culpar o plugin.

Esquecer o BlueSlimeCore é o segundo erro clássico. É um jar separado, é necessário, e o plugin não roda sozinho. Faça o upload de ambos, sempre.

Então há a pasta de expansões. Algumas pessoas deixam o jar principal, reiniciam, e se perguntam por que nenhuma das funcionalidades legais apareceu. Essas funcionalidades vivem nos jars de expansão separados que você tem que copiar manualmente. O plugin base lida com a marca de combate e a punição de logout; tudo o mais é opt-in.

Uma nota rápida sobre Folia: é suportado, mas Folia funciona muito diferente sob o capô, então teste o conjunto de expansões em um mundo de staging antes de empurrar para o vivo. Na verdade, esse é um conselho sólido para qualquer software de servidor, não apenas Folia.

Enquanto estou distribuindo dicas não relacionadas (plugins de combate me colocam no espírito de administrador de servidor): se a multidão de sobrevivência continua discutindo se seus portais de néter se alinham, o calculadora de portal de néter resolve isso em cerca de dez segundos. Nada a ver com CombatLogX. Só útil.

Alternativas e minha opinião honesta

CombatLogX não é a única opção anti-logout de combate por aí. CombatTagPlus é uma escolha leve e de longa data que muitos servidores mais antigos ainda juram por, e há vários plugins de "marca de combate" menores flutuando no SpigotMC se você quiser algo morto simples. O trade-off usual é flexibilidade: os mais simples fazem uma coisa, enquanto CombatLogX oferece o bufê completo de expansões.

Eu o rodaria? Em um servidor PvP, sim, sem muita hesitação. É ativamente mantido, o design modular é genuinamente inteligente, e o preço (gratuito, GPL-3.0) é difícil de argumentar contra. O requisito de Java 25 é a única coisa que eu verificaria primeiro, porque é um verdadeiro problema em hosts mais baratos.

Se o seu servidor não tem PvP e não tem perda de itens na morte, você pode pular esse. Para qualquer um que execute lutas dignas de serem vencidas, é uma recomendação fácil.