TDXDevelopment Documentation

What survives an update, what gets backed up, and the one thing that doesn't auto-merge.

Every TDX plugin uses a config-versioning system: when an update ships new settings, the missing keys are added to your existing files. Your customisations are preserved, you don't need to diff files by hand.

What happens when you update

Stop the server

Always stop the server cleanly before swapping a plugin jar. A graceful shutdown flushes any pending writes to disk; killing the process mid-write can corrupt the SQLite database (rare, but real).

Replace the jar

Delete the old jar from plugins/ and drop the new one in.

Start the server

On first boot with the new jar, the plugin runs the config updater for each of its files:

It compares the config-version in your file with the one bundled in the new jar. If yours is not older, nothing happens.
If it is older, the live file is first copied to <file>.backup-YYYYMMDD-HHMMSS so you have a known-good rollback.
Every key that exists in the bundled file but is missing from yours is added with its default value.
Your existing values are never overwritten. Only new keys are added.

Which files this covers:

TDX Leaderboards: config.yml and messages.yml.
TDX VotePlus: config.yml and the nine feature files (vote-rewards.yml, milestones.yml and so on). Its messages.yml and the guis/ files are never rewritten. A message key you do not have simply uses the bundled default text.
TDX Welcome Raffle: config.yml and messages.yml. Its rewards.yml is never rewritten, so prizes you delete stay deleted.

You'll see something like this in the log:

latest.log

[INFO] [TDXVotePlus] Backed up vote-rewards.yml -> vote-rewards.yml.backup-20260411-143205
[INFO] [TDXVotePlus] Updated vote-rewards.yml (v1 -> v2, 1 new keys added).

Your own comments are kept. A new key arrives without the explanatory comment that sits above it in the bundled file, so check the changelog for what it does. The reference pages here cover every key.

The auto-merger never deletes keys that are no longer used, it only adds. If a future plugin version drops a config block, your old block stays in the file and is silently ignored. This is by design: it makes rolling back to an older jar painless.

What doesn't auto-update

Two things are not touched by the config updater:

Storage backend. Switching from SQLite to MySQL (or vice-versa) is never automatic, and there is no import command: the new backend starts empty. See each plugin's storage page for what that means.
Database changes. When an update needs a new table or column, the plugin adds it on startup. Nothing is removed again if you go back to an older jar, so back up the database before a big update and test it on a staging copy first.

Always read the changelog of a major version bump (e.g. 1.x → 2.x) before updating production. Patch bumps (1.2.8 → 1.2.9) are always safe.

If something goes wrong

Restore the timestamped backup that was written next to your config:

cd plugins/TDXVotePlus
mv config.yml config.yml.broken
mv config.yml.backup-20260411-1432 config.yml

Then restart the server. If the issue is database-shaped instead of config-shaped, ask in the TDX Discord before doing anything destructive, most "the plugin lost my data" reports turn out to be a config pointing at the wrong database.

Updating safely