feat(admin): complete configurable progression
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
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
|
||||
status: done
|
||||
---
|
||||
|
||||
# US-010: Administer player progression
|
||||
@@ -11,19 +11,19 @@ As a **server administrator**, I want command-based progression controls so that
|
||||
|
||||
## 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.
|
||||
- [x] Administrative commands require `spigotbase.admin`, which server operators receive by default.
|
||||
- [x] Administrative player arguments safely resolve online players and previously known offline players.
|
||||
- [x] Player state remains keyed by UUID while retaining the latest known name for lookup and display.
|
||||
- [x] `/baseadmin progress <player>` displays the player's base, counters, earned path levels, active cooldowns, toggles, and visitor settings.
|
||||
- [x] `/baseadmin setlevel <player> <path> <level>` sets an earned path level while enforcing or explicitly granting required preceding levels.
|
||||
- [x] `/baseadmin setprogress <player> <path> <amount>` updates the selected counter and consistently evaluates reached tiers.
|
||||
- [x] `/baseadmin reset <player> <path>` resets a selected path without silently leaving benefits that require it.
|
||||
- [x] `/baseadmin reset <player> all` removes the player's base, progression, active cooldowns, and plugin preferences after confirmation.
|
||||
- [x] Administrators can clear personal and visitor cooldowns independently.
|
||||
- [x] Administrative commands can update configured block requirements, warm-ups, and cooldowns for each level using validated values.
|
||||
- [x] Runtime configuration changes are persisted for subsequent restarts.
|
||||
- [x] Lowered progression requirements are evaluated for a player on their next relevant action rather than immediately updating every stored player.
|
||||
- [x] Every successful mutation reports exactly what changed, and invalid requests make no partial changes.
|
||||
|
||||
## Related
|
||||
|
||||
|
||||
Reference in New Issue
Block a user