Configuration

Everything lives in plugins/ExyliaSurvivalCore/. config.yml, messages.yml and each module's config.yml are generated from the plugin's own schema on first run, comments included. The menus and the default ladders — ranks, rewards, categories, missions, votes, seasons and the rest — ship inside the jar and are written from it.

Five kinds of file

A lifted-out file that already exists is treated as already moved, so a file you deliberately emptied stays empty rather than having the shipped defaults written back over it.

What an edit survives

The bundled-and-tracked files are refreshed on every start, and the menus, votes.yml and seasons.yml again on every reload. For each YAML file the plugin compares three things: your file, the shipped file, and the defaults you last reviewed, which are kept in .defaults/files/ inside the plugin folder.

• A missing file is written — unless it was installed before and you deleted it. A deleted menu stays deleted, and the console names the menu it could not register.
• A key the new version adds is written into your file at once, comments included.
• A default that changed or was removed, on a key still at the value you last reviewed, is left as it is and listed in /exylialib updates, where you apply or keep it.
• Anything you changed or deleted is never touched.
• A file whose shipped menu-version (or defaults-version) is higher than yours is replaced whole; your previous file is kept next to it as <name>.v<old version>.

On a server updating from a version that tracked nothing yet, every value already on disk counts as yours, and a key missing from your file is listed in /exylialib updates rather than added, since you may have deleted it on purpose. A file that does not parse is left untouched and reported.

trade/window.yml goes one step further: the window reads the jar's copy first and yours on top of it, so an item a new version adds is drawn even while its entry waits in /exylialib updates.

config.yml

Three blocks: debug, the fifty module switches — see Modules — and teleport.

There is no database section here. The database is configured in database.yml, written by ExyliaLib.

teleport

How teleports behave when nothing asks for something else. The plugin hands this section to ExyliaLib's teleports on every start and every reload.

teleport:
  warmup-seconds: 0.0
  cancel-on-move: true
  cancel-on-damage: true
  safe-search-radius: 5
  safe-max-attempts: 32
  cross-server-ttl-seconds: 300
  cross-server-settle-seconds: 0.5
  back-history-size: 3
  back-history-minutes: 30
  tpa-expiry-seconds: 60
  tpa-max-pending: 8
  random-max-attempts: 16

A value outside its range is pulled back to the nearest end of it; a negative warmup becomes 0.

messages.yml

One prefix and fifty-one sections — errors, admin, and one for every module except join-leave. Every line the plugin sends is in this file; nothing player-facing is hardcoded.

errors is the shared block: module-disabled, no-permission, player-not-found, invalid-number, world-blacklisted. admin.restart-required is the line /sc reload ends with when a module switch is waiting for a restart.

A line may open with an effect tag such as [sound:ENTITY_VILLAGER_NO|1.0|1.0], which is an instruction and never reaches the screen. %prefix% is substituted from the prefix key.

Shared shapes

Several modules draw the same three things, and they take the same keys everywhere.

colour takes PINK, BLUE, RED, GREEN, YELLOW, PURPLE or WHITE. overlay takes PROGRESS, NOTCHED_6, NOTCHED_10, NOTCHED_12 or NOTCHED_20. time-style takes auto, seconds, tenths, hundredths, clock or full. A stay or duration of 0 means "until something stops it".

Sounds are always SOUND_NAME|VOLUME|PITCH, and a blank string disables one.

Per-module files

What each key does is on that module's own page: Movement, Combat, Duel rooms, Progression, Missions and seasons, Rewards and votes, Kits and crates, Zones, Restrictions, Quality of life, Optimization, Economy, Shop, Market, Trade and vaults and Protections.

Comments that are out of date

The generated files carry their own explanations, and four of those are wrong. They are listed here so that a file disagreeing with this documentation is not a surprise.

Reloading

/survivalcore reload, from the console or in game, runs three steps in order:

1. configs — config.yml including debug and teleport, messages.yml and the prefix, and every schema-backed module file.
2. modules — each module that is on declares its files again and re-reads what it keeps: ladders, rules, missions.yml, votes.yml, seasons.yml and the rest.
3. menus — menus/admin/ is replaced from the jar, the other menus are refreshed as described above, and every menu is compiled again. This step also runs on /exylialib reload.

A step that fails is reported by name and the ones after it still run. The reload does not apply a module switch; when one no longer matches what is running, it ends by naming the modules that need a restart.