Tags
Creators
Details
2.9.4-BETA
Compatibility
Changes
ViewDistanceTweaks v2.9.4-BETA
Dynamic view distance and simulation distance adjustment per world, driven by what your server can actually carry at that moment.
Three fixes to how a pre-generation run accounts for itself, one to what /vdt history says a decrease was for, and a readable operating-system chart.
Fixed
-
Chunks from a finished run were charged to the next one. Chunk requests are asynchronous, so some are always still outstanding when a run is cancelled or completes. Nothing reset the in-flight counter and the callback counted unconditionally, so those late arrivals landed on whichever run came after: it reported terrain it had never built, and the counter could fall below zero — which widened the next run's batch budget past what the config allows. Each run now carries a token, and callbacks that outlive their run are dropped.
-
The progress file was trusted as written. A radius beyond the configured maximum — an old file kept after you lowered the limit, or one edited by hand — resumed a run that
/vdt pregen startwould have refused outright. The same bounds apply now however a run begins. -
An idle server asked the disk for the progress file several times a second. The automatic trigger called it on every pass, forever, to be told "no" each time. It looks once.
-
/vdt historyblamed tick load for changes that had nothing to do with it. A server idling at 1.9ms loggeddecrease (mspt=1.9, mode=reactive)while dropping every world from 10 to 6. The change was correct — the worlds sat above the maximum inconfig.ymland were brought into range — but on an idle server that line reads as a malfunction, and the history exists precisely to answer "why is my view distance 6". It now names the bound that was exceeded, and only for the value that actually exceeded it:above the configured maximum (sim 10 > 6, view 10 > 8) — brought into range
Added
- A readable Operating System chart on bStats. The built-in one drills down on
os.version, which on Linux is the raw kernel string — so 90% of servers scatter across roughly 94 slices, the largest holding under 10%, while Windows sits tidily under "Windows 11". That chart is built by bStats and cannot be changed from a plugin, so this adds one beside it keyed on the kernel series:6.8.0-137-genericand6.8.0-124-genericare two slices in the old chart and one population in reality. Unrecognised version strings are passed through rather than dropped.
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
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:X7x1kZUF:RDMdGxJ2"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:X7x1kZUF:RDMdGxJ2"
}

