Concurrent Chunk Management Engine - Forge

C2ME-Forge 0.2.0-forge.8.2 (Minecraft 1.18.2) - build 2026-10-28

The first 1.18.2 update since forge.4: forge.8.1 was never uploaded, so everything it contained is in here too (the forge.8.1 notes follow below). New in forge.8.2: the Ice and Fire startup crash, the Twilight Forest canopy crash, a set of light bugs that left players seeing wrong light with any light engine (the built-in Starlight included), and support for the new optional light engine add-on C2ME-Betterlight. World generation is unchanged.

Fixed - crashes
• Servers with Ice and Fire 2.1.13 did not start ("Critical injection failure" at mod loading): C2ME and Ice and Fire both replaced the same log call in world generation, and only one of them can. C2ME now wraps the call instead, so both work (reported by Colton)
• Twilight Forest: a canopy tree generated by two threads at once threw "Feature placement" / ConcurrentModificationException, the chunk was never generated, and the error came back when the server stopped. The tree's shared leaf list is now kept per thread

Fixed - light players see (with any light engine: the built-in Starlight, vanilla, or C2ME-Betterlight)
• Light that changed shortly after a chunk was sent (lava flowing, fire, torches placed by world generation) reached only the players who had that chunk at the very edge of their view; everyone else kept the old light until they left and came back. Light that changes within 30 seconds of a chunk's send now goes to every player who has the chunk. In our test with the built-in Starlight: 999 to 1,612 wrong light values on 4 of 6 runs before, 0 in 8 runs after
• Next to a chunk that once had 64 or more block changes in one tick, the light in the neighbouring chunks never updated for most players (Minecraft then tells clients not to light those block changes themselves). That light is now sent to everyone, and clients light those block changes too. In our test with the built-in Starlight: 3,793 wrong light values before, 0 after
• With no-tick view distance: chunks sent before their neighbours were lit kept dark or bright patches in new terrain, and blocks placed by world generation's last step (glow lichen and others) never reached players beyond the ticking range ("ghost" blocks). Both fixed (ported from upstream C2ME): in our travel test, 31,035 and 58,856 wrong values before, 55 and 4 after
• A finished chunk that was loaded again only as a neighbour of new chunks never saved the light its new neighbours shone into it (a Minecraft bug), so after a restart light seams 1-2 levels darker showed along chunk borders. These chunks are saved now: 0 of 13 test worlds had a seam, 2 of 3 without the fix
• Client crash "Getting biome" (MissingPaletteEntryException) after teleporting away and back: chunks the client should have dropped stayed in its chunk storage and were overwritten while being drawn. The client now drops them when its view moves (about 200 such chunks per return before, 0 after)

New - C2ME-Betterlight support
• C2ME-Betterlight is an optional add-on with C2ME's own light engine for 1.18.2 (a separate download, made for this exact C2ME version). Installed, it replaces the built-in Starlight; without it nothing changes. The log says which engine runs

Drop-in update, recommended for everyone on the 1.18.2 line. No config changes needed.
Support: https://discord.gg/s7BYs6Njj5

---------------------------------------------------------------------------------------------------------------
forge.8.1 notes (never uploaded on its own, included in forge.8.2):

The first 1.18.2 update since forge.4. It brings the 1.18.2 line up to date with the 1.20.1 releases forge.9.2 to forge.9.9.2: several permanent server freezes, every known way a chunk could lose blocks, chests or mods' data when it unloads, and settings in c2me.toml that did nothing. (forge.5 to forge.8 were internal builds and were never uploaded; everything they contained is in here.) World generation is unchanged.

Fixed - freezes
• Permanent server freeze while a chunk is being turned into a finished chunk, when something asks for that chunk again from inside its own loading (chunk-load and entity-join handlers do this; Dimensional Doors does it for every pocket chunk, MineColonies Compatibility on every block removal). The request now gets the chunk being loaded. Both variants (the same chunk and a different chunk) and the case where Dimensional Doors fills a pocket chunk at the very end of that step are covered. The log says "re-entrant chunk load protection is active" at startup; Canary and Radium no longer switch the protection off
• Server freeze ("a single server tick took 60 seconds") near chunks that never finish loading, when a mod's block looks at the world while its light is calculated (found on 1.20.1, reported by SleeplessDrago; 1.18.2's built-in Starlight asks blocks the same way). The light engine no longer waits for such a chunk; the block gets the chunk's blocks as they are at that moment, and the log names the code that asked. In a test that makes every chunk's lighting do this, the old behaviour froze while preparing the spawn area; forge.8.1 starts normally
• Chunk task scheduler: a lost wakeup that could stall generation, and a priority boost for chunks the server waits on that was not re-entrant
• If generation waits more than 30 seconds for a thread-unsafe mod's feature lane, the log names what holds it

Fixed - chunks losing data
• Chests, machines and other block contents could be lost when a chunk's unload save had to be retried: the retry saved the chunk after Minecraft had already emptied it. With every save forced through the retry, the code before this fix kept 2 of 64 test chests; forge.8.1 keeps 64 of 64
• A retried unload save was never written at all, and a chunk loaded again right after it unloaded could come back as its older saved version or be generated again (edits rolled back). After a 16,129-chunk pregen and a normal stop, forge.4's worlds held 16,035 and 16,032 finished chunks; forge.8.1's hold all 16,129
• When a background save failed, the "falling back to sync saving" fallback saved nothing. It now saves on the server thread: with every save made to fail on purpose, all 3,275 chunks were saved (64 of 64 test chests kept)
• Block entities that clear their data when they are removed (Copycats+ blocks, for example) were saved empty: their data is now captured on the server thread when the save is scheduled
• Mods' own per-chunk data was never saved (Mekanism, Immersive Engineering, Blood Magic, Project MMO and others use Forge's chunk-save event, which C2ME never fired). It fires again, at the same point as in Forge
• Mods' chunk-load handlers and chunk capabilities ran on C2ME's worker threads, several at once; they run on the server thread again (0 of 196 test loads off the server thread, 196 of 196 before). Compatible with Architectury

Fixed - crashes
• "IllegalArgumentException: Already scheduled" when a mod requests a chunk's load a second time while the server waits for it (Better Chunk Loading)
• Crash or hang with chunk generators that add entities from a generation thread or keep shared maps that are not thread-safe (Meulti's Backrooms). New setting threadedWorldGen.serializedChunkGenerators (default fr.meulti.mbackrooms); every other generator stays fully parallel
• /c2me notick no longer crashes when no-tick view distance was switched off

Settings
• Several c2me.toml settings had no effect on Forge and now work: threadedWorldGen.enabled, ioSystem.replaceImpl, ioSystem.async, generalOptimizations.autoSave.mode, generalOptimizations.midTickChunkTasksInterval (-1 now disables mid-tick chunk tasks, as the comment says), vanillaWorldGenOptimizations.optimizeAquifer, vanillaWorldGenOptimizations.useEndBiomeCache and ioSystem.chunkStreamVersion. The log says which settings switched something off
• A c2me.toml with a typo is kept as c2me.toml.broken-<number> instead of being replaced silently; values out of range are reported in the log; -D overrides apply to the current run only and are never written into c2me.toml
• With Valkyrien Skies installed, no-tick view distance switches itself off (ship physics only uses ticking-ready chunks)

Faster
• CPUs with 8 threads or fewer now use all of their threads for world generation (a 4-thread server runs 4 generation workers instead of 3), and the adaptive Chunky feed no longer slows a pregen down because of garbage-collection time alone while most of the heap is free (it still does when collecting takes more than half of the time). A 16,129-chunk pregen on 4 cores / 4 threads: 3:17, 3:10, 3:06 on forge.4; between 2:31 and 2:53 in six of seven runs of this code (3:34 in one)
• The adaptive Chunky feed now adjusts a pregen that is already running, not just the next one (on our test machine it ramps to 512 chunks in flight). A 16,129-chunk pregen on a 16-thread server: 1:19 and 1:22 on forge.4, 1:13 and 1:12 on this code (same session, alternating)

Diagnostics
• One log line at startup names the hardware (CPU, threads, RAM, heap, workers, Java, OS) for benchmark reports
• Crash reports and launchers point to the C2ME-Forge Discord instead of upstream C2ME's issue tracker
• Test-only switches (off unless set): -Dc2me.disableMixin.<ClassName>=true, -Dc2me.debug.forceSaveRetryChanged=true, -Dc2me.debug.failAsyncSaves=N, -Dc2me.debug.lightThreadReadsLevel=true, -Dc2me.debug.lightThreadMayWait=true