CoreProtect — Minecraft Java Edition 1.16 - 1.21.11+

Mehrspieler-Server von Minecraft benötigen ein detailliertes Audit der Spieleraktionen, um unbefugte Kartenänderungen und den Diebstahl von Spielwerten zu verhindern. Der Vanilla-Serverkern protokolliert weder die Historie der Geländebearbeitung noch das Verschieben von Gegenständen in Behältern, weshalb Administratoren keine Möglichkeit haben, Verstöße zu identifizieren oder Zerstörungen rückgängig zu machen, ohne die Kartendateien vollständig aus Sicherungskopien wiederherzustellen. Das Server-Plugin CoreProtect zeichnet alle Ereignisse der Weltänderung auf, erstellt detaillierte Indizes der Benutzeraktionen und führt punktuelle Rückgängigmachungen (Rollbacks) des Raums auf Basis komplexer parametrischer Abfragen durch. Das Werkzeug arbeitet im asynchronen Modus und schreibt Transaktionen in eine Warteschlange, um den Haupt-Thread des Servers vor Verzögerungen zu schützen.

1. Datenbanken und asynchrone Logging-Architektur

Das Plugin CoreProtect fängt Serverereignisse mithilfe der Event-Handler der Bukkit/Paper API ab. Um die Blockierung des Haupt-Threads des Servers (Server Thread) während der Verarbeitung von Tausenden von Einträgen pro Sekunde zu verhindern, verwendet das Plugin ein asynchrones Logging-Modell. Ereignisse (Zerstörung eines Blocks, Änderung des Truheninventars, Verwendung eines Befehls) werden zunächst in einen internen dynamischen Puffer DataQueue gelegt. Ein Hintergrund-Verbraucher-Thread (Consumer Thread) liest die Transaktionen aus dem Puffer und schreibt sie in Stapeltransaktionen (Batch processing) in die Datenbank, was die Belastung des Datenträgers verringert.

Das Plugin unterstützt die Arbeit mit zwei Datenbankmanagementsystemen (DBMS):

1. SQLite (lokal, standardmäßig): Alle Informationen werden in die Datei database.db im Plugin-Verzeichnis geschrieben. SQLite erfordert keine Installation von Drittanbieterdiensten, was es für kleine lokale Server mit geringem Transaktionsaufkommen praktisch macht.

2. MySQL / MariaDB (externer Server): Verwendet eine Netzwerkverbindung zu einem separaten Datenbankserver. Diese Lösung ist der Industriestandard für große Server und Servernetzwerke mit hoher Spielerzahl (ab 50 Spielern). MySQL gewährleistet eine hohe Ausführungsgeschwindigkeit von Indexabfragen und verhindert eine Fragmentierung des lokalen Speichers.

Schema der Datenbanktabellen

CoreProtect erstellt eine Reihe relationaler Tabellen zur Optimierung der Datenspeicherung. Anstatt für jeden Eintrag vollständige Textzeichenfolgen zu speichern, verwendet das Plugin Wörterbuchtabellen für eindeutige Spielernamen, Welten, Blocktypen und Entitäten.

Alle Koordinaten x, y, z werden gemeinsam mit der Welt-Kennung wid indexiert, um eine sofortige Suche nach Transaktionen in einem bestimmten Radius zu gewährleisten.

2. Befehlssyntax und Filterparameter

Die Interaktion mit der CoreProtect-Datenbank erfolgt über Textbefehle. Die wichtigsten Operationen sind: Inspektion, Suche, Rollback und Rückgängigmachen des Rollbacks.

Inspektormodus /co inspect oder /co i)

Der Befehl schaltet den Client in den lokalen Audit-Modus. Nach der Aktivierung kann der Spieler mit der Welt interagieren, um Protokolle zu erhalten:

·        Ein Linksklick auf einen vorhandenen Block zeigt im Chat den Nickname desjenigen an, der ihn platziert hat, sowie Datum, Uhrzeit und Koordinaten.

·        Ein Rechtsklick auf eine leere Fläche (oder einen Block) zeigt die Historie der Blöcke an, die diesen Raum zuvor eingenommen haben oder abgebaut wurden.

·        Ein Rechtsklick auf einen Behälter (Truhe, Ofen, Fass, Shulker) zeigt das Protokoll der Gegenstandsbewegungen an.

Filterparameter für Abfragen /co rollback, /co restore, /co lookup)

Zur Datenauswahl verwendet das Plugin kombinierte Parameter im Format Parameter:Wert. Die Parameter werden durch Leerzeichen getrennt:

1. Benutzer u:<Name>): Gibt den zu überprüfenden Spieler an. Es können mehrere Namen durch Kommas getrennt angegeben werden (zum Beispiel u:Stevie,Alex). Für das Rückgängigmachen natürlicher Ereignisse werden technische Kennungen verwendet:

·        u:#fire – Feuerausbreitung.

·        u:#lava – Lavaausbreitung.

·        u:#water – Wasserausbreitung.

·        u:#creeper – Explosion eines Creepers.

·        u:#tnt – Explosion von TNT.

·        u:#enderman – Verschieben von Blöcken durch einen Enderman.

2. Zeit t:<Wert>): Zeitintervall für die Analyse. Unterstützt die Maßeinheiten: s (Sekunden), m (Minuten), h (Stunden), d (Tage), w (Wochen), y (Jahre). Es ist erlaubt, Einheiten zu kombinieren, zum Beispiel: t:2w4d6h (2 Wochen, 4 Tage und 6 Stunden).

3. Radius r:<Zahl>): Radius des Suchbereichs in Blöcken um den Ausführenden des Befehls. Unterstützt auch spezielle Werte:

·        r:#global – Suche in der gesamten Datenbank (innerhalb aller geladenen Chunks).

·        r:#world – Suche innerhalb der aktuellen Spielwelt.

·        r:#chunk – Suche im aktuellen Chunk des Spielers.

·        r:#selection (oder r:#we) – beschränkt die Suche auf die Grenzen des aktuellen Auswahlrasters von WorldEdit.

4. Aktion a:<Typ>): Filtert die Einträge nach Operationstyp:

·        a:block – Platzieren und Zerstören von Blöcken.

·        a:+block – nur Platzieren von Blöcken.

·        a:-block – nur Zerstören von Blöcken.

·        a:container – Inventartransaktionen.

·        a:+container – Hinzufügen von Gegenständen zu einem Behälter.

·        a:-container – Entnehmen von Gegenständen aus einem Behälter.

·        a:kill – Tod von Tieren und Monstern.

·        a:spawn – Spawn von Entitäten.

·        a:chat – Chatnachrichten.

·        a:command – eingegebene Befehle.

·        a:session – Anmeldung von Spielern.

5. Blöcke b:<Material>): Beschränkt die Suche auf die angegebenen Materialien (zum Beispiel b:stone,oak_planks).

6. Ausschluss e:<Material>): Schließt Materialien von der Verarbeitung aus (zum Beispiel e:tnt).

Vorschau des Rollbacks und Rückgängigmachen von Operationen

Zur Minimierung von Fehlern bei großangelegten Rollbacks unterstützt CoreProtect ein System der visuellen Simulation:

1. Die Ausführung des Rollback-Befehls mit dem Flag #preview (zum Beispiel /co rollback u:Griefer t:2h r:20 #preview) verändert die Kartendateien nicht. Stattdessen erhält der Client in der aktuellen Rendering-Sitzung Pakete zur Blockänderung. Der Administrator sieht die Welt im Zustand „nach dem Rollback", während die Blöcke für die anderen Spieler unverändert bleiben.

#preview

/co apply

2. Um das Ergebnis anzuwenden, wird der Befehl /co apply verwendet.

3. Um die Vorschau abzubrechen, wird der Befehl /co cancel verwendet.

4. Um einen bereits durchgeführten physischen Rollback rückgängig zu machen, wird der Befehl /co undo angewendet, der die Koordinaten in den Zustand vor der Ausführung von /co rollback zurückversetzt.

3. Vollständige Beschreibung der Konfigurationsdatei config.yml

Die Konfigurationsdatei steuert Limits, Logging-Parameter und die Verbindung zu Datenbanken.

Block der allgemeinen Parameter (General Settings)

·        verbose: true – gibt während der Ausführung von Rollbacks einen ausführlichen Bericht über jede geänderte Koordinate in der Konsole aus. Bei der Einstellung false wird nur die Gesamtzahl der geänderten Blöcke ausgegeben.

·        check-updates: true – prüft beim Start, ob auf den Servern des Entwicklers neue Versionen des Plugins vorhanden sind.

·        api-enabled: true – erlaubt Drittanbieter-Plugins die Interaktion mit den Daten von CoreProtect.

·        default-radius: 10 – Standard-Rollback-Radius, falls dieser Parameter im Befehl nicht angegeben ist.

·        max-radius: 250 – begrenzt den maximalen Radius für einen einzelnen Befehl. Der Wert 0 hebt die Begrenzung auf.

Block der Logging-Parameter (Logging Settings)

Diese Parameter legen fest, welche Ereignisse genau in die Datenbank geschrieben werden. Das Deaktivieren nicht benötigter Logs hilft, die Größe der Datenbank zu verringern:

·        block-place: true / block-break: true – Protokollierung des normalen Platzierens und Zerstörens von Blöcken durch Spieler.

·        natural-break: true – Protokollierung des Herabfallens von Blöcken infolge von Verschiebungen oder der Zerstörung von Stützblöcken (zum Beispiel das Zerstören eines Blocks, an dem eine Fackel hing).

·        block-movement: true – Protokollierung des gravitationsbedingten Fallens von Sand, Kies oder Beton.

·        pistons: true – Protokollierung des Verschiebens von Blöcken mithilfe von Kolben.

·        block-burn: true – Protokollierung der Zerstörung von Blöcken durch Feuer.

·        block-ignite: true – Protokollierung des Anzündens von Blöcken durch Spieler mithilfe eines Feuerzeugs oder von Feuerbällen.

·        explosions: true – Protokollierung von Explosionen durch TNT, Creeper, Betten im Nether oder Enderkristalle.

·        entity-kills: true – Erfassung des Todes von Dorfbewohnern, Tieren, Monstern und Rüstungsständern.

·        player-chat: true / player-command: true – Protokollierung von Chatnachrichten und Konsolenbefehlen.

·        player-session: true – Protokollierung der Anmelde- und Abmeldezeiten der Spieler auf dem Server.

·        container-transactions: true – Protokollierung der Bewegungen von Gegenständen in Truhen, Öfen, Trichtern und Shulkern.

Block der Datenbank (Database Settings)

·        use-mysql: false – Umschalter für den Datenbanktyp. Bei der Einstellung true verbindet sich das Plugin mit einem externen MySQL-DBMS.

·        table-prefix: co_ – Präfix für die Namen der SQL-Tabellen.

·        mysql-host: localhost – IP-Adresse oder Domänenname des MySQL-Datenbankservers.

·        mysql-port: 3306 – Netzwerkport für die Verbindung.

·        mysql-database: minecraft – Name der Zieldatenbank.

·        mysql-username: root – Benutzername der Datenbank.

·        mysql-password: password – Passwort des Benutzers.

·        mysql-ssl: false – aktiviert die SSL-Verschlüsselung der Verbindung zum Datenbankserver.

4. API für Plugin-Entwickler

CoreProtect gewährt Entwicklern über die Klasse CoreProtectAPI Zugriff auf seine Datenbank. Dies erlaubt anderen Plugins (zum Beispiel WorldEdit oder Schutzsystemen), ihre eigenen Änderungen zu protokollieren oder eine automatische Suche in der Historie durchzuführen.

Initialisierung der API

Zur Verbindung mit der API wird die Initialisierungsmethode verwendet:

Wichtigste Methoden der API-Schnittstelle

·        boolean logPlacement(String user, Location location, Material type, BlockData blockData) – protokolliert das Platzieren eines Blocks in der Datenbank im Namen des angegebenen Benutzers.

·        boolean logRemoval(String user, Location location, Material type, BlockData blockData) – protokolliert das Zerstören eines Blocks.

·        boolean logContainerTransaction(String user, Location location, Material type, ItemStack itemStack, boolean isAdded) – zeichnet das Hinzufügen (true) oder Entnehmen (false) von Gegenständen aus einem Behälter auf.

·        List<String[]> performLookup(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – führt eine Suche anhand der angegebenen Filter durch und gibt ein Array von Ergebnissen zurück.

·        List<String[]> performRollback(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – leitet ein asynchrones Rückgängigmachen der Änderungen in der Welt ein.

·        List<String[]> performRestore(int time, List<String> restrictUsers, List<String> excludeUsers, List<Object> restrictBlocks, List<Object> excludeBlocks, List<Integer> restrictActions, int radius, Location location) – leitet eine asynchrone Wiederherstellung der Änderungen ein.

·        boolean hasPlaced(String user, Block block, int time, int offset) – prüft, ob der angegebene Spieler diesen Block innerhalb eines bestimmten Zeitraums platziert hat.

·        boolean hasRemoved(String user, Block block, int time, int offset) – prüft, ob der angegebene Spieler diesen Block zerstört hat.

5. Leistung, Kompatibilität und Wartung

Beim Einsatz von CoreProtect auf Servern mit hoher Spielerzahl berücksichtigen Administratoren die Besonderheiten der Interaktion mit modernen Serverarchitekturen:

·        Unterstützung von Folia: Der Folia-Serverkern verwendet ein regionalisiertes Multithreading-Scheduling (Regionized multithreading), das von Plugins eine strikte Thread-Sicherheit bei der Arbeit mit der Welt erfordert. CoreProtect ist für den Betrieb in Folia angepasst: Die Ausführung der Operationen /co rollback und /co restore erfolgt über den Region Scheduler, was Zugriffskonflikte auf Chunks und kritische Fehler des Typs ConcurrentModificationException verhindert.

·        MultiPaper-Clustering: Auf Servern vom Typ MultiPaper wird CoreProtect auf die Verwendung einer einzigen externen MySQL-Datenbank konfiguriert. Dies hilft, die Historie der Spieleraktionen auf den verschiedenen Server-Nodes des Clusters zu synchronisieren.

·        Bereinigung der Datenbank (Purge): Die lokale SQLite-Datenbank fragmentiert mit der Zeit und wächst an, wodurch die Ausführung von Befehlen verlangsamt wird. Der Befehl /co purge t:30d löscht Einträge, die älter als 30 Tage sind. Nach der Bereinigung der SQLite-Datenbank verkleinert sich die Datei database.db nicht automatisch, da das SQLite-DBMS freie Seiten für künftige Einträge aufbewahrt. Für eine physische Verkleinerung der Datei auf der Festplatte muss der Befehl VACUUM über die Datenbankkonsole ausgeführt oder der Server gestoppt und die Komprimierung mithilfe von Drittanbieter-Werkzeugen durchgeführt werden. Die Verwendung von MySQL beseitigt dieses Problem, da das MySQL-DBMS ungenutzten Festplattenspeicher effizienter freigibt.

Fazit

CoreProtect ist der Standard für Logging- und Wiederherstellungssysteme auf Servern von Minecraft Java Edition. Im Gegensatz zu Alternativen wie LogBlock (das nur die Arbeit mit MySQL unterstützt und auf die Protokollierung von Blöcken beschränkt ist) oder Prism (das eine komplexere Konfigurationsstruktur aufweist) bietet CoreProtect einen vollständig autonomen Betrieb mit SQLite, eine detaillierte Verfolgung des Behälterinhalts sowie ein einzigartiges Vorschausystem für Rollbacks #preview. Die einzige technische Einschränkung des Plugins ist die erhebliche Belastung des Datenträgers während der Bereinigung großer lokaler SQLite-Datenbanken, weshalb großen Projekten empfohlen wird, dedizierte MySQL-DBMS auf schnellen NVMe-Festplatten zu verwenden. Das Plugin eignet sich sowohl für kleine private Server unter Freunden als auch für große Projekte mit Hunderten aktiver Spieler.