ViewDistanceTweaks v2.8.2

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

Bugfix release. The first item is serious if you use never-reduce-below-players — that option could drive a struggling server straight to maximum distance.

Fixed

• never-reduce-below-players forced distances UP instead of holding a floor. It raised the target to the raw player count after the step limits and the min/max clamp had already been applied, so nothing downstream could contain it. A world with 20 players jumped from simulation distance 4 to its configured maximum of 12 in a single check — with max-increase-step: 1 — and did so at 120ms MSPT, in every adjustment mode. The more players a world held, the harder it pushed, which is exactly backwards from what an overloaded server needs.

  It is a floor now, never a lift: it can hold a decrease back, but it can no longer manufacture an increase, and it can never exceed the current distance. The documented purpose is unchanged — a world sitting at 10 with 10 players still refuses to drop below 10 under load.

• /vdt profile normal restored almost nothing, and profile switches accumulated. Profiles overwrote the config values in place with nothing to fall back on. Switching event-mode → night-mode kept every event-mode value the second profile did not happen to mention, and normal reset only the two distance caps. A server therefore stayed on its event thresholds indefinitely after the event, with nothing to indicate it; only /vdt reload recovered. Every profile-writable value is now restored before an overlay is applied, so switching is stateless and normal means what the config and the command have always claimed.

• /vdt status announced updates by string inequality. Left over from the 2.8 rewrite, which moved everything else to a numeric comparison. Since getLatestVersion() now returns the newest compatible version rather than the newest overall, any difference was reported as an update — a server on a beta build with accepted-release-types at release was told to "update" to the older release it had already passed.

• Chunk complexity sampling only ever looked in one direction. The spiral that picks sample chunks around each player derived its offset as ring - abs(dx), which is never negative, so every sample landed in the same half-plane. A hopper array one chunk in the opposite direction was invisible, and with use-complexity-weighting: true that multiplier moves real chunk budget between worlds. The spiral now walks complete rings — indices 0 to 80 cover exactly the 9×9 block around the player, all four quadrants equally.

• The auto-updater did not check where the update folder points. An empty settings.update-folder in bukkit.yml resolves to the plugins folder itself, which would have staged the download on top of the running jar instead of beside it. It now refuses and says why.

Verification

The distance calculation was executed headlessly across 577,155 parameter combinations — every adjustment mode, MSPT from 5 to 120, player counts, step sizes and option combinations — checking that view never falls below simulation distance, that both stay inside their configured bounds, that step limits hold, that profile caps are never exceeded, and that prioritize-simulation-distance never sheds view distance while simulation distance still has room. All hold.

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