CombatLogX: Cómo evitar el combat logging en tu servidor

Imagínalo: persigues a alguien por medio del mapa en una pelea PvP, asestas el golpe final, y desaparecen. Desconectado. Sin botín, sin victoria, nada que mostrar por la carrera. Eso es combat logging, y CombatLogX es el plugin construido para asegurarse de que deje de funcionar.

Qué hace CombatLogX

CombatLogX es un plugin Spigot (también funciona en Paper y Folia) construido alrededor de una regla simple: si estás en combate, no puedes escapar saliendo del juego. En el momento en que un jugador ataca o recibe un golpe, el plugin los "marca" como en combate durante un período establecido. Si cierras sesión mientras la marca está activa, serás castigado, lo que generalmente significa que tu personaje muere ahí mismo y suelta todo, exactamente como si hubieras perdido el duelo honestamente.

Está escrito en Java, es de código abierto bajo la licencia GPL-3.0, y tiene alrededor de 154 estrellas en GitHub. El mantenedor, SirBlobman, lo ha mantenido funcionando durante años y admite versiones de Minecraft hasta la 26.1.2. Ese historial importa más que cualquier cantidad de estrellas cuando le estás dando a un plugin el control sobre las reglas de combate de tu servidor.

Así que ese es el esqueleto. Pero lo que mantiene a los administradores leales a él es el sistema de expansiones, y llegaré a eso.

Por qué los administradores de servidores lo usan

El combat logging es el tipo de problema que envenena silenciosamente un servidor PvP. Un jugador descubre que puede hacer alt-F4 en el segundo en que su salud es peligrosa, y dentro de una semana todos lo están haciendo. Las peleas dejan de significar algo. ¿Por qué arriesgar tu equipo de diamante cuando simplemente puedes desconectar el cable de ethernet?

Los servidores de facciones son el hogar obvio para esto. Hablando en serio, también lo son los mundos de supervivencia con PvP abierto, configuraciones de estilo hardcore, y cualquier cosa donde el botín esté en juego. Si tus jugadores pueden perder elementos al morir, alguien intentará evadir esa muerte desconectándose.

Y no se trata solo del castigo. Una configuración anti-salida justa hace que el combate se sienta honesto, que es la mitad de la razón por la que la gente viene a un servidor PvP en primer lugar. Las peleas justas mantienen a los jugadores. Los escapes baratos los ahuyentan.

Es un pequeño plugin que resuelve un problema social genuinamente molesto. Ese es mi tipo de mod favorito.

Instalarlo en tu servidor

Aviso antes de empezar: CombatLogX necesita Java 25, un servidor ejecutando Spigot, Paper o Folia (desde 1.19.4 hasta 26.1.2), y una biblioteca complementaria llamada BlueSlimeCore, versión 2.9.9 o más nueva. Si te pierdes la parte de BlueSlimeCore, el plugin simplemente no se cargará, lo que confunde a muchos principiantes.

Puedes obtener la última compilación de la página de recursos de SpigotMC, o desde el servidor Jenkins del mantenedor si quieres compilaciones beta. La versión actual es v11.4.0.0.1156. Una vez que tengas el zip, el flujo aproximado se ve así:

# 1. Detén el servidor primero
stop

# 2. Coloca estos en /plugins/
# CombatLogX.jar
# BlueSlimeCore.jar

# 3. Coloca los jars de expansión en
# /plugins/CombatLogX/expansions/

# 4. Inicia el servidor nuevamente, luego recarga las configuraciones en el juego
/clx reload

El zip viene con el jar principal, la dependencia principal, y un conjunto de jars de expansión que copias en esa carpeta de expansiones. Edita los archivos de configuración e idioma a tu gusto, ejecuta /clx reload, y estás en vivo. No se necesita un reinicio completo para la mayoría de los ajustes de configuración, lo cual es muy útil cuando estás ajustando las duraciones de las marcas.

Un pequeño desvío mientras estamos en el tema de configurar un servidor: si estás probando esto en un servidor nuevo y quieres una dirección limpia para darles a tus amigos, nuestra herramienta DNS gratuita de Minecraft te da un dominio ordenado en lugar de que todos memoricen una IP. Volvamos al plugin.

Expansiones, donde se pone interesante

Aquí es donde CombatLogX se separa de un script anti-salida básico. La mayoría de sus características no están incorporadas en el jar principal. Son expansiones, pequeños módulos que colocas en la carpeta de expansiones, cada uno su propio archivo jar. ¿Quieres una característica? Añade el jar. ¿No la quieres? Borra el jar. Ese es el modelo completo.

El mantenedor mantiene la lista completa en la documentación, pero las categorías cubren lo que esperarías que un administrador enfocado en PvP quiera: impedir que los jugadores ejecuten ciertos comandos mientras están marcados, bloquear teletransportes fuera de una pelea, mantener a los combatientes fuera de zonas seguras, temporizadores en pantalla para que los jugadores vean cuánto tiempo están atrapados, y ventanas de protección para jugadores completamente nuevos para que no sean granjados en el segundo en que aparecen.

También controlas los parámetros en la configuración: cuánto tiempo dura la marca de combate, qué cuenta como combate, quién está exento. Configúralo demasiado corto y los jugadores se deslizan, demasiado largo y la gente se queja de estar atrapada. Alrededor de quince a treinta segundos tiende a sentirse bien, aunque eso depende completamente de la velocidad de tu servidor.

El enfoque modular tiene una ventaja real. Tu plugin principal se mantiene ligero, y solo ejecutas código para características que realmente usas. Un pequeño servidor de skyblock y una red de facciones extendida pueden ejecutar CombatLogX sin que una de ellas cargue peso muerto.

Un detalle agradable: cada carpeta de expansión viene con su propio README, así que no estás volando a ciegas cuando activas algo.

Dónde la gente se queda atrapada

El requisito de Java 25 es el grande. Un número sorprendente de hosts económicos y configuraciones antiguas aún ejecutan Java anterior, y CombatLogX simplemente no iniciará sin 25. Verifica el panel de tu host para un selector de versión de Java antes de culpar al plugin.

Olvidar BlueSlimeCore es el segundo error clásico. Es un jar separado, es requerido, y el plugin no ejecutará por sí solo. Carga ambos, cada vez.

Luego está la carpeta de expansiones. Algunas personas colocan el jar principal, reinician, y se preguntan por qué ninguna de las características interesantes apareció. Esas características viven en los jars de expansión separados que tienes que copiar a mano. El plugin base maneja el marcado y el castigo por salida, todo lo demás es opcional.

Una nota pequeña sobre Folia: es compatible, pero Folia funciona muy diferente bajo el capó, así que prueba tu conjunto de expansiones en un mundo de staging antes de subir a producción. En realidad, ese es un consejo sólido para cualquier software de servidor, no solo Folia.

Mientras reparto consejos no relacionados (los plugins de combate me ponen en la mentalidad de administrador del servidor): si tu multitud de supervivencia sigue discutiendo si sus portales del inframundo se alinean, la calculadora de portales del inframundo lo resuelve en aproximadamente diez segundos. Nada que ver con CombatLogX. Solo útil.

Alternativas y mi opinión honesta

CombatLogX no es la única opción anti-combat-log por ahí. CombatTagPlus es una opción ligera de larga duración en la que muchos servidores antiguos aún confían, y hay varios plugins "combat tag" más pequeños flotando en SpigotMC si quieres algo muy simple. El trade-off es generalmente flexibilidad: los más simples hacen una cosa, mientras que CombatLogX te da todo el buffet de expansiones.

¿Lo ejecutaría? En un servidor PvP, sí, sin mucha vacilación. Se mantiene activamente, el diseño modular es genuinamente inteligente, y el precio (gratuito, GPL-3.0) es difícil de argumentar. El requisito de Java 25 es lo único que verificaría primero, porque es una trampa real en hosts más económicos.

Si tu servidor no tiene PvP y no hay pérdida de elementos al morir, puedes saltarte este. Para cualquiera que ejecute peleas que valga la pena ganar, es una recomendación fácil.