Biome Cleaner

Cleanup silently didn't run on modpacks using fast biome-generation mods. Reported on a 222-mod Fabric modpack running Wilder Wild, Bloom, and zfastnoise: Wilder Wild's dying_forest was generating as tiny single-quart islands and the cleaner was leaving them in place. On modpacks that include zfastnoise (or other performance mods that swap Minecraft's biome-creation step for a faster version), the cleaner was being skipped entirely — installed and loaded, but never actually cleaning anything. The symptom was that small biome patches stayed exactly where they were after world generation; running /biomecleaner inspect on one of them reported "Chunk seen by cleaner: NO" even on a freshly-generated chunk. The mod now hooks one step higher up in the chunk-generation pipeline, at the point all the fast-noise mods, C2ME's parallel worldgen, and vanilla all converge — so cleanup runs regardless of which mod is doing the biome-fill. If you were using config/zfastnoise.mixin.toml's [mixin.perf] biome = false line as a workaround, you can flip it back to true. No effect on default-config worlds or on modpacks without those perf mods — same biomes, same seeds.

Tiny inland biome strips could persist when running parallel worldgen mods like C2ME. Reported on the same modpack: a 4-quart strip of minecraft:beach was visible inland inside a bloom:golden_forest region, exactly the "stranded coastal patch" the size-range rules are meant to prevent. Root cause was a precision difference between two ways Minecraft samples biome data — the cleaner's view and the actual chunk palette occasionally disagree at a handful of boundary quarts when C2ME's density-function compiler is in use. The cleaner already protects against most consequences of this disagreement, but in one specific case the disagreeing quarts could end up in the "keep" portion of an oversized-region trim while the surrounding "real" quarts ended up in the trimmed-away portion — leaving a tiny visible island of the disagreement biome. The cleaner now catches this case in both the runtime path and the warming-ahead path, and replaces the affected quarts with whatever the surrounding noise field actually wanted there. Default-config worlds without C2ME (or any other density-function-compiler mod) are unchanged — the underlying disagreement only occurs under those specific mod combinations. Same biomes, same seeds, no config changes required.

Less GC churn during chunk generation, especially with C2ME and similar parallel-worldgen mods. A second round of allocation tuning in the cleanup hot path. The cleaner now reuses the scratch buffers it builds while scanning which biomes border an oversized region — previous releases threw those buffers away after every region — and a related internal lookup that turns noise samples into biomes is no longer creating small short-lived helper objects on every call. On the bench worlds we use for tuning, this trims roughly 185 MB of garbage off a representative chunk-generation run, and worst-case chunk generation time (the slowest few chunks per hundred) drops by about 17% versus 1.1.5. In practice: fewer noticeable hitches when flying into unexplored terrain and less work for the GC overall. Single-player vanilla setups see a smaller but still positive change. No effect on the biomes the cleaner produces — same world, same output, just less overhead.

Cache size auto-tuning now floors at 128 MB on heaps of 6 GB or more. A small follow-up to the heap-scaled cache curve introduced in 1.1.5. With auto-sizing, a 6 GB heap used to land at about 122 MB of cache budget — slightly under the pre-1.1.5 fixed default of 128 MB. The auto curve now floors at 128 MB whenever your allocated heap is 6 GB or larger, so anyone running on auto-sizing with a generous Minecraft allocation is guaranteed at least the same cache they'd have had on a default 1.1.4 install. Heaps below 6 GB are unchanged, and any explicit cacheMemoryMB value already set in config/biome-cleanup/advanced.json is still respected exactly as before.