CoreProtect — Minecraft Java Edition 1.16 - 1.21.11+

Les serveurs multijoueurs de Minecraft ont besoin d'un audit détaillé des actions des joueurs afin de prévenir les modifications non autorisées de la carte et le vol d'objets de valeur du jeu. Le cœur vanilla du serveur n'enregistre ni l'historique de modification du terrain ni le déplacement des objets dans les conteneurs ; les administrateurs n'ont donc aucun moyen d'identifier les contrevenants ou d'annuler les destructions sans restaurer entièrement les fichiers de la carte à partir des copies de sauvegarde. Le plugin serveur CoreProtect enregistre tous les événements de modification du monde, crée des index détaillés des actions des utilisateurs et effectue des restaurations (rollbacks) ponctuelles de l'espace à partir de requêtes paramétriques complexes. L'outil fonctionne en mode asynchrone, en écrivant les transactions dans une file d'attente afin de protéger le thread principal du serveur contre les ralentissements.

1. Bases de données et architecture asynchrone de journalisation

Le plugin CoreProtect intercepte les événements du serveur à l'aide des gestionnaires d'événements de l'API Bukkit/Paper. Pour éviter le blocage du thread principal du serveur (Server Thread) lors du traitement de milliers d'enregistrements par seconde, le plugin utilise un modèle de journalisation asynchrone. Les événements (destruction d'un bloc, modification de l'inventaire d'un coffre, utilisation d'une commande) sont d'abord placés dans un tampon dynamique interne DataQueue. Un thread consommateur en arrière-plan (Consumer Thread) lit les transactions du tampon et les écrit dans la base de données par transactions par lots (Batch processing), ce qui réduit la charge sur le support de stockage.

Le plugin prend en charge le travail avec deux systèmes de gestion de bases de données (SGBD) :

1. SQLite (local par défaut) : Toutes les informations sont écrites dans le fichier database.db situé dans le répertoire du plugin. SQLite ne nécessite pas l'installation de services tiers, ce qui le rend pratique pour les petits serveurs locaux à faible volume de transactions.

2. MySQL / MariaDB (serveur externe) : Utilise une connexion réseau vers un serveur de bases de données distinct. Cette solution est la norme industrielle pour les grands serveurs et les réseaux de serveurs à forte affluence (à partir de 50 joueurs). MySQL garantit une vitesse élevée d'exécution des requêtes indexées et élimine la fragmentation du stockage local.

Schéma des tables de la base de données

CoreProtect crée un ensemble de tables relationnelles afin d'optimiser le stockage des données. Au lieu d'enregistrer des chaînes de texte complètes pour chaque entrée, le plugin utilise des tables-dictionnaires pour les noms uniques de joueurs, de mondes, de types de blocs et d'entités.

Toutes les coordonnées x, y, z sont indexées conjointement avec l'identifiant du monde wid afin d'assurer une recherche instantanée des transactions dans un rayon donné.

2. Syntaxe des commandes et paramètres de filtrage

L'interaction avec la base de données de CoreProtect s'effectue à l'aide de commandes textuelles. Les opérations principales sont : l'inspection, la recherche, la restauration et l'annulation de la restauration.

Mode inspecteur /co inspect ou /co i)

La commande fait passer le client en mode d'audit local. Après l'activation, le joueur peut interagir avec le monde pour obtenir les journaux :

·        Un clic gauche sur un bloc existant affiche dans le chat le pseudo de celui qui l'a posé, la date, l'heure et les coordonnées.

·        Un clic droit sur une surface vide (ou un bloc) affiche l'historique des blocs qui occupaient auparavant cet espace ou qui ont été retirés.

·        Un clic droit sur un conteneur (coffre, four, tonneau, shulker) affiche le journal du déplacement des objets.

Paramètres de filtrage des requêtes /co rollback, /co restore, /co lookup)

Pour la sélection des données, le plugin utilise des paramètres combinés au format paramètre:valeur. Les paramètres sont séparés par des espaces :

1. Utilisateur u:<nom>) : Indique le joueur à vérifier. Il est possible d'indiquer plusieurs noms séparés par des virgules (par exemple, u:Stevie,Alex). Pour annuler les événements naturels, on utilise des identifiants techniques :

·        u:#fire – propagation du feu.

·        u:#lava – écoulement de lave.

·        u:#water – écoulement d'eau.

·        u:#creeper – explosion d'un creeper.

·        u:#tnt – explosion de TNT.

·        u:#enderman – déplacement de blocs par un enderman.

2. Temps t:<valeur>) : Intervalle de temps pour l'analyse. Prend en charge les unités de mesure : s (secondes), m (minutes), h (heures), d (jours), w (semaines), y (années). Il est permis de combiner les unités, par exemple : t:2w4d6h (2 semaines, 4 jours et 6 heures).

3. Rayon r:<nombre>) : Rayon de la zone de recherche en blocs autour de l'exécutant de la commande. Prend également en charge des valeurs spéciales :

·        r:#global – recherche dans toute la base de données (au sein de tous les chunks chargés).

·        r:#world – recherche au sein du monde de jeu actuel.

·        r:#chunk – recherche dans le chunk actuel du joueur.

·        r:#selection (ou r:#we) – limite la recherche aux limites de la grille de sélection actuelle de WorldEdit.

4. Action a:<type>) : Filtre les entrées selon le type d'opération :

·        a:block – pose et destruction de blocs.

·        a:+block – uniquement pose de blocs.

·        a:-block – uniquement destruction de blocs.

·        a:container – transactions d'inventaire.

·        a:+container – ajout d'objets dans un conteneur.

·        a:-container – retrait d'objets d'un conteneur.

·        a:kill – mort des animaux et des monstres.

·        a:spawn – apparition des entités.

·        a:chat – messages dans le chat.

·        a:command – commandes saisies.

·        a:session – connexion des joueurs.

5. Blocs b:<matériau>) : Limite la recherche aux matériaux indiqués (par exemple, b:stone,oak_planks).

6. Exclusion e:<matériau>) : Exclut des matériaux du traitement (par exemple, e:tnt).

Aperçu de la restauration et annulation des opérations

Pour réduire au minimum les erreurs lors des restaurations à grande échelle, CoreProtect prend en charge un système de simulation visuelle :

1. L'exécution de la commande de restauration avec l'indicateur #preview (par exemple, /co rollback u:Griefer t:2h r:20 #preview) ne modifie pas les fichiers de la carte. Le client reçoit à la place les paquets de modification des blocs dans la session de rendu actuelle. L'administrateur voit le monde dans l'état « après restauration », tandis que pour les autres joueurs les blocs restent inchangés.

#preview

/co apply

2. Pour appliquer le résultat, on utilise la commande /co apply.

3. Pour annuler l'aperçu, on utilise la commande /co cancel.

4. Pour annuler une restauration physique déjà effectuée, on applique la commande /co undo, qui rétablit les coordonnées dans l'état antérieur à l'exécution de /co rollback.

3. Description complète du fichier de configuration config.yml

Le fichier de configuration gère les limites, les paramètres de journalisation et la connexion aux bases de données.

Bloc des paramètres généraux (General Settings)

·        verbose: true – affiche dans la console un rapport détaillé sur chaque coordonnée modifiée pendant l'exécution des restaurations. Si défini sur false seul le nombre total de blocs modifiés est affiché.

·        check-updates: true – vérifie au démarrage la présence de nouvelles versions du plugin sur les serveurs du développeur.

·        api-enabled: true – permet aux plugins tiers d'interagir avec les données de CoreProtect.

·        default-radius: 10 – rayon de restauration par défaut si ce paramètre n'est pas indiqué dans la commande.

·        max-radius: 250 – limite le rayon maximal pour une seule commande. La valeur 0 supprime la limitation.

Bloc des paramètres de journalisation (Logging Settings)

Ces paramètres déterminent quels événements sont précisément écrits dans la base de données. Désactiver les journaux inutiles permet de réduire la taille de la base de données :

·        block-place: true / block-break: true – journalisation de la pose et de la destruction ordinaires de blocs par les joueurs.

·        natural-break: true – journalisation de la chute de blocs à la suite de déplacements ou de la destruction de blocs de support (par exemple, casser le bloc sur lequel reposait une torche).

·        block-movement: true – journalisation de la chute gravitationnelle du sable, du gravier ou du béton.

·        pistons: true – journalisation du déplacement de blocs à l'aide de pistons.

·        block-burn: true – journalisation de la destruction de blocs par le feu.

·        block-ignite: true – journalisation de l'embrasement de blocs par les joueurs à l'aide d'un briquet ou de boules de feu.

·        explosions: true – journalisation des explosions de TNT, de creepers, de lits dans le Nether ou de cristaux de l'End.

·        entity-kills: true – enregistrement de la mort des villageois, des animaux, des monstres et des supports d'armure.

·        player-chat: true / player-command: true – journalisation des messages du chat et des commandes de console.

·        player-session: true – journalisation de l'heure de connexion et de déconnexion des joueurs du serveur.

·        container-transactions: true – journalisation des opérations de déplacement d'objets dans les coffres, les fours, les entonnoirs et les shulkers.

Bloc de la base de données (Database Settings)

·        use-mysql: false – commutateur du type de base de données. Si défini sur true le plugin se connecte à un SGBD MySQL externe.

·        table-prefix: co_ – préfixe pour les noms des tables SQL.

·        mysql-host: localhost – adresse IP ou nom de domaine du serveur de bases de données MySQL.

·        mysql-port: 3306 – port réseau pour la connexion.

·        mysql-database: minecraft – nom de la base de données cible.

·        mysql-username: root – nom d'utilisateur de la base de données.

·        mysql-password: password – mot de passe de l'utilisateur.

·        mysql-ssl: false – active le chiffrement SSL de la connexion au serveur de bases de données.

4. API pour les développeurs de plugins

CoreProtect offre aux développeurs un accès à sa base de données via la classe CoreProtectAPI. Cela permet à d'autres plugins (par exemple WorldEdit ou des systèmes de protection) d'enregistrer leurs propres modifications ou d'effectuer une recherche automatique dans l'historique.

Initialisation de l'API

Pour se connecter à l'API, on utilise la méthode d'initialisation :

Principales méthodes de l'interface API

·        boolean logPlacement(String user, Location location, Material type, BlockData blockData) – enregistre la pose d'un bloc dans la base de données au nom de l'utilisateur indiqué.

·        boolean logRemoval(String user, Location location, Material type, BlockData blockData) – enregistre la destruction d'un bloc.

·        boolean logContainerTransaction(String user, Location location, Material type, ItemStack itemStack, boolean isAdded) – enregistre l'opération d'ajout (true) ou de retrait (false) d'objets d'un conteneur.

·        List<String[]> performLookup(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – effectue une recherche selon les filtres indiqués et renvoie un tableau de résultats.

·        List<String[]> performRollback(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – lance une restauration asynchrone des modifications dans le monde.

·        List<String[]> performRestore(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – lance un rétablissement asynchrone des modifications.

·        boolean hasPlaced(String user, Block block, int time, int offset) – vérifie si le joueur indiqué a posé ce bloc dans un laps de temps donné.

·        boolean hasRemoved(String user, Block block, int time, int offset) – vérifie si le joueur indiqué a détruit ce bloc.

5. Performances, compatibilité et maintenance

Lorsqu'ils utilisent CoreProtect sur des serveurs à forte affluence, les administrateurs tiennent compte des particularités de l'interaction avec les architectures de serveur modernes :

·        Prise en charge de Folia : Le cœur de serveur Folia utilise une planification multithread par régions (Regionized multithreading), qui exige des plugins une stricte sécurité des threads lors du travail avec le monde. CoreProtect est adapté au fonctionnement sous Folia : l'exécution des opérations /co rollback et /co restore s'effectue via le planificateur de régions (Region Scheduler), ce qui prévient les conflits d'accès aux chunks et les erreurs critiques de type ConcurrentModificationException.

·        Clustering MultiPaper : Sur les serveurs de type MultiPaper, CoreProtect est configuré pour utiliser une base de données MySQL externe unique. Cela aide à synchroniser l'historique des actions des joueurs sur les différents nœuds du cluster.

·        Nettoyage de la base de données (Purge) : La base de données locale SQLite se fragmente et grossit avec le temps, ralentissant l'exécution des commandes. La commande /co purge t:30d supprime les entrées de plus de 30 jours. Après le nettoyage de la base de données SQLite, le fichier database.db ne diminue pas automatiquement de taille, car le SGBD SQLite conserve les pages libres pour les futures entrées. Pour réduire physiquement le fichier sur le disque, il faut exécuter la commande VACUUM via la console de la base de données ou arrêter le serveur et procéder à la compression à l'aide d'utilitaires tiers. L'utilisation de MySQL élimine ce problème, car le SGBD MySQL libère plus efficacement l'espace disque inutilisé.

Conclusion

CoreProtect est la norme pour les systèmes de journalisation et de restauration sur les serveurs de Minecraft Java Edition. Contrairement à des alternatives telles que LogBlock (qui ne prend en charge que le travail avec MySQL et se limite à la journalisation des blocs) ou Prism (qui présente une structure de configuration plus complexe), CoreProtect propose un fonctionnement entièrement autonome avec SQLite, un suivi détaillé du contenu des conteneurs, ainsi qu'un système unique d'aperçu des restaurations #preview. La seule limitation technique du plugin est la charge importante sur le support de stockage lors du nettoyage de grandes bases de données locales SQLite ; il est donc recommandé aux grands projets d'utiliser des SGBD MySQL dédiés sur des disques NVMe rapides. Le plugin convient aussi bien aux petits serveurs privés entre amis qu'aux projets de grande envergure réunissant des centaines de joueurs actifs.