dmg/spigot-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 27 Wiki Activity

feat(base): implement progression system

Browse Source
This commit is contained in:
dmg
2026-08-09 15:01:44 -04:00
commit c87d923cad
76 changed files with 5092 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
design/user-stories/us-010-administer-player-progression.md
+31
View File
@@ -0,0 +1,31 @@
---
type: User Story
title: "US-010: Administer player progression"
description: Let administrators inspect and safely modify player progression and live progression settings through commands.
status: in-progress
---
# US-010: Administer player progression
As a **server administrator**, I want command-based progression controls so that I can inspect players, correct state, and tune requirements without an inventory UI.
## Acceptance criteria
- [ ] Administrative commands require `spigotbase.admin`, which server operators receive by default.
- [ ] Administrative player arguments safely resolve online players and previously known offline players.
- [ ] Player state remains keyed by UUID while retaining the latest known name for lookup and display.
- [ ] `/baseadmin progress <player>` displays the player's base, counters, earned path levels, active cooldowns, toggles, and visitor settings.
- [ ] `/baseadmin setlevel <player> <path> <level>` sets an earned path level while enforcing or explicitly granting required preceding levels.
- [ ] `/baseadmin setprogress <player> <path> <amount>` updates the selected counter and consistently evaluates reached tiers.
- [ ] `/baseadmin reset <player> <path>` resets a selected path without silently leaving benefits that require it.
- [ ] `/baseadmin reset <player> all` removes the player's base, progression, active cooldowns, and plugin preferences after confirmation.
- [ ] Administrators can clear personal and visitor cooldowns independently.
- [ ] Administrative commands can update configured block requirements, warm-ups, and cooldowns for each level using validated values.
- [ ] Runtime configuration changes are persisted for subsequent restarts.
- [ ] Lowered progression requirements are evaluated for a player on their next relevant action rather than immediately updating every stored player.
- [ ] Every successful mutation reports exactly what changed, and invalid requests make no partial changes.
## Related
- [US-009: View progression and unlock notifications](us-009-view-progression-and-notifications.md)
- [US-011: Configure and persist progression](us-011-configure-and-persist-progression.md)