Administration

/chorus reload#

/chorus reload          every file
/chorus reload kits     one module

Module names: homes, warps, spawn, teleport-requests, utility, economy, shops, chat, items, kits, world, staff, players, custom-commands.

Reloading one module does not touch the rest of the server — no commands are unregistered and nobody's session is disturbed.

Three things need a full restart: the storage section, aliases.yml, and adding or removing a custom command.

/chorus status#

What the plugin found when it started:

» CHORUSCORE « 0.1.0
▪ Storage » sqlite
▪ Economy » built in, 412 accounts
▪ PlaceholderAPI » hooked in
▪ Modules » homes, warps, spawn, teleport-requests, ...
▪ Updates » up to date

Most of what gets reported as a bug in a core plugin is one of these lines saying something the owner did not expect. Read it after every config change.

/chorus debug#

Everything worth pasting into a bug report, in one block: the plugin version, the server and game version, the Java version, the scheduling model, memory, the storage and economy in use, which modules are on and off, and what else is installed.

/commands#

Lists only what the player actually holds the permission for and that is switched on, grouped by module. It is never a catalogue of things that will refuse them.

/commands              everything you may use
/commands homes        one module
/commands home         anything whose name matches
/commands homes 2      page two

Also reachable as /help.

Running it from a member account is the fastest way to check whether your permissions came out the way you meant.

Forgetting old players#

/chorus purge 180          count what would go, delete nothing
/chorus purge 180 run      do it

A core plugin keeps a row for every player who ever joined, and after a few years most of them belong to somebody who logged in once. Nothing else removes them.

It deletes the homes, money, mail, ignores, kit cooldowns, inventory backups, powertools, notes and payment history of everybody not seen in that many days.

Six things make it safe:

• It can be asked what it would do. Without run it counts and deletes nothing, which is the version worth doing first.
• Anybody who owns a chest shop is left alone in full, and counted separately. Deleting their row would leave a chest and a sign standing in the world with nothing behind them.
• Anybody online is left alone, whatever their date says.
• The whole run is one transaction. A failure halfway leaves the database exactly as it was rather than with half a player deleted.
• Thirty days is the floor. A smaller number is refused rather than run.
• The staff log is not touched. It is a record of what staff did, not data belonging to the player it was done to.

The real run asks to be confirmed.

Confirmations#

confirmations:
  seconds: 15

The things that cannot be taken back ask to be run a second time first:

• /clearinventory
• /delhome
• /delwarp
• /sethome over a home you already have
• /sweep of a whole world
• a payment over economy.confirm-above
• /chorus purge ... run
• both importers, with run

seconds: 0 asks for nothing. chorus.bypass.confirm skips them.

Updates#

updates:
  check: true
  source: modrinth
  project: choruscore
  url: ''
  notify-staff: true

Asks once at startup and once a day whether a newer ChorusCore is out. Nothing is downloaded and nothing is installed — it says a newer one exists and that is all.

Nothing about this server is sent. Not the address, not the player count, not even the version being run.

Everything about it fails quietly. A site that is down, a project that has been renamed or a server with no way out to the internet all end the same way: no answer, no message and no line in the console.

notify-staff tells anybody holding chorus.updates as they join. The console is told either way. /chorus status says what the last check found.

An empty project switches the check off without setting check: false, which is the right setting for a private build.

Metrics#

metrics: true

Sends the server version, the storage type, the economy mode and how many modules are on to bStats. No player data of any kind. false sends nothing.

The staff log#

staff-log:
  enabled: true
  keep-days: 60
  page-size: 10

Freezes and unfreezes, /sudo, /lockdown, /tempfly, notes and every /eco. Read it with /stafflog — see Staff tools.

Housekeeping that runs on its own#

At startup, entries past their keep-days are dropped:

0 means keep for ever, which on a busy server means a table that only ever grows.

Inventory backups also have backups.keep-per-player, which is the one that actually holds a death-heavy server's table down.