CoreProtect — Minecraft Java Edition 1.16 - 1.21.11+

Los servidores multijugador de Minecraft necesitan una auditoría detallada de las acciones de los jugadores para evitar modificaciones no autorizadas del mapa y el robo de objetos de valor del juego. El núcleo vanilla del servidor no registra el historial de edición del terreno ni el movimiento de objetos en los contenedores, por lo que los administradores no tienen forma de identificar a los infractores ni de deshacer las destrucciones sin restaurar por completo los archivos del mapa a partir de copias de seguridad. El plugin de servidor CoreProtect registra todos los eventos de modificación del mundo, crea índices detallados de las acciones de los usuarios y realiza reversiones (rollbacks) puntuales del espacio basándose en consultas paramétricas complejas. La herramienta funciona en modo asíncrono, escribiendo las transacciones en una cola para proteger el hilo principal del servidor frente a retrasos.

1. Bases de datos y arquitectura asíncrona de registro

El plugin CoreProtect intercepta los eventos del servidor mediante los manejadores de eventos de la API de Bukkit/Paper. Para evitar el bloqueo del hilo principal del servidor (Server Thread) durante el procesamiento de miles de registros por segundo, el plugin utiliza un modelo de registro asíncrono. Los eventos (destrucción de un bloque, cambio del inventario de un cofre, uso de un comando) se colocan primero en un búfer dinámico interno DataQueue. Un hilo consumidor en segundo plano (Consumer Thread) lee las transacciones del búfer y las escribe en la base de datos mediante transacciones por lotes (Batch processing), lo que reduce la carga sobre el disco.

El plugin admite el trabajo con dos sistemas de gestión de bases de datos (SGBD):

1. SQLite (local por defecto): Toda la información se escribe en el archivo database.db en el directorio del plugin. SQLite no requiere la instalación de servicios de terceros, lo que lo hace cómodo para servidores locales pequeños con un bajo nivel de transacciones.

2. MySQL / MariaDB (servidor externo): Utiliza una conexión de red a un servidor de bases de datos independiente. Esta solución es el estándar industrial para grandes servidores y redes de servidores con un alto número de jugadores conectados (a partir de 50 jugadores). MySQL garantiza una alta velocidad de ejecución de las consultas indexadas y elimina la fragmentación del almacenamiento local.

Esquema de las tablas de la base de datos

CoreProtect crea un conjunto de tablas relacionales para optimizar el almacenamiento de datos. En lugar de guardar cadenas de texto completas para cada registro, el plugin utiliza tablas de diccionario para los nombres únicos de jugadores, mundos, tipos de bloques y entidades.

Todas las coordenadas x, y, z se indexan junto con el identificador del mundo wid para garantizar una búsqueda instantánea de transacciones dentro de un radio determinado.

2. Sintaxis de comandos y parámetros de filtrado

La interacción con la base de datos de CoreProtect se realiza mediante comandos de texto. Las operaciones principales son: inspección, búsqueda, reversión y anulación de la reversión.

Modo inspector /co inspect o /co i)

El comando cambia el cliente al modo de auditoría local. Tras la activación, el jugador puede interactuar con el mundo para obtener los registros:

·        El clic izquierdo sobre un bloque existente muestra en el chat el apodo de quien lo colocó, la fecha, la hora y las coordenadas.

·        El clic derecho sobre una superficie vacía (o un bloque) muestra el historial de los bloques que antes ocupaban ese espacio o que fueron desmontados.

·        El clic derecho sobre un contenedor (cofre, horno, barril, shulker) muestra el registro del movimiento de objetos.

Parámetros de filtrado de consultas /co rollback, /co restore, /co lookup)

Para la selección de datos, el plugin utiliza parámetros combinados con el formato parámetro:valor. Los parámetros se separan con espacios:

1. Usuario u:<nombre>): Indica el jugador que se va a comprobar. Se pueden indicar varios nombres separados por comas (por ejemplo, u:Stevie,Alex). Para revertir eventos naturales se utilizan identificadores técnicos:

·        u:#fire – propagación del fuego.

·        u:#lava – derrame de lava.

·        u:#water – derrame de agua.

·        u:#creeper – explosión de un creeper.

·        u:#tnt – explosión de dinamita.

·        u:#enderman – desplazamiento de bloques por un enderman.

2. Tiempo t:<valor>): Intervalo de tiempo para el análisis. Admite las unidades de medida: s (segundos), m (minutos), h (horas), d (días), w (semanas), y (años). Se permite combinar unidades, por ejemplo: t:2w4d6h (2 semanas, 4 días y 6 horas).

3. Radio r:<número>): Radio de la zona de búsqueda en bloques alrededor del ejecutor del comando. También admite valores especiales:

·        r:#global – búsqueda en toda la base de datos (dentro de todos los chunks cargados).

·        r:#world – búsqueda dentro del mundo de juego actual.

·        r:#chunk – búsqueda en el chunk actual del jugador.

·        r:#selection (o r:#we) – limita la búsqueda a los límites de la cuadrícula de selección actual de WorldEdit.

4. Acción a:<tipo>): Filtra los registros según el tipo de operación:

·        a:block – colocación y destrucción de bloques.

·        a:+block – solo colocación de bloques.

·        a:-block – solo destrucción de bloques.

·        a:container – transacciones de inventario.

·        a:+container – adición de objetos a un contenedor.

·        a:-container – extracción de objetos de un contenedor.

·        a:kill – muerte de animales y monstruos.

·        a:spawn – aparición de entidades.

·        a:chat – mensajes en el chat.

·        a:command – comandos introducidos.

·        a:session – autenticación de jugadores.

5. Bloques b:<material>): Limita la búsqueda a los materiales indicados (por ejemplo, b:stone,oak_planks).

6. Exclusión e:<material>): Excluye materiales del procesamiento (por ejemplo, e:tnt).

Vista previa de la reversión y anulación de operaciones

Para minimizar los errores durante las reversiones a gran escala, CoreProtect admite un sistema de simulación visual:

1. La ejecución del comando de reversión con la opción #preview (por ejemplo, /co rollback u:Griefer t:2h r:20 #preview) no modifica los archivos del mapa. En su lugar, el cliente recibe los paquetes de cambio de bloques en la sesión de renderizado actual. El administrador ve el mundo en estado "tras la reversión", mientras que para el resto de jugadores los bloques permanecen sin cambios.

#preview

/co apply

2. Para aplicar el resultado se utiliza el comando /co apply.

3. Para cancelar la vista previa se utiliza el comando /co cancel.

4. Para deshacer una reversión física ya ejecutada se aplica el comando /co undo, que devuelve las coordenadas al estado anterior a la ejecución de /co rollback.

3. Descripción completa del archivo de configuración config.yml

El archivo de configuración gestiona los límites, los parámetros de registro y la conexión a las bases de datos.

Bloque de parámetros generales (General Settings)

·        verbose: true – muestra en la consola un informe detallado de cada coordenada modificada durante la ejecución de las reversiones. Si se establece en false solo se muestra el número total de bloques modificados.

·        check-updates: true – comprueba durante el arranque si hay nuevas versiones del plugin en los servidores del desarrollador.

·        api-enabled: true – permite que plugins de terceros interactúen con los datos de CoreProtect.

·        default-radius: 10 – radio de reversión por defecto si este parámetro no se indica en el comando.

·        max-radius: 250 – limita el radio máximo para un solo comando. El valor 0 elimina la limitación.

Bloque de parámetros de registro (Logging Settings)

Estos parámetros determinan qué eventos se registran exactamente en la base de datos. Desactivar los registros innecesarios ayuda a reducir el tamaño de la base de datos:

·        block-place: true / block-break: true – registro de la colocación y destrucción habituales de bloques por parte de los jugadores.

·        natural-break: true – registro de la caída de bloques debida a desplazamientos o a la destrucción de los bloques de soporte (por ejemplo, romper el bloque sobre el que se sostenía una antorcha).

·        block-movement: true – registro de la caída gravitacional de arena, grava u hormigón.

·        pistons: true – registro del desplazamiento de bloques mediante pistones.

·        block-burn: true – registro de la destrucción de bloques por el fuego.

·        block-ignite: true – registro del prendido de bloques por los jugadores mediante un mechero o bolas de fuego.

·        explosions: true – registro de explosiones de dinamita, creepers, camas en el Nether o cristales del End.

·        entity-kills: true – registro de la muerte de aldeanos, animales, monstruos y soportes de armaduras.

·        player-chat: true / player-command: true – registro de mensajes del chat y comandos de consola.

·        player-session: true – registro de la hora de entrada y salida de los jugadores del servidor.

·        container-transactions: true – registro de las operaciones de movimiento de objetos en cofres, hornos, tolvas y shulkers.

Bloque de la base de datos (Database Settings)

·        use-mysql: false – interruptor del tipo de base de datos. Si se establece en true el plugin se conecta a un SGBD MySQL externo.

·        table-prefix: co_ – prefijo para los nombres de las tablas SQL.

·        mysql-host: localhost – dirección IP o nombre de dominio del servidor de bases de datos MySQL.

·        mysql-port: 3306 – puerto de red para la conexión.

·        mysql-database: minecraft – nombre de la base de datos de destino.

·        mysql-username: root – nombre de usuario de la base de datos.

·        mysql-password: password – contraseña del usuario.

·        mysql-ssl: false – activa el cifrado SSL de la conexión al servidor de bases de datos.

4. API para desarrolladores de plugins

CoreProtect ofrece a los desarrolladores acceso a su base de datos a través de la clase CoreProtectAPI. Esto permite que otros plugins (por ejemplo, WorldEdit o sistemas de protección) registren sus propios cambios o realicen una búsqueda automática en el historial.

Inicialización de la API

Para conectarse a la API se utiliza el método de inicialización:

Principales métodos de la interfaz API

·        boolean logPlacement(String user, Location location, Material type, BlockData blockData) – registra la colocación de un bloque en la base de datos en nombre del usuario indicado.

·        boolean logRemoval(String user, Location location, Material type, BlockData blockData) – registra la destrucción de un bloque.

·        boolean logContainerTransaction(String user, Location location, Material type, ItemStack itemStack, boolean isAdded) – registra la operación de adición (true) o extracción (false) de objetos de un contenedor.

·        List<String[]> performLookup(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – realiza una búsqueda según los filtros indicados y devuelve un array de resultados.

·        List<String[]> performRollback(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – inicia una reversión asíncrona de los cambios en el mundo.

·        List<String[]> performRestore(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – inicia una restauración asíncrona de los cambios.

·        boolean hasPlaced(String user, Block block, int time, int offset) – comprueba si el jugador indicado colocó este bloque dentro de un tiempo determinado.

·        boolean hasRemoved(String user, Block block, int time, int offset) – comprueba si el jugador indicado destruyó este bloque.

5. Rendimiento, compatibilidad y mantenimiento

Al trabajar con CoreProtect en servidores con un alto número de jugadores conectados, los administradores tienen en cuenta las particularidades de la interacción con las arquitecturas de servidor modernas:

·        Compatibilidad con Folia: El núcleo de servidor Folia utiliza una planificación multihilo por regiones (Regionized multithreading), lo que exige a los plugins una estricta seguridad de hilos al trabajar con el mundo. CoreProtect está adaptado para funcionar en Folia: la ejecución de las operaciones /co rollback y /co restore se realiza a través del planificador de regiones (Region Scheduler), lo que evita conflictos de acceso a los chunks y errores críticos del tipo ConcurrentModificationException.

·        Clustering con MultiPaper: En los servidores de tipo MultiPaper, CoreProtect se configura para utilizar una única base de datos MySQL externa. Esto ayuda a sincronizar el historial de acciones de los jugadores en los distintos nodos del clúster.

·        Limpieza de la base de datos (Purge): La base de datos local SQLite se fragmenta y crece con el tiempo, ralentizando la ejecución de los comandos. El comando /co purge t:30d elimina los registros con más de 30 días de antigüedad. Tras la limpieza de la base de datos SQLite, el archivo database.db no se reduce de tamaño automáticamente, ya que el SGBD SQLite conserva las páginas libres para futuros registros. Para reducir físicamente el archivo en el disco es necesario ejecutar el comando VACUUM a través de la consola de la base de datos o detener el servidor y realizar la compresión mediante utilidades de terceros. El uso de MySQL elimina este problema, ya que el SGBD MySQL libera de forma más eficiente el espacio de disco no utilizado.

Conclusión

CoreProtect es el estándar para los sistemas de registro y restauración en los servidores de Minecraft Java Edition. A diferencia de alternativas como LogBlock (que solo admite el trabajo con MySQL y se limita al registro de bloques) o Prism (que tiene una estructura de configuración más compleja), CoreProtect ofrece un funcionamiento totalmente autónomo con SQLite, un seguimiento detallado del contenido de los contenedores y, además, un sistema único de vista previa de reversiones #preview. La única limitación técnica del plugin es la considerable carga sobre el disco durante la limpieza de grandes bases de datos locales SQLite, por lo que a los proyectos grandes se les recomienda utilizar SGBD MySQL dedicados en discos NVMe rápidos. El plugin es adecuado tanto para pequeños servidores privados entre amigos como para proyectos a gran escala con cientos de jugadores activos.