Getting started

Installation

Dependencies and what each optional one enables, first boot, the files the plugin generates, where the database is set, and what a reload actually reloads.

Before you start

packetevents is a hard dependency, like on every Exylia plugin: without it the server refuses to load this one. FastAsyncWorldEdit is optional: it is listed under softdepend, and regenerating zones turn themselves off without it and say so in the log.

Plugin	What for
`packetevents`	Required (`depend`). Power-ups are drawn as packet-level floating items, item spawners colour their glow with it, and ExyliaLib runs its packet features through it.
`FastAsyncWorldEdit`	Optional. Regenerating zones save and paste schematics through it; without it they stay off.

ExyliaLib is listed under softdepend on purpose — the loader that installs ExyliaLib is the one that has to load first for that install to happen — but nothing here runs without it. It provides the configuration, menus, database, placeholders, holograms, scoreboards, regions, wizards, chat inputs, teleports, the scheduler, and the facades that read other plugins' economies and clans. The plugin names no minimum ExyliaLib version: the loader installs the library, and the library's own updater keeps it current.

Optional plugins

Declared under softdepend, each one switches on something specific:

Plugin	What it enables
`PlaceholderAPI`	The plugin's placeholders outside it; `placeholder` requirements in `ranks.yml`; stats of type `PAPI`, such as the shipped `playtime`.
`WorldGuard`	Region scopes in the enchantment and blocked-item rules. For protections: the `WORLDGUARD` backend, which mirrors every protection as a WorldGuard region; refusing land that overlaps somebody else's WorldGuard region; and the ProtectionStones import. Protections do not need it — the default backend is `INTERNAL`.
`BlueMap`, `dynmap`	Protections drawn on the web map, when turned on in `modules/protections/config.yml`.
`Votifier` (or NuVotifier)	Votes reaching the `votes` module. Without it, votes only arrive through `/voteadmin fake`.
`Apollo` (`Apollo-Bukkit`, `Apollo-Folia`), `FeatherServerAPI`	Spawn and homes shown as client waypoints.
`Worlds`	World handling on Folia.

Two more are not in plugin.yml and are read through ExyliaLib:

Vault or PlayerPoints — their currencies sit next to the ones the economy module stores, and the economy module can publish one of its own currencies as the server's Vault economy. See Economy.
ExyliaClans or SimpleClans — clans and alliances for duel rooms and protections. Without one, nobody is in a clan.

Installing

Drop in the jars

Copy ExyliaSurvivalCore.jar, ExyliaLib.jar and packetevents.jar into plugins/, plus FastAsyncWorldEdit.jar if you want regenerating zones.

Start the server

The first boot writes config.yml, messages.yml, one folder per module under modules/, the menus and the tables of every module that is on.

Turn off what you do not want

All fifty switches ship as true. Set the rest to false and restart — see Modules.

Set the spawn and grant the nodes

/spawn set, then grant your groups their nodes. Nothing is declared in plugin.yml, so no node has a default. See First steps.

Warnings worth recognising in the console at boot:

No economy is installed: prices and payouts are skipped. — no currency is registered at all: the economy module is off and neither Vault nor PlayerPoints provides one.
Regen zones are off: <reason> — FastAsyncWorldEdit's schematic support is not usable, so the regen-zones module loads but never regenerates anything.
NuVotifier is not installed: votes only arrive through /voteadmin fake.
Missions are on but stats are off: … and Seasons rank stat counters, and the stats module is off: nothing will be ranked. — both read the stat counters, which only the stats module keeps.
Protections are set to the WORLDGUARD backend, but WorldGuard is not enabled. Falling back to INTERNAL.

Generated files

All of them live in plugins/ExyliaSurvivalCore/.

Path	Contents
`config.yml`	`debug`, the fifty module switches and the `teleport` section.
`messages.yml`	Every line the plugin sends, in fifty-one sections.
`modules/<id>/config.yml`	One per module that has settings.
`modules/<id>/<data>.yml`	The ladders: ranks, rewards, categories, groups, worlds, stats, missions, rules.
`modules/votes/votes.yml`, `modules/seasons/seasons.yml`, `modules/trade/window.yml`	Shipped files kept up to date without undoing your edits.
`modules/<id>/menus/`, `menus/currency_select.yml`	The sixty-nine menus outside `menus/admin/`. Yours to edit; new keys are added, your values are kept.
`menus/admin/`	The forty-nine admin screens. Rewritten from the jar on every start and every reload.
`.defaults/files/`	The shipped defaults you last reviewed, which is how an update tells your edits from its own.
`database.yml`	Database engine and Redis, written by ExyliaLib.

config.yml, messages.yml and every modules/<id>/config.yml are generated from the plugin's own schema, comments included. A key the schema does not recognise is reported once as UNKNOWN_KEY and removed. The menus and the default ladders are shipped inside the jar. How each kind of file is written and updated is on Configuration.

Do not edit anything under `menus/admin/`

That whole directory is replaced from the jar every time the plugin enables and every time you run /sc reload. Edits there are lost, without a warning.

Each of those forty-nine files opens with a header saying it is yours and is never overwritten. That header is wrong.

The one exception is modules/warps/menus/warp_setup.yml — an admin editor that lives outside menus/admin/ and therefore survives.

Database

By default the plugin uses H2: a file inside the plugin folder, with no server and no maintenance. To share homes, warps, kits, ranks, balances and statistics across servers, point every server at the same database:

plugins/ExyliaSurvivalCore/database.yml

database:
  type: mysql
  mysql:
    host: 127.0.0.1
    port: 3306
    database: minecraft
    username: root
    password: ""

Supported engines: h2, mysql, mariadb, postgresql and mongodb. An engine the library does not recognise falls back to H2 with a console warning. The file is ExyliaLib's; its full reference, including the redis block, is in the library's database page.

The tables are listed on the Database page. A module that is off never creates its own.

Reloading

/survivalcore reload

Aliases /sc. It runs from the console, and it reloads three things in order: the configuration files, each module's own files, and the menus. A step that fails is reported by name and the steps after it still run.

Reloaded	Not reloaded
`config.yml`, including `debug` and `teleport`	The module switches — a module turned on or off needs a restart
Every `modules/<id>/` file of a module that is on	The database connection
`messages.yml`	Anything stored in the database, which is read when it changes
The menus — which also replaces `menus/admin/` from the jar

When a switch in config.yml no longer matches what is running, the reload ends with "Restart to apply module changes » …" and the ids of those modules.

Updating

Replace the jar and restart. menus/admin/ is refreshed from the jar. Everything in the database is untouched. Everything else keeps your edits:

config.yml, messages.yml and each module's config.yml keep your values.
The free-form and lifted-out files — ranks.yml, rewards.yml, rules.yml and the rest — are never rewritten.
The module menus, votes.yml, seasons.yml and trade/window.yml receive keys a new version adds; a default that changed waits in /exylialib updates instead of overwriting yours. A file whose shipped menu-version is higher than yours is replaced, and yours is kept next to it as <name>.v<old version>.

Something missing on this page? Tell us on Discord