Modules & Presets

EternalSystem consists of one jar (Eternal-<Version>.jar) for Spigot/Paper and the proxy (BungeeCord/Waterfall or Velocity). Replay, party, lobby, Autonicker, coins etc. are no longer separate plugins but modules in this jar. Every server only loads the modules that are enabled for it. A disabled module has no commands (they reply with „Dieses Modul ist auf diesem Server nicht aktiv“, "This module is not active on this server"), no listeners and no background tasks.

Files in the plugin folder

After the first start, plugins/Eternal/ contains:

The files are not overwritten during updates.

How a server gets its modules

1. The server starts and registers itself via heartbeat in the database (eternal_shared_config, key server:<name>): type, version, installed plugins, active modules. After that, again every 5 minutes.
2. A new server runs with core only (basic commands).
3. In the dashboard under Server → Module ("Modules"), select the server on the left, choose a preset and/or toggle modules individually, then Speichern ("Save"). The dashboard stores modules.yml:<server> in the database for this.
4. On the next restart or after /eternal reload, the server adopts this database copy. It always wins over the local file.

Without a database copy, plugins/Eternal/modules.yml (Spigot) or the same file in the proxy's data folder applies.

modules.yml

# first apply a preset
preset: core
# then turn individual modules on/off
modules: {}
#  market: false
#  magic-items: false

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

Without preset, core applies. Unknown keys under modules: are treated as custom modules (see below). The file is meant for sharing: modules.yml exportieren ("Export modules.yml") in the dashboard delivers exactly this file, custom presets included.

All modules

Dependencies are checked transitively: if you enable locks without inventory-sync, item-tracking is dropped first, and with it locks. The dashboard shows missing prerequisites in red („braucht: …“, "requires: …"); the server logs „Modul X bleibt aus — braucht Y“ ("Module X stays off — requires Y").

Presets

clans is included in full and citybuild – enable it additionally for survival servers.

Custom presets are created in the dashboard via Aktuelle Auswahl als Preset speichern ("Save current selection as preset"). They are stored in modules-presets.yml in the database and embedded in every exported modules.yml. Built-in presets cannot be deleted.

Dashboard: Server → Module

Permission: eternal.web.modules (default level Admin, requires eternal.web.admin).

• Server list on the left: green dot = online, tooltip with „zuletzt gesehen“ ("last seen"). A crossed-out pencil means „noch nicht im Dashboard konfiguriert – nutzt lokale modules.yml“ ("not yet configured in the dashboard – uses local modules.yml").
• The Preset selection at the top right resets all toggles.
• Per module: toggle, description, „braucht: …“ (green = met, red = missing), status chip läuft ("running", active on the server) or ausstehend ("pending", saved, active after restart or /eternal reload).
• Speichern ("Save"), modules.yml exportieren ("Export modules.yml"), Vergessen ("Forget"; removes the server from the list, it registers again on its next start).
• At the bottom, you can see how many modules are active after resolving dependencies.

Assignment & custom modules (Server → Zuordnung)

Every toggleable unit of the plugin is a feature with a stable key:

The page lists all features with the module they ship in. Permission: eternal.web.modules.

• Reassigning: every feature can be moved to a different module (built-in or custom). The server then toggles it together with that module.
• Custom modules: key (a-z, 0-9, -), name, icon, description. A custom module is off on every server until it is enabled per server under Module.
• It is stored network-wide as features.txt in the database; effective after restart or /eternal reload.

Other plugins' commands: when a command is off (its module is off on this server), another plugin with the same command takes it over – e.g. Essentials' /msg. Eternal's version stays reachable as /eternal:msg. When the command is on, it belongs to Eternal even if the other plugin was loaded later (its version: /<plugin>:<command>). Example: put cmd:msg and cmd:reply into a custom module that is off → Essentials handles private messages.

Some examples of the default assignment that are not obvious:

Clearlag (part of core)

Removes items on the ground: automatically at an interval (feature task:clearlag) with an announcement before, or right away with /clearlag (permission eternal.clearlag). /clearlag info shows everyone the time left. MagicItems, custom items and locked items stay; tracked items get a "Clearlag" entry in their history.

clearlag:
  auto: true
  interval-minutes: 15
  warn-seconds: [60, 10]
  arrows: true          # stuck arrows too
  xp-orbs: false        # XP orbs too
  worlds-excluded: []   # worlds where nothing is removed

Common pitfalls

• Change does not take effect: modules are only read at startup and on /eternal reload. The dashboard then shows „ausstehend“ ("pending").
• Module stays off: a prerequisite is missing (log line „bleibt aus — braucht …“, "stays off — requires …").
• Server does not show up: the heartbeat goes into the server's database. The dashboard only sees it if server and REST API use the same MySQL database – not with the local H2 file (database.type: h2).
• Hotbar items of nick and party are missing: the name tag and party head only exist on servers with the lobby module. On game servers, only the commands work. See Lobby module.
• Same server name twice: server-name in config.yml must be unique per server and match the name in the proxy – otherwise heartbeat and module list overwrite each other.