ViewDistanceTweaks

Six defects found by reading the code, plus one the fixes themselves would have introduced. Nothing here was reported by anyone, which is rather the point: every one of them is a case where the plugin did something other than what it said, quietly.

The config upgrader could not add an option to a block your file already had

2.8.3 taught the plugin to top up an old config.yml instead of telling you to delete it. It worked one level deep: whole top-level blocks were appended, and anything added inside a block your file already declares was invisible to it.

Measured against a real 2.6 config, that left 17 options behind — the entire chunk-complexity feature, which lives under proactive-mode-settings. Ten blocks were appended, the version marker was set to current, and the log said nothing about the seventeen it had not added. Because the marker was now current, the version check returned early on every later start too, so nothing ever mentioned it again.

Absent would have been bad enough. What made it worse: use-complexity-weighting reads false when the key is missing, so anyone who found the option in the documentation and typed it in by hand got a feature that does nothing at all — complexity-weights was missing as well, so every chunk weighed exactly 1.0, every world's multiplier came out 1.0, and /vdt status --weight reported 1.00x across the board with no explanation.

Missing options are now merged into the block that owns them, carrying their comments, at whatever indentation your file already uses, and each one is named in the log. Your own values and comments are untouched, a config.yml.bak is still taken first, and running the upgrade twice changes nothing the second time.

Updates needed two restarts, and a long-running server never saw them at all

The update check ran exactly once, when the plugin enabled. A downloaded jar is staged in plugins/update/ and installed by the next restart — so every update cost two restarts: one to notice and stage it, one to apply it. And a server that stays up for weeks never noticed anything, because its single check happened before the release existed.

There is now a re-check every six hours. The jar is already waiting whenever the server does restart, so one restart is enough. update-notify still decides whether any of this runs, and switching it off takes effect on the next /vdt reload rather than at the next restart.

The scheduler could only cancel its most recent repeating task

Found while adding the re-check above, which is the first thing this plugin ever needed a second repeating task for. The adapter kept a single task handle, so registering a second one overwrote the first, and shutdown then cancelled only the newer of the two — leaving the engine's per-tick driver running against a plugin that had just been disabled. That would have bitten anyone reloading with a plugin manager rather than restarting.

/papi info credited the wrong author

The PlaceholderAPI expansion reported EmpireBlocks — the plugin's package name, not a person — while plugin.yml names LucasTHCR. Both now come from the same place, and the test suite compares them.

Two messages said different things depending on where you read them

Every message exists twice: as a built-in default and in messages.yml. The file wins at runtime, so a line that fell behind there is what servers actually show.

help.update still advertised /vdt update long after /vdt update download existed, so the download argument was missing from the help output on every install. And status.fixed.disabled said "Both per-player override features are disabled" after AFK throttling had been added to the condition it describes — three features, two named.

The two copies are compared in the test suite now, text and all, not just checked for having the same keys.

Smaller

Messages.get() carried a comment promising it would render what it could rather than throw inside a command handler, and then threw. No call site passes a mismatched replacement list today, which is exactly why the contradiction could sit there unnoticed; the code now does what the comment always claimed.