Tags
Creators
Details
2.12.0-RELEASE
Compatibility
Changes
Cap view distance at what the clients actually render
Nobody sees further than their own client draws. If the highest client setting in a world is 8, a server view distance of 16 loads, ticks and pays for rings of chunks that are never sent to anyone.
The new client-view-distance-cap section caps a world's view distance at the largest value its players' clients report, plus a small headroom. It never goes below that world's min-view-distance, simulation distance follows so view >= sim still holds, and an empty world is left alone. A client that never reported a value counts as unknown rather than as a cap of zero.
Off by default. It only pays on servers whose players run low settings, and changes nothing where everyone uses 16 or more. /vdt status shows the highest client value per world when it is on.
A config upgrade that quietly did nothing
Found while building the above, and it would have affected every future option: the upgrader keeps a hand-maintained list of the sections it knows. A section missing from that list was never added to an existing config, while the config version marker was raised anyway, after which the upgrader stayed silent about it for good. The option then ran on its code default and nobody could find it in their file.
There is now a test comparing that list against the shipped config, so a new section cannot slip through again.
Shorter comments
Roughly 1700 lines of explanatory comment came out of the source. The reasoning behind each fix lives in the commit that made it; what stays in the code is the short note that keeps a line from being rewritten wrongly. No behaviour changed.
Upgrading
Replace the jar and restart. The new section is added to your existing config.yml automatically, switched off.
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:WnhSRHVs"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:X7x1kZUF:WnhSRHVs"
}

