Updates docs.
This commit is contained in:
128
docs/Modernize.md
Normal file
128
docs/Modernize.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Score Keeper Modernization Plan
|
||||
|
||||
Current baseline: October 2026. This replaces
|
||||
[the historical Cursor plan](../.cursor/plans/Modernize.md) as the maintained
|
||||
roadmap. It is a plan, not authorization to change runtime behavior or publish.
|
||||
Read [CONTRIBUTING.md](../CONTRIBUTING.md) and [AGENTS.md](../AGENTS.md) first.
|
||||
|
||||
## Baseline: already implemented
|
||||
|
||||
The old Maven/Java 17/older Minecraft migration is no longer pending.
|
||||
|
||||
| Area | Current implementation |
|
||||
| --- | --- |
|
||||
| Build | Gradle 9.8.0 wrapper, Java 25 toolchain, Foojay resolver, configuration cache, Spotless |
|
||||
| Paper target | API `26.2.build.129-stable`, manifest API `26.2`, documented Paper 26.2/26.3 support |
|
||||
| Identity and messaging | UUID-based scores, Paper/Adventure messages, plugin logger, online `getPlayerExact` lookup |
|
||||
| Domain | Named buckets, initial values, four reporting policies, default/individual assignments |
|
||||
| Persistence | Version-3 scores YAML, archives YAML, legacy flat UUID score loading, shutdown save/enable load |
|
||||
| Competitions | Target/timed/manual runs, scheduled checks, top-N rankings, score snapshots/restoration |
|
||||
| Tooling | Bash build/deploy/server/backup/restore/local and Modrinth publishing; legacy PowerShell subset |
|
||||
| Documentation | Contributor entry point, shared agent rules, current domain/integration references, manual release checklist, schema-shaped project metadata |
|
||||
|
||||
Implemented is not the same as verified on every advertised server version.
|
||||
There are no automated Java tests yet; the CI `test` task is currently `NO-SOURCE`.
|
||||
There is no real-server integration task and no automatic publishing workflow.
|
||||
|
||||
## Phase 1: reliable regression coverage (SK-08 through SK-11)
|
||||
|
||||
These are prerequisites for changing persistence, permissions, arithmetic, or
|
||||
run behavior. Keep the default test task server-free.
|
||||
|
||||
- [ ] Add JUnit 5 infrastructure and an in-memory Paper harness compatible with
|
||||
the current Java/Paper API (for example, MockBukkit if compatible). Use Mockito
|
||||
only for narrow boundaries where a harness is unnecessary; verify compatibility
|
||||
before choosing/pinning dependencies.
|
||||
- [ ] Cover bucket ID/label/reporting validation, duplicates, initial values,
|
||||
UUID isolation, lazy reads, active/default selection, all-player assignment
|
||||
clearing, and signed add/subtract/reset semantics.
|
||||
- [ ] Cover YAML round trips in temporary data directories: buckets, scores,
|
||||
assignments, runs/snapshots, archives, and legacy flat scores. Include invalid
|
||||
UUIDs, unknown buckets, malformed values, and empty archive buckets.
|
||||
- [ ] Cover all eight command executors: sender/self/online-target resolution,
|
||||
literal reset booleans, duration units/overflow, usage/errors, and existing
|
||||
permission boundaries.
|
||||
- [ ] Verify Adventure reporting audiences, changed-vs-unchanged scores, unit
|
||||
labels, self/other bucket notices, and no duplicate run change notifications.
|
||||
- [ ] Introduce a small controllable clock/scheduler seam where necessary for
|
||||
deterministic run tests; avoid a wholesale architecture rewrite.
|
||||
- [ ] Verify descending/name/UUID run ties, archive UUID ties, offline/unranked
|
||||
entries, top-N boundaries, immediate targets, duration expiration, manual stop,
|
||||
resumed runs, and exact pre-run score restoration (including new run entrants).
|
||||
- [ ] Make CI produce real test reports and fail on these regressions once tests
|
||||
exist; do not mistake missing reports for tested coverage.
|
||||
|
||||
## Phase 2: explicit real-server validation (SK-12)
|
||||
|
||||
- [ ] Add an opt-in `integrationTest` source set/task only for behavior requiring
|
||||
actual Paper. Keep it out of normal `test`/`build`, use disposable directories,
|
||||
and own/stop only the processes it starts.
|
||||
- [ ] Load the built jar on both Paper 26.2 and 26.3 with Java 25; verify real
|
||||
command registration/dispatch, Adventure output, scheduler completion, API
|
||||
integration/load order, and persistence across clean restarts.
|
||||
- [ ] Run [human-tests.md](human-tests.md) on both versions before release.
|
||||
Record artifact version, Paper build, Java version, observations, and logs.
|
||||
- [ ] Review startup/runtime deprecation warnings and unsupported API calls
|
||||
found by builds/runtime tests; update compatibility claims only with evidence.
|
||||
|
||||
Do not broaden support to Spigot, Bukkit, Folia, or future Paper versions by
|
||||
documentation changes alone.
|
||||
|
||||
## Phase 3: persistence and correctness hardening
|
||||
|
||||
Choose behavior changes explicitly and add regression tests first.
|
||||
|
||||
- [ ] Design safe periodic/dirty-state saves or explicit saves so crashes do not
|
||||
lose all changes since shutdown. Decide save cadence and I/O threading while
|
||||
snapshotting mutable state on the main thread.
|
||||
- [ ] Design atomic replacement/recovery and consistency between score resets
|
||||
and archives across the two YAML files. Preserve or migrate legacy data, and
|
||||
ensure save failures are visible to administrators/callers.
|
||||
- [ ] Define validation rules for malformed YAML rather than relying on defaulting
|
||||
getters. Cover invalid integer types, assignments, missing archive fields,
|
||||
empty snapshots, and recovery without overwriting good data.
|
||||
- [ ] Decide whether integer overflow should fail, clamp, or use a wider score
|
||||
type. Preserve negative-score use cases and provide an explicit data/API
|
||||
migration if the type changes.
|
||||
- [ ] Review the misleading `until-disabled` mode name: document current
|
||||
resume-across-disable behavior until any new end-on-disable mode is deliberately
|
||||
designed. Do not silently rename the command or change saved lifetime values.
|
||||
|
||||
## Phase 4: command and integration ergonomics
|
||||
|
||||
- [ ] Design permission nodes/defaults for score get/add/subtract/reset and archive
|
||||
listing; define self-vs-other access and a migration strategy before restricting
|
||||
currently open commands.
|
||||
- [ ] Implement SK-13: explicit bucket selection for `/score-get`, with unambiguous
|
||||
syntax, validation, help, docs, and tests. Preserve existing optional-player usage.
|
||||
- [ ] Align manifest/executor help with supported archive scopes, reporting
|
||||
arguments, and literal reset booleans; consider tab completion as a separate
|
||||
tested improvement.
|
||||
- [ ] Evaluate a smaller API/domain boundary only where needed for tested
|
||||
behavior or companion integration. Retain public overload compatibility and
|
||||
avoid unnecessary service abstractions.
|
||||
|
||||
## Phase 5: safer developer and release tooling
|
||||
|
||||
- [ ] Scope Bash start/stop/backup/restore process checks to the configured server
|
||||
or a verified owned PID; never stop another project's Paper process.
|
||||
- [ ] Verify the bootstrap helpers select an actual Java 25 JDK, not merely the
|
||||
first cached Java executable, and document supported hosts.
|
||||
- [ ] Bring PowerShell setup/configuration/process management to deliberate
|
||||
parity with Bash or clearly retain a reduced supported surface. Prefer graceful
|
||||
shutdown over forced termination.
|
||||
- [ ] Make deployment select/verify the intended artifact and version instead of
|
||||
relying only on newest modification time and a stale-source warning.
|
||||
- [ ] Add lightweight local-link and JSON Schema checks for docs/metadata to CI,
|
||||
keeping the scraper's slug-keyed contract and existing filenames.
|
||||
- [ ] Rehearse a tagged release: rebuild after tagging, verify manifest/version,
|
||||
run manual checks, review changelog and compatibility, upload deliberately, and
|
||||
update hosted Modrinth description separately.
|
||||
|
||||
## Completion criteria
|
||||
|
||||
A modernization item is done only when its behavior and failure modes have
|
||||
appropriate tests or recorded manual evidence, directly related docs are current,
|
||||
and existing data/API contracts are preserved or explicitly migrated. Use
|
||||
[TODO.md](../TODO.md) for SK feature/task status; this plan organizes the broader
|
||||
work and must not mark unchecked tests or future infrastructure as implemented.
|
||||
@@ -1,365 +1,182 @@
|
||||
# ScoreKeeper — Score-Tracking & "High-Score Table" Domain Analysis
|
||||
# Score Keeper - Score-Tracking Domain
|
||||
|
||||
> **Scope of this document:** the domain logic that tracks player scores and (intended) the
|
||||
> high-score table. Written for a new team member who must understand the scoring system
|
||||
> *without opening the source*. Every claim below is traced to a file/line so it can be
|
||||
> re-verified.
|
||||
>
|
||||
> **Bottom line up front (read this first):** ScoreKeeper currently tracks **live scores
|
||||
> only, in memory, for the running server session**. It has **no persistence** and **no
|
||||
> high-score table**. The high-score table is *described as a planned feature* in the
|
||||
> README and is where the `/score-archive` command is *intended* to land scores, but
|
||||
> **that code path is an unimplemented stub today.** There is no sorting, no tie-breaking,
|
||||
> no entry cap, no decay, and no scoring formula/weighting anywhere in the codebase.
|
||||
> This is a greenfield/early-stage domain — the write-up documents the *real* state and
|
||||
> flags the gap, because documenting features that don't exist as if they did would mislead
|
||||
> the next engineer.
|
||||
This documents implemented behavior in
|
||||
[ScoreKeeperPlugin.java](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/ScoreKeeperPlugin.java),
|
||||
[ScoreBucket.java](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/ScoreBucket.java),
|
||||
and [ScoreReporting.java](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/ScoreReporting.java).
|
||||
For command syntax see [README.md](../README.md); for runtime wiring see
|
||||
[the integration reference](plugin-integration-and-event-wiring.md).
|
||||
|
||||
---
|
||||
## Buckets and live scores
|
||||
|
||||
## 0. How to read the rest of this doc against the task's four questions
|
||||
- A bucket has an immutable ID, singular label, plural label, initial integer
|
||||
value, and reporting policy. IDs match `[A-Za-z0-9_-]+`, are case-sensitive,
|
||||
and must be unique. Labels must be nonblank; reporting cannot be null.
|
||||
- A fresh server has `points` (`point`/`points`, initial value `0`, reporting `none`).
|
||||
Loading bucket data restores this bucket if it is missing.
|
||||
- `_bucketScores` maps bucket ID to `UUID -> int`. Players can have independent
|
||||
scores in multiple buckets. Names are not used as identity keys.
|
||||
- The server default bucket and optional UUID-specific assignments determine a
|
||||
player's active bucket. Selecting the default removes their override.
|
||||
`switchAllPlayers` changes the default and clears **all** assignments,
|
||||
including offline players' assignments, without deleting scores.
|
||||
- `getScore` lazily registers a missing score at the bucket's initial value.
|
||||
Joining alone does not create an entry. Reads therefore affect who appears
|
||||
in a later archive or run ranking.
|
||||
- Add/subtract perform ordinary Java integer arithmetic. Zero/negative amounts
|
||||
are allowed, scores can be negative, and overflow wraps. There are no bonuses,
|
||||
weighting, decay, or automatic gameplay scoring.
|
||||
- Reset writes the bucket initial value, not necessarily zero. Existing
|
||||
no-bucket API methods use the active bucket; explicit-bucket overloads do not
|
||||
change the player's assignment.
|
||||
|
||||
The task asks for (1) the score-entry data model + persistence format, (2) how scores are
|
||||
recorded, (3) the high-score-table algorithm, and (4) scoring formulas/weighting.
|
||||
For each question the answer is: **the mechanism that exists vs. the mechanism the project
|
||||
intends**, so readers never conflate the two.
|
||||
## Reporting and bucket changes
|
||||
|
||||
| # | Question | Short answer |
|
||||
|---|----------|--------------|
|
||||
| 1 | Score-entry data model & persistence | Live score = `UUID -> int` in a `HashMap`. **No persistence** (load/save are `TODO` stubs). |
|
||||
| 2 | How scores are recorded | **Manual, event-free:** the *administrator* runs a command. No game events, no timers. |
|
||||
| 3 | High-score-table algorithm | **Not implemented.** No sort/tie-break/cap/decay. Only an aspirational `/score-archive`. |
|
||||
| 4 | Scoring formulas / weighting | **None.** Scores are plain integer accumulators; no weighting, no decay, no bonuses. |
|
||||
For a changed value written through `setScore`, outside a run:
|
||||
|
||||
---
|
||||
| Policy | Audience |
|
||||
| --- | --- |
|
||||
| `none` (default) | Nobody |
|
||||
| `player` | Scored player |
|
||||
| `global` | All online players |
|
||||
| `admin` | Online operators or holders of `scorekeeper.admin`, plus the server log |
|
||||
|
||||
## 1. The score-entry data model & persistence *(task Q1)*
|
||||
Writing the same value sends no score-change report. Commands that change scores
|
||||
do not independently promise success messages; inspect `/score-get` when reporting
|
||||
is `none`. A bucket change tells an affected online player the ID and current score.
|
||||
Unit formatting uses the singular label for exactly `1`, plural otherwise.
|
||||
`/score-get` itself displays only the number, without bucket or unit labels.
|
||||
|
||||
### 1.1 What a "score entry" actually is (current reality)
|
||||
Run reporting overrides the bucket policy. Archive resets and run start/restore
|
||||
directly update maps and do not send ordinary per-score change reports.
|
||||
|
||||
The entire live-score domain is **one field** in the plugin's entry-point class:
|
||||
## High-score runs
|
||||
|
||||
- **File:** `src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/ScoreKeeperPlugin.java:38`
|
||||
- **Declaration:** `private final HashMap<UUID, Integer> _playerScores = new HashMap<UUID, Integer>();`
|
||||
Each bucket can have at most one active run; different buckets may run concurrently.
|
||||
Top N must be at least one. There are three lifetime modes:
|
||||
|
||||
That is the whole model:
|
||||
- **Target score:** finishes when any recorded score reaches/exceeds the target.
|
||||
With reset enabled, the target must exceed the initial value. Without reset,
|
||||
existing scores can finish a run immediately when it starts.
|
||||
- **Duration:** a positive duration, stored as an absolute epoch-millisecond
|
||||
expiration. Time offline counts toward expiration.
|
||||
- **Until disabled:** no automatic end; stop explicitly. Plugin disable saves the
|
||||
run rather than finishing it, so it resumes on restart.
|
||||
|
||||
| Aspect | Value |
|
||||
|--------|-------|
|
||||
| Record shape | A single `Integer` (the score), keyed by a player's `UUID`. |
|
||||
| Key type | `java.util.UUID` — the player's `UniqueId`, *not* the name string. |
|
||||
| Value type | `int` (Java `Integer`), autoboxed into the map. |
|
||||
| Container | one `java.util.HashMap` on the plugin instance. |
|
||||
| Uniqueness | one entry per `UUID`. A player can have exactly one live score at a time. |
|
||||
| Default for a new player | `0` — see §3.1 ("first-time player" edge case). |
|
||||
Starting with reset enabled snapshots existing bucket entries and sets them to
|
||||
the initial value. During the run, a changed score is always reported to its
|
||||
player. If that player is in the top N **after the change**, the report is sent
|
||||
to all other online players too, once per recipient.
|
||||
|
||||
There is **no `Score`/`ScoreEntry`/`PlayerStats` value class**, no timestamp, no
|
||||
name stored alongside the score (name is looked up from the live server only — see §2.3),
|
||||
and no secondary index.
|
||||
Completion is checked immediately at start/load, synchronously every 20 ticks,
|
||||
and on a changed target-run score. Manual stop also completes the run.
|
||||
The scheduled check uses wall-clock time; under server lag it need not fire at
|
||||
an exact real-time second.
|
||||
|
||||
### 1.2 Persistence format: **none exists**
|
||||
### Ranking and results
|
||||
|
||||
Persistence is *intended* but *not built*. Three concrete stubs prove this:
|
||||
Rankings include all recorded entries in that bucket, including offline players
|
||||
and entries read/created before the run. The order is:
|
||||
|
||||
1. **On disable (server stop):** `ScoreKeeperPlugin.java:46-49` `onDisable()` logs
|
||||
*"Unable to save scores to file. This feature is not implemented yet."* — the map
|
||||
is **discarded** on shutdown; nothing is written.
|
||||
2. **On enable (server start):** `ScoreKeeperPlugin.java:59-60` `onEnable()` logs
|
||||
*"Unable to load scores from file. This feature is not implemented yet."* — the map
|
||||
always starts **empty** `{}` every server start.
|
||||
3. **Archive:** `ScoreKeeperPlugin.java:72-74` `archiveScore(Player)` logs
|
||||
*"Unable to archive score for <name>."* and returns — the "save to high-score table"
|
||||
action is a no-op.
|
||||
1. Descending score.
|
||||
2. Case-insensitive player name, using Paper's offline-player lookup.
|
||||
3. UUID string to break remaining ties.
|
||||
|
||||
So there is **no SQLite, no JSON, no YAML, no flat file, no config.yml**. The only file on
|
||||
disk that concerns scores is `plugin.yml` (the command manifest — it lists the commands but
|
||||
stores no scores). A grep of the whole tree for `sql / json / yaml / saveResource /
|
||||
YamlConfiguration / File / Files. / Gson / Jackson` finds **zero hits** other than the
|
||||
TODO/log strings.
|
||||
Unknown/blank names fall back to the UUID string. Ties have distinct consecutive
|
||||
places, not shared ranks. Top N limits display/reporting, not stored entries.
|
||||
Every online player receives the final top-N table and their own full-ranking
|
||||
place/score, or an unranked result at the initial value. The final table is logged.
|
||||
|
||||
**Persistence format today = "in RAM only, lost on server restart."**
|
||||
With reset enabled, completion replaces the bucket map with its pre-run snapshot.
|
||||
Players first recorded during the run are removed from that map and get the initial
|
||||
value on their next read. Personal results refer to the finished run, not restored
|
||||
scores. Without reset, earned scores remain. Run completion does **not** create a
|
||||
score archive.
|
||||
|
||||
> Implication for a new engineer: any "who's the top player" question answered *across
|
||||
> restarts* is impossible today. Scores reset to the map being empty on every server boot.
|
||||
## Archives
|
||||
|
||||
---
|
||||
Player, single-bucket, and all-bucket archives create immutable snapshots with a
|
||||
random UUID ID, scope text, epoch-millisecond creation time, and nested
|
||||
`bucket ID -> UUID -> int` scores. A player archive uses their active bucket;
|
||||
bucket/all archives include all recorded entries, even offline players.
|
||||
|
||||
## 2. How scores are recorded *(task Q2)*
|
||||
Live archived entries reset to their respective initial values. Archiving fails
|
||||
before changing any scores if a selected bucket has an active run; stop the run
|
||||
first. Archives do not cap or prune entries.
|
||||
|
||||
### 2.1 The recording model is **manual and command-driven — no events, no timers**
|
||||
[ScoreArchiveListCommand.java](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/commands/ScoreArchiveListCommand.java)
|
||||
lists archives newest first. Within an archive, scores display descending with
|
||||
UUID-string tie-breaking (not the run's name tie-break). Names and unit labels are
|
||||
resolved at display time, not captured in the snapshot; missing bucket definitions
|
||||
use the generic unit `scores`.
|
||||
|
||||
Scores move only when an administrator (or console/RCON) **types a command**. There is:
|
||||
## Persistence
|
||||
|
||||
- **No** `implements Listener`, no `@EventHandler`, no `registerEvents(...)`, no
|
||||
`getServer().getPluginManager().registerEvents(...)`.
|
||||
- **No** scheduler: no `getScheduler()`, no `runTask`, no `Timer`.
|
||||
- **No** automatic hook to game events (e.g. a player killing a mob or reaching a goal
|
||||
awards points automatically — *nothing like that exists*).
|
||||
Both files live in `plugins/ScoreKeeper/`. Loading occurs on enable and saving
|
||||
on disable. There is no periodic autosave or immediate archive write despite
|
||||
the command's "Saved score archive" acknowledgement; a crash can lose recent
|
||||
state. Back up only after a successful clean shutdown.
|
||||
|
||||
A grep for `EventListener|@EventHandler|Listener|Scheduler|runTask` across `src/` returns
|
||||
**zero**.
|
||||
### `scores.yml` (currently writes version 3)
|
||||
|
||||
So "scoring" happens **on demand**, by a person, via one of the four mutating commands:
|
||||
|
||||
| Command | Effect on the map | Source |
|
||||
|---------|-------------------|--------|
|
||||
| `/score-add [player] <amount>` | `score += amount` | `ScoreKeeperPlugin.addScore` `:67-70` |
|
||||
| `/score-subtract [player] <amount>` | `score -= amount` | `ScoreKeeperPlugin.subtractScore` `:88-91` |
|
||||
| `/score-reset [player]` | `score = 0` | `ScoreKeeperPlugin.resetScore` `:80-82` |
|
||||
| `/score-archive [player]` | **intended** to snapshot to a high-score table and reset to 0; **actually a no-op** | `ScoreKeeperPlugin.archiveScore` `:72-74` |
|
||||
|
||||
`/score-get [player]` is read-only (returns the score, §2.4).
|
||||
|
||||
### 2.2 The add/subtract primitives (the only real "write" path)
|
||||
|
||||
Both funnel through one private setter:
|
||||
|
||||
```
|
||||
addScore(player, n) -> old = getPlayerScore(player); setPlayerScore(player, old + n) :67-70
|
||||
subtractScore(player,n)-> old = getPlayerScore(player); setPlayerScore(player, old - n) :88-91
|
||||
setScore(player, s) -> setPlayerScore(player, s) :84-86
|
||||
resetScore(player) -> setPlayerScore(player, 0) :80-82
|
||||
setPlayerScore(p, v) -> _playerScores.put(p.getUniqueId(), v) :108-110
|
||||
```yaml
|
||||
version: 3
|
||||
default-bucket: points
|
||||
buckets:
|
||||
points:
|
||||
singular: point
|
||||
plural: points
|
||||
initial-value: 0
|
||||
reporting: none
|
||||
scores:
|
||||
"00000000-0000-0000-0000-000000000001": 10
|
||||
player-buckets:
|
||||
"00000000-0000-0000-0000-000000000002": points
|
||||
high-score-runs:
|
||||
points:
|
||||
top-n: 3
|
||||
reset-scores: true
|
||||
lifetime: duration
|
||||
target-score: 0
|
||||
expires-at: 1800000000000
|
||||
previous-scores:
|
||||
"00000000-0000-0000-0000-000000000001": 25
|
||||
```
|
||||
|
||||
Notes a new engineer must internalize:
|
||||
This illustrates field shapes, not a file to install unchanged. Overrides equal
|
||||
to the default bucket are normally omitted. Saved lifetime strings are
|
||||
`target_score`, `duration`, and `until_disabled`. The loader reads structure,
|
||||
not a version-dispatch migration table.
|
||||
|
||||
- **Read-modify-write.** `addScore`/`subtractScore` read the current value, compute, write
|
||||
back in two map operations. (There is no concurrency control — see §5 risks.)
|
||||
- **`int` math.** Values are Java `int`; a score can go **negative** (there is no floor at
|
||||
0 — `/score-subtract 50` on a 10-score yields `-40`), and can overflow `int` only after
|
||||
`~2.1e9` points, which is not a practical concern.
|
||||
- **No validation of the direction.** The only validation is *syntactic*: the amount must
|
||||
parse as an integer (see §2.3).
|
||||
If `buckets` is absent, the loader treats top-level UUID/integer entries as legacy
|
||||
`points` scores. Invalid bucket definitions/UUIDs/runs are skipped with warnings;
|
||||
invalid reporting falls back to `none`, and an unknown default falls back to
|
||||
`points`. Unknown bucket assignments are ignored. Bukkit YAML getters supply
|
||||
defaults for some missing/wrongly typed values: do not assume every malformed
|
||||
value is rejected or logged.
|
||||
|
||||
### 2.3 Command surface (who/what is allowed to record a score)
|
||||
### `archives.yml`
|
||||
|
||||
Every command executor lives in `src/main/java/.../scorekeeper/commands/` and shares one
|
||||
shape: parse args, resolve the target player, call the `ScoreKeeperPlugin` method, return
|
||||
`true` (consumed). Two behavioral details matter:
|
||||
|
||||
- **Self-target default:** if a *player* runs a command and omits the name, they target
|
||||
*themselves*: `targetPlayer = (Player) sender`. (e.g. `ScoreGetCommand.java:44`,
|
||||
`ScoreAddCommand.java:48`, `ScoreResetCommand.java:47-49`.)
|
||||
- **RCON/console path:** if the sender is **not** a player (console/RCON), a player name
|
||||
is **required** — omitting it prints usage instead of acting
|
||||
(`ScoreGetCommand.java:46-48`, `ScoreAddCommand.java:45-47`,
|
||||
`ScoreResetCommand.java:44-46`).
|
||||
- **Name resolution:** `getServer().getPlayerExact(name)` — **exact, case-sensitive**
|
||||
lookup by the *currently online* name (`ScoreGetCommand.java:50`,
|
||||
`ScoreAddCommand.java:57`, `ScoreResetCommand.java:50`). A name that is not online
|
||||
yields `null` → "Can't find a player with that name". Note the *map key is a UUID*, but
|
||||
*lookup by name only works while that player is online* — you cannot change an offline
|
||||
player's score by name today.
|
||||
- **No permission nodes anywhere.** `plugin.yml` declares no `permission:`/`permissions:`
|
||||
and the code checks none. The README's note ("the commands aside from get are intended
|
||||
for admins … Permissions support is coming") is **intent, not enforcement** — a vanilla
|
||||
player can run `/score-add` today.
|
||||
|
||||
### 2.4 Reading a score (`/score-get`)
|
||||
|
||||
`ScoreGetCommand.java:38-84` → `ScoreKeeperPlugin.getScore(player)` → `getPlayerScore(player)`
|
||||
(`ScoreKeeperPlugin.java:76-78, 100-106`). It returns the live integer (0 for a known-but-
|
||||
unwritten player, which also *materializes* a 0 entry, see §3.1). Output formatting
|
||||
("Your score is N" vs. "PLAYER's score is N") depends only on whether the sender is the
|
||||
target or not — it carries no ranking or table.
|
||||
|
||||
---
|
||||
|
||||
## 3. The high-score-table algorithm *(task Q3)*
|
||||
|
||||
### 3.1 What exists: **nothing. It is aspirational.**
|
||||
|
||||
There is **no high-score table, no ranking structure, no sort, no tie-break rule, no max
|
||||
entry count, and no decay/rotation** anywhere in the codebase. The task's premise ("the
|
||||
high-score table") reflects the **product intent** in the README, not the **code**. Concretely:
|
||||
|
||||
- The README (`README.md:11`) says `/score-archive` *"Saves the player's score to a
|
||||
'High Scores' table and resets their current score to 0."*
|
||||
- The manifest (`plugin.yml:18-20`) declares `/score-archive` with that very description.
|
||||
- But the command is a stub: `ScoreArchiveCommand.java:37-39` (`onCommand` body) replies
|
||||
*"archive command unimplemented"*, and the underlying `archiveScore`
|
||||
(`ScoreKeeperPlugin.java:72-74`) only logs and returns — it neither writes a table nor
|
||||
resets anything.
|
||||
|
||||
Therefore the "algorithm" is: **no-op.** A new engineer asked to "implement the high-score
|
||||
table" is starting from zero; the design questions in §3.2 are **open**, not answered by code.
|
||||
|
||||
### 3.2 Open design questions the table must settle (no code today decides these)
|
||||
|
||||
Since no implementation exists, these are *decisions to be made*, recorded here so the
|
||||
implementation task doesn't reinvent the debate:
|
||||
|
||||
- **Storage/persistence format.** The load/save TODOs (`:47`, `:59`) say "to file";
|
||||
`plugin.yml`/Bukkit convention favors YAML (`YamlConfiguration`), but JSON/SQLite are all
|
||||
viable. **Unchosen.** Persisting to `data/` via `getDataFolder()` is the idiomatic Bukkit
|
||||
path.
|
||||
- **What an entry is.** Today a live score is just `{uuid -> int}`. A high-score entry
|
||||
likely needs **player name + score + (timestamp?) + (date earned?)**. Name is *not*
|
||||
currently stored with the score, so a durable table must capture the name at archive
|
||||
time (a UUID-only entry can't render a leaderboard without the name being resolvable).
|
||||
- **Sorting / ordering.** Almost certainly **descending by score**.
|
||||
- **Tie-breaking.** Undefined. Candidate rules: by *score only*; by *earliest* archived
|
||||
first (stable, time-ordered); by *name* (alphabetical); or "first to reach that score."
|
||||
- **Max entries / cap.** Undefined. A leaderboard needs a cap (e.g. top 10 / top 30);
|
||||
today there is no cap because there is no table.
|
||||
- **Decay / rotation / time window.** None, and none described in docs — so the safe
|
||||
default is **"scores are permanent, no decay."**
|
||||
- **Reset semantics on archive.** README promises archive *resets to 0* *and* records.
|
||||
`ScoreArchiveCommand` must decide: does archiving also reset? Does it allow multi-entries
|
||||
(a player appearing more than once) or one row per player? All open.
|
||||
|
||||
### 3.3 Full lifecycle of a score: creation → (intended) display on the high-score table
|
||||
|
||||
This is the acceptance-criterion walk-through. Each stage is marked **[REAL]** (in code now)
|
||||
or **[GAP]** (intended, not built).
|
||||
|
||||
1. **Player joins / acts** — a score *doesn't* exist yet. First interaction with the map is
|
||||
lazy (see stage 4a). **[REAL]**
|
||||
2. **Admin records a score** — `admin: /score-add Alice 10`. Parsed in `ScoreAddCommand`,
|
||||
routed to `addScore`. The first time this runs for Alice, `getPlayerScore` **creates**
|
||||
her entry at 0 and returns it; then `10` is written. **[REAL]**
|
||||
3. **Score accumulates** — later `/score-add Alice 5` → 15; `/score-subtract Alice 2` → 13;
|
||||
`/score-reset Alice` → 0. All in the in-memory map, live only. **[REAL]**
|
||||
4. **Read** — `/score-get Alice` → "Alice's score is 13". No ranking shown. **[REAL]**
|
||||
5. **Server restart** — `onDisable` *cannot* save (stub), `onEnable` *cannot* load (stub);
|
||||
the map is **lost**. Alice's 13 is gone; every score starts empty again. **[REAL] —
|
||||
this is the current data-loss reality.**
|
||||
6. **Intended: archive to the high-score table** — `admin: /score-archive Alice` should
|
||||
freeze Alice's 13 into a durable, sorted leaderboard and reset her live score to 0, so
|
||||
it survives restarts. **[GAP]** — currently returns "archive command unimplemented".
|
||||
7. **Intended: display on the high-score table** — a command (not yet built) renders the
|
||||
capped, sorted list. **[GAP]** — no such command, no structure to render.
|
||||
|
||||
**Edge cases (explicitly, per the acceptance criteria):**
|
||||
|
||||
- **First-time player / first write.** A player has no map entry until `getPlayerScore` is
|
||||
called, which **inserts `0` on first access** (`ScoreKeeperPlugin.java:100-106`). So a
|
||||
first `/score-add X 10` yields **10, not** `10 - 0` ambiguity, and a first `/score-subtract
|
||||
X 3` yields **−3** (no minimum-0 clamp). A first `/score-get X` returns **0** and
|
||||
*materializes* the entry at 0. This `get-or-create-0` behavior is the de-facto "first-time
|
||||
player" rule. **[REAL]**
|
||||
- **Ties.** **Undefined** because no table exists. When the table is built, decide a
|
||||
tie-break (§3.2). No code today can observe or sort ties — `HashMap` gives no order. **[GAP]**
|
||||
- **Table full.** **Undefined** because no cap exists. When a cap is introduced, decide
|
||||
what happens to the displaced entry: drop it, or "rotate" it into overflow. No code
|
||||
today enforces a maximum. **[GAP]**
|
||||
- **Offline / unknown name.** `getPlayerExact(name)` returns `null` for anyone not
|
||||
currently online or any misspelling → the command prints "Can't find a player with that
|
||||
name" and changes nothing. You **cannot** archive or reset an *offline* player by name
|
||||
today; by-UUID writes (if a future table stores names+UUIDs) would fix that. **[REAL]**
|
||||
- **Negative / large scores.** No clamp; negatives allowed, `int` overflow only near
|
||||
~2.1 billion. **[REAL]**
|
||||
- **Double-spawn / relogin.** Keyed by `UUID`, **not name**, so a name change or two
|
||||
players sharing a name can't collide on the *live* map; but a *name* is never stored,
|
||||
so a future table that only persists the UUID can later fail to render a name.
|
||||
|
||||
---
|
||||
|
||||
## 4. Scoring formulas & weighting *(task Q4)*
|
||||
|
||||
**None.** There is:
|
||||
|
||||
- No formula, no multiplier, no combo/bonus/streak logic.
|
||||
- No weighting between action types.
|
||||
- No time-based decay or "points per game" normalization.
|
||||
|
||||
Scores are **pure integer accumulators**: `score = Σ(adds) − Σ(subtracts)` over the session,
|
||||
resettable to 0 by `/score-reset` (intended: on `/score-archive`). The only "arithmetic" in
|
||||
the code is the `+`/`−` in `addScore`/`subtractScore` and the `0` floor written by
|
||||
`resetScore`. `int` semantics apply (wrapping overflow; no checked arithmetic). Any
|
||||
formula/weighting is a **future-design** decision, not encoded today.
|
||||
|
||||
---
|
||||
|
||||
## 5. Data-flow diagram (text)
|
||||
|
||||
```
|
||||
ADMINISTRATOR / CONSOLE / RCON (no game events, no scheduler, no auto-scoring)
|
||||
│ types a command
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ command executors │ commands/Score*Command.java
|
||||
│ parse args + resolve player│ getPlayerExact(name) ── must be ONLINE (name→UUID)
|
||||
│ (self-target if player) │ no permission checks
|
||||
└──────────────┬──────────────┘
|
||||
│ calls
|
||||
▼
|
||||
┌───────────────────────────────────────────────┐
|
||||
│ ScoreKeeperPlugin (entry point; plugin.yml main)│
|
||||
│ │
|
||||
│ addScore / subtractScore / resetScore / setScore │ read-modify-write on...
|
||||
│ getScore (read) archiveScore (STUB)│
|
||||
└──────────────┬───────────────────────┬──────────┘
|
||||
│ read-modify-write │ (intended: snapshot→table, reset 0)
|
||||
▼ ▼
|
||||
live map: HashMap<UUID, int> ╳ NOT IMPLEMENTED
|
||||
"score entry = one int per UUID" high-score table:
|
||||
default 0, no clamp, in RAM only ─ no structure, no sort,
|
||||
│ ─ no persistence,
|
||||
├─ READ: /score-get → "N" ─ no cap/decay
|
||||
│
|
||||
└─ LIFECYCLE:
|
||||
onEnable : load from file → TODO (stays {} ; lost on restart)
|
||||
onDisable : save to file → TODO (map discarded at shutdown)
|
||||
|
||||
PERSISTENCE: none │ SCORE FORMULA: none │ EVENTS/TIMERS: none │
|
||||
PERMISSIONS: none │ HIGH-SCORE TABLE: aspirational stub only
|
||||
```yaml
|
||||
archives:
|
||||
"00000000-0000-0000-0000-000000000003":
|
||||
scope: bucket points
|
||||
created-at: 1800000000000
|
||||
buckets:
|
||||
points:
|
||||
scores:
|
||||
"00000000-0000-0000-0000-000000000001": 10
|
||||
```
|
||||
|
||||
---
|
||||
This file has no explicit format version. Empty bucket score maps may be omitted
|
||||
on serialization because only individual score entries are written.
|
||||
The two files are saved separately; there is no cross-file transaction or atomic
|
||||
replacement guarantee. Save I/O errors use the plugin logger. Never edit live
|
||||
data while the server is running: shutdown can overwrite it.
|
||||
|
||||
## 6. Quick reference — "where to look first"
|
||||
## Validation status
|
||||
|
||||
| I want to understand… | Go to |
|
||||
|-----------------------|-------|
|
||||
| The entire live data model | `ScoreKeeperPlugin.java:38` (one `HashMap<UUID,Integer>`) |
|
||||
| How a score changes | `addScore`/`subtractScore`/`resetScore`/`setScore` `:67-91` |
|
||||
| How a score is read | `getScore` `:76-78` → `getPlayerScore` `:100-106` (note get-or-create-0) |
|
||||
| The "high-score table" | **Doesn't exist** — see `archiveScore` stub `:72-74`; design open in §3.2 |
|
||||
| Persistence (save/load) | `onDisable` `:46-49`, `onEnable` `:59-60` — both `TODO`, not built |
|
||||
| Command behaviors | `commands/Score*Command.java` (self-target default; RCON requires a name; exact online-name lookup) |
|
||||
| What's declared/intended but not wired | `plugin.yml:18-20` (`/score-archive`), `README.md:11`, `README.md` notes |
|
||||
| Build/runtime target | `build.gradle` (paper-api 1.21.7, Java 21), `plugin.yml` (`api-version: 1.21`) |
|
||||
|
||||
---
|
||||
|
||||
## 7. Risks a new engineer should know (correctness gaps in the *current* live domain)
|
||||
|
||||
These are real, not future-work — flagging because the doc's job is to prevent a new
|
||||
developer from assuming the system is more mature than it is:
|
||||
|
||||
1. **Data loss on restart.** No save/load (`:47`, `:59`). Every server boot wipes all
|
||||
scores. Any "leaderboard across sessions" is broken by design.
|
||||
2. **No permissions.** Anyplayer can self-add points. README says this is by intent
|
||||
("coming after I get archive to work") but it is not enforced.
|
||||
3. **Race condition on add/subtract.** `read → compute → write` is not atomic and the
|
||||
`HashMap` is not thread-safe; concurrent command executions could lose an update.
|
||||
(Low likelihood today since commands are serial on one thread, but it's a latent bug for
|
||||
any async/event-driven scoring that gets added.)
|
||||
4. **No minimum-0 / no validation of amount sign.** Subtracts produce negatives freely.
|
||||
5. **Name lookups are online-only & exact.** Can't target offline players by name;
|
||||
case-sensitive; "Alice" ≠ "alice".
|
||||
6. **No high-score table.** The flagship advertised feature (`/score-archive` → "High
|
||||
Scores" table) is a no-op; a new engineer must not expect ranking/persistence to work.
|
||||
|
||||
---
|
||||
|
||||
## 8. Summary for the synthesizer (`Project.md` § "domain model & scoring logic")
|
||||
|
||||
Distilled, code-grounded, and honest:
|
||||
|
||||
- **Model:** one `int` per player `UUID`, held in `ScoreKeeperPlugin._playerScores`
|
||||
(`HashMap`), default `0`.
|
||||
- **Recording:** manual, admin-driven commands; **no events/timers**; no permission guard.
|
||||
- **Persistence:** **none** — load/save are `TODO`; scores are lost on restart.
|
||||
- **High-score table:** **does not exist** — `/score-archive` is a stub; sorting/tie-break/
|
||||
cap/decay are **undecided design items** (listed in §3.2).
|
||||
- **Formula/weighting:** **none** — plain `int` accumulation.
|
||||
- **Lifecycle:** create-on-first-access (0) → add/subtract/reset (live only) → read via
|
||||
`/score-get` → *intended* archive+reset + table display **not built** → lost on restart.
|
||||
- **Edge cases:** first-time/first-write ⇒ 0-or-delta, no floor; ties/table-full ⇒ undefined
|
||||
(no table yet); offline/unknown name ⇒ "can't find", unchanged.
|
||||
|
||||
Everything below the "high-score table" line of the README is **future work**, and the
|
||||
write-up's job is to make that boundary explicit so the next team member isn't misled.
|
||||
These are source-level behavior descriptions, not claims of passing automated
|
||||
tests. Pending coverage is tracked in [TODO.md](../TODO.md). Before release,
|
||||
use [human-tests.md](human-tests.md), particularly ranking ties, empty buckets,
|
||||
restoration, malformed data, and restart/upgrade cases.
|
||||
|
||||
@@ -1,55 +1,72 @@
|
||||
# ScoreKeeper Human Testing
|
||||
# Score Keeper Human Testing
|
||||
|
||||
Use this checklist on a disposable Paper 26.2 or 26.3 server. ScoreKeeper stores data in its plugin folder and interacts with online players, command senders, and scheduled high-score runs; a passing build alone does not verify these in-game workflows.
|
||||
Use this manual pre-release checklist on disposable Paper 26.2 and 26.3 servers
|
||||
(test both before advertising both). Score Keeper stores data in its plugin folder
|
||||
and interacts with players, command senders, and scheduled runs; a passing build
|
||||
alone does not verify these workflows. These are test scenarios, not passing results.
|
||||
See [CONTRIBUTING.md](../CONTRIBUTING.md) for setup and helper-script safety, and
|
||||
[the domain reference](domain-score-tracking.md) for expected behavior.
|
||||
|
||||
## Test Setup
|
||||
|
||||
- Use Java 25 or newer and a backed-up test server. Keep the server log available throughout testing.
|
||||
- Create at least two test players: one operator/admin and one ordinary player. Use a console or RCON session for console-sender cases.
|
||||
- Use Java 25 and a backed-up test server. Keep the server log available throughout testing.
|
||||
- Use at least three test players for rankings: an operator, a non-operator with `scorekeeper.admin`, and an ordinary player. Use a console or RCON session for non-player sender cases.
|
||||
- Before each run, preserve `plugins/ScoreKeeper/scores.yml` and `archives.yml`, or use a fresh test server. Archive, reset, and bucket-wide commands intentionally change scores.
|
||||
- Record command sender, arguments, expected and observed messages, and score values before and after each operation.
|
||||
- Record plugin artifact/version, Paper version/build, Java version, command sender, arguments, expected and observed messages, and score values before and after each operation. Save pass/fail notes and relevant logs outside player data committed to the repo.
|
||||
- Ensure only the intended Score Keeper jar is installed. Stop with `stop` in the server console so disable-time saves run. Do not use helper scripts that can stop other Paper processes on a shared host.
|
||||
|
||||
## Human Checklist
|
||||
|
||||
### Startup and score commands
|
||||
|
||||
- Start Paper and confirm ScoreKeeper enables, registers every documented command, and loads existing data without errors.
|
||||
- As a player, run `/score-get`, `/score-add`, `/score-subtract`, and `/score-reset`; check the displayed values and the configured initial value. Repeat with console/RCON, supplying a player name where required.
|
||||
- Try zero, negative, very large, missing, and non-numeric amounts. Confirm invalid input is handled clearly and does not unexpectedly alter a score.
|
||||
- Start Paper and confirm Score Keeper enables, registers every documented command, and loads existing data without errors.
|
||||
- As a player, run `/score-get`, `/score-add 10`, `/score-subtract 3`, and `/score-reset`; inspect `/score-get` after each mutation. Repeat with console/RCON, supplying a player name where required. Missing targets from non-player senders must produce usage, not self-scoring.
|
||||
- Try zero and negative amounts: they are valid signed integers (for example, adding `-3` decreases the score). Try missing/non-numeric/out-of-range amounts: these should produce usage/errors without changing scores. At integer boundaries, record the current wrapping behavior; there is no overflow guard.
|
||||
- Target offline/unknown names and supply extra arguments; verify errors/usage without unrelated changes. Confirm gameplay such as mob kills does not award points unless a companion plugin is installed.
|
||||
- Use two players to verify each player's score is independent. Change a player's Minecraft name if practical, then confirm their score remains associated with their UUID.
|
||||
- Check singular/plural unit labels at values of 1, 0, and multiple units, and confirm messages show the correct bucket and value.
|
||||
- Check singular/plural labels at 1, 0, negative, and multiple values in reporting, bucket-change, and run/archive messages. `/score-get` only displays a number; it does not show bucket/units.
|
||||
|
||||
### Buckets and reporting
|
||||
|
||||
- Create a test bucket with a nonzero initial value and distinctive singular/plural labels. Verify invalid IDs, blank labels, and duplicate IDs are rejected cleanly.
|
||||
- Create a test bucket with a nonzero initial value and distinctive singular/plural labels, for example `/score-bucket create Bread loaf loaves 5 player`. Verify invalid/duplicate IDs, invalid initial values, and unknown reporting policies produce errors. IDs are case-sensitive; command labels each occupy one argument. Use a companion-plugin API test if checking blank/null labels that cannot be supplied naturally as command arguments.
|
||||
- Switch one player to the bucket, add and subtract points, and confirm other players remain in their own active bucket. Switch back and verify the original score is unchanged.
|
||||
- Change the server-wide default with `/score-bucket all <bucketId>`. Confirm individual assignments are cleared, online players receive the appropriate change notice, and new players use the new default.
|
||||
- For each reporting policy (`none`, `player`, `admin`, `global`), change a score and verify exactly the intended audience receives the report. Test with an operator, a `scorekeeper.admin` player, an ordinary player, and the scored player.
|
||||
- Exercise bucket creation, switching, and administration as authorized and unauthorized senders. The README says archive, bucket administration, and run management require `scorekeeper.admin`; verify the behavior on the target server.
|
||||
- Exercise authorized/unauthorized bucket creation and switching another/all players: these require `scorekeeper.admin`. An ordinary player must still be able to view/select their own bucket. Selecting the already-active bucket should not produce a bucket-change notice.
|
||||
- Set reporting to `none` and verify a successful add/subtract/reset can be silent. Writing the same score should not send a change report under any policy. `admin` reports should also reach the server log.
|
||||
- Note that the README says score get/add/subtract/reset currently have no permission checks and can target any online player. Confirm that exposure is acceptable for the server before enabling these commands publicly.
|
||||
|
||||
### Archives
|
||||
|
||||
- Archive one player's active-bucket score, then inspect `/score-archive-list` and `/score-archive-list <archiveId>`. Confirm the saved value and bucket are correct and the live score returns to that bucket's initial value.
|
||||
- Archive one player's active-bucket score as an admin, then inspect `/score-archive-list` and `/score-archive-list <archiveId>`. Confirm the snapshot value/bucket and the live score returns to that bucket's initial value. Ordinary players must be denied archive creation but can list/view archives.
|
||||
- Repeat for `/score-archive bucket <bucketId>` and `/score-archive all`. Confirm only the selected bucket or all buckets are archived and reset as requested.
|
||||
- Check archive IDs are listed newest first, then restart and confirm archives and their contents remain available.
|
||||
- Try an unknown archive ID or bucket ID and verify a useful failure without unrelated scores being changed.
|
||||
- Include recorded offline players and ties: entries sort descending by score then UUID, not run-style name ties. Check empty bucket archives before/after restart and record any omitted empty bucket sections.
|
||||
- Attempt player/bucket/all archiving while a selected bucket has an active run. It must fail before changing any selected scores; stop the run and retry. Archive resets should not send normal per-score reporting.
|
||||
|
||||
### High-score runs
|
||||
|
||||
- Start a target-score run and a timed run using a test bucket and at least three players. Confirm the run starts with the requested top-N and reset setting.
|
||||
- Start target/timed runs with at least three players. Use literal booleans, for example `/score-run start Bread 2 true duration 10s`. Top N must be at least 1. Reject invalid booleans, zero/negative/overflowing duration, uppercase time suffixes, unknown buckets, and duplicate runs.
|
||||
- A reset target must exceed the initial value. Without reset, a pre-existing score at/above the target may finish immediately; verify this rather than assuming every start remains active.
|
||||
- Change scores for players inside and outside the current top-N. Verify individual score-change messages and global reporting for current top-N players match the run behavior.
|
||||
- End runs by reaching the target, expiration, and `/score-run stop`. Also start an `until-disabled` run and stop it manually.
|
||||
- Check final ranking order, ties, each online player's reported place, and the displayed top-N cutoff.
|
||||
- With reset enabled, verify scores begin at the bucket initial value and pre-run scores are restored after completion. With reset disabled, confirm scores remain as earned.
|
||||
- Restart while a run is active. Confirm the run and reset snapshot survive, timed runs expire at the intended time, and stopping or completing the run produces one final result rather than duplicate results.
|
||||
- Check descending score, case-insensitive name then UUID tie-breaking, distinct consecutive places for ties, each online player's place, unranked players, and the top-N cutoff. Include recorded offline players; top N limits display, not stored entries.
|
||||
- With reset enabled, verify scores begin at the initial value and pre-run entries are restored exactly. A player first recorded during the run should return to the initial value on the next read after completion. With reset disabled, scores remain as earned. Final personal results must show run scores, not restored scores.
|
||||
- Restart cleanly while a run is active. Confirm snapshots survive, timed expiration includes time offline, overdue runs finish on enable, and `until-disabled` resumes until explicitly stopped. Confirm completion happens once and no automatic archive is created.
|
||||
- Run two buckets concurrently and confirm independent completion/restoration. Observe timed completion under lag: checks run every 20 ticks, not at an exact wall-clock second.
|
||||
|
||||
### Persistence and upgrades
|
||||
|
||||
- Restart after changing scores, bucket definitions, reporting policies, the default bucket, and per-player bucket assignments. Verify all values and assignments persist.
|
||||
- Test a clean data folder and an existing/older `scores.yml` or `archives.yml` on a backed-up server. Confirm startup handles defaults, known legacy data, and malformed or unknown entries without silently corrupting valid data.
|
||||
- Check saved files after a clean shutdown and after a forced test restart; distinguish expected last-save behavior from data loss.
|
||||
- Test a clean data folder and copies of older files, including flat top-level UUID scores (loaded into `points`). Verify default/reporting fallbacks and invalid UUID/bucket/run warnings. For malformed types/unknown assignments, record actual getter defaults/ignored values; current loading is not comprehensive validation.
|
||||
- Check `scores.yml` version 3 and the archive fields after a clean shutdown. Both files save only on disable, not each mutation. On an explicitly authorized disposable server, compare a forced crash with the last clean save: loss of recent changes is a known limitation, not successful durability.
|
||||
- If using a companion plugin, verify `depend: [ScoreKeeper]` load order, main-thread awards into an explicit bucket, and visible failure when Score Keeper is absent/disabled. Verify no unintended active-bucket switch.
|
||||
|
||||
## Automated Coverage
|
||||
|
||||
There are currently no Java test sources or test dependencies in this project, and no integration-test source set. The Gradle `test` task therefore does not currently exercise ScoreKeeper behavior. All scenarios above should be treated as unverified until tested in-game; the “Ready” test tasks in `TODO.md` describe work that has not yet been added.
|
||||
There are currently no Java test sources or test dependencies in this project,
|
||||
and no integration-test source set. Gradle `test` is `NO-SOURCE` and does not
|
||||
exercise Score Keeper behavior. Scenarios remain unverified until actually
|
||||
tested; SK-08 through SK-12 in [TODO.md](../TODO.md) and
|
||||
[the modernization plan](Modernize.md) describe pending automated coverage.
|
||||
|
||||
@@ -1,10 +1,24 @@
|
||||
**ScoreKeeper Plugin**
|
||||
**Score Keeper**
|
||||
|
||||
ScoreKeeper tracks player scores in configurable buckets. Use it for event points, competitions, or other server-side scoring systems, and integrate it with other plugins through the public API.
|
||||
Score Keeper tracks player scores in configurable buckets. Use it for event points,
|
||||
competitions, or other server-side scoring systems, and integrate it with other
|
||||
plugins through the public API. Points are awarded by commands or companion
|
||||
plugins, not by built-in gameplay event listeners.
|
||||
|
||||
## Installation
|
||||
|
||||
Requires Java 25 and Paper 26.2 or 26.3. Stop your server cleanly, back up plugin
|
||||
data, and place the downloaded jar in `plugins`, removing older Score Keeper jars.
|
||||
Restart and check the server log. The installed plugin ID and data folder remain
|
||||
`ScoreKeeper`; the display name is Score Keeper.
|
||||
|
||||
## Commands
|
||||
|
||||
Players can omit an optional player name to target themselves. Console and RCON must provide a player name for score get/add/subtract/reset commands.
|
||||
Players can omit an optional player name to target themselves. Named targets must
|
||||
be online. Console and RCON must provide a player name for score get/add/subtract/reset;
|
||||
archive also accepts `all` and `bucket` scopes. Add/subtract accept signed 32-bit
|
||||
integers, including zero and negative amounts. Bucket IDs are case-sensitive and
|
||||
allow letters, numbers, `_`, and `-`; each command-created unit label is one argument.
|
||||
|
||||
* `/score-get [playerName]` - Displays the target player's score in their active bucket.
|
||||
* `/score-add <amount>` - Adds an amount to your score in your active bucket.
|
||||
@@ -23,14 +37,18 @@ Players can omit an optional player name to target themselves. Console and RCON
|
||||
* `/score-bucket create <id> <singular> <plural> <initialValue> [reporting]` - Creates a bucket. Reporting can be `admin`, `global`, `player`, or `none` (default).
|
||||
* `/score-bucket <playerName> <bucketId>` - Switches a player's active bucket.
|
||||
* `/score-bucket all <bucketId>` - Changes the server's default bucket and clears individual bucket assignments.
|
||||
* `/score-run start <bucketId> <topN> <reset:true|false> target <score>` - Starts a run that ends when a score reaches the target.
|
||||
* `/score-run start <bucketId> <topN> <reset:true|false> duration <time>` - Starts a timed run. Use a positive number and lowercase `s`, `m`, `h`, `d`, or `w`, such as `4h`.
|
||||
* `/score-run start <bucketId> <topN> <reset:true|false> until-disabled` - Starts a run with no automatic end.
|
||||
* `/score-run start <bucketId> <topN> <true|false> target <score>` - Starts a run that ends when a score reaches the target.
|
||||
* `/score-run start <bucketId> <topN> <true|false> duration <time>` - Starts a timed run. Use a positive number and lowercase `s`, `m`, `h`, `d`, or `w`, such as `4h`.
|
||||
* `/score-run start <bucketId> <topN> <true|false> until-disabled` - Starts a run with no automatic end, including across clean restarts.
|
||||
* `/score-run stop <bucketId>` - Ends an active run.
|
||||
|
||||
## Permissions
|
||||
|
||||
The `scorekeeper.admin` permission (default: operators) is required for archive commands, bucket creation/administration, and high-score run management. Score get/add/subtract/reset and archive-list commands currently have no permission checks; add, subtract, and reset can target any online player.
|
||||
The `scorekeeper.admin` permission (default: operators) is required for
|
||||
`score-archive`, bucket creation, switching another player/all players, and run
|
||||
management. Viewing/selecting your own bucket is open. Score get/add/subtract/reset
|
||||
and archive-list have no permission checks; add, subtract, and reset can target
|
||||
**any online player**. Restrict access externally if this does not fit your server.
|
||||
|
||||
## Features
|
||||
|
||||
@@ -40,10 +58,38 @@ The `scorekeeper.admin` permission (default: operators) is required for archive
|
||||
* Archive player, bucket, or all-bucket scores; archived scores reset to their bucket's initial value.
|
||||
* Persist bucket definitions, assignments, scores, active runs, and archives in the plugin's data folder.
|
||||
|
||||
Reporting defaults to `none`, so successful score mutations can be silent; use
|
||||
`/score-get` to inspect the number. Changed scores use singular units for exactly
|
||||
1, plural otherwise. Scores may be negative and overflow is not checked.
|
||||
|
||||
Runs require top N of at least 1 and a literal `true`/`false` reset argument.
|
||||
For example, `/score-run start points 3 true duration 4h`. Run reporting overrides
|
||||
the bucket policy: the scored player always receives changes, and current top-N
|
||||
players' changes are reported globally. Rankings include all recorded bucket
|
||||
entries, even offline players; ties use case-insensitive name then UUID and
|
||||
consecutive places. Final results include each online player's place. Reset runs
|
||||
restore previous scores, while non-reset runs keep earned scores. Timed runs use
|
||||
wall-clock time, including time offline; an existing target can finish a non-reset
|
||||
run immediately.
|
||||
|
||||
Stop a run before archiving its bucket. Final run results are announced/logged,
|
||||
not automatically archived. Archives and live state are saved to
|
||||
`plugins/ScoreKeeper/archives.yml` and `scores.yml` **on clean shutdown/plugin
|
||||
disable**, not after every command. Crashes can lose changes since the last save.
|
||||
Do not edit data files while the server is running.
|
||||
|
||||
## API
|
||||
|
||||
Other plugins can create buckets with `createBucket(id, singular, plural, initialValue, reporting)`, use bucket-aware score methods, and start or stop high-score runs with `startTargetScoreRun`, `startTimedScoreRun`, `startUntilDisabledScoreRun`, and `stopHighScoreRun`.
|
||||
Other plugins can create buckets with
|
||||
`createBucket(id, singular, plural, initialValue, ScoreReporting)`, use bucket-aware
|
||||
score methods, and manage runs with `startTargetScoreRun`, `startTimedScoreRun`,
|
||||
`startUntilDisabledScoreRun`, and `stopHighScoreRun`. Declare a dependency on
|
||||
`ScoreKeeper` and call the enabled plugin API on Paper's main thread.
|
||||
See the [integration reference](https://github.com/headhunter45/ScoreKeeper/blob/develop/docs/plugin-integration-and-event-wiring.md).
|
||||
|
||||
## Compatibility
|
||||
|
||||
Built exclusively for Paper 26.2 and 26.3 with the Paper API and Adventure APIs. Bukkit and Spigot servers are not supported.
|
||||
|
||||
Source and development instructions are in the
|
||||
[repository](https://github.com/headhunter45/ScoreKeeper). Licensed under GNU AGPL v3 or later.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "Score Keeper",
|
||||
"url": "https://modrinth.com/plugin/scorekeeper",
|
||||
"summary": "Track player scores in configurable buckets with custom reporting, high-score runs, and archives. Includes in-game commands and an API for other plugins.",
|
||||
"summary": "A Paper scoring engine with configurable buckets, reporting, high-score runs, shutdown-persisted archives, commands, and a companion-plugin API.",
|
||||
"visibility": "public",
|
||||
"links": {
|
||||
"issueTracker": "https://github.com/headhunter45/ScoreKeeper/issues",
|
||||
|
||||
@@ -1,166 +1,136 @@
|
||||
# ScoreKeeper — Plugin Integration & Event/Command Reference
|
||||
# Score Keeper - Plugin Integration and Event Wiring
|
||||
|
||||
> Analysis for the ScoreKeeper codebase. Scope: how the plugin hooks into the
|
||||
> Minecraft (Paper) server runtime — event listeners, command registrations,
|
||||
> scheduled/tick logic, and inter-plugin/API surface — with a table mapping each
|
||||
> trigger → handler class → effect on score data.
|
||||
>
|
||||
> Platform: **Paper** (`io.papermc.paper:paper-api:1.21.7-R0.1-SNAPSHOT`), Java 21,
|
||||
> Gradle. Main class: `com.majinnaibu.minecraft.plugins.scorekeeper.ScoreKeeperPlugin`.
|
||||
New Score Keeper contributors should start with
|
||||
[CONTRIBUTING.md](../CONTRIBUTING.md), which covers architecture, setup, and validation.
|
||||
This is an optional detailed reference for runtime wiring and companion-plugin
|
||||
authors, not a second onboarding guide. [domain-score-tracking.md](domain-score-tracking.md)
|
||||
describes state and [README.md](../README.md) gives full command syntax.
|
||||
|
||||
---
|
||||
## Paper lifecycle
|
||||
|
||||
## 1. TL;DR for a new developer
|
||||
The entry point is
|
||||
[ScoreKeeperPlugin](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/ScoreKeeperPlugin.java),
|
||||
declared in [plugin.yml](../src/main/resources/plugin.yml) under the plugin ID
|
||||
`ScoreKeeper`. Compilation targets Paper `26.2.build.129-stable` on Java 25;
|
||||
supported server versions are Paper 26.2 and 26.3.
|
||||
|
||||
ScoreKeeper is almost entirely **command-driven**. It registers **no Bukkit event
|
||||
listeners**, declares **no `@EventHandler` methods, no `Listener` implementations,
|
||||
and calls `getPluginManager().registerEvents(...)` nowhere**. It also schedules
|
||||
**no timed tasks** (no `BukkitScheduler`/`BukkitRunnable`/tick logic).
|
||||
| Trigger | Handler / effect |
|
||||
| --- | --- |
|
||||
| Plugin enable | Register eight executors, initialize `points`, load scores/archives, check existing runs, schedule synchronous checks every 20 ticks |
|
||||
| Scheduled check | `checkHighScoreRuns`: finish expired duration runs or runs whose target is reached |
|
||||
| Plugin disable | Serialize bucket definitions, scores, assignments, active runs/snapshots, and archives to two YAML files |
|
||||
| Minecraft join/quit/death/kill | No built-in listeners or automatic score awards |
|
||||
| Companion-plugin API call | Perform requested score/bucket/archive/run operation |
|
||||
|
||||
The only things that touch score state are **five console/chat commands**
|
||||
(`score-get`, `score-add`, `score-subtract`, `score-reset`, `score-archive`).
|
||||
Score state lives in an **in-memory `HashMap<UUID, Integer>`** and is **not
|
||||
persisted** — `onEnable`/`onDisable` have `TODO` stubs, so data is lost on restart.
|
||||
There are no `Listener` implementations, `@EventHandler` methods, custom scoring
|
||||
events, or event registrations. The scheduler manages runs, not gameplay scoring.
|
||||
Expired saved runs finish during enable; `until-disabled` runs persist and resume.
|
||||
|
||||
There is a **`highscore` / high-score table in the project name and the task
|
||||
prompt, but no such command or logic exists yet** — it is unimplemented.
|
||||
## Command wiring
|
||||
|
||||
---
|
||||
Each manifest command is explicitly wired in `onEnable` using `getCommand` and
|
||||
`setExecutor`. A missing declaration fails startup via `Objects.requireNonNull`.
|
||||
|
||||
## 2. Event listeners (Bukkit/Adventure)
|
||||
Handlers are in [commands/](../src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/commands/).
|
||||
|
||||
**None.** The plugin listens to no server events. Confirmed by absence of any of:
|
||||
`@EventHandler`, `implements Listener`, `registerEvents(`, `PlayerJoinEvent`,
|
||||
`PlayerQuitEvent`, `PlayerDeathEvent`, or any other event import/registration.
|
||||
| Command | Executor | Delegation / effect | Permission |
|
||||
| --- | --- | --- | --- |
|
||||
| `score-get` | `ScoreGetCommand` | `getScore`, active bucket, lazy entry creation | None |
|
||||
| `score-add` | `ScoreAddCommand` | `addScore`, signed integer addition | None |
|
||||
| `score-subtract` | `ScoreSubtractCommand` | `subtractScore`, signed integer subtraction | None |
|
||||
| `score-reset` | `ScoreResetCommand` | `resetScore`, active bucket initial value | None |
|
||||
| `score-archive` | `ScoreArchiveCommand` | `archivePlayerScore`, `archiveBucketScores`, or `archiveAllScores` | `scorekeeper.admin` |
|
||||
| `score-archive-list` | `ScoreArchiveListCommand` | `getScoreArchives` or `getScoreArchive` | None |
|
||||
| `score-bucket` | `ScoreBucketCommand` | View/select own bucket, create bucket, switch another/all players | Admin for create/other/all; none for self |
|
||||
| `score-run` | `ScoreRunCommand` | Start target/timed/manual run, or stop it | `scorekeeper.admin` |
|
||||
|
||||
| Server event | Handler | Effect on score data |
|
||||
|---|---|---|
|
||||
| PlayerJoin | *none* | none |
|
||||
| PlayerQuit | *none* | none |
|
||||
| PlayerDeath | *none* | none |
|
||||
| (all other Bukkit events) | *none* | none |
|
||||
| Custom/plugin-injected events | *none* | none |
|
||||
`scorekeeper.admin` defaults to operators in the manifest. Guards are implemented
|
||||
inside selected executors, not per-command manifest permission fields. Public API
|
||||
calls do not enforce sender permissions; the caller must enforce its own policy.
|
||||
|
||||
**Implication:** nothing about a player's score changes as a result of gameplay
|
||||
events (joining, quitting, dying, scoring points in-game, etc.). The only way
|
||||
score data changes is through the commands in §3.
|
||||
Named player targets use Paper's `getPlayerExact` and must be online. Players
|
||||
may omit the optional name to target themselves; non-player senders have no
|
||||
self context. Console/RCON can use archive `all`/`bucket` forms without a player.
|
||||
Bucket IDs are case-sensitive even though command keywords such as `all` are not.
|
||||
|
||||
---
|
||||
Parse/validation failures are returned as Adventure usage/error messages.
|
||||
Handlers consume commands by returning `true`. Score mutation commands rely on
|
||||
bucket/run reporting instead of unconditional success messages; the default
|
||||
`none` policy can make a successful mutation silent.
|
||||
|
||||
## 3. Command registrations & permissions
|
||||
## Companion-plugin integration
|
||||
|
||||
Commands are declared in `src/main/resources/plugin.yml` (no `aliases`, no
|
||||
`permissions:` block, and no per-command `permission:` — so **every command is
|
||||
available to every sender with no permission gating**). Each is wired to an
|
||||
executor in `ScoreKeeperPlugin.onEnable()`.
|
||||
Score Keeper declares no plugin dependencies of its own. A companion that requires
|
||||
it should compile against the matching jar as a provided/compile-only dependency,
|
||||
and declare `depend: [ScoreKeeper]` in its own Bukkit-style manifest so it loads
|
||||
after Score Keeper. For optional integration, use `softdepend` and handle absence
|
||||
or disabled state explicitly.
|
||||
|
||||
Argument-resolution idiom shared by every handler:
|
||||
`boolean rcon = !(sender instanceof Player);` — an RCON caller has no self
|
||||
context, so the "target = self" shortcut is unavailable and a `<playerName>`
|
||||
must be supplied.
|
||||
There is no ServicesManager registration or standalone API module. Obtain the
|
||||
enabled plugin by ID and check its type, for example during the companion's enable:
|
||||
|
||||
`<playerName>` is resolved with `server.getPlayerExact(name)` — an **exact,
|
||||
case-sensitive lookup of currently-online players only**. Score operations
|
||||
therefore apply to **online players**, and an unknown/offline name yields a
|
||||
"Can't find a player with that name" error (except where noted).
|
||||
```java
|
||||
Plugin candidate = getServer().getPluginManager().getPlugin("ScoreKeeper");
|
||||
if (!(candidate instanceof ScoreKeeperPlugin scoreKeeper) || !candidate.isEnabled()) {
|
||||
getLogger().severe("Score Keeper is required but is not enabled.");
|
||||
getServer().getPluginManager().disablePlugin(this);
|
||||
return;
|
||||
}
|
||||
```
|
||||
|
||||
### Reference table — command → handler class → effect on score data
|
||||
Imports for this example are `org.bukkit.plugin.Plugin` and
|
||||
`com.majinnaibu.minecraft.plugins.scorekeeper.ScoreKeeperPlugin`. Keep the
|
||||
reference for your integration lifecycle, not as a global singleton.
|
||||
Do not shade a second copy of Score Keeper into the companion jar.
|
||||
|
||||
| Trigger (command) | Usage | Handler class | Delegates to | Effect on score data |
|
||||
|---|---|---|---|---|
|
||||
| `score-get` | `/score-get [player]` | `ScoreGetCommand` | `ScoreKeeperPlugin.getScore(Player)` → `getPlayerScore` | **Read only.** Returns the player's current score. Side effect: lazily registers the player at `0` if unseen. No persistent change. |
|
||||
| `score-add` | `/score-add [player] <amount>` | `ScoreAddCommand` | `ScoreKeeperPlugin.addScore(Player,int)` | `score = old + amount` (integer `amount` in `[1..]`). |
|
||||
| `score-subtract` | `/score-subtract [player] <amount>` | `ScoreSubtractCommand` | `ScoreKeeperPlugin.subtractScore(Player,int)` | `score = old - amount` (can go negative). |
|
||||
| `score-reset` | `/score-reset [player]` | `ScoreResetCommand` | `ScoreKeeperPlugin.resetScore(Player)` | `score = 0` (writes 0; key created if absent). |
|
||||
| `score-archive` | `/score-archive [player]` | `ScoreArchiveCommand` | *nothing* | **No state change.** Handler prints `"archive command unimplemented"`. It does **not** call `ScoreKeeperPlugin.archiveScore(...)` — see §5. |
|
||||
### Public operations
|
||||
|
||||
### Command behaviour details
|
||||
| Area | Methods |
|
||||
| --- | --- |
|
||||
| Bucket definition | `createBucket(id, singular, plural, initialValue[, ScoreReporting])`, `getBucket(id)`, `getBuckets()` |
|
||||
| Active selection | `getPlayerBucket(Player)`, `switchPlayerBucket(Player, id)`, `switchAllPlayers(id)` |
|
||||
| Score CRUD | `getScore(Player[, id])`, `setScore(Player[, id], score)`, `addScore(Player[, id], amount)`, `subtractScore(Player[, id], amount)`, `resetScore(Player[, id])` |
|
||||
| Archives | `archivePlayerScore(Player)`, `archiveBucketScores(id)`, `archiveAllScores()`, `getScoreArchives()`, `getScoreArchive(archiveId)` |
|
||||
| Compatibility wrapper | `archiveScore(Player)` delegates to player archive creation but discards the returned ID |
|
||||
| Runs | `startTargetScoreRun(id, topN, resetScores, targetScore)`, `startTimedScoreRun(id, topN, resetScores, Duration)`, `startUntilDisabledScoreRun(id, topN, resetScores)`, `stopHighScoreRun(id)`, `hasActiveHighScoreRun(id)` |
|
||||
| Messaging/logging | `sendMessage(CommandSender, Component)`, `logInfo`, `logWarning`, `logError` |
|
||||
|
||||
- **Sender vs. target.** Single-arg form means "operate on the invoking player"
|
||||
(`split.length == 1` → `targetPlayer = sender`). Two-arg form means
|
||||
`<playerName> <amount>` (add/subtract) or `<playerName>` (get/reset). For an
|
||||
RCON sender, the single-arg form is treated as missing a target and prints
|
||||
usage instead.
|
||||
- **Amount parsing.** `score-add`/`score-subtract` require an integer
|
||||
`amount`; a non-integer prints `"amount must be an integer"`.
|
||||
- **Error/usage messaging.** `echoError` (red) and `echoUsage` (colour-coded)
|
||||
differ between player and RCON call sites (`/score-add` vs `score-add`).
|
||||
All handlers `return true` (command handled).
|
||||
- **Permissions.** None declared → no operator/permission requirement; any
|
||||
player or RCON can run them.
|
||||
The bracket notation above describes overloads, not literal Java syntax.
|
||||
`getBucket` and `getScoreArchive` return null when unknown; mutating/score methods
|
||||
validate bucket existence and throw `IllegalArgumentException` for invalid
|
||||
operations. Do not swallow errors or report success after a failure.
|
||||
Bucket maps and archive snapshots exposed by getters are immutable copies/views.
|
||||
|
||||
---
|
||||
Example explicit-bucket award, with imports for `ScoreReporting` and `Player`:
|
||||
|
||||
## 4. Scheduled tasks / tick-based logic
|
||||
```java
|
||||
if (scoreKeeper.getBucket("event") == null) {
|
||||
scoreKeeper.createBucket("event", "point", "points", 0, ScoreReporting.PLAYER);
|
||||
}
|
||||
scoreKeeper.addScore(player, "event", 10);
|
||||
```
|
||||
|
||||
**None.** Confirmed by absence of `getScheduler()`, `runTask`,
|
||||
`BukkitRunnable`, `BukkitTask`, `scheduleSync*`, or any periodic/repeating
|
||||
logic. ScoreKeeper runs no background or tick-driven work.
|
||||
Only create a shared bucket if its existing definition meets your integration's
|
||||
requirements; duplicate creation throws. Explicit-bucket scoring does not switch
|
||||
the player's active bucket.
|
||||
|
||||
---
|
||||
### Threading and ownership
|
||||
|
||||
## 5. Inter-plugin dependencies & API exposure
|
||||
All calls touching state, players, or reporting must execute on Paper's main
|
||||
server thread. The plugin's `LinkedHashMap` state and read-modify-write operations
|
||||
are not synchronized. Marshal asynchronous event/work results to a synchronous
|
||||
Paper task before calling this API. Score Keeper does not provide Folia/region
|
||||
scheduler support.
|
||||
|
||||
- **Declared dependencies:** plugin.yml has no `depend`, `softdepend`, `load`,
|
||||
or `load-before` → **no declared inter-plugin coupling**.
|
||||
- **Build dependency:** the only third-party dependency is
|
||||
`io.papermc.paper:paper-api` (marked `compileOnly`, and explicitly ignored as a
|
||||
snapshot by the release plugin). No other plugin/API is referenced.
|
||||
- **Public API surface.** `ScoreKeeperPlugin` is a plain `JavaPlugin` exposing
|
||||
`public` methods that other plugins *could* call if they hold a reference:
|
||||
- `void addScore(Player, int)`
|
||||
- `void subtractScore(Player, int)`
|
||||
- `int getScore(Player)`
|
||||
- `void setScore(Player, int)` — **public but used by no command** (internal
|
||||
write path; the only writer not reachable via a command).
|
||||
- `void resetScore(Player)`
|
||||
- `void archiveScore(Player)` — **public but called by nothing**; it only logs
|
||||
a warning. The `/score-archive` command does **not** invoke it.
|
||||
- `void sendMessage(CommandSender, Component)`, `logInfo/logWarning/logError`
|
||||
- **No formal service registration.** There is no `registerService`/`asService`
|
||||
(ServiceLoader), no dedicated API artifact, and no `api:` block in plugin.yml.
|
||||
Exposure is by **public method surface only** — informal and not discoverable
|
||||
by other plugins.
|
||||
- **Persistence (unimplemented).** `onEnable` logs a warning that load-from-file
|
||||
is unimplemented; `onDisable` logs that save-to-file is unimplemented. The
|
||||
`HashMap<UUID,Integer>` is the sole state store and is **forgotten on restart**.
|
||||
Do not mutate private maps or write the YAML files from another plugin.
|
||||
Use the API so reporting, validation, target completion, and snapshots remain
|
||||
consistent. API calls change in-memory state; durability is deferred until
|
||||
Score Keeper disables successfully.
|
||||
|
||||
---
|
||||
## Verification
|
||||
|
||||
## 6. Lifecycle
|
||||
|
||||
| Hook | What it does |
|
||||
|---|---|
|
||||
| `onEnable()` | Wires the five `score-*` command executors; logs the "load not implemented" warning and an enable log line. |
|
||||
| `onDisable()` | Logs the "save not implemented" warning. **All in-memory scores are lost on shutdown.** |
|
||||
|
||||
---
|
||||
|
||||
## 7. State model (quick reference)
|
||||
|
||||
- **Store:** `private HashMap<UUID,Integer> _playerScores` on `ScoreKeeperPlugin`
|
||||
(one map field for the whole plugin).
|
||||
- **Keying:** by `Player.getUniqueId()` (UUID), so scores are per-player and
|
||||
survive name changes *within a single server run*; lost on restart.
|
||||
- **Lazy init:** any read (including `get`/`score-get`) auto-creates the key at `0`.
|
||||
- **Writers:** `addScore`, `subtractScore`, `resetScore`, `setScore`, all funneled
|
||||
through `setPlayerScore(player, value)`.
|
||||
- **Concurrency:** plain `HashMap`; safe today only because command dispatch
|
||||
runs on the server's main thread. Not thread-safe for off-thread use.
|
||||
|
||||
---
|
||||
|
||||
## 8. "Which server trigger causes which state change" — summary
|
||||
|
||||
| Trigger | State change |
|
||||
|---|---|
|
||||
| `/score-add [player] <amount>` | `_playerScores[uuid] += amount` |
|
||||
| `/score-subtract [player] <amount>` | `_playerScores[uuid] -= amount` |
|
||||
| `/score-reset [player]` | `_playerScores[uuid] = 0` |
|
||||
| `/score-get [player]` | none (reads; lazily registers at 0) |
|
||||
| `/score-archive [player]` | none (not implemented) |
|
||||
| Any Minecraft/Bukkit event (join/quit/death/etc.) | **none — no listeners exist** |
|
||||
| Server tick / scheduled task | **none — no scheduler exists** |
|
||||
| Server enable | no data change (registration + log only) |
|
||||
| Server disable | in-memory scores discarded (no persistence) |
|
||||
| `addScore`/`subtractScore`/`setScore`/`archiveScore` via the public API | same table where called; only reachable by code holding a plugin reference, not by in-game events or commands (except add/subtract/reset which do have commands) |
|
||||
There is currently no automated plugin harness or real-server test task.
|
||||
Validate load ordering, command dispatch, messages, run scheduler behavior, and
|
||||
clean-restart persistence on disposable Paper servers using
|
||||
[human-tests.md](human-tests.md). Do not assume a successful compilation verifies
|
||||
companion load order or runtime API compatibility.
|
||||
|
||||
@@ -1,23 +1,48 @@
|
||||
{
|
||||
"id": "scorekeeper",
|
||||
"title": "ScoreKeeper",
|
||||
"description": "A reusable Paper 26.2/26.3 scoring engine with named buckets, custom reporting, persistent archives, high-score runs, player commands, and a public API for companion plugins.",
|
||||
"docId": "ScoreKeeper",
|
||||
"image": {
|
||||
"url": "https://image.pollinations.ai/prompt/pixel%20art%20Minecraft%20server%20scoreboard%20with%20a%20glowing%20diamond%20and%20number%20counters%2C%20clean%20square%20game%20plugin%20thumbnail%2C%20no%20text",
|
||||
"alt": "Pixel art scoreboard with a diamond for the ScoreKeeper Minecraft plugin",
|
||||
"prompt": "Pixel art Minecraft server scoreboard with a glowing diamond and number counters, clean square game plugin thumbnail, no text",
|
||||
"width": 1024,
|
||||
"height": 1024,
|
||||
"backgroundClassName": "bg-surface"
|
||||
},
|
||||
"url": "/projects/scorekeeper",
|
||||
"tags": [],
|
||||
"source": {
|
||||
"type": "",
|
||||
"url": ""
|
||||
},
|
||||
"feedback": {
|
||||
"url": ""
|
||||
"score-keeper": {
|
||||
"id": "score-keeper",
|
||||
"title": "Score Keeper",
|
||||
"description": "A Paper 26.2/26.3 scoring engine with named buckets, custom reporting, shutdown-persisted scores and archives, high-score runs, player commands, and a main-thread API for companion plugins.",
|
||||
"docId": "Score-Keeper",
|
||||
"headerImage": null,
|
||||
"platforms": [
|
||||
{
|
||||
"name": "Paper",
|
||||
"info": "Paper 26.2 and 26.3; Java 25 required. Bukkit and Spigot servers are not supported.",
|
||||
"links": [
|
||||
{
|
||||
"label": "Download on Modrinth",
|
||||
"url": "https://modrinth.com/plugin/scorekeeper"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"image": {
|
||||
"url": "/projects/score-keeper/logo.png",
|
||||
"alt": "Score Keeper Minecraft plugin logo",
|
||||
"width": 1024,
|
||||
"height": 1024,
|
||||
"backgroundClassName": "bg-surface"
|
||||
},
|
||||
"url": "/projects/score-keeper",
|
||||
"tags": ["Open-Source", "Game", "Minecraft", "Java"],
|
||||
"source": {
|
||||
"type": "github",
|
||||
"url": "https://github.com/headhunter45/ScoreKeeper"
|
||||
},
|
||||
"feedback": {
|
||||
"type": "github-issues",
|
||||
"url": "https://github.com/headhunter45/ScoreKeeper/issues"
|
||||
},
|
||||
"features": [
|
||||
"Named score buckets with custom units, initial values, and reporting policies",
|
||||
"UUID-keyed integer scores with default and per-player bucket selection",
|
||||
"Player, bucket, and all-bucket archives with score resets",
|
||||
"Target-score, timed, and manually stopped high-score runs with top-N results",
|
||||
"Optional pre-run score snapshots and restoration",
|
||||
"YAML persistence on clean shutdown",
|
||||
"Player commands and a main-thread API for companion plugins"
|
||||
],
|
||||
"technology": ["Java 25", "Paper API", "Adventure", "Gradle", "YAML"]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,12 +1,31 @@
|
||||
# ScoreKeeper
|
||||
# Score Keeper
|
||||
|
||||
ScoreKeeper is a reusable scoring engine for Paper 26.2 and 26.3. It gives events, competitions, and companion plugins a shared language for points: named buckets can have custom singular/plural labels, initial values, reporting policies, archives, and high-score runs.
|
||||
Score Keeper is a reusable scoring engine for Paper 26.2 and 26.3. It gives events,
|
||||
competitions, and companion plugins a shared language for points: named buckets
|
||||
can have custom singular/plural labels, initial values, reporting policies,
|
||||
archives, and high-score runs.
|
||||
|
||||
The plugin is both a player-facing command system and an extension point. Administrators can start target-based, timed, or manually stopped score runs, while other plugins can create buckets, award points, archive results, and build richer game loops through the public API. Scores, assignments, runs, and archives persist across server restarts. Bukkit and Spigot servers are not supported.
|
||||
The plugin is both a player-facing command system and an extension point.
|
||||
Administrators can start target-based, timed, or manually stopped score runs,
|
||||
while other plugins can create buckets, award points, archive results, and build
|
||||
richer game loops through the public API. Gameplay does not automatically award
|
||||
scores. Scores, assignments, active runs, and archives persist across clean server
|
||||
restarts through shutdown saves. Bukkit and Spigot servers are not supported.
|
||||
|
||||
Run standings include deterministic tie-breaking, top-N announcements, personal
|
||||
places, and optional restoration of pre-run scores. Separate archives snapshot
|
||||
player, bucket, or all-bucket scores and reset the live values.
|
||||
|
||||
## Engineering Notes
|
||||
|
||||
- Built with Gradle and Java 25 for modern Paper.
|
||||
- Uses UUID-based player identity and YAML-backed persistence.
|
||||
- Includes server-free JUnit coverage for domain rules, commands, reporting, archives, and lifecycle behavior.
|
||||
- Designed as the scoring foundation used by companion plugins such as MobScores.
|
||||
- Exposes a main-thread Java API for companion plugins; no service registration or built-in gameplay listeners.
|
||||
- Has no automated Java test coverage yet; manual pre-release scenarios are documented, with test infrastructure planned.
|
||||
- Uses the display name "Score Keeper" while retaining `ScoreKeeper` as the repository and plugin identifier.
|
||||
- Licensed under GNU AGPL v3 or later.
|
||||
|
||||
Score get/add/subtract/reset commands currently have no permission checks and can
|
||||
target online players; archive, bucket administration, and run management use
|
||||
`scorekeeper.admin`. Saves happen on disable, not every mutation, so crashes may
|
||||
lose recent state.
|
||||
|
||||
@@ -1,280 +0,0 @@
|
||||
# ScoreKeeper — Project Reference
|
||||
|
||||
> **For a developer joining the team cold.** Read top-to-bottom in ~8 minutes;
|
||||
> you'll know where to look and what's real vs. planned on day one.
|
||||
|
||||
---
|
||||
|
||||
## 1. What is ScoreKeeper?
|
||||
|
||||
ScoreKeeper is a **Paper Minecraft plugin** (Java 25, Paper/Adventure APIs) that manages player
|
||||
score tracking. It exposes five in-game/console commands (`/score-get`, `/score-add`,
|
||||
`/score-subtract`, `/score-reset`, `/score-archive`) for manual score manipulation — no events,
|
||||
no timers, no automation.
|
||||
|
||||
**State of the project:** live in-memory scores work today; the \"high-score table\" advertised
|
||||
in the README name and `/score-archive` description is **not implemented**. Persistence, ranking,
|
||||
and scoring formulas are all **future scope**. See §4 for the gap between *what exists* and
|
||||
*what is planned*.
|
||||
|
||||
---
|
||||
|
||||
## 2. Tech Stack & Build
|
||||
|
||||
| Item | Value |
|
||||
|------|-------|
|
||||
| Language | Java 21 (Gradle auto-downloads toolchain) |
|
||||
| Runtime target | Paper 26.2 and 26.3 |
|
||||
| Build tool | Gradle 8.14.3 (`gradlew`) |
|
||||
| Linting | Spotless (`googleJavaFormat()` + license header from `config/license-header.txt`) |
|
||||
| Versioning | `org.danilopianini.git-sensitive-semantic-versioning`; minimum version `0.2.1`; reads `vX.Y.Z` tags |
|
||||
| External deps | **None at runtime.** The Paper API is `compileOnly` only. |
|
||||
| CI/release entry point | Run `./gradlew spotlessCheck build`, tag the release commit (for example, `git tag -a v0.2.2 -m "Release v0.2.2"`), then rebuild to produce the stable release artifact |
|
||||
|
||||
### Build quickly
|
||||
|
||||
```bash
|
||||
./gradlew build # compiles, runs tests (none yet)
|
||||
./gradlew spotlessApply # format to project style
|
||||
./gradlew assemble # produces jar in build/libs/
|
||||
```
|
||||
|
||||
Drop the resulting jar onto a Paper server's `plugins/` directory.
|
||||
|
||||
---
|
||||
|
||||
## 3. Architecture Overview
|
||||
|
||||
### Directory layout
|
||||
|
||||
```
|
||||
├── src/main/java/com/majinnaibu/minecraft/plugins/scorekeeper/
|
||||
│ ├── ScoreKeeperPlugin.java ← entry point, onEnable/onDisable, score CRUD core
|
||||
│ └── commands/
|
||||
│ ├── ScoreGetCommand.java → /score-get [player]
|
||||
│ ├── ScoreAddCommand.java → /score-add [player] <amount>
|
||||
│ ├── ScoreSubtractCommand.java → /score-subtract [player] <amount>
|
||||
│ ├── ScoreResetCommand.java → /score-reset [player]
|
||||
│ └── ScoreArchiveCommand.java → /score-archive [player] (stub)
|
||||
├── src/main/resources/
|
||||
│ └── plugin.yml ← command manifest + main-class declare
|
||||
├── tools/bash/ & tools/powershell/ ← dev helper scripts
|
||||
├── config/license-header.txt ← Spotless license header
|
||||
├── build.gradle ← Gradle build config (above)
|
||||
├── gradle.properties ← version, group coordinates
|
||||
├── CONTRIBUTING.md ← dev env setup
|
||||
└── README.md ← user-facing command reference + notes
|
||||
```
|
||||
|
||||
### Data flow (text diagram)
|
||||
|
||||
```
|
||||
ADMIN / CONSOLE / RCON ──▶ types a /score-* command
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ 5× Score*Command.java│ executors parse args,
|
||||
│ resolves target │ resolvePlayerExact(name) (online-only)
|
||||
└──────────┬───────────┘
|
||||
│ calls
|
||||
▼
|
||||
┌──────────────────────────────┐
|
||||
│ ScoreKeeperPlugin │
|
||||
│ │
|
||||
│ addScore / subtractScore │ read-modify-write
|
||||
│ resetScore / setScore │
|
||||
│ getScore (read) │
|
||||
│ archiveScore (STUB — no-op) │
|
||||
└──────────┬───────────────────┘
|
||||
│
|
||||
▼
|
||||
HashMap<UUID, Integer> ← in RAM only
|
||||
_playerScores ← ScoreKeeperPlugin:38
|
||||
```
|
||||
|
||||
**Key architectural facts:**
|
||||
|
||||
- **Single class owns everything.** `ScoreKeeperPlugin` holds the scores map, score CRUD
|
||||
methods, logging helpers (logWarning/logInfo/logError), and the Adventure component builder
|
||||
for chat color. There is no service layer or boundary separation.
|
||||
- **No event listeners.** Zero `@EventHandler`/`Listener` registrations across the codebase.
|
||||
Game events (join, death, kill) do not affect scores. Only manual commands change state.
|
||||
- **No scheduler or tick logic.** No periodic tasks, no countdowns, no automated scoring.
|
||||
- **No permission nodes.** Every command is available to every sender (player, console, RCON).
|
||||
|
||||
### File: ScoreKeeperPlugin.java (`ScoreKeeperPlugin`)
|
||||
|
||||
- `main` class in `plugin.yml` (Paper plugin entry point)
|
||||
- `HashMap<UUID, Integer> _playerScores` at line 38 — the sole score store
|
||||
- `onEnable()` (line 52): wires five command executors, logs \"load not implemented\" warning
|
||||
- `onDisable()` (line 46): logs \"save not implemented\" warning — scores lost on shutdown
|
||||
- Score CRUD methods: `addScore`, `subtractScore`, `resetScore`, `setScore`, `getScore`,
|
||||
`archiveScore` (lines 67–91, 76–86, 72–74)
|
||||
- Private helpers: `getPlayerScore(Player)` (get-or-create at 0), `setPlayerScore(Player,int)`
|
||||
|
||||
---
|
||||
|
||||
## 4. Domain Model & Scoring Logic
|
||||
|
||||
### 4.1 What exists today (REAL — in code)
|
||||
|
||||
| Aspect | Detail | Source |
|
||||
|--------|--------|--------|
|
||||
| Score model | Single `int` per player, keyed by UUID | `ScoreKeeperPlugin:38` |
|
||||
| Storage container | `HashMap<UUID, Integer>` on plugin instance | same file |
|
||||
| Default value | `0` — lazy-created on first map access | `getPlayerScore:100-106` |
|
||||
| Live only | **No persistence.** Scores erased on server restart | `onEnable:59`, `onDisable:47` |
|
||||
| Scoring direction | Any integer (negatives allowed, no floor) | add/subtract are raw `+`/`-` |
|
||||
| Recording method | Manual commands only — `/score-add`, `/score-subtract` | command executors |
|
||||
| Auto-scoring | **None** — no events, no timers | proven by grep across src/ |
|
||||
| Permissions | **None declared.** All commands open to all senders | `plugin.yml`, no permission guard in code |
|
||||
|
||||
### 4.2 Open Score Lifecycle (what exists + what is planned)
|
||||
|
||||
```
|
||||
Stage 1. First access — getPlayerScore() auto-creates key at 0 [REAL]
|
||||
2. Admin runs /score-add player N or /score-subtract [REAL]
|
||||
3. Player accumulates points over the session [REAL]
|
||||
4. Read via /score-get (read-only, lazily registers) [REAL]
|
||||
5. Server restart — scores LOST on shutdown [REAL]
|
||||
6. Intended: /score-archive freezes score → table [GAP ✓ not built]
|
||||
7. Intended: high-score table display command [GAP ✓ not built]
|
||||
```
|
||||
|
||||
### 4.3 The "high-score table" — status
|
||||
|
||||
| Feature | Status | Details |
|
||||
|---------|--------|---------|
|
||||
| `/score-archive` | **Stub** | Command prints \"archive command unimplemented\"; `archiveScore()` method only logs, never writes a table or resets the player's score |
|
||||
| Persistence (save) | **Not built** | `onDisable()` is a TODO stub — map discarded at shutdown |
|
||||
| Persistence (load) | **Not built** | `onEnable()` is a TODO stub — map always starts empty `{}` |
|
||||
| Sorting / ranking | **Not coded** | No sort, no tie-breaking, no entry cap, no decay logic exists |
|
||||
| Scoring formulas | **Not coded** | Scores are plain integer accumulators (`Σ(adds) − Σ(subtracts)`) |
|
||||
|
||||
**Design decisions to be made (none answered by code today):**
|
||||
|
||||
- Storage format for the table (YAML per Bukkit convention; JSON? SQLite?)
|
||||
- What an entry looks like (name + score + timestamp? name is not stored with score today)
|
||||
- Sort order and tie-breaking strategy
|
||||
- Max entries / leaderboard cap
|
||||
- Whether `/score-archive` also resets the live score (README says it does)
|
||||
|
||||
---
|
||||
|
||||
## 5. Plugin Integration & Reference Table
|
||||
|
||||
### 5.1 Command → Handler → Effect on score data
|
||||
|
||||
| Trigger | Usage | Handler | Effect |
|
||||
|---------|-------|---------|--------|
|
||||
| `/score-get [player]` | Self or other | `ScoreGetCommand.java:38-84`, delegated to `getScore → getPlayerScore` | **Read-only.** Returns integer. Lazily creates entry at `0` if unseen. |
|
||||
| `/score-add [player] <N>` | Self (omit name) or target others | `ScoreAddCommand.java` | `score += N`. Amount must parse as int. No direction validation (negative N still adds). |
|
||||
| `/score-subtract [player] <N>` | Same | `ScoreSubtractCommand.java` | `score -= N`. No minimum clamping; negatives freely produced. |
|
||||
| `/score-reset [player]` | Same | `ScoreResetCommand.java` | `score = 0`. Key created at `0` if absent. |
|
||||
| `/score-archive [player]` | Same | `ScoreArchiveCommand.java` | **No-op.** Prints \"archive command unimplemented\". Does NOT call the `archiveScore()` method. |
|
||||
|
||||
### 5.2 Shared behavior details
|
||||
|
||||
Every executor follows this pattern:
|
||||
|
||||
1. Parse arguments — if `split.length == 1` and sender is a player, target = self (RCON/console
|
||||
requires an explicit `<playerName>` or prints usage).
|
||||
2. Resolve target player via `server.getPlayerExact(name)` — **exact, case-sensitive, online-only.**
|
||||
3. Call the corresponding `ScoreKeeperPlugin` method.
|
||||
4. Echo color-coded result; return `true`.
|
||||
|
||||
### 5.3 Inter-plugin / public API surface
|
||||
|
||||
`ScoreKeeperPlugin` exposes these public methods that other plugins *could* call if they hold a reference
|
||||
(but there is **no formal service registration**):
|
||||
|
||||
| Method | Visibility | Called by commands? | Notes |
|
||||
|--------|------------|---------------------|-------|
|
||||
| `addScore(Player, int)` | `public` | Yes (`/score-add`) | Read-modify-write on `_playerScores` |
|
||||
| `subtractScore(Player, int)` | `public` | Yes (`/score-subtract`) | Same pattern |
|
||||
| `getScore(Player)` | `public` | Yes (`/score-get`) | Wrapper around `getPlayerScore` |
|
||||
| `setScore(Player, int)` | `public` | **No** | Internal write path only; not hooked to any command |
|
||||
| `resetScore(Player)` | `public` | Yes (`/score-reset`) | Sets to `0` |
|
||||
| `archiveScore(Player)` | `public` | **No** | Only logs a warning; never called by the archive command |
|
||||
|
||||
### 5.4 Concurrency note
|
||||
|
||||
The map is a plain `HashMap`. Safe because Paper dispatches commands on the server's single main
|
||||
thread — but it is **not safe for off-thread use**. Any future event-driven scoring that runs
|
||||
asynchronously could corrupt state via non-atomic read-modify-write.
|
||||
|
||||
---
|
||||
|
||||
## 6. Configuration Reference
|
||||
|
||||
| File | Format | Purpose |
|
||||
|------|--------|---------|
|
||||
| `plugin.yml` | YAML (Bukkit manifest) | Declares main class, api-version, five commands + descriptions/usage strings |
|
||||
| `build.gradle` | Gradle Kotlin (Groovy DSL) | Dependencies, task config, release/spotless settings |
|
||||
| `gradle.properties` | Properties | Project version and group coordinates (for Maven publishing) |
|
||||
| **No `config.yml`** | — | ScoreKeeper has **no player-editable configuration**. |
|
||||
| **No `permissions:` block** | — | No permission nodes declared; all commands are open. Plans say \"permissions coming after archive works.\" |
|
||||
|
||||
---
|
||||
|
||||
## 7. Running & Testing Locally
|
||||
|
||||
### Build
|
||||
|
||||
```bash
|
||||
./gradlew assemble # produces ScoreKeeper.jar in build/libs/
|
||||
```
|
||||
|
||||
### Run locally (Paper server)
|
||||
|
||||
1. Download Paper 26.2 or 26.3 from `https://papermc.io`
|
||||
2. Copy the built jar into `plugins/`
|
||||
3. Start the server, verify onEnable logs:
|
||||
```
|
||||
[ScoreKeeper] ScoreKeeper version X.Y.Z is enabled.
|
||||
[ScoreKeeper] Unable to load scores from file. This feature is not implemented yet.
|
||||
```
|
||||
|
||||
### Commands (in-game or via RCON/console)
|
||||
|
||||
| Test scenario | Command | Expected output |
|
||||
|--------------|---------|-----------------|
|
||||
| Check own score | `/score-get` | \"Your score is 0\" (creates entry at 0) |
|
||||
| Add points to self | `/score-add 10` | \"You gained 10 points! Now have 10.\" |
|
||||
| Subtract from self | `/score-subtract 5` | \"You lost 5 points! Now have 5.\" |
|
||||
| Check another player | `/score-get PlayerName` | \"PlayerName's score is N.\" (must be online) |
|
||||
| Reset own score | `/score-reset` | \"Your score has been reset to 0.\" |
|
||||
| Archive (stub) | `/score-archive` | \"archive command unimplemented\" |
|
||||
|
||||
### Tests
|
||||
|
||||
- **No unit/integration tests exist yet.** `./gradlew test` runs an empty suite. Consider
|
||||
adding tests for `ScoreKeeperPlugin`'s private `Player` score state mocking in a future task.
|
||||
|
||||
---
|
||||
|
||||
## 8. Where to Look First
|
||||
|
||||
| I want to understand… | Go to |
|
||||
|----------------------|-------|
|
||||
| The entire live data model | `ScoreKeeperPlugin:38` — one `HashMap<UUID, Integer>` field |
|
||||
| How scores change (write path) | `addScore(/:67-70)`, `subtractScore(/:88-91)`, `setPlayerScore(/:108-110)` |
|
||||
| How a player is looked up | `getPlayerExact(name)` online only — see any `*Command.java` line ~50 |
|
||||
| First-time-player behavior | `getPlayerScore(/:100-106)` — auto-inserts `0` on first access |
|
||||
| High-score / archive table | **Does not exist.** See `archiveScore(/:72-74)` stub; design decisions in §4.3 |
|
||||
| Persistence (save/load) | `onDisable(/:47)`, `onEnable(/:59)` — both TODO, nothing writes to disk |
|
||||
| What's declared/intended but not wired | `plugin.yml:18-20` (`/score-archive`), `README.md:11` and README notes |
|
||||
| Command implementations | `commands/Score*Command.java` (all 5 handlers) |
|
||||
| Build/runtime config | `build.gradle`, `plugin.yml`, `gradle.properties` |
|
||||
| Dev env / CONTRIBUTING | `CONTRIBUTING.md` |
|
||||
---
|
||||
|
||||
## Appendix: Risk Summary
|
||||
|
||||
| # | Issue | Impact | Section |
|
||||
|---|-------|--------|---------|
|
||||
| 1 | **Data loss on restart** — no save/load implemented | Every server boot wipes all scores (§4.1) | §4.1 |
|
||||
| 2 | **No permissions** — any player can self-add points | Integrity of scoring is unenforceable today (§5.2) | §5.2 |
|
||||
| 3 | **Race condition on add/subtract** — non-atomic read-modify-write on plain `HashMap` | Corrupt state if future event-driven scoring runs async (§5.4) | §5.4 |
|
||||
| 4 | **No `int` overflow safety** — Java wrapping semantics apply | Undetectable score corruption near ±2.1 billion | §4.1 |
|
||||
| 5 | **Name lookups online-only & case-sensitive** | Can't target offline players; \"Alice\" ≠ \"alice\" (§5.2) | §5.2 |
|
||||
114
docs/projects.schema.json
Normal file
114
docs/projects.schema.json
Normal file
@@ -0,0 +1,114 @@
|
||||
{
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"title": "Projects",
|
||||
"description": "Project metadata keyed by the project route slug.",
|
||||
"type": "object",
|
||||
"patternProperties": {
|
||||
"^[a-z0-9]+(?:-[a-z0-9]+)*$": { "$ref": "#/definitions/project" }
|
||||
},
|
||||
"additionalProperties": false,
|
||||
"definitions": {
|
||||
"image": {
|
||||
"type": "object",
|
||||
"required": ["url", "width", "height"],
|
||||
"properties": {
|
||||
"url": {
|
||||
"type": "string",
|
||||
"description": "Public asset path or remote image URL. A blank header image URL falls back to image.",
|
||||
"pattern": "^(\\s*|/[^/].*|https?://.+)$"
|
||||
},
|
||||
"alt": { "type": "string" },
|
||||
"prompt": { "type": "string" },
|
||||
"name": { "type": "string" },
|
||||
"width": { "type": "integer", "minimum": 1 },
|
||||
"height": { "type": "integer", "minimum": 1 },
|
||||
"backgroundClassName": { "type": "string" }
|
||||
},
|
||||
"additionalProperties": false
|
||||
},
|
||||
"projectLink": {
|
||||
"type": "object",
|
||||
"required": ["url"],
|
||||
"properties": {
|
||||
"type": { "type": "string" },
|
||||
"url": { "type": "string", "pattern": "^(\\s*|https?://.+)$" }
|
||||
},
|
||||
"additionalProperties": false
|
||||
},
|
||||
"platform": {
|
||||
"type": "object",
|
||||
"required": ["name"],
|
||||
"properties": {
|
||||
"name": { "type": "string", "pattern": "\\S" },
|
||||
"info": { "type": "string" },
|
||||
"links": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": ["label", "url"],
|
||||
"properties": {
|
||||
"label": { "type": "string", "pattern": "\\S" },
|
||||
"url": {
|
||||
"type": "string",
|
||||
"format": "uri",
|
||||
"pattern": "^https?://.+"
|
||||
}
|
||||
},
|
||||
"additionalProperties": false
|
||||
}
|
||||
}
|
||||
},
|
||||
"additionalProperties": false
|
||||
},
|
||||
"project": {
|
||||
"type": "object",
|
||||
"required": ["id", "title", "description", "tags"],
|
||||
"properties": {
|
||||
"id": { "type": "string", "pattern": "^[a-z0-9]+(?:-[a-z0-9]+)*$" },
|
||||
"title": { "type": "string", "pattern": "\\S" },
|
||||
"description": { "type": "string", "pattern": "\\S" },
|
||||
"docId": { "type": "string", "minLength": 1 },
|
||||
"image": { "$ref": "#/definitions/image" },
|
||||
"headerImage": {
|
||||
"description": "Optional detail-page logo override. Omit, set to null, or use a blank URL to fall back to image. Listing cards continue to use image.",
|
||||
"anyOf": [{ "$ref": "#/definitions/image" }, { "type": "null" }]
|
||||
},
|
||||
"status": { "type": "string" },
|
||||
"platforms": {
|
||||
"type": "array",
|
||||
"items": { "$ref": "#/definitions/platform" }
|
||||
},
|
||||
"url": {
|
||||
"type": "string",
|
||||
"pattern": "^/projects/[a-z0-9]+(?:-[a-z0-9]+)*$"
|
||||
},
|
||||
"tags": {
|
||||
"type": "array",
|
||||
"items": { "type": "string", "minLength": 1 },
|
||||
"uniqueItems": true
|
||||
},
|
||||
"source": {
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/projectLink" },
|
||||
{ "required": ["type"] }
|
||||
]
|
||||
},
|
||||
"feedback": { "$ref": "#/definitions/projectLink" },
|
||||
"repository": {
|
||||
"type": "string",
|
||||
"format": "uri",
|
||||
"pattern": "^https?://.+"
|
||||
},
|
||||
"features": {
|
||||
"type": "array",
|
||||
"items": { "type": "string", "minLength": 1 }
|
||||
},
|
||||
"technology": {
|
||||
"type": "array",
|
||||
"items": { "type": "string", "minLength": 1 }
|
||||
}
|
||||
},
|
||||
"additionalProperties": false
|
||||
}
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user