C2ME allowThreadedFeatures: why modded worldgen breaks

The setting

C2ME is a Fabric mod that speeds up chunk generation by spreading it across CPU cores. Inside config/c2me.toml it exposed a key called threadedWorldGen.allowThreadedFeatures, and C2ME's own source documents it clearly enough that nobody can claim they were not warned:

Whether to allow feature generation (world decorations like trees, ores and etc.) run in parallel (may cause incompatibility with other mods)

The part most write-ups get wrong is the default. It was on. The config accessor is built with getBoolean(true, false), and that method takes (boolean def, boolean incompatibleDef), so true is the default and false is only the value substituted when C2ME detects an incompatibility. The older 1.18 era config code expresses the same default with a supplier returning true.

That reframes the whole problem. This is not only a story about people who enabled a risky flag because a performance guide told them to. If threadedWorldGen.enabled was on, and it defaulted to on whenever C2ME saw at least three worker threads available, then threaded feature placement was on too.

What it actually parallelised

Almost nothing, and that is the point. In ChunkStatusUtils.getThreadingType, the structure start, structure reference, biome, noise, surface, carver and lighting stages all return PARALLELIZED with no config check at all. Exactly one stage consults the setting:

} else if (status.equals(ChunkStatus.FEATURES)) {
    return Config.allowThreadedFeatures ? PARALLELIZED : SINGLE_THREADED;
}

So turning it off never disabled C2ME's threading. It moved one stage, decoration, back onto a single thread while everything else stayed parallel. The performance cost of turning it off was always far smaller than the guides implied, and the risk of leaving it on was concentrated entirely in that one stage.

Why decoration is the dangerous stage

FEATURES is the stage that places trees, ores, plants, vegetation patches and most mod added scatter. It is also the only worldgen stage that routinely writes outside the chunk it is generating, because a tree rooted at a chunk edge has to put leaves in the neighbour.

Vanilla's feature placers are written with that in mind. Many modded ones are not. They keep mutable state on a shared feature instance, read blocks outside the region they are permitted to touch, or assume nothing else is running. None of those are bugs under single threaded vanilla generation, because single threaded generation never exposes them. Run four chunks' worth of them concurrently and you get races.

C2ME's issue tracker is full of the loud version of this. Twilight Forest worldgen crashes in issues 157 and 472 and 376, BetterEnd crashing clients and servers in issue 236, BetterNether killing a server during Chunky pregeneration in issue 247. On the NeoForge port, issue 50 describes flying through new End biomes with BetterEnd installed and reports that a "bad chunk is generated and nothing works anymore after that."

The quiet version is worse

A crash at least tells you something happened. The failure mode that costs people whole worlds is the one that does not.

When a race causes a feature to be skipped rather than to throw, generation completes normally. No exception, no warning, nothing in the log. The chunk is written to disk with whatever decoration survived, and Minecraft never revisits a chunk that has already passed the FEATURES stage. A biome comes out bare, a mod's plants are missing from half the terrain, a structure that should be there is not, and everything looks like a config problem with the content mod rather than a threading problem in worldgen.

This is why the fix is not a config flip. Setting allowThreadedFeatures = false prevents future damage and repairs nothing. Land that already generated stays exactly as it generated. The only real repair is deleting the affected region files so the chunks regenerate, which is safe for terrain nobody has built on and destructive for terrain anyone has, and which is why this is worth checking before a world gets old rather than after.

Where it stands today

The setting is gone. The c2me-threading-worldgen module exists through C2ME's ver/1.21 branch and is absent from ver/1.21.1 onward, where the parallelism work has moved into c2me-rewrites-chunk-system. If you are on a current build and cannot find the key in c2me.toml, nothing is wrong.

That leaves two groups. If you are pinned to an older Minecraft version on an older C2ME, open c2me.toml, set threadedWorldGen.allowThreadedFeatures = false, and accept that whatever already generated is what you have. If you are current, the advice you may still find in performance guides telling you to enable it is describing a setting that no longer exists.