Links
Tags
Creators
Details
All versions
1.4.2
Release
Kyokalith 1.4.22 months ago 30
Compatibility
Minecraft: Java Edition
26.2
26.1.x
Platforms
Bukkit
Folia
Paper
Purpur
Spigot
Changes
Changed
- Dirty position write-back moved off the ticking thread and batched into one transaction. A spark profile of a live 12-player server showed
DirtyPositionStore.persistaccounting for roughly 1% of server-thread wall time: every flush cycle opened a fresh JDBC connection per pending chunk and committed each one separately, so a cycle with a few hundred dirty chunks paid a few hundred file opens and a few hundredfsyncs — on the thread that ticks the world. The cycle now runs on the async scheduler (Schedulers.asyncTimer:runTaskTimerAsynchronouslyon Spigot/Paper,AsyncScheduler.runAtFixedRateon Folia) and writes the whole batch through a single connection and a single transaction.- Nothing about persistence guarantees was relaxed. A dirty flag that fails to land re-opens the cover-and-dig exploit, so the same data is still written on the same cadence — only the thread and the batching changed. A failed batch (e.g.
SQLITE_BUSY) falls back to the original per-chunk path, preserving the "one bad chunk must not skip the rest of the cycle" guarantee that has held since 1.x; anything still failing is requeued for the next cycle. - Folia/threading safety. The flush task touches no Bukkit API.
DirtyPositionStore's shared state was already built on concurrent collections; the write paths (flush,flushAll,clearEpoch) are now additionally serialized by an internal lock.clearEpochmatters specifically here: it and the flush used to be implicitly mutually exclusive because both ran on the main thread, and without the lock an in-flight batch could write back an epoch that NatureRevive had just cleared. The finalflushAllinonDisablewaits for an in-flight cycle, keeping PlugMan hot-swaps safe.
- Nothing about persistence guarantees was relaxed. A dirty flag that fails to land re-opens the cover-and-dig exploit, so the same data is still written on the same cadence — only the thread and the batching changed. A failed batch (e.g.
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:hBIX7vSw:o2SMkph8"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:hBIX7vSw:o2SMkph8"
}
