Tags
Creators
Details
2.10.2-RELEASE
Compatibility
Changes
/vdt simulate now sees the same vetoes the engine applies
The memory safeguard and the chunk-generation lock both refuse a distance increase inside the check cycle, but neither existed in the preview /vdt simulate builds. On a server sitting under memory-safeguard.min-free-percent, the preview therefore announced an increase that the engine went on to reject — every cycle, with nothing to say why. Both now go through one shared method, so the reason the preview prints is the condition the engine acted on.
/vdt mspt has a permission of its own
It was the only subcommand falling through to the base /vdt node, while status, history and simulate each required one. It reads the same figures as /vdt status and now shares that node, so no existing grant changes meaning.
Smaller
- Removed a duplicate
update.aheadkey frommessages.yml. plugin.ymlnow says that the reload permission also covers/vdt update.
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:sPHIzK0b"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:X7x1kZUF:sPHIzK0b"
}

