Storage (YAML, SQLite, MySQL)
Bounties and combat stats are the only two modules with persisted data, and they share the same storage backend, configured once in the main config.yml:
storage:
type: yaml
table-prefix: atomcombat_
sqlite:
file: data/atomcombat.db
mysql:
host: localhost
port: 3306
database: atomcombat
username: root
password: ''
pool-size: 10type: yaml (default)
No setup required. Each module keeps its own flat file under plugins/AtomCombat/data/ (configurable per module, e.g. storage.file in modules/bounties.yml). Writes are atomic (written to a temp file, then moved into place) so a crash mid-write can't corrupt your data.
Best for a single small-to-medium server.
type: sqlite
Stores everything in one local database file (storage.sqlite.file, relative to the plugin data folder). Still local to this server, but avoids YAML's full-file-rewrite pattern and scales better with large bounty/stat histories.
type: mysql
Points AtomCombat at a shared MySQL database (storage.mysql.*). Use this if you run a network of survival servers and want a single leaderboard and a single bounty board shared across all of them. Connections are pooled with HikariCP; pool-size caps how many connections AtomCombat opens.
table-prefix lets AtomCombat share a database with other plugins without table name collisions — it creates <prefix>bounties and <prefix>stats.
Switching backends
Switching storage.type and reloading (or restarting) starts AtomCombat reading and writing through the new backend immediately. AtomCombat does not automatically migrate existing data between backends — export/import between YAML and SQL is a manual step if you need to carry old data over.
If AtomCombat cannot connect to the configured SQLite or MySQL database at startup, it logs a warning and falls back to YAML storage for that run rather than failing to start.