Tags
Creators
Details
2.10.8-RELEASE
Compatibility
Changes
A follow-up to 2.10.7. Two of the three fixes here repair code that shipped yesterday, in the config upgrader that 2.10.7 rewrote — both found by testing that rewrite against awkward files rather than by reading it again.
If your config.yml was correctly topped up by 2.10.7, nothing here changes for you.
The config upgrader did nothing at all on a file with Windows line endings
Java counts a carriage return as a line terminator, so the pattern matching each line left it unconsumed and failed on every single line of a CRLF file. The upgrader then found no blocks to look inside, added nothing, and reported nothing — an outcome indistinguishable from having had nothing to do.
Any config.yml last saved by a Windows editor was silently skipped by 2.10.7's whole reason for existing. The file is now read regardless of its line endings, and keeps them when it is written back.
A comment after a block's name made that block invisible to the upgrader
A block written as a value — some-option: 4 — owns no child options, and adding some would contradict the value already there, so those are deliberately left alone. A trailing comment looked exactly the same to that check: proactive-mode-settings: # my note was read as holding a value, and the entire block was skipped.
That is precisely backwards. A file somebody has annotated by hand is a file somebody has tuned, which is the one most worth topping up carefully.
Chunk complexity weights had no built-in default, so the feature could run and do nothing
Every option in this plugin falls back to its documented default when your file does not mention it. complexity-weights was the single exception: with the section absent the list of per-block surcharges stayed empty, so every chunk weighed the same, every world's multiplier came out at exactly 1.0, and use-complexity-weighting ran without changing anything — while /vdt status --weight reported a tidy 1.00x for every world.
Any config.yml written before that block existed was in that state, which is every config not yet topped up by 2.10.7. Turning the feature on did nothing and said nothing.
The thirteen shipped weights are now built in as well, so a missing section means the documented default like everywhere else. A section you have deliberately emptied still stays empty — that is an answer, not an omission — and if the feature is on with no weights at all, the log now says so instead of leaving you to wonder why nothing moved.
Under the hood
The shipped config.yml and the built-in fallbacks are now compared against each other in the test suite, option by option. They are meant to be identical — otherwise a fresh install and an upgraded one quietly behave differently, depending only on when the server was first set up — and that is now checked rather than assumed. It is what turned up the complexity-weights gap above.
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:BsSTrVfl"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:X7x1kZUF:BsSTrVfl"
}

