System Management

XenoLevels can run multiple leveling systems side by side. Use this guide to create new systems, reshape existing ones, or safely remove them without breaking player progression.

Create a new system (from zero)

1. Duplicate the template – Copy plugins/XenoLevels/systems/main into a new folder (for example, systems/mining).
2. Register the system – Add the new key under systems/systems.yml and set enabled: true. Optionally set default-system if it should replace the primary track.
3. Define its identity – Update system.yml with a unique name, scoreboard colors, combo timing, and any prestige or requirement toggles.
4. Shape the level curve – Configure baseline and milestone requirements in levels.yml. Keep ranges reasonable so the first sessions feel rewarding.
5. Attach EXP events – Map gameplay triggers in exp-events.yml. Reuse filters and categories from the Event Catalog to keep the file readable.
6. Wire optional modules – Add payouts in rewards.yml, time-limited boosts in boosters.yml, UI tweaks in gui.yml, and protections in anti-abuse.yml.
7. Localise messages – Extend lang.yml with system-specific titles, buttons, and confirmation text so players see consistent branding.
8. Reload and test – Run /xlv reload followed by /xlv info <player> <system> to confirm the system loads, then trigger a few events to verify EXP, rewards, and permissions.

Modify a live system

• Safe edits – Adjust configuration files directly, then /xlv reload during low-traffic windows. For deeper formula changes, announce downtime and back up player data.
• Reward and booster updates – Whenever you change rewards.yml or boosters.yml, test with a non-admin alt to ensure permissions and GUI links behave correctly.
• Event tuning – Use conditions and anti-abuse modules to soften spikes instead of deleting events outright. This keeps progress smooth across playstyles.
• Audit visibility – Verify PlaceholderAPI outputs on scoreboards after edits so players always see accurate levels and progress bars.

Remove or archive a system

1. Communicate the change – Let players know you are sunsetting a system and whether progress will migrate elsewhere.
2. Disable safely – Set the system entry to enabled: false in systems/systems.yml and reload. This stops further EXP without deleting data.
3. Retire files – Once disabled, delete or archive the system folder under plugins/XenoLevels/systems/<id>/. Keep backups if you plan to reintroduce it later.
4. Clean references – Remove related GUI buttons, placeholder usages, or reward commands that targeted the retired system to avoid missing target errors.
5. Validate player data – Spot-check a few player records with /xlv info to confirm the remaining systems still report correct levels and prestiges.

Advanced workflows

• Seasonal rotations – Keep multiple systems configured and toggle them with enabled flags to run seasonal ladders without rewriting configs.
• Entry requirements – Combine conditions.yml and booster requirements to gate systems behind permissions, balances, or regions.
• Prestige ladders – Use prestiges.yml to offer long-term resets. Pair them with unique rewards and booster unlocks so prestige choices feel meaningful.
• Data migrations – Before structural changes, back up the plugins/XenoLevels folder. If you reorganize events or requirements, keep identifiers stable so existing progress maps cleanly onto the new structure.