Commands

The library registers one command, /exylialib, with no aliases. Subcommands tab-complete. Each sits behind its own permission so a server can hand one out without the others; every one of them is op by default.

/settings is the library's other command, and it is off until settings.command.enabled is turned on in config.yml. It opens the screen where players set the preferences every Exylia plugin registers, and needs exylialib.settings, which every player has by default.

The status panel

The bare /exylialib prints everything about the library on this server in one panel:

• Library — version, platform, whether auto-update is on and how often it checks, debug, small text.
• Network — whether Redis is on, this server's id on it, and the proxy bridge: a ping sent now and timed, so a proxy that went away reads as gone. A silent proxy reads as no answer, with the usual cause (ExyliaProxyUtils missing, or on another Redis or key prefix). Players on the network when the bridge answers.
• Modules — active scoreboards, holograms and effects, how many plugins use menus and regions, actions registered, config files loaded.
• Database — the engine, and one line per plugin with its own state, so one plugin's unreachable database is not hidden behind nine healthy ones.
• Depending plugins — every plugin using the library, with its version.

Without Redis the panel arrives at once; with it, as soon as the proxy answers, or after five seconds.

Moving and wiping data

export names the tables it found before it starts. A plugin only appears once it has asked for its first table, so a plugin that registers one lazily exports fewer than it owns — read the names.

import refuses to write into tables that already hold rows, and hands back the exact command that would go through. force merges: rows whose key is in the dump are overwritten, rows that are not stay where they are.

wipe runs twice. The first run deletes nothing: it lists what would go and gives a six-digit code. The same command with that code within 60 seconds — same sender, same request — writes a dump first and only then deletes; if the dump fails, nothing is deleted. Restart afterwards: until then the plugin still holds the rows in memory, and its writes to the wiped tables are ignored so they cannot come back. Restore a dump with /exylialib import <plugin> <file> true.

Wiping by kind

Every table a plugin declares says what it holds, so a wipe picks kinds instead of table names:

Two presets name the usual sets: @season (progress, world and cache) and @players (progress and cache). Neither ever touches @setup or @unspecified tables; those go only when named, by kind, by table, or with all. <plugin> <table|all> keeps working as before, and all all is every table of every plugin.

/exylialib wipe all @season            # a new season, every plugin
/exylialib wipe ExyliaClans @world     # one plugin's world state

In game, /exylialib wipe alone opens the same thing as screens: pick a preset, leave plugins out, see the rows each kind would remove, and confirm by typing WIPE. The screens can also delete the vanilla player files (playerdata, stats, advancements) on the next start.

Resetting a player

resetplayer deletes one player's rows without a restart. Only tables that name the player's column take part; the others are skipped, and the preview says how many.

/exylialib resetplayer Steve                       # every plugin, the default kinds
/exylialib resetplayer Steve ExyliaPracticeCore    # one plugin
/exylialib resetplayer Steve all @progress @account

• With no kinds, a reset clears progress, world and cache. Naming kinds replaces that set: @account and @history are only removed when named, and @setup and @unspecified are refused.
• Presets do not apply here: name kinds one by one.
• It confirms like wipe: the first run shows what goes and a code, the same line with the code runs it.
• A player online on another server is refused. The player is kicked and kept out of the network while it runs, a dump is written first, and they may join again as soon as it finishes.
• Deleting the player's vanilla files is offered only by the screens.

Staff log

Every Exylia plugin can record what staff do — who did what to whom, where, and which items moved — into its own database. /exylialib logs reads them all together:

/exylialib logs Steve                  # everything done by or to Steve
/exylialib logs * ExyliaMarket         # every market entry
/exylialib logs Steve * trade          # Steve's trades, in any plugin

* (or all) means no filter. A player gets a menu with an entry per action and the items it moved; the console gets the newest lines as text. Retention, write interval, row limits and what is never recorded are in the logs block of config.yml.

Pending rewards

Rewards a plugin could not hand over yet wait in that plugin's pending store until the player claims them. /exylialib pendingrewards lists who is owed what, across every plugin. A player gets a menu, straight to one player's batches when a name is given: left click gives a batch to its owner (who must be online), shift-right click cancels it (it asks twice). The console gets a summary. Every give and cancel is written to the server console.

Updates on join

An admin is told on join when there is something to act on:

• with exylialib.admin, when plugin updates are staged and waiting for a restart;
• with exylialib.updates, when default changes are waiting in /exylialib updates, once per batch.