Links
Tags
Creators
Details
0.16.0
Compatibility
Changes
v0.16.0 — Async chunk load (stable)
0.16.0 brings the async chunk load introduced in v0.15 to a stable release: load-side POI reads moved off-thread, a thread-safety symmetry fix for the capability subsystem, and hardened shutdown paths. Async load is still off by default and opt-in (load.enabled), aimed at server owners chasing load performance who are willing to opt in. Forge 1.20.1 build only
What this version brings
Async load (PARTIAL mode) moves chunk deserialization from the main thread to a background load worker. The 0.16 cycle did three things around this path:
- Tier A async POI prefetch: the load worker reads that column's POI region bytes off-thread during deserialization, the main thread populates the cache before replay, eliminating the synchronous
tryRead().join()disk wait that used to sit on the main thread. Real production server (137 mods, 8 load workers, fast flight): main-thread POIgetOrLoaddropped from 15.0% to 0.1%, load-side main-thread cost down ~13.7% - Capability subsystem thread-safety symmetry fix: during chunk load,
LevelChunkconstruction dispatches the globalAttachCapabilitiesEventandreadCapsFromNBTtriggers third-party capability deserialization — both are the same kind of main-thread-assuming work as the already-deferredChunkDataEvent.Load. This build defers them to the main-thread replay as well, fixing a potential thread-safety hazard for mods that attach persistent capabilities to chunks under async load. The replay executes faithfully, capability data is read back as usual, no data loss - Hardened shutdown: load / save workers are now daemon threads with a JVM shutdown fallback hook, preventing another mod that throws on the shutdown event chain from hanging the whole server while BAS finishes its teardown; in-flight load tasks are also included in the shutdown drain barrier, symmetric with the save side
Verification
- Pre-release multi-angle adversarial review of the capability off-thread path + 155 unit tests (including byte-faithful replay assertions for the capability defer)
- Test-server reobf jar end-to-end: the async load worker loads spawn chunks through the capability defer + main-thread replay, zero exceptions, zero data delta
Safety and compatibility
- Lossless: capability gather and deserialization are replayed faithfully on the main thread in original order, byte-for-byte equivalent to vanilla synchronous load
- Failure fallback: a worker parse failure falls back to a main-thread vanilla read, reads disk bytes only, zero data loss
- Users without async load enabled (the default): no behavior change in the load path
Configuration ([load] section)
load.enabled(default false): master switch for async chunk load, opt-inload.asyncPoiPrefetch(default true): with async load on and PARTIAL mode, prefetch the POI region on the load worker; set false to fall back to a main-thread synchronous read if a POI-storage mod misbehaves
Upgrading
- Drop-in jar replacement. Without async load enabled (
load.enabled=false, default): no behavior change - Modpacks that attach persistent capabilities to chunks: this build fixes a thread-safety hazard for those capabilities under async load — upgrading is recommended
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:WAXR3mM5:ohIMgsDo"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:WAXR3mM5:ohIMgsDo"
}

