Our own development and testing traffic currently reaches the public bStats dashboard. Only real production servers should be counted there.
Where it stands today
MetricsReporter already has the switch: starting the server with -Dsethomestwo.metrics.disabled=true skips bStats entirely and logs one line at startup.
https://github.com/Blockframe-Studios/SetHomesTwo/blob/dev/src/main/java/com/samleighton/sethomestwo/metrics/MetricsReporter.java#L36-L66
The problem is that nothing sets it. The switch is opt-out, and the local Paper test server in ../Spigot/start.bat launches without it, so every manual in-game test session reports usage, config shape and command counts to service 33420 as if it were a real server. The same is true of any test server a second developer runs. Automated tests are already covered: ServerTestBase writes plugins/bStats/config.yml with enabled: false under the mock server, so MockBukkit never reports.
The distortion is not just an inflated server count. Dev servers exercise every command and every GUI path far more heavily than a real server does, and they run odd config combinations while a feature is being tried out, so the usage charts get pulled toward whatever we happen to be testing that week.
What to do
Give developers a launch script that sets the flag, so the flag is never something anyone has to remember.
- Commit a dev launch script to the repository, for example
dev/start-dev.bat, that deploys the newest jar from target/ and launches Paper with -Dsethomestwo.metrics.disabled=true alongside the existing heap and JDWP arguments. It is a template: the local test server lives in the sibling ../Spigot/ folder, which is not a git repository, so the tracked copy is what a developer copies in.
- Update the local
../Spigot/start.bat to pass the flag.
- Document it where contributors will see it, in the repository
CLAUDE.md dev loop section and in the workspace CLAUDE.md gotchas, both of which currently state that start.bat does not set the property and therefore does report.
Production needs no counterpart. We do not ship a start script; server owners write their own launch command and the plugin is only a jar. The property defaults to off, so any server not launched by our dev script keeps reporting exactly as it does now. There is nothing to strip out of a production script because there is no production script.
For a second developer running on a host panel where JVM arguments cannot be edited, plugins/bStats/config.yml with enabled: false is the equivalent server-wide opt-out and MetricsReporter already honors it before bStats is constructed.
Acceptance criteria
- A dev launch script is tracked in the repository and passes
-Dsethomestwo.metrics.disabled=true.
- Starting the local test server with it logs
SetHomesTwo metrics are off: sethomestwo.metrics.disabled is set. and MetricsReporter.isRunning() stays false.
- Starting a server without the flag still reports, unchanged.
- Both
CLAUDE.md files describe the dev script and no longer claim the local server reports.
Out of scope
Auto-detecting a dev build from the jar, and a config.yml key for metrics. The per-plugin opt-out was deliberately left out of the config, and inverting the default so unreleased builds stay silent is a larger change that can be raised separately if forgetting the script turns out to be a real problem in practice.
Our own development and testing traffic currently reaches the public bStats dashboard. Only real production servers should be counted there.
Where it stands today
MetricsReporteralready has the switch: starting the server with-Dsethomestwo.metrics.disabled=trueskips bStats entirely and logs one line at startup.https://github.com/Blockframe-Studios/SetHomesTwo/blob/dev/src/main/java/com/samleighton/sethomestwo/metrics/MetricsReporter.java#L36-L66
The problem is that nothing sets it. The switch is opt-out, and the local Paper test server in
../Spigot/start.batlaunches without it, so every manual in-game test session reports usage, config shape and command counts to service 33420 as if it were a real server. The same is true of any test server a second developer runs. Automated tests are already covered:ServerTestBasewritesplugins/bStats/config.ymlwithenabled: falseunder the mock server, so MockBukkit never reports.The distortion is not just an inflated server count. Dev servers exercise every command and every GUI path far more heavily than a real server does, and they run odd config combinations while a feature is being tried out, so the usage charts get pulled toward whatever we happen to be testing that week.
What to do
Give developers a launch script that sets the flag, so the flag is never something anyone has to remember.
dev/start-dev.bat, that deploys the newest jar fromtarget/and launches Paper with-Dsethomestwo.metrics.disabled=truealongside the existing heap and JDWP arguments. It is a template: the local test server lives in the sibling../Spigot/folder, which is not a git repository, so the tracked copy is what a developer copies in.../Spigot/start.batto pass the flag.CLAUDE.mddev loop section and in the workspaceCLAUDE.mdgotchas, both of which currently state thatstart.batdoes not set the property and therefore does report.Production needs no counterpart. We do not ship a start script; server owners write their own launch command and the plugin is only a jar. The property defaults to off, so any server not launched by our dev script keeps reporting exactly as it does now. There is nothing to strip out of a production script because there is no production script.
For a second developer running on a host panel where JVM arguments cannot be edited,
plugins/bStats/config.ymlwithenabled: falseis the equivalent server-wide opt-out andMetricsReporteralready honors it before bStats is constructed.Acceptance criteria
-Dsethomestwo.metrics.disabled=true.SetHomesTwo metrics are off: sethomestwo.metrics.disabled is set.andMetricsReporter.isRunning()stays false.CLAUDE.mdfiles describe the dev script and no longer claim the local server reports.Out of scope
Auto-detecting a dev build from the jar, and a
config.ymlkey for metrics. The per-plugin opt-out was deliberately left out of the config, and inverting the default so unreleased builds stay silent is a larger change that can be raised separately if forgetting the script turns out to be a real problem in practice.