Module & Presets

EternalSystem besteht aus einem Jar (Eternal-<Version>.jar) für Spigot/Paper und den Proxy (BungeeCord/Waterfall oder Velocity). Replay, Party, Lobby, Autonicker, Coins usw. sind keine eigenen Plugins mehr, sondern Module in diesem Jar. Jeder Server lädt nur die Module, die für ihn freigeschaltet sind. Ein abgeschaltetes Modul hat keine Befehle (sie antworten mit „Dieses Modul ist auf diesem Server nicht aktiv“), keine Listener und keine Hintergrund-Tasks.

Dateien im Plugin-Ordner

Nach dem ersten Start liegt unter plugins/Eternal/:

Die Dateien werden bei Updates nicht überschrieben.

Wie ein Server seine Module bekommt

1. Der Server startet und meldet sich per Heartbeat in der Datenbank (eternal_shared_config, Schlüssel server:<name>): Typ, Version, installierte Plugins, aktive Module. Danach alle 5 Minuten erneut.
2. Ein neuer Server läuft nur mit core (Basis-Befehle).
3. Im Dashboard unter Server → Module den Server links auswählen, ein Preset wählen und/oder Module einzeln schalten, Speichern. Das Dashboard legt dafür modules.yml:<server> in der Datenbank ab.
4. Beim nächsten Neustart oder nach /eternal reload übernimmt der Server diese Datenbank-Kopie. Sie gewinnt immer über die lokale Datei.

Ohne Datenbank-Kopie gilt plugins/Eternal/modules.yml (Spigot) bzw. dieselbe Datei im Datenordner des Proxys.

modules.yml

# zuerst ein Preset anwenden
preset: core
# danach einzelne Module an-/abschalten
modules: {}
#  market: false
#  magic-items: false

# eigene Presets
# presets:
#   bauserver:
#     modules: [core, punishments, reports, chatlog, inventory-sync, item-tracking, locks]

Ohne preset gilt core. Unbekannte Schlüssel unter modules: werden als eigene Module (siehe unten) behandelt. Die Datei ist zum Teilen gedacht: modules.yml exportieren im Dashboard liefert genau diese Datei, eigene Presets inklusive.

Alle Module

Abhängigkeiten werden transitiv geprüft: Wer locks ohne inventory-sync einschaltet, verliert erst item-tracking und dadurch auch locks. Das Dashboard zeigt fehlende Voraussetzungen rot („braucht: …“), der Server loggt „Modul X bleibt aus — braucht Y“.

Presets

clans ist in full und citybuild enthalten – für Survival-Server zusätzlich einschalten.

Eigene Presets entstehen im Dashboard über Aktuelle Auswahl als Preset speichern. Sie landen in modules-presets.yml in der Datenbank und werden in jede exportierte modules.yml eingebettet. Eingebaute Presets lassen sich nicht löschen.

Dashboard: Server → Module

Recht: eternal.web.modules (Standard-Stufe Admin, braucht eternal.web.admin).

• Server-Liste links: grüner Punkt = online, Tooltip mit „zuletzt gesehen“. Ein durchgestrichener Stift heißt „noch nicht im Dashboard konfiguriert – nutzt lokale modules.yml“.
• Preset-Auswahl oben rechts setzt alle Schalter neu.
• Pro Modul: Schalter, Beschreibung, „braucht: …“ (grün erfüllt, rot fehlt), Status-Chip läuft (aktiv auf dem Server) oder ausstehend (gespeichert, aktiv nach Neustart bzw. /eternal reload).
• Speichern, modules.yml exportieren, Vergessen (entfernt den Server aus der Liste, er meldet sich beim nächsten Start neu).
• Unten steht, wie viele Module nach Auflösung der Abhängigkeiten aktiv sind.

Zuordnung & eigene Module (Server → Zuordnung)

Jede schaltbare Einheit des Plugins ist ein Feature mit stabilem Schlüssel:

Die Seite listet alle Features mit dem Modul, in dem sie ausgeliefert werden. Recht: eternal.web.modules.

• Umhängen: Jedes Feature lässt sich in ein anderes Modul verschieben (eingebaut oder eigen). Der Server schaltet es dann zusammen mit diesem Modul.
• Eigene Module: Schlüssel (a-z, 0-9, -), Name, Icon, Beschreibung. Ein eigenes Modul ist auf jedem Server aus, bis es unter Module pro Server eingeschaltet wird.
• Gespeichert wird netzwerkweit als features.txt in der Datenbank; wirksam nach Neustart bzw. /eternal reload.

Befehle anderer Plugins: Ist ein Befehl aus (sein Modul auf diesem Server aus), übernimmt ihn ein anderes Plugin, das denselben Befehl hat – z. B. /msg von Essentials. Eternals Version bleibt als /eternal:msg erreichbar. Ist der Befehl an, gehört er Eternal, auch wenn das andere Plugin später geladen wurde (dessen Version: /<plugin>:<befehl>). Beispiel: cmd:msg und cmd:reply in ein eigenes, ausgeschaltetes Modul hängen → Essentials übernimmt Privatnachrichten.

Einige Beispiele für die Standard-Zuordnung, die nicht offensichtlich sind:

Clearlag (Teil von core)

Entfernt Bodenitems: automatisch im Intervall (Feature task:clearlag) mit Ansage vorher, oder sofort mit /clearlag (Recht eternal.clearlag). /clearlag info zeigt allen die Restzeit. MagicItems, Custom Items und gesperrte Items bleiben liegen; getrackte Items bekommen in ihrer Historie den Eintrag „Clearlag“.

clearlag:
  auto: true
  interval-minutes: 15
  warn-seconds: [60, 10]
  arrows: true          # steckende Pfeile ebenfalls
  xp-orbs: false        # XP-Kugeln ebenfalls
  worlds-excluded: []   # Welten, in denen nichts entfernt wird

Typische Stolperfallen

• Änderung greift nicht: Module werden nur beim Start und bei /eternal reload gelesen. Im Dashboard steht dann „ausstehend“.
• Modul bleibt aus: Voraussetzung fehlt (Log-Zeile „bleibt aus — braucht …“).
• Server taucht nicht auf: Der Heartbeat landet in der Datenbank des Servers. Nur wenn Server und REST-API dieselbe MySQL-Datenbank nutzen, sieht das Dashboard ihn – mit der lokalen H2-Datei (database.type: h2) nicht.
• Hotbar-Items von Nick und Party fehlen: Namensschild und Party-Kopf gibt es nur auf Servern mit dem Modul lobby. Auf Spielservern funktionieren nur die Befehle. Siehe Lobby-Modul.
• Gleicher Servername doppelt: server-name in config.yml muss pro Server eindeutig sein und dem Namen im Proxy entsprechen – sonst überschreiben sich Heartbeat und Modul-Liste.