Per-world view and simulation distance, adjusted automatically from MSPT and chunk load.
Six defects, all found by reading the code rather than from a report. Every one of them is a case where the plugin quietly did something other than what it said.
Pre-generation could charge one run's chunks to the next one, on Folia
A chunk request is asynchronous, so requests are still outstanding when a run is cancelled or finishes. The token that identifies which run a callback belongs to was read inside the task that had already been handed to the chunk's region, instead of before handing it over. On Paper that work runs inline, so the two are the same instant and the guard held. On Folia there is a real gap, and a run that ended inside it left the task reading the token of the run that came next.
Those late callbacks then decremented the new run's in-flight count past zero — which widens its batch budget — counted chunks it had not built, and released positions from its outstanding set. That set is what the saved resume point is derived from, so the new run could skip ground nobody had generated, and a restart would not notice. The probe path had always captured the token at dispatch; the generation path does now too.
This only ever affected Folia. If you are on Paper, nothing here changes for you.
/vdt status --fixed reported "disabled" while it was throttling players
The command was gated on per-player-fixed-view-distance and per-player-fixed-simulation-distance alone. AFK throttling sets its distances through exactly the same per-player machinery, so a server running only afk-player-throttling had players actively overridden while the one command whose job is to show that answered "this feature is disabled" and listed nothing at all.
The rows were already written for it — each entry records whether it came from a permission or from the throttle, and the output has a line for both — only the gate never let anyone reach them. This is the same shape as the sweep bug fixed in 2.7.1: a feature gated on an unrelated flag.
/vdt pregen pause did nothing to an auto-paused run, and said it had worked
pause() returned early whenever the run was paused at all. That also covers the automatic pause the engine sets for players being online, MSPT over the limit, or free heap under the floor. So typing the command during any of those changed nothing, the reply still said "paused", and the moment the blocker cleared the engine lifted its own pause and the run carried straight on.
An operator pause is now what it claims to be: it takes over an automatic one, and only a pause somebody already set by hand is left alone. /vdt pregen stop never had this problem.
Idle pre-generation rebuilt the same area forever
When an automatic run finished, the progress file was deleted and nothing was left on record saying the work was done. The next pass over an empty server therefore started the whole thing again on the same spawn centre and the same radius, and kept doing it for as long as nobody logged in.
Every lap re-probes the entire area, and every probe pulls its chunk into memory — 251,001 of them at the default radius of 250. Nothing reported it, because each individual lap looked like an ordinary run.
A completed automatic run is now recorded in pregen-done.json next to config.yml, and the trigger checks it against the area the config is currently asking for. Raising idle-pregeneration.radius, or pointing the feature at a different world, is new work and still runs; deleting the file starts the old area over. Manual /vdt pregen start runs are not recorded and are never blocked by it.
Smaller things
The chunk-complexity weigher keeps two maps keyed by world name. forgetWorld() cleared the engine's own six when a world unloaded but not those, so a server that creates and discards worlds at runtime — minigame arenas, per-player plots — kept an entry per world for the lifetime of the process.
Predictive pre-loading drops its stored player positions when the MSPT or memory gate holds it back. Speed is measured as the distance since the last sample divided by one tick interval, so keeping the samples across a pause meant the first cycle afterwards charged the entire pause against a single interval: somebody who had walked off and stopped read as flying, along a path they had already finished.
Startup grace measures its end from the current tick instead of from tick zero. That was only correct for the one caller there is today, and silently wrong for any other.