Getting started

Installation

Dependencies, the first boot and the restart it triggers, the files the plugin generates and where the database is set.

Before you start

ExyliaSandBox declares two hard dependencies. Without either of them the server refuses to load the plugin at all.

Plugin	What for
`Chunky`	Pre-generating each managed world out to its border before anybody is let in.
`packetevents`	Declared as a hard dependency in `plugin.yml`. The plugin does not call it itself; it is there because the rest of the suite is built on it.

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 the plugin does not run without it. It provides the configuration, menus, database, placeholders, holograms, sidebars, region registry, inventory snapshots, session claims, wizards and chat inputs.

Optional:

PlaceholderAPI to use the plugin's nine placeholders outside it.
ExyliaPracticeCore. Its presence changes who owns the player's inventory — see the callout below.
The Worlds plugin, on Folia only. Folia cannot create a world the ordinary way; ExyliaLib routes around it through Worlds. Without it, a managed world on Folia goes UNAVAILABLE.
LuckPerms, or any permission plugin, for the exyliasandbox.max_kits.<n> tier.

ViaVersion, Multiverse-Core, PhantomWorlds, ExyliaEvents and ExyliaFFA are named in plugin.yml but never read by this plugin.

ExyliaPracticeCore takes the inventory over

When ExyliaPracticeCore is installed, ExyliaSandBox never saves or restores the player's inventory on entry, exit, death or join — the practice lobby dresses them instead. Detection is by plugin name only. Install it, or do not; installing it halfway through is what leaves a player holding a sandbox kit in the lobby.

Installing

Drop in the jars

Copy ExyliaSandBox.jar, ExyliaLib.jar, Chunky.jar and packetevents.jar into plugins/.

Start the server, and expect it to stop

The first boot writes config.yml, messages.yml, scoreboards.yml, the menus and the seven tables, seeds five worlds and five kit-room categories, and then pre-generates every managed world through Chunky. When the last one finishes, the plugin shuts the server down. Start it again and the worlds are ready.

Set the lobby

/sandbox → SET LOBBY stores wherever you are standing. That is where every player is sent when they die, leave or disconnect. Nothing works properly until it is set.

Set the kit creator room

/sandbox → SET KIT CREATOR stores the room /kitcreator teleports into.

Grant the nodes

Nothing is declared in plugin.yml, so no node has a default. See First steps.

Finishing a pre-generation shuts the server down

This is not only the first boot. Whenever the pre-generation queue drains — including after creating one world from the admin panel on a live server — the plugin calls Bukkit.shutdown() and logs All worlds pregenereted. Restarting server.... Create worlds during a maintenance window, or with a process manager that brings the server back up.

Generated files

All of them live in plugins/ExyliaSandBox/.

File	Contents
`config.yml`	RTP and queue numbers, the queue action bars, the TPA timeout, the teleport-pad visuals, the command whitelist.
`messages.yml`	Every line the plugin sends, in twelve sections.
`scoreboards.yml`	The one sidebar, shown to anybody standing in a sandbox world.
`menus/user/`	The seven player screens. Written once, never overwritten.
`menus/admin/`	The twelve admin screens. Rewritten from the jar on every start.
`database.yml`	Database engine and Redis, written by ExyliaLib.

There is no config.yml inside the jar: the file is generated from the plugin's own schema on first run, comments included. That is why an unknown key is reported once and then removed.

menus/admin/ is rewritten on every start

Every admin screen is refreshed from the jar each time the plugin enables, so a button added in a release reaches servers that already have the folder. Each of those files carries the banner saying so. Edits under menus/user/ are kept.

Database

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

plugins/ExyliaSandBox/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. The file is ExyliaLib's; its full reference is in the library's database page.

The seven tables, all prefixed sandbox_: sandbox_worlds, sandbox_player_kits, sandbox_predefined_kits, sandbox_kitroom_categories, sandbox_kitroom_items, sandbox_player_stats, sandbox_settings and sandbox_tp_regions. Their columns are on the Database page.

Updating

Replace the jar and restart. Your edits to config.yml, messages.yml, scoreboards.yml and menus/user/ are kept; menus/admin/ is refreshed from the jar. Worlds, kits and statistics live in the database and are never touched by an update.

/sandbox reload re-reads the three config files and recompiles the menus without a restart. It runs from the console.

Something missing on this page? Tell us on Discord