ViewDistanceTweaks v2.9.2-BETA

Dynamic view distance and simulation distance adjustment per world, driven by what your server can actually carry at that moment.

Update if you use /vdt viewdistance or /vdt simulationdistance. A value above 32 did not just fail — it stopped the plugin until the next reload.

Fixed

• An out-of-range distance stopped the engine. /vdt viewdistance 53 was handed straight to World#setViewDistance, which accepts only 2 to 32, and threw. The command checked the lower bound and never the upper one.

  The throw was the smaller half of it. The override is registered before it is applied, so the rejected value stayed in the map: the next check cycle re-applied it, threw again, and because that call sits inside the tick handler it took everything queued behind it with it — override expiry, per-player overrides and every remaining world check. The plugin was effectively dead until /vdt reload cleared the override, with only a stack trace to say so.

  Two more doors led to the same place. Per-world min/max-view-distance, min/max-simulation-distance and the startup-grace values were all read with a lower bound only, so a typo in config.yml reached the same setter from inside the check cycle. The clamp those needed already existed and was applied to the AFK values, the chunk-generation emergency distance and the profile caps — the per-world settings simply never used it.

  applyDistances() now clamps as a last resort before the Bukkit setters, so no caller can put the engine in that state again. The command itself refuses an out-of-range value outright instead of clamping, so you are told what happened rather than quietly getting a different number than you typed.

• The error message for an unparseable value said the opposite of what was wrong. Typing 53# answered "Invalid value (minimum 2)". It now reports the value back along with both bounds.

• Pre-generation tripped the safeguard that is meant to exclude it. A generated chunk reaches the tracker twice, and the pre-gen claim was consumed by the first arrival before the chunk was marked as seen — so the second arrival found no claim and counted it. Every pre-generated chunk fed the chunk-generation safeguard, which then locked distance increases and pinned view distance to the emergency value while the plugin generated terrain by itself. Only affects servers with chunk-generation-safeguard.enabled: true.

• The shipped messages.yml had fallen behind the code. Every server logged "25 message key(s) are missing" on load, fresh installs included: the whole /vdt pregen command surface, the update-download messages and help.pregen existed only as code defaults, so none of them could be customised — the keys were not in the file to edit. The advice in that line made it worse, because deleting the file returned the same incomplete copy and discarded any customisation for nothing. The file is complete again, the log names the keys it is falling back on, and the regenerate hint is honest.

• /vdt update reported the wrong version when up to date. It printed the newest version in your accepted channels, while the log line directly above it printed the installed one — the same placeholder meaning two different things in two lines from one command. On a beta build with the default accepted-release-types, the newest accepted version is an older release, so a server on 2.9.2-BETA was told "up to date (2.8.3-RELEASE)". It reports the installed version now, and says plainly when that version is ahead of anything its channels will offer.

• The pre-generation ETA could be off by a factor of a hundred. It divided the remaining chunks by a rate that blends two operations differing by two orders of magnitude: checking whether a chunk exists is a disk lookup, building one is a generation pass. A resumed run crossing terrain it had already built reported 1029 chunks/s and an ETA of 2m 20s while it was genuinely generating at 11/s with hours of work left. /vdt pregen status now shows both rates separately and bases the ETA on generation alone — and says the ETA is not known yet while the run is still only skipping, instead of inventing a number.

Under the hood

The bounds were already in the engine, respected only on the per-player path — where this exact class of bug was first noticed in 2.5, when an out-of-range permission value took that feature down. They are the same bounds for a world, and are named accordingly now. The regression test fails against the previous build with the exact message from the report.

Dependencies

• Paper 1.21.x / 26.x — required
• PlaceholderAPI — optional
• EssentialsX — optional, only for AFK detection

Support

Join our Discord: dc.gg/paperstream

Author: LucasTHCR