Chunksmith

On Forge 1.20.1, a player who did not have Chunksmith could no longer join a server that did. The mod is meant to be optional on the client -- it is a server-side pre-generator, and the client half only adds distant terrain for players who want it. But since 3.x the server registered its chunksmith:lod network channel as required, so Forge's login handshake refused any client that lacked it: the player was kicked at join with "Connection closed - mismatched mod channel list". This build makes the channel optional again, so a vanilla-Forge client joins a Chunksmith Forge server exactly as it did on 2.2.3. The server is unchanged for players who do have Chunksmith -- the channel simply is not negotiated to those who do not.

This was a regression from the 3.x LOD channel and it affected Forge only. NeoForge was already correct (its channel was marked optional during the 3.1.0-beta-1 client merge) and Fabric never forced the client (its play channels are inherently permissive). Only the Forge cell was missed.

Only the Forge 1.20.1 jar changed. Every other cell is byte-for-byte identical to 3.1.0-beta-4 and is unaffected.

Fixed

• Forge 1.20.1: the LOD network channel is now optional. Both accepted-version predicates on the chunksmith:lod SimpleChannel are wrapped in NetworkRegistry.acceptMissingOr(...), which accepts the "channel absent" sentinel the FML login handshake sends for a client that does not have the channel. A bare version-equality predicate rejected that sentinel, which marked the channel required and made the server refuse the client. Mirrors the NeoForge cell's .optional().

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

Every time a player asked "what LOD terrain is near me?", the server read every region file in the store and hashed its contents -- on the main server thread. On a 340-region, 850 MB store that is 205 MB of memory allocated per request, several times a second, in blocks big enough that the garbage collector has to handle each one as a special case. A live server ran out of memory doing it, and then took 67 minutes to shut down. It is fixed: the answer is now built from each file's timestamp and size, off the main thread, and the same request allocates 18 KB -- 11,808x less -- with zero of those collector pauses where there used to be 38.

Also new: your client now notices new terrain on its own. Every few minutes it and the server compare a single small checksum; if they differ, the client pulls only what changed. You no longer have to relog, or walk somewhere, to see terrain a running pre-generation has just finished.

Read this before you update

The LOD network protocol changed (v1 -> v2). Your server and every player's client must BOTH be on 3.1.0-beta-4 or later. A mismatched pair will not exchange LOD data -- both sides refuse it, both say so in the log, and nothing else breaks (no crash, no hang, no stuck downloads) -- but the distant terrain will simply not be there. There is no way around this: the number the two sides compare to decide "do I already have this region?" is exactly the thing that had to change, and an old client asking the new question would re-download your entire LOD store every five seconds, forever. We would have traded a memory problem for a bandwidth one.

Update the server and the clients together. On the first join after updating, each client re-downloads the regions in its view radius once -- it has no record of what it can vouch for yet -- and then never again.

Fixed

• The LOD index no longer reads the store to build itself, and no longer runs on the server thread. To tell a client which regions it should have, the server used to open every region file near that player, read all of it, and CRC32 the bytes -- 205 MB of allocation per request on a real store, 74-173 ms of the tick each time, and because the buffers are multi-megabyte the JVM allocates them out of a special "humongous" path that forces a collection. Over five minutes of a player walking around, that was 38 garbage-collection pauses, all of them attributed to exactly this. It is why one server climbed to 100% memory during a pre-generation and could not save its worlds afterwards. The freshness marker for a region is now derived from its modification time and size -- which is all the question ever needed, because the question is only ever "is this the same file I already sent you?" -- and the scan runs on a background thread, one outstanding scan per player, so the tick does no I/O at all. Same request: 18 KB, under a millisecond, zero humongous allocations, zero GC pauses.
• The client was doing the same thing to its own store, and nobody ever noticed. On every index it read and hashed every region file it had, for the same reason. A server dies loudly and gets reported; a client with a big heap just stutters. It now records what the server told it about each region in a small manifest file beside the store, so the "do I already have this?" check is a lookup and one file-size stat.
• The index can no longer be unbounded in size. It was capped at 4,096 regions -- but a region can be 7 MB, so that cap permitted a ~28 GB answer. It is now capped in bytes (2 GiB), and the scan is sorted nearest-first, so if a store is bigger than the cap what a client loses is the furthest terrain, and it gets that as it walks toward it.
• A region that GREW is no longer downloaded and then thrown away. The client remembered which regions it had drawn by their coordinates alone -- which answers "have I ever drawn this?", not "have I drawn this version of it?". A pre-generation does not only create new regions; it keeps growing the ones under you, for hours. The client would notice the change, fetch the bigger file, hand it to the renderer -- and the renderer's own bookkeeping would recognise the coordinates, drop the new data on the floor, and report success. You would have watched the far ring of terrain fill in while the ground under you stayed frozen at whatever it was when you joined. Regions are now remembered by coordinate and version.
• A client on a too-old server is no longer left staring at an empty horizon in silence. If you update your client before the server updates, the old server refuses your hello and answers nothing at all -- so the client has nothing to check a version against, and it used to note the silence only at debug level. You got no terrain and no explanation. It now says so plainly, once, in the log: no LOD data is on offer here, either because this server does not run Chunksmith (perfectly normal) or because it runs a version older than 3.1.0-beta-4, and if you expected terrain then both ends need to be on the same version. It cannot tell those two cases apart -- an old server tells it nothing to tell them apart with -- so it names both instead of guessing. One line, once, and never silence.

Added

• Periodic checksum sync -- new terrain arrives while you stand still. Every 300 seconds by default, the client asks the server for a one-line summary of the LOD regions in its view (a count and a single folded checksum) and compares it with its own. If they match, that is the end of it. If they do not, it pulls the index and fetches only the difference. No relog. No walking. It costs 22 bytes out and 34 bytes back -- about 0.19 bytes per second per player -- and on the server it is roughly 86 syscalls and not one byte of file content read. One mechanism covers all three of "the server generated more", "a region I hold changed", and "I lost regions off my disk" (delete some and the next poll brings back exactly those).
• sync-interval-seconds in config/chunksmith-lod.properties (client-side; the file is written with defaults and comments on first run). Default 300. Values below 30 are clamped to 30 -- a config value is a suggestion, and a one-second poll must not become a denial of service against a server that is already busy pre-generating. No settings screen yet; that is 3.2.

Changed

• CsLodProtocol.VERSION 1 -> 2. Deliberate and unavoidable; see the notice above. The wire layout is unchanged -- what changed is the meaning of the index's freshness field (a CRC32 of the file's contents became an opaque timestamp+size token). Both ends check the version, both refuse a mismatch, and both name it in the log rather than failing quietly.
• Moving a world between machines, or restoring it from a backup, now re-sends the LOD regions once. Copying files changes their modification times without changing their contents, so every freshness token moves and connected clients re-fetch what is in their radius. That is the honest price of the fix, it is bounded, and it is once. The alternative failure -- a marker that says "unchanged" about a region that did change -- leaves a player looking at terrain that no longer exists with no mechanism that could ever correct it. A redundant download is a bandwidth bill; a stale region that is trusted is a bug you cannot see.

Notes

• This release rebuilds the eleven jars that carry the LOD feature (Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1 / 26.2 / 26.3, NeoForge 1.21.1 / 1.21.11 / 26.1 / 26.2, Forge 1.20.1). The Bukkit/Paper/Folia plugin jars and the other mod jars have no LOD code path at all, so they are unchanged and remain at 3.1.0-beta-3 -- there is nothing in this release for them to receive.
• Everything above was measured on a real 340-region / 853 MB store with a real Distant Horizons client connected and a pre-generation running: server heap 18% of an 8 GB maximum, zero full collections, zero "Can't keep up" tick warnings, and a clean 22-second shutdown in the middle of the pre-generation -- the exact situation that previously hung for over an hour.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

The Overworld was showing up in the Nether. It is not any more. If you went through a Nether portal on a Chunksmith server, the distant terrain you saw there was not the Nether -- it was the Overworld's, pushed into the Nether's sky. Grass, oceans and beaches, floating over the lava. Everything reported success while it happened. This release fixes it, on both sides.

Fixed

• Distant terrain from one dimension no longer appears in another. The client picked which dimension's LOD data to download from the FIRST dimension the server happened to list when you joined -- on any normal server, the Overworld -- and then never revisited that choice for the rest of the session. Walk through a portal and it kept downloading the Overworld's terrain and handing it to your LOD renderer, which drew it around you in the Nether. Neither Distant Horizons nor voxy checks that the terrain it is given belongs to the world you are in; they accepted it, saved it, and drew it. The client now tracks the dimension you are actually standing in, re-asks the server the moment you change dimension, and refuses to inject any record that does not belong to the level in front of it. Terrain from another dimension is never a substitute for this one's, and it is no longer treated as one.
• The Nether's own LOD data is no longer silently skipped. A second, independent bug, which would have kept the Nether empty even after the fix above. The client remembers which regions it has already drawn so a travel refresh does not re-push terrain you can already see -- but it remembered them by region coordinates ALONE. Region (0,0) is a different place in every dimension, so the moment the Overworld's (0,0) had been drawn, the Nether's (0,0) counted as "already done" and was dropped on the floor, for the whole session, without a word. Regions are now remembered per dimension, which is the only way a region coordinate means anything.
• The server no longer serves an index for a dimension you are not in. The list of regions near you is filtered by your renderer's range measured from YOUR position -- and a position only means something in a particular world. The server now answers with the dimension you are actually standing in, whatever was asked for, and says so in the log when the two differ. This alone stops an already-installed 3.1.0-beta-2 client from putting Overworld terrain in your Nether sky, since the client files and draws the data under the dimension the server names.
• Changing dimension mid-download no longer wastes the transfer. A download in flight when you step through a portal is now cancelled -- on both ends -- instead of continuing to spend your connection on a world you have left, and the regions it had not reached are re-fetched for the dimension you are in.

Notes

• The wire protocol is UNCHANGED (CsLodProtocol.VERSION is still 1). A beta-2 client and a beta-3 server interoperate, and the server-side correction above means such a client is partly fixed without updating -- but only partly (it will still skip a region whose coordinates it drew in another dimension), so please update.
• Single-dimension play -- the overwhelmingly normal case, an Overworld-only pregen and a player who never leaves it -- behaves exactly as before.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Fixes a hard crash at startup that could hit large modpacks. Chunksmith's five optional worldgen/entity diagnostic mixins are now best-effort (require = 0), so another mod that removes or overrides one of their target methods can no longer take the game down at boot. Reported on NeoForge 1.21.1 in a ~400-mod pack.

Chunksmith's core behavior is unchanged - the functional mixins (keep-awake, chunk housekeeping, entity-retention, client housekeeping) stay hard-required, so a genuine problem there still fails loudly.

2.2.1 (2026-07-05) -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked via scripts/_metadata.py (previously the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.
• Internal docs folder renamed .docs -> docs (gitignored). README build-script references corrected to scripts/build-*.ps1.

2.1.3

Minecraft 26.3-snapshot-2 support

Adds Fabric support for 26.3-snapshot-2. This build covers BOTH 26.3-snapshot-1 and 26.3-snapshot-2, so snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the 26.3-snapshot-1 -> snapshot-2 decompiled source diff -- the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Packaging + build hygiene

• Every jar now ships a correct per-version pack.mcmeta (added the missing Fabric resource metadata; corrected the NeoForge pack_format).
• The mod and plugin now compile clean under -Xlint:all with zero warnings. These are behavior- preserving changes only (final classes, explicit numeric casts, a non-deprecated permission API call, and justified suppressions for intentional cross-version Bukkit/Paper API use).

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith 2.2.2 plugin (Bukkit/Spigot/Paper/Folia) tagged for the MC 26.3-snapshot-3 line. The plugin is API-level (api-version 26.1) and unchanged in behaviour; boot + pregen verified on Paper 26.2 and Folia 26.1.2 (Paper/Folia had not yet published a 26.3-snapshot-3 build).

Chunksmith 2.2.2

Minecraft 26.3-snapshot-3 support (Fabric)

Rebuilds the Fabric 26.3 cell against 26.3-snapshot-3. This is a dependency/compatibility bump only -- no functional changes.

• Retargeted to MC 26.3-snapshot-3 with fabric-api 0.154.3+26.3.
• pack_format updated 90 -> 91 (26.3-snapshot-3 resource format).
• Claims 26.3-snapshot-3 exclusively (no lower-26.3 compatibility advertised).

Smoketested on a dedicated Fabric 26.3-snapshot-3 server: boot to Done, all mixins applied, server pre-generation ran to completion with zero errors.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2.1 -- metadata + build hygiene bugfix

• Issue-tracker URL: every mod manifest now points to the mod_support hub (github.com/Kishku7/mod_support/issues), single-sourced + audit-checked (previously resolved to the mod's own disabled Issues tab).
• pack.mcmeta: the 1.21.10 / 1.21.11 cells (Fabric/Forge/NeoForge) now ship the supported_formats range form required for pack_format > 64 (were plain int, which caused the client to skip the mod resource pack on 1.21.9+).
• Build hygiene: removed the dead oss.sonatype.org snapshots repo and the unused Architectury maven repo from all cell build scripts.

No gameplay/behavior changes. All 29 jars rebuilt and server-pregen smoketested (fresh world, radius 500) before release.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

ChunkSmith 2.2

Reliability release. Every jar's declared compatibility now matches what actually loads and runs, validated by boot + pre-generation smoketests on every supported Minecraft version, every loader, and every plugin platform (96 test runs). No gameplay or feature changes since 2.1.3.

Fixed

• Fabric 1.21.5-1.21.7 could not load the mod at all - the 1.21.8 jar's declared Minecraft range accidentally excluded them. 1.21.6-1.21.8 are now served by the 1.21.8 jar; 1.21.5 gets its own dedicated jar (a Minecraft save-data API changed in 1.21.6, so one jar cannot span both).
• New dedicated 1.21.5 jars (Fabric and Forge).
• Forge on MC 1.21 crashed at startup - Forge 51 bundles an older Mixin library that rejects the JAVA_21 compatibility level; the 1.21.1 jar now declares JAVA_17 (no functional difference).
• Forge loader-version floors corrected so the oldest claimed version of each jar actually loads: the 1.20.4 jar now loads on MC 1.20.2-1.20.3, the 1.21.1 jar on MC 1.21, and the 1.21.10 jar on MC 1.21.9 (beta Forge).
• Forge 1.21.6-1.21.7 support restored - Forge rewrote its event bus in Forge 56 (MC 1.21.6); the 1.21.8 jar now targets the new per-event bus API with the correct floor, and the new 1.21.5 jar keeps the classic bus for MC 1.21.5.
• NeoForge dependency floors corrected: the 1.20.6 jar now loads on MC 1.20.5 (NeoForge 20.5-beta) and the 1.21.1 jar on MC 1.21 (NeoForge 21.0).
• 26.x jars are functionally unchanged and revalidated on 26.1 through 26.3-snapshot-2.

Notes

• 26.3 builds are marked beta (Minecraft 26.3 is still in snapshot).
• Server-side only, as always: install on the server; clients need nothing.

Chunksmith 2.1.3 - Forge 1.21.5-1.21.8

Brings the classic Forge 1.21.8 build up to the current standard: corrected pack.mcmeta (proper per-version value), a clean -Xlint:all build, dead snapshot repo removed, and version 2.1.3 baked into the mod metadata. Carries the worldgen entity-save fix. Boot + fresh pre-gen smoketested on classic Forge.

Chunksmith 2.1.3 - Forge 1.21.2-1.21.4

Brings the classic Forge 1.21.4 build up to the current standard: corrected pack.mcmeta (proper per-version value), a clean -Xlint:all build, dead snapshot repo removed, and version 2.1.3 baked into the mod metadata. Carries the worldgen entity-save fix. Boot + fresh pre-gen smoketested on classic Forge.

Chunksmith 2.1.3 - Forge 1.21-1.21.1

Brings the classic Forge 1.21.1 build up to the current standard: corrected pack.mcmeta (proper per-version value), a clean -Xlint:all build, dead snapshot repo removed, and version 2.1.3 baked into the mod metadata. Carries the worldgen entity-save fix. Boot + fresh pre-gen smoketested on classic Forge.

Chunksmith 2.1.3 - Forge 1.20.5-1.20.6

Brings the classic Forge 1.20.6 build up to the current standard: corrected pack.mcmeta (now the proper per-version value), a clean -Xlint:all build, and version 2.1.3 baked into the mod metadata. Carries the worldgen entity-save fix. Boot + fresh pre-gen smoketested on classic Forge 50.2.8. (Tagged 1.20.5-1.20.6; Forge never shipped a 1.20.5 build, so this simply avoids an unexplained gap.)

Chunksmith 2.1.3 - Forge 1.21.11

Fills in the classic Forge loader for Minecraft 1.21.11 (previously only Fabric and NeoForge were published). Carries the worldgen entity-save fix and is built to the current standard: correct pack.mcmeta and a clean -Xlint:all build. Boot + fresh pre-gen smoketested on classic Forge 61.x.

Chunksmith 2.1.3 - Forge 1.21.9-1.21.10

Fills in the classic Forge loader for Minecraft 1.21.9-1.21.10 (previously only Fabric and NeoForge were published for these). Carries the worldgen entity-save fix and is built to the current standard: correct pack.mcmeta and a clean -Xlint:all build. Boot + fresh pre-gen smoketested on classic Forge 60.1.9.

Chunksmith 2.1.3 - Forge 1.20.2-1.20.4

Fills in the classic Forge loader for Minecraft 1.20.2-1.20.4 (previously only Fabric and NeoForge were published for these). Carries the worldgen entity-save fix (legacy-direct accessor chain, correct for pre-1.20.5) and is built to the current standard: correct pack.mcmeta and a clean -Xlint:all build. Boot + radius-1000 fresh pre-gen smoketested on classic Forge 49.2.7.

Chunksmith 2.1.3 - Forge 1.20.1

Fills in the classic Forge loader for Minecraft 1.20.1 (previously only Fabric and NeoForge were published for 1.20.1). Carries the worldgen entity-save fix (legacy-direct variant for the 1.20.1 accessor chain) and is built to the current standard: correct pack.mcmeta and a clean -Xlint:all build. Boot + radius-1000 fresh pre-gen smoketested on classic Forge 47.4.20.

Chunksmith 2.1.3

Minecraft 26.3-snapshot-2 support (Fabric). This build covers both 26.3-snapshot-1 and 26.3-snapshot-2 - snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the snapshot-1 -> snapshot-2 source diff; the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Also in this release:

• Every jar now ships a correct per-version pack.mcmeta.
• The mod and plugin build clean under -Xlint:all (behavior-preserving hygiene only).

Chunksmith 2.1.3

Minecraft 26.3-snapshot-2 support (Fabric). This build covers both 26.3-snapshot-1 and 26.3-snapshot-2 - snapshot-1 users should upgrade. It is a pure dependency bump: no worldgen or mixin logic changed (verified against the snapshot-1 -> snapshot-2 source diff; the snapshot-2 worldgen refactor does not touch any Chunksmith injection point).

Also in this release:

• Every jar now ships a correct per-version pack.mcmeta.
• The mod and plugin build clean under -Xlint:all (behavior-preserving hygiene only).

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith Changelog

2.1.2

Fixed: worldgen entities (mobs, item frames, armor stands, etc.) could fail to save

During large pre-generation runs, entities that spawn as brand-new chunks are generated could, in some cases, fail to be saved -- in practice, "mobs that just don't persist."

What was happening. When Minecraft unloads a freshly generated chunk's entities, it normally first reads any already-saved entities for that chunk so they can be merged before the new data is written. Chunksmith skips that read when a chunk has no saved entity data -- a real optimization that keeps memory and disk under control during big pre-gens. The problem was how it decided "is there saved entity data?": that check ran off the storage thread, against a cache that was never refreshed, and it ignored writes that were still queued in memory but not yet flushed to disk. So a chunk that was stored, unloaded, and then re-loaded before its write reached disk could have its just-saved entities overwritten -- and lost.

The fix. The "is there saved entity data?" check now runs on the chunk-storage system's own thread -- the single thread that owns both the in-memory write queue and the region files -- and it checks the queued writes AND the on-disk data. It can no longer race the writer, read a half-written file header, or trust a stale cache. If any saved data exists, or anything is uncertain, Chunksmith performs the full, safe read-and-merge exactly as vanilla would. Nothing is ever skipped when data might exist, so no entity can be lost.

This fix is applied across every supported Minecraft version and loader.

Also in this release

• Unified version. All Minecraft lines (1.20.x, 1.21.x, 26.x) and all loaders (Fabric, Forge, NeoForge, and the Bukkit/Paper plugin) are now on a single version, 2.1.2, so every supported version carries the same set of fixes.
• 26.x loader metadata. Minecraft version ranges are now closed (a 26.1 build targets 26.1.x only, a 26.2 build targets 26.2.x only, and so on) instead of open-ended, so a build can no longer claim to support a Minecraft line it was not built and tested against.

Earlier releases were published on Modrinth only; this is the first in-repo changelog entry.

Chunksmith 2.1.1 (plugin)

A plugin-only patch that fixes chunk pre-generation on Folia.

Fixed

• Pre-generation now works on Folia. Previously, running /cs start on a Folia server appeared to hang: the task started but never made progress and never finished. The cause was the adaptive I/O throttle calling the server's global tick-time API (getAverageTickTime()), which Folia does not support off a region thread - it threw UnsupportedOperationException: Not on any region, and because the generation task runs on a background thread the error was swallowed and the task died silently on the very first chunk. Chunksmith now detects Folia explicitly (Folia is a fork of Paper, so the old check matched Paper first and took the wrong path) and skips the unsupported global tick-time signal on Folia, letting the per-chunk-latency throttle carry the work. Verified on Folia 26.1.2: a radius-100 pre-generation runs to completion and persists to disk.

Changed (internal)

• Server-platform detection is now resolved once into a single cached value, ordered most-specific-first (Folia -> Paper -> Spigot -> Bukkit).
• Generation-task failures are now logged instead of being silently swallowed.

This is a plugin-only release; the Fabric/NeoForge mod is unaffected and remains at 2.1.0. Available for Bukkit / Spigot / Paper / Folia, Minecraft 26.1.x - 26.3-snapshot-1. Original Chunky by pop4959.

Chunksmith 2.1.1 (plugin)

A plugin-only patch that fixes chunk pre-generation on Folia.

Fixed

• Pre-generation now works on Folia. Previously, running /cs start on a Folia server appeared to hang: the task started but never made progress and never finished. The cause was the adaptive I/O throttle calling the server's global tick-time API (getAverageTickTime()), which Folia does not support off a region thread - it threw UnsupportedOperationException: Not on any region, and because the generation task runs on a background thread the error was swallowed and the task died silently on the very first chunk. Chunksmith now detects Folia explicitly (Folia is a fork of Paper, so the old check matched Paper first and took the wrong path) and skips the unsupported global tick-time signal on Folia, letting the per-chunk-latency throttle carry the work. Verified on Folia 26.1.2: a radius-100 pre-generation runs to completion and persists to disk.

Changed (internal)

• Server-platform detection is now resolved once into a single cached value, ordered most-specific-first (Folia -> Paper -> Spigot -> Bukkit).
• Generation-task failures are now logged instead of being silently swallowed.

This is a plugin-only release; the Fabric/NeoForge mod is unaffected and remains at 2.1.0. Available for Bukkit / Spigot / Paper / Folia, Minecraft 26.1.x - 26.3-snapshot-1. Original Chunky by pop4959.

Chunksmith 2.1.1 (plugin)

A plugin-only patch that fixes chunk pre-generation on Folia.

Fixed

• Pre-generation now works on Folia. Previously, running /cs start on a Folia server appeared to hang: the task started but never made progress and never finished. The cause was the adaptive I/O throttle calling the server's global tick-time API (getAverageTickTime()), which Folia does not support off a region thread - it threw UnsupportedOperationException: Not on any region, and because the generation task runs on a background thread the error was swallowed and the task died silently on the very first chunk. Chunksmith now detects Folia explicitly (Folia is a fork of Paper, so the old check matched Paper first and took the wrong path) and skips the unsupported global tick-time signal on Folia, letting the per-chunk-latency throttle carry the work. Verified on Folia 26.1.2: a radius-100 pre-generation runs to completion and persists to disk.

Changed (internal)

• Server-platform detection is now resolved once into a single cached value, ordered most-specific-first (Folia -> Paper -> Spigot -> Bukkit).
• Generation-task failures are now logged instead of being silently swallowed.

This is a plugin-only release; the Fabric/NeoForge mod is unaffected and remains at 2.1.0. Available for Bukkit / Spigot / Paper / Folia, Minecraft 26.1.x - 26.3-snapshot-1. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1

26.3-snapshot-1 builds are published as alpha (snapshot target; release-quality code, provisional compatibility). Chunksmith is a server-side mod/plugin. Original Chunky by pop4959.

Chunksmith 2.1.0

The 2.1.0 release unifies the entire Minecraft 26 line onto one codebase and completes a deep cleanup of the fork. Available for Minecraft 26.1 through 26.3-snapshot-1 on Fabric and NeoForge, and as a Bukkit/Spigot/Paper plugin.

Changed

• Whole 26.x line unified. What used to be three separate branches (26.1 / 26.2 / 26.3) is now a single source tree, so every supported 26.x version builds from one place and fixes apply across the line at once.
• Finished rebrand. The internal package, class names, permission nodes (chunksmith.command.*, with the legacy chunky.command.* nodes still honored), system flags, and remaining user-facing labels are now fully Chunksmith. Existing commands and permissions keep working.

Removed

• Inherited dead code. Dropped the cross-platform disk-space estimation, unused Hilbert-curve imports, and pre-26 code paths no longer relevant to the 26 line.

Notes

• Mod vs plugin parity. The mod carries server-internal protections (keep-awake during generation, prompt chunk unloading, and a worldgen entity-retention fix) needed on an unpatched vanilla server. On Paper/Folia those are already provided natively by the server's chunk system, so the plugin relies on the platform rather than re-implementing them. Same core, appropriate depth per platform.

Availability

• Fabric: 26.1, 26.2, 26.3-snapshot-1
• NeoForge: 26.1, 26.2 (no NeoForge build for 26.3 yet)
• Plugin (Bukkit/Spigot/Paper): 26.1.x, 26.2, 26.3-snapshot-1