ChunksmithСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачатьСкачать
ВЕРСИИ (602)
release
4.6.0+26.x-plugin
4.6.0+26.x-plugin13 окт. 2026 г.1,9 тыс.Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.3
4.6.0+26.313 окт. 2026 г.9,3 тыс.Minecraft: 26.3fabric
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.3-neoforge
4.6.0+26.3-neoforge13 окт. 2026 г.300Minecraft: 26.3neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.2
4.6.0+26.213 окт. 2026 г.2,6 тыс.Minecraft: 26.2fabric
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.2-neoforge
4.6.0+26.2-neoforge13 окт. 2026 г.172Minecraft: 26.2neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.1
4.6.0+26.113 окт. 2026 г.468Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+26.1-neoforge
4.6.0+26.1-neoforge13 окт. 2026 г.158Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.x-plugin
4.6.0+1.21.x-plugin13 окт. 2026 г.521Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.8
4.6.0+1.21.813 окт. 2026 г.106Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.8-neoforge
4.6.0+1.21.8-neoforge13 окт. 2026 г.18Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.8-forge
4.6.0+1.21.8-forge13 окт. 2026 г.10Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.5
4.6.0+1.21.513 окт. 2026 г.54Minecraft: 1.21.5fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.5-forge
4.6.0+1.21.5-forge13 окт. 2026 г.4Minecraft: 1.21.5forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.4
4.6.0+1.21.413 окт. 2026 г.112Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.4-neoforge
4.6.0+1.21.4-neoforge13 окт. 2026 г.12Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.4-forge
4.6.0+1.21.4-forge13 окт. 2026 г.16Minecraft: 1.21.3, 1.21.4forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.11
4.6.0+1.21.1113 окт. 2026 г.1 тыс.Minecraft: 1.21.11fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.11-neoforge
4.6.0+1.21.11-neoforge13 окт. 2026 г.122Minecraft: 1.21.11neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.11-forge
4.6.0+1.21.11-forge13 окт. 2026 г.70Minecraft: 1.21.11forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.10
4.6.0+1.21.1013 окт. 2026 г.106Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.10-neoforge
4.6.0+1.21.10-neoforge13 окт. 2026 г.21Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.10-forge
4.6.0+1.21.10-forge13 окт. 2026 г.15Minecraft: 1.21.10forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.1
4.6.0+1.21.113 окт. 2026 г.1,3 тыс.Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.1-neoforge
4.6.0+1.21.1-neoforge13 окт. 2026 г.6 тыс.Minecraft: 1.21, 1.21.1neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.21.1-forge
4.6.0+1.21.1-forge13 окт. 2026 г.84Minecraft: 1.21, 1.21.1forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.x-plugin
4.6.0+1.20.x-plugin13 окт. 2026 г.54Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.6
4.6.0+1.20.613 окт. 2026 г.20Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.6-neoforge
4.6.0+1.20.6-neoforge13 окт. 2026 г.10Minecraft: 1.20.6neoforge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.6-forge
4.6.0+1.20.6-forge13 окт. 2026 г.6Minecraft: 1.20.6forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.4
4.6.0+1.20.413 окт. 2026 г.104Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.4-forge
4.6.0+1.20.4-forge13 окт. 2026 г.16Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.1
4.6.0+1.20.113 окт. 2026 г.896Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.6.0+1.20.1-forge
4.6.0+1.20.1-forge13 окт. 2026 г.2,4 тыс.Minecraft: 1.20.1forge
Что нового
- New: LOD for the ground players explore. Until now only a pregen added LOD, so anywhere a player went
past the pregenerated area stayed blank in everyone's distant view. Now every chunk a player loads is
added to the server's LOD the first time it is saved (or, on Bukkit/Paper, unloaded), and connected
players receive it within about a minute without relogging (mod_support #46). It is on by default, in
single player too, and can be turned off with `/cs set lodFromExploredChunks false`
(`lod-from-explored-chunks: false` on Bukkit/Paper). Chunks already in the LOD store are skipped, so a
pregenerated area costs nothing extra. `/cs lod status` shows how many explored chunks were added.
Works with C2ME (tested). Not covered: Moonrise, which replaces the whole chunk system; there a pregen
is still the way to add LOD.
release
4.5.1+26.x-plugin
4.5.1+26.x-plugin13 окт. 2026 г.148Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.3
4.5.1+26.313 окт. 2026 г.610Minecraft: 26.3fabric
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.3-neoforge
4.5.1+26.3-neoforge13 окт. 2026 г.18Minecraft: 26.3neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.2
4.5.1+26.213 окт. 2026 г.183Minecraft: 26.2fabric
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.2-neoforge
4.5.1+26.2-neoforge13 окт. 2026 г.11Minecraft: 26.2neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.1
4.5.1+26.113 окт. 2026 г.28Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+26.1-neoforge
4.5.1+26.1-neoforge13 окт. 2026 г.16Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.x-plugin
4.5.1+1.21.x-plugin13 окт. 2026 г.48Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.8
4.5.1+1.21.813 окт. 2026 г.12Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.8-neoforge
4.5.1+1.21.8-neoforge13 окт. 2026 г.4Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.8-forge
4.5.1+1.21.8-forge13 окт. 2026 г.2Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.5
4.5.1+1.21.513 окт. 2026 г.2Minecraft: 1.21.5fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.5-forge
4.5.1+1.21.5-forge13 окт. 2026 г.6Minecraft: 1.21.5forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.4
4.5.1+1.21.413 окт. 2026 г.10Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.4-neoforge
4.5.1+1.21.4-neoforge13 окт. 2026 г.0Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.4-forge
4.5.1+1.21.4-forge13 окт. 2026 г.4Minecraft: 1.21.3, 1.21.4forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.11
4.5.1+1.21.1113 окт. 2026 г.46Minecraft: 1.21.11fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.11-neoforge
4.5.1+1.21.11-neoforge13 окт. 2026 г.0Minecraft: 1.21.11neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.11-forge
4.5.1+1.21.11-forge13 окт. 2026 г.4Minecraft: 1.21.11forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.10
4.5.1+1.21.1013 окт. 2026 г.8Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.10-neoforge
4.5.1+1.21.10-neoforge13 окт. 2026 г.4Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.10-forge
4.5.1+1.21.10-forge13 окт. 2026 г.2Minecraft: 1.21.10forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.1
4.5.1+1.21.113 окт. 2026 г.80Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.1-neoforge
4.5.1+1.21.1-neoforge13 окт. 2026 г.242Minecraft: 1.21, 1.21.1neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.21.1-forge
4.5.1+1.21.1-forge13 окт. 2026 г.6Minecraft: 1.21, 1.21.1forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.x-plugin
4.5.1+1.20.x-plugin13 окт. 2026 г.6Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.6
4.5.1+1.20.613 окт. 2026 г.4Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.6-neoforge
4.5.1+1.20.6-neoforge13 окт. 2026 г.0Minecraft: 1.20.6neoforge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.6-forge
4.5.1+1.20.6-forge13 окт. 2026 г.2Minecraft: 1.20.6forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.4
4.5.1+1.20.413 окт. 2026 г.6Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.4-forge
4.5.1+1.20.4-forge13 окт. 2026 г.2Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.1
4.5.1+1.20.113 окт. 2026 г.58Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.1+1.20.1-forge
4.5.1+1.20.1-forge13 окт. 2026 г.110Minecraft: 1.20.1forge
Что нового
- The startup message about LOD storage now says about 5 KB per chunk (measured 2026-10-12 on
9,409 chunks), not 12 KB. Nothing about the store changed; the old figure overstated it.
- When LOD downloads over the fast path fail, the client now says why: the first failure's cause is
printed after the "LOD: done" line and shown in the download status. Before, only the "failed"
count went up, with no error anywhere (mod_support #48).
- Fixed: when LOD downloads over the fast path all failed, the client only switched to the slower
in-band channel after trying EVERY region. With requests hanging to their 60-second timeout that took
about an hour, so LOD never arrived. It now switches after the first four fail with nothing received,
within about a minute (mod_support #48). A busy server (HTTP 429) does not count.
- Fixed: the client no longer starts an in-band transfer while leaving a server, and the "accepted a
connection but served nothing" warning names the real port instead of 0.
- Fixed (server): a download whose receiver stops reading (a PC that lost power, a dropped Wi-Fi link) is
now closed after 30 seconds without progress. Before, each one held one of the backchannel's four
threads for up to a quarter of an hour, and four of them stopped downloads for every player.
- Fixed: on a Bukkit/Paper server (which has no in-band channel), a client that fell back to in-band
waited for an answer that never came and stopped syncing for the rest of the session, so it never tried
the fast path again either. The client now gives up an unanswered in-band request after 60 seconds and
tries the backchannel again at the next sync, so LOD arrives as soon as the backchannel works.
- Fixed: when the client fell back to in-band, the next sync could start a second in-band transfer of the
same regions while the first was still arriving. The two mixed their pieces and the client then failed
to read the region ("incorrect header check"), so that LOD never showed.
release
4.5.0+26.x-plugin
4.5.0+26.x-plugin10 окт. 2026 г.490Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.3
4.5.0+26.310 окт. 2026 г.3,3 тыс.Minecraft: 26.3fabric
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.3-neoforge
4.5.0+26.3-neoforge10 окт. 2026 г.70Minecraft: 26.3neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.2
4.5.0+26.210 окт. 2026 г.1 тыс.Minecraft: 26.2fabric
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.2-neoforge
4.5.0+26.2-neoforge10 окт. 2026 г.36Minecraft: 26.2neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.1
4.5.0+26.110 окт. 2026 г.159Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+26.1-neoforge
4.5.0+26.1-neoforge10 окт. 2026 г.78Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.x-plugin
4.5.0+1.21.x-plugin10 окт. 2026 г.103Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.8
4.5.0+1.21.810 окт. 2026 г.24Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.8-neoforge
4.5.0+1.21.8-neoforge10 окт. 2026 г.10Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.8-forge
4.5.0+1.21.8-forge10 окт. 2026 г.6Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.5
4.5.0+1.21.510 окт. 2026 г.24Minecraft: 1.21.5fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.5-forge
4.5.0+1.21.5-forge10 окт. 2026 г.0Minecraft: 1.21.5forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.4
4.5.0+1.21.410 окт. 2026 г.36Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.4-neoforge
4.5.0+1.21.4-neoforge10 окт. 2026 г.24Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.4-forge
4.5.0+1.21.4-forge10 окт. 2026 г.0Minecraft: 1.21.3, 1.21.4forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.11
4.5.0+1.21.1110 окт. 2026 г.264Minecraft: 1.21.11fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.11-neoforge
4.5.0+1.21.11-neoforge10 окт. 2026 г.43Minecraft: 1.21.11neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.11-forge
4.5.0+1.21.11-forge10 окт. 2026 г.24Minecraft: 1.21.11forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.10
4.5.0+1.21.1010 окт. 2026 г.24Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.10-neoforge
4.5.0+1.21.10-neoforge10 окт. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.10-forge
4.5.0+1.21.10-forge10 окт. 2026 г.5Minecraft: 1.21.10forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.1
4.5.0+1.21.110 окт. 2026 г.350Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.1-neoforge
4.5.0+1.21.1-neoforge10 окт. 2026 г.1,2 тыс.Minecraft: 1.21, 1.21.1neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.21.1-forge
4.5.0+1.21.1-forge10 окт. 2026 г.16Minecraft: 1.21, 1.21.1forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.x-plugin
4.5.0+1.20.x-plugin10 окт. 2026 г.10Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.6
4.5.0+1.20.610 окт. 2026 г.14Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.6-neoforge
4.5.0+1.20.6-neoforge10 окт. 2026 г.2Minecraft: 1.20.6neoforge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.6-forge
4.5.0+1.20.6-forge10 окт. 2026 г.4Minecraft: 1.20.6forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.4
4.5.0+1.20.410 окт. 2026 г.26Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.4-forge
4.5.0+1.20.4-forge10 окт. 2026 г.7Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.1
4.5.0+1.20.110 окт. 2026 г.244Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.5.0+1.20.1-forge
4.5.0+1.20.1-forge10 окт. 2026 г.621Minecraft: 1.20.1forge
Что нового
- New: while a pregen is running on a server, players already connected now get the new LOD about a
minute after it is generated, without moving. Before, someone standing still waited for the 5-minute
sync (mod_support #45). Works with 4.x clients; only the server needs updating for this part.
- Fixed: in single player with Voxy, Chunksmith fed Voxy directly as it generated AND sent the same LOD to
itself again over the slow in-band path, re-sending every growing region during a pregen. The second
copy is gone: single player now only catches up, once per session, on LOD Voxy has not had yet.
- Fixed: a world-enter pregen that finished could still fail to mark the world as done, so it ran
again the next time the world was loaded. The last chunk's progress could arrive after the
"finished" signal it was meant to come before.
- Changed: the world-enter pregen now centres on where you spawn by default, not on 0,0. A mod that
moves spawn (Village Spawn Point, for example) used to send it thousands of blocks away. The new
default, `worldEnterPregenCenter` = `auto`, leaves any world that already finished a world-enter
pregen centred where it was, so nothing you already generated moves. `origin`, `spawn` and `x,z`
still work if you set them.
release
4.4.1+26.3
4.4.1+26.38 окт. 2026 г.2,9 тыс.Minecraft: 26.3fabric
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+26.3-neoforge
4.4.1+26.3-neoforge8 окт. 2026 г.94Minecraft: 26.3neoforge
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+26.2
4.4.1+26.28 окт. 2026 г.736Minecraft: 26.2fabric
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+26.2-neoforge
4.4.1+26.2-neoforge8 окт. 2026 г.24Minecraft: 26.2neoforge
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+26.1
4.4.1+26.18 окт. 2026 г.136Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+26.1-neoforge
4.4.1+26.1-neoforge8 окт. 2026 г.52Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+1.21.11
4.4.1+1.21.118 окт. 2026 г.184Minecraft: 1.21.11fabric, quilt
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+1.21.11-neoforge
4.4.1+1.21.11-neoforge8 окт. 2026 г.24Minecraft: 1.21.11neoforge
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.1+1.21.11-forge
4.4.1+1.21.11-forge8 окт. 2026 г.24Minecraft: 1.21.11forge
Что нового
- Fixed: a crash a few seconds after entering a world or starting a server with Very Many Players
(VMP) installed (mod_support #44). A diagnostic read a chunk-level tracker that VMP replaces; it now
reads each chunk's own level, which works with or without VMP.
- That diagnostic no longer runs in the background at all. Its lines in `/cs debug` are worked out
when you run the command.
- Only the 1.21.11 and 26.x jars change; no other version had this diagnostic.
release
4.4.0+26.x-plugin
4.4.0+26.x-plugin1 окт. 2026 г.1 тыс.Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.3
4.4.0+26.31 окт. 2026 г.5,2 тыс.Minecraft: 26.3fabric
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.3-neoforge
4.4.0+26.3-neoforge1 окт. 2026 г.179Minecraft: 26.3neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.2
4.4.0+26.21 окт. 2026 г.1,4 тыс.Minecraft: 26.2fabric
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.2-neoforge
4.4.0+26.2-neoforge1 окт. 2026 г.70Minecraft: 26.2neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.1
4.4.0+26.11 окт. 2026 г.263Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+26.1-neoforge
4.4.0+26.1-neoforge1 окт. 2026 г.74Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.x-plugin
4.4.0+1.21.x-plugin1 окт. 2026 г.292Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.8
4.4.0+1.21.81 окт. 2026 г.72Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.8-neoforge
4.4.0+1.21.8-neoforge1 окт. 2026 г.15Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.8-forge
4.4.0+1.21.8-forge1 окт. 2026 г.14Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.5
4.4.0+1.21.51 окт. 2026 г.29Minecraft: 1.21.5fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.5-forge
4.4.0+1.21.5-forge1 окт. 2026 г.5Minecraft: 1.21.5forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.4
4.4.0+1.21.41 окт. 2026 г.86Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.4-neoforge
4.4.0+1.21.4-neoforge1 окт. 2026 г.35Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.4-forge
4.4.0+1.21.4-forge1 окт. 2026 г.15Minecraft: 1.21.3, 1.21.4forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.11
4.4.0+1.21.111 окт. 2026 г.477Minecraft: 1.21.11fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.11-neoforge
4.4.0+1.21.11-neoforge1 окт. 2026 г.38Minecraft: 1.21.11neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.11-forge
4.4.0+1.21.11-forge1 окт. 2026 г.46Minecraft: 1.21.11forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.10
4.4.0+1.21.101 окт. 2026 г.56Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.10-neoforge
4.4.0+1.21.10-neoforge1 окт. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.10-forge
4.4.0+1.21.10-forge1 окт. 2026 г.15Minecraft: 1.21.10forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.1
4.4.0+1.21.11 окт. 2026 г.746Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.1-neoforge
4.4.0+1.21.1-neoforge1 окт. 2026 г.2,7 тыс.Minecraft: 1.21, 1.21.1neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.21.1-forge
4.4.0+1.21.1-forge1 окт. 2026 г.49Minecraft: 1.21, 1.21.1forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.x-plugin
4.4.0+1.20.x-plugin1 окт. 2026 г.19Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.6
4.4.0+1.20.61 окт. 2026 г.10Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.6-neoforge
4.4.0+1.20.6-neoforge1 окт. 2026 г.6Minecraft: 1.20.6neoforge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.6-forge
4.4.0+1.20.6-forge1 окт. 2026 г.6Minecraft: 1.20.6forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.4
4.4.0+1.20.41 окт. 2026 г.77Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.4-forge
4.4.0+1.20.4-forge1 окт. 2026 г.6Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.1
4.4.0+1.20.11 окт. 2026 г.566Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.4.0+1.20.1-forge
4.4.0+1.20.1-forge1 окт. 2026 г.1,6 тыс.Minecraft: 1.20.1forge
Что нового
- New: LOD horizon. `/cs horizon <radius>` pregens normally inside the radius; past it, chunks are
generated only for their LOD and are not saved, so a huge LOD pregen no longer fills the disk
(mod_support #39). Multiplayer LOD downloads work the same. `/cs horizon off` turns it off, and
`worldEnterLodHorizon` does the same for the world-enter pre-gen (default off).
- Two chunks past the horizon are still saved, so trees and lakes on the edge are not cut in half.
Chunks a player goes near are always saved.
- Works wherever Chunksmith builds LOD. Not available with Moonrise, or with C2ME's experimental
`gcFreeChunkSerializer`; the command says so. On Paper, some partly generated chunks at the edges are
still written.
- Built against NeoForge 26.1.2.112, 26.3.0.39-beta, 21.1.252 and 21.4.158.
release
4.3.6+26.x-plugin
4.3.6+26.x-plugin27 сент. 2026 г.339Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.3
4.3.6+26.327 сент. 2026 г.2,1 тыс.Minecraft: 26.3fabric
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.3-neoforge
4.3.6+26.3-neoforge27 сент. 2026 г.60Minecraft: 26.3neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.2
4.3.6+26.227 сент. 2026 г.657Minecraft: 26.2fabric
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.2-neoforge
4.3.6+26.2-neoforge27 сент. 2026 г.47Minecraft: 26.2neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.1
4.3.6+26.127 сент. 2026 г.118Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+26.1-neoforge
4.3.6+26.1-neoforge27 сент. 2026 г.34Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.x-plugin
4.3.6+1.21.x-plugin27 сент. 2026 г.163Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.8
4.3.6+1.21.827 сент. 2026 г.16Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.8-neoforge
4.3.6+1.21.8-neoforge27 сент. 2026 г.3Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.8-forge
4.3.6+1.21.8-forge27 сент. 2026 г.9Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.5
4.3.6+1.21.527 сент. 2026 г.12Minecraft: 1.21.5fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.5-forge
4.3.6+1.21.5-forge27 сент. 2026 г.2Minecraft: 1.21.5forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.4
4.3.6+1.21.427 сент. 2026 г.57Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.4-neoforge
4.3.6+1.21.4-neoforge27 сент. 2026 г.31Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.4-forge
4.3.6+1.21.4-forge27 сент. 2026 г.19Minecraft: 1.21.3, 1.21.4forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.11
4.3.6+1.21.1127 сент. 2026 г.179Minecraft: 1.21.11fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.11-neoforge
4.3.6+1.21.11-neoforge27 сент. 2026 г.25Minecraft: 1.21.11neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.11-forge
4.3.6+1.21.11-forge27 сент. 2026 г.26Minecraft: 1.21.11forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.10
4.3.6+1.21.1027 сент. 2026 г.18Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.10-neoforge
4.3.6+1.21.10-neoforge27 сент. 2026 г.5Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.10-forge
4.3.6+1.21.10-forge27 сент. 2026 г.5Minecraft: 1.21.10forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.1
4.3.6+1.21.127 сент. 2026 г.218Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.1-neoforge
4.3.6+1.21.1-neoforge27 сент. 2026 г.827Minecraft: 1.21, 1.21.1neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.21.1-forge
4.3.6+1.21.1-forge27 сент. 2026 г.20Minecraft: 1.21, 1.21.1forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.x-plugin
4.3.6+1.20.x-plugin27 сент. 2026 г.12Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.6
4.3.6+1.20.627 сент. 2026 г.8Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.6-neoforge
4.3.6+1.20.6-neoforge27 сент. 2026 г.4Minecraft: 1.20.6neoforge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.6-forge
4.3.6+1.20.6-forge27 сент. 2026 г.2Minecraft: 1.20.6forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.4
4.3.6+1.20.427 сент. 2026 г.29Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.4-forge
4.3.6+1.20.4-forge27 сент. 2026 г.1Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.1
4.3.6+1.20.127 сент. 2026 г.183Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.6+1.20.1-forge
4.3.6+1.20.1-forge27 сент. 2026 г.470Minecraft: 1.20.1forge
Что нового
- Big modpacks no longer see the world-enter pre-gen speed up and slow down over and over: cached
chunks are released as soon as memory runs short (mod_support #37).
- New debug setting `debugWorldEnterSkipLod` (off by default) skips LOD building during the world-enter pre-gen.
release
4.3.5+26.x-plugin
4.3.5+26.x-plugin26 сент. 2026 г.84Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.3
4.3.5+26.326 сент. 2026 г.485Minecraft: 26.3fabric
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.3-neoforge
4.3.5+26.3-neoforge26 сент. 2026 г.14Minecraft: 26.3neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.2
4.3.5+26.226 сент. 2026 г.184Minecraft: 26.2fabric
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.2-neoforge
4.3.5+26.2-neoforge26 сент. 2026 г.8Minecraft: 26.2neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.1
4.3.5+26.126 сент. 2026 г.37Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+26.1-neoforge
4.3.5+26.1-neoforge26 сент. 2026 г.9Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.x-plugin
4.3.5+1.21.x-plugin26 сент. 2026 г.52Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.8
4.3.5+1.21.826 сент. 2026 г.8Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.8-neoforge
4.3.5+1.21.8-neoforge26 сент. 2026 г.0Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.8-forge
4.3.5+1.21.8-forge26 сент. 2026 г.4Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.5
4.3.5+1.21.526 сент. 2026 г.6Minecraft: 1.21.5fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.5-forge
4.3.5+1.21.5-forge26 сент. 2026 г.1Minecraft: 1.21.5forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.4
4.3.5+1.21.426 сент. 2026 г.17Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.4-neoforge
4.3.5+1.21.4-neoforge26 сент. 2026 г.35Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.4-forge
4.3.5+1.21.4-forge26 сент. 2026 г.19Minecraft: 1.21.3, 1.21.4forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.11
4.3.5+1.21.1126 сент. 2026 г.54Minecraft: 1.21.11fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.11-neoforge
4.3.5+1.21.11-neoforge26 сент. 2026 г.3Minecraft: 1.21.11neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.11-forge
4.3.5+1.21.11-forge26 сент. 2026 г.5Minecraft: 1.21.11forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.10
4.3.5+1.21.1026 сент. 2026 г.4Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.10-neoforge
4.3.5+1.21.10-neoforge26 сент. 2026 г.0Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.10-forge
4.3.5+1.21.10-forge26 сент. 2026 г.2Minecraft: 1.21.10forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.1
4.3.5+1.21.126 сент. 2026 г.55Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.1-neoforge
4.3.5+1.21.1-neoforge26 сент. 2026 г.259Minecraft: 1.21, 1.21.1neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.21.1-forge
4.3.5+1.21.1-forge26 сент. 2026 г.3Minecraft: 1.21, 1.21.1forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.x-plugin
4.3.5+1.20.x-plugin26 сент. 2026 г.2Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.6
4.3.5+1.20.626 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.6-neoforge
4.3.5+1.20.6-neoforge26 сент. 2026 г.1Minecraft: 1.20.6neoforge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.6-forge
4.3.5+1.20.6-forge26 сент. 2026 г.1Minecraft: 1.20.6forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.4
4.3.5+1.20.426 сент. 2026 г.8Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.4-forge
4.3.5+1.20.4-forge26 сент. 2026 г.2Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.1
4.3.5+1.20.126 сент. 2026 г.53Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.5+1.20.1-forge
4.3.5+1.20.1-forge26 сент. 2026 г.93Minecraft: 1.20.1forge
Что нового
- Fixed the world-enter pre-gen slowing to a crawl after about an hour: finished chunks now unload
while the world is frozen instead of piling up in memory, and generation is faster (mod_support #37).
release
4.3.4+26.x-plugin
4.3.4+26.x-plugin24 сент. 2026 г.75Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.3
4.3.4+26.324 сент. 2026 г.427Minecraft: 26.3fabric
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.3-neoforge
4.3.4+26.3-neoforge24 сент. 2026 г.19Minecraft: 26.3neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.2
4.3.4+26.224 сент. 2026 г.218Minecraft: 26.2fabric
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.2-neoforge
4.3.4+26.2-neoforge24 сент. 2026 г.9Minecraft: 26.2neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.1
4.3.4+26.124 сент. 2026 г.32Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+26.1-neoforge
4.3.4+26.1-neoforge24 сент. 2026 г.12Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.x-plugin
4.3.4+1.21.x-plugin24 сент. 2026 г.21Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.8
4.3.4+1.21.824 сент. 2026 г.4Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.8-neoforge
4.3.4+1.21.8-neoforge24 сент. 2026 г.1Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.8-forge
4.3.4+1.21.8-forge24 сент. 2026 г.2Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.5
4.3.4+1.21.524 сент. 2026 г.3Minecraft: 1.21.5fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.5-forge
4.3.4+1.21.5-forge24 сент. 2026 г.1Minecraft: 1.21.5forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.4
4.3.4+1.21.424 сент. 2026 г.4Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.4-neoforge
4.3.4+1.21.4-neoforge24 сент. 2026 г.3Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.4-forge
4.3.4+1.21.4-forge24 сент. 2026 г.1Minecraft: 1.21.3, 1.21.4forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.11
4.3.4+1.21.1124 сент. 2026 г.40Minecraft: 1.21.11fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.11-neoforge
4.3.4+1.21.11-neoforge24 сент. 2026 г.3Minecraft: 1.21.11neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.11-forge
4.3.4+1.21.11-forge24 сент. 2026 г.4Minecraft: 1.21.11forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.10
4.3.4+1.21.1024 сент. 2026 г.7Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.10-neoforge
4.3.4+1.21.10-neoforge24 сент. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.10-forge
4.3.4+1.21.10-forge24 сент. 2026 г.2Minecraft: 1.21.10forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.1
4.3.4+1.21.124 сент. 2026 г.55Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.1-neoforge
4.3.4+1.21.1-neoforge24 сент. 2026 г.293Minecraft: 1.21, 1.21.1neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.21.1-forge
4.3.4+1.21.1-forge24 сент. 2026 г.1Minecraft: 1.21, 1.21.1forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.x-plugin
4.3.4+1.20.x-plugin24 сент. 2026 г.3Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.6
4.3.4+1.20.624 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.6-neoforge
4.3.4+1.20.6-neoforge24 сент. 2026 г.4Minecraft: 1.20.6neoforge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.6-forge
4.3.4+1.20.6-forge24 сент. 2026 г.2Minecraft: 1.20.6forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.4
4.3.4+1.20.424 сент. 2026 г.5Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.4-forge
4.3.4+1.20.4-forge24 сент. 2026 г.3Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.1
4.3.4+1.20.124 сент. 2026 г.42Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.4+1.20.1-forge
4.3.4+1.20.1-forge24 сент. 2026 г.126Minecraft: 1.20.1forge
Что нового
- Fixed a pre-gen that could stop for good while the world was frozen, until you entered the world
(mod_support #37).
- The auto-pause warning now only appears when an auto-pause can actually happen.
- Singleplayer no longer warns about opening a network port.
- Forge jars no longer list Minecraft versions Forge cannot run (1.20.5, 1.21.2, 1.21.9).
- Built against NeoForge 26.3.0.16-beta and Forge 1.21.5-55.1.14.
release
4.3.3+26.x-plugin
4.3.3+26.x-plugin20 сент. 2026 г.259Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.3
4.3.3+26.320 сент. 2026 г.1,1 тыс.Minecraft: 26.3fabric
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.3-neoforge
4.3.3+26.3-neoforge20 сент. 2026 г.57Minecraft: 26.3neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.2
4.3.3+26.220 сент. 2026 г.545Minecraft: 26.2fabric
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.2-neoforge
4.3.3+26.2-neoforge20 сент. 2026 г.57Minecraft: 26.2neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.1
4.3.3+26.120 сент. 2026 г.127Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+26.1-neoforge
4.3.3+26.1-neoforge20 сент. 2026 г.65Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.x-plugin
4.3.3+1.21.x-plugin20 сент. 2026 г.75Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.8
4.3.3+1.21.820 сент. 2026 г.39Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.8-neoforge
4.3.3+1.21.8-neoforge20 сент. 2026 г.32Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.8-forge
4.3.3+1.21.8-forge20 сент. 2026 г.12Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.5
4.3.3+1.21.520 сент. 2026 г.24Minecraft: 1.21.5fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.5-forge
4.3.3+1.21.5-forge20 сент. 2026 г.26Minecraft: 1.21.5forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.4
4.3.3+1.21.420 сент. 2026 г.11Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.4-neoforge
4.3.3+1.21.4-neoforge20 сент. 2026 г.4Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.4-forge
4.3.3+1.21.4-forge20 сент. 2026 г.2Minecraft: 1.21.3, 1.21.4forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.11
4.3.3+1.21.1120 сент. 2026 г.128Minecraft: 1.21.11fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.11-neoforge
4.3.3+1.21.11-neoforge20 сент. 2026 г.15Minecraft: 1.21.11neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.11-forge
4.3.3+1.21.11-forge20 сент. 2026 г.16Minecraft: 1.21.11forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.10
4.3.3+1.21.1020 сент. 2026 г.15Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.10-neoforge
4.3.3+1.21.10-neoforge20 сент. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.10-forge
4.3.3+1.21.10-forge20 сент. 2026 г.4Minecraft: 1.21.10forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.1
4.3.3+1.21.120 сент. 2026 г.166Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.1-neoforge
4.3.3+1.21.1-neoforge20 сент. 2026 г.750Minecraft: 1.21, 1.21.1neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.21.1-forge
4.3.3+1.21.1-forge20 сент. 2026 г.15Minecraft: 1.21, 1.21.1forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.x-plugin
4.3.3+1.20.x-plugin20 сент. 2026 г.2Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.6
4.3.3+1.20.620 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.6-neoforge
4.3.3+1.20.6-neoforge20 сент. 2026 г.4Minecraft: 1.20.6neoforge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.6-forge
4.3.3+1.20.6-forge20 сент. 2026 г.2Minecraft: 1.20.6forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.4
4.3.3+1.20.420 сент. 2026 г.15Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.4-forge
4.3.3+1.20.4-forge20 сент. 2026 г.3Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.1
4.3.3+1.20.120 сент. 2026 г.142Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.3+1.20.1-forge
4.3.3+1.20.1-forge20 сент. 2026 г.348Minecraft: 1.20.1forge
Что нового
4.3.2 stopped the pre-gen latching forever. It did not stop it pausing OFTEN, and on a two-core
client the run settled into a fixed-period pause/resume/fail cycle instead. Reported on
mod_support #36 by the reporter of #33, who confirmed the latch is gone and that the run now
"pauses too often. Thus slowing down pregeneration."
**A resumed run kept its narrow start for about one sample.** It came back below the width that
failed, as intended -- and then reset its slow-start threshold to the CONFIGURED CEILING, which is
the value that decides how fast it is allowed to widen again. Below that threshold the recovery
path may climb eight steps per sample, so a run resumed at a width of 1 was permitted to burst
straight back toward a ceiling of 200 and into the wall that had just stopped it. Resuming narrow
bought nothing. A resumed run now inherits the width that FAILED as its threshold, so the climb
stops where the evidence stops.
**The resume grace no longer answers the third failure the same way it answered the first.** It was
a flat five seconds, which is the right answer to a passing autosave and the wrong answer to a
machine that has already failed at this repeatedly -- it is what let the oscillation sustain
itself. It now doubles on each consecutive auto-pause, bounded by the pause-side grace and by 60
seconds. Only a width HELD healthily clears the escalation: coming back is not success, staying
back is.
**Two log lines were stating the wrong number.** The auto-pause notice and the auto-resume notice
both printed the PAUSE grace where they meant the RESUME grace -- so a run that came back after
five seconds announced it had waited two minutes. Both now print what they actually waited, and
the pause notice says which repeat it is.
**The below-floor clock was decoupled from the resume clock.** It had been read off the resume
grace doubled, which was harmless while that was a constant and would have become a trap the
moment it started escalating: being more patient about resuming would silently have made the
controller slower to narrow.
release
4.3.2+26.x-plugin
4.3.2+26.x-plugin20 сент. 2026 г.77Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.3
4.3.2+26.320 сент. 2026 г.407Minecraft: 26.3fabric
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.3-neoforge
4.3.2+26.3-neoforge20 сент. 2026 г.43Minecraft: 26.3neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.2
4.3.2+26.220 сент. 2026 г.193Minecraft: 26.2fabric
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.2-neoforge
4.3.2+26.2-neoforge20 сент. 2026 г.30Minecraft: 26.2neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.1
4.3.2+26.120 сент. 2026 г.54Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+26.1-neoforge
4.3.2+26.1-neoforge20 сент. 2026 г.26Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.x-plugin
4.3.2+1.21.x-plugin20 сент. 2026 г.47Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.8
4.3.2+1.21.820 сент. 2026 г.28Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.8-neoforge
4.3.2+1.21.8-neoforge20 сент. 2026 г.16Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.8-forge
4.3.2+1.21.8-forge20 сент. 2026 г.29Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.5
4.3.2+1.21.520 сент. 2026 г.14Minecraft: 1.21.5fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.5-forge
4.3.2+1.21.5-forge20 сент. 2026 г.41Minecraft: 1.21.5forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.4
4.3.2+1.21.420 сент. 2026 г.7Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.4-neoforge
4.3.2+1.21.4-neoforge20 сент. 2026 г.1Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.4-forge
4.3.2+1.21.4-forge20 сент. 2026 г.2Minecraft: 1.21.3, 1.21.4forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.11
4.3.2+1.21.1120 сент. 2026 г.37Minecraft: 1.21.11fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.11-neoforge
4.3.2+1.21.11-neoforge20 сент. 2026 г.4Minecraft: 1.21.11neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.11-forge
4.3.2+1.21.11-forge20 сент. 2026 г.4Minecraft: 1.21.11forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.10
4.3.2+1.21.1020 сент. 2026 г.7Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.10-neoforge
4.3.2+1.21.10-neoforge20 сент. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.10-forge
4.3.2+1.21.10-forge20 сент. 2026 г.1Minecraft: 1.21.10forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.1
4.3.2+1.21.120 сент. 2026 г.55Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.1-neoforge
4.3.2+1.21.1-neoforge20 сент. 2026 г.269Minecraft: 1.21, 1.21.1neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.21.1-forge
4.3.2+1.21.1-forge20 сент. 2026 г.3Minecraft: 1.21, 1.21.1forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.x-plugin
4.3.2+1.20.x-plugin20 сент. 2026 г.3Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.6
4.3.2+1.20.620 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.6-neoforge
4.3.2+1.20.6-neoforge20 сент. 2026 г.1Minecraft: 1.20.6neoforge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.6-forge
4.3.2+1.20.6-forge20 сент. 2026 г.0Minecraft: 1.20.6forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.4
4.3.2+1.20.420 сент. 2026 г.5Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.4-forge
4.3.2+1.20.4-forge20 сент. 2026 г.1Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.1
4.3.2+1.20.120 сент. 2026 г.50Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.2+1.20.1-forge
4.3.2+1.20.1-forge20 сент. 2026 г.110Minecraft: 1.20.1forge
Что нового
A pre-gen that auto-paused could never start again on a modest machine, and said nothing at all
while it sat there. Reported on mod_support #33: a run stopped at 5.08% with the CPU idle and
"no warnings, no errors, nothing" in the log. 4.3.1 fixed a different bug in the same area -- it
stopped a stopped run being RECORDED as finished -- and did not touch the stop itself.
**Server operators: two of these change behaviour on a healthy dedicated server too, not only on a
weak client.** An auto-pause now ends in seconds rather than minutes, and a struggling run narrows
its dispatch width below 8 where it previously stopped instead.
### Fixed
- **A paused pre-gen could not resume on a machine whose tick cost exceeds 55ms.** The resume test
was two hard-coded numbers -- `mspt <= 55` and `heap < 70` -- while the PAUSE side is entirely
relative: heap from `throttleMaxHeapPercent`, and tick from the adaptive `TickBudget` target,
which is allowed as high as the 150ms ceiling. The two sides were answering different questions,
so on any machine whose own baseline tick cost is above ~55ms the resume condition was
unreachable by construction. Stopping even made it LOOK further away than it was: once dispatch
halts, the baseline re-learns what the machine costs on its own and the effective target rises to
meet it -- the run has become sustainable -- while the fixed 55ms test keeps asking the machine
to be faster than it has ever been. Both arms now use the pause side's own references.
- **A pause could not be short even in principle.** Pausing and resuming shared one grace setting,
120 seconds by default. That patience is right on the way IN, where it stops an autosave killing
a healthy run, and wrong on the way OUT, where it costs the whole run. The resume side now has
its own grace, capped at 5 seconds.
- **Auto-pause fired while there was still room to simply slow down.** It triggered on elapsed time
alone, with no test for whether narrowing had been tried. It now requires the dispatch width to
be at its minimum first, and the width can fall below the comfort floor of 8, one step at a time,
before stopping is considered at all. A resumed run reopens at half the width that failed rather
than climbing straight back into the wall it was stopped by.
- **The whole mechanism was silent.** Every notice auto-pause had went to the console sender -- a
chat channel, not the log -- so on a client-hosted world nothing was written down anywhere, and a
stop was indistinguishable from a hang. It now logs the countdown starting, the countdown being
cancelled by a recovery, the pause (with the condition that tripped it, the tick and heap
numbers behind the decision, and the percentage it stopped at), and the resume.
### Changed
- **The LOD auto-enable notice was telling operators its cost was zero.** It printed "~5.8 KB/chunk;
measured cost to pregen speed: none". Measured on one machine, same heap, same radius, virgin
ground per arm: **108.5 chunks/sec with LOD off against 50.6 with it on**, and about 12 KB/chunk
of store rather than 5.8. LOD generation roughly halves pre-gen throughput. The notice now says
so. Nothing about LOD itself changed -- only the claim made about it. This also explains why a
dedicated server pre-gens slower than a client: LOD auto-enables on a dedicated server and stays
off on a client.
release
4.3.1+26.x-plugin
4.3.1+26.x-plugin19 сент. 2026 г.118Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.3
4.3.1+26.319 сент. 2026 г.424Minecraft: 26.3fabric
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.3-neoforge
4.3.1+26.3-neoforge19 сент. 2026 г.27Minecraft: 26.3neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.2
4.3.1+26.219 сент. 2026 г.218Minecraft: 26.2fabric
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.2-neoforge
4.3.1+26.2-neoforge19 сент. 2026 г.46Minecraft: 26.2neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.1
4.3.1+26.119 сент. 2026 г.47Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+26.1-neoforge
4.3.1+26.1-neoforge19 сент. 2026 г.28Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.x-plugin
4.3.1+1.21.x-plugin19 сент. 2026 г.33Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.8
4.3.1+1.21.819 сент. 2026 г.18Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.8-neoforge
4.3.1+1.21.8-neoforge19 сент. 2026 г.14Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.8-forge
4.3.1+1.21.8-forge19 сент. 2026 г.12Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.5
4.3.1+1.21.519 сент. 2026 г.39Minecraft: 1.21.5fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.5-forge
4.3.1+1.21.5-forge19 сент. 2026 г.12Minecraft: 1.21.5forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.4
4.3.1+1.21.419 сент. 2026 г.6Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.4-neoforge
4.3.1+1.21.4-neoforge19 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.4-forge
4.3.1+1.21.4-forge19 сент. 2026 г.3Minecraft: 1.21.3, 1.21.4forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.11
4.3.1+1.21.1119 сент. 2026 г.50Minecraft: 1.21.11fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.11-neoforge
4.3.1+1.21.11-neoforge19 сент. 2026 г.3Minecraft: 1.21.11neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.11-forge
4.3.1+1.21.11-forge19 сент. 2026 г.6Minecraft: 1.21.11forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.10
4.3.1+1.21.1019 сент. 2026 г.5Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.10-neoforge
4.3.1+1.21.10-neoforge19 сент. 2026 г.0Minecraft: 1.21.9, 1.21.10neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.10-forge
4.3.1+1.21.10-forge19 сент. 2026 г.3Minecraft: 1.21.10forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.1
4.3.1+1.21.119 сент. 2026 г.66Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.1-neoforge
4.3.1+1.21.1-neoforge19 сент. 2026 г.271Minecraft: 1.21, 1.21.1neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.21.1-forge
4.3.1+1.21.1-forge19 сент. 2026 г.1Minecraft: 1.21, 1.21.1forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.x-plugin
4.3.1+1.20.x-plugin19 сент. 2026 г.0Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.6
4.3.1+1.20.619 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.6-neoforge
4.3.1+1.20.6-neoforge19 сент. 2026 г.1Minecraft: 1.20.6neoforge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.6-forge
4.3.1+1.20.6-forge19 сент. 2026 г.4Minecraft: 1.20.6forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.4
4.3.1+1.20.419 сент. 2026 г.8Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.4-forge
4.3.1+1.20.4-forge19 сент. 2026 г.4Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.1
4.3.1+1.20.119 сент. 2026 г.51Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.1+1.20.1-forge
4.3.1+1.20.1-forge19 сент. 2026 г.118Minecraft: 1.20.1forge
Что нового
A world-enter pregen that stopped early was recorded as having finished, and the world was then
skipped forever. Reported on mod_support #35: a 5000-block radius produced a partial area, and on
re-entry Chunksmith announced the world was already pre-generated and refused to run again. The
resume-on-re-entry behaviour that makes a large radius workable at all was the exact thing being
destroyed -- a 5000-block radius is about 306,000 chunks, which nobody finishes in one sitting.
### Fixed
- **The world-enter pregen treated "the task ended" as "the work finished".** It recorded completion
from `GenerationCompleteEvent`, which `GenerationTask` fires from the single end-of-task path that
a genuine exhaustion of the iterator, a cancel, a pause and an **auto-pause** all reach. The task's
own comment beside that line already said it: *"Ending a task is not the same as finishing the
work."* Auto-pause is the likely trigger in the wild -- when the server cannot keep up,
`GenerationTask` deliberately stops rather than stutter and expects the resume watcher to pick the
run back up, which is correct behaviour and is not being changed here. What was wrong is that
stopping made Chunksmith write `worldenter-done.json` with the **configured** radius, describing a
run that had covered a fraction of it. `WorldEnterDone.satisfies()` then did its job perfectly and
skipped that world on every subsequent load.
- Completion is now recorded only when the task itself reports the selection covered. The progress
event already carries that verdict (`GenerationTask.update()` sets `complete` only when
`chunkIterator.total() - finishedChunks == 0`), so the number being trusted is the task's own
iterator total rather than this feature's `estimateChunks()` circle-area approximation -- which is
documented as inexact and has no business deciding whether a permanent record gets written.
- **The world is released either way.** Whatever ended the task, the player is behind a frozen world
and a progress screen, and leaving them there is the one outcome that is never acceptable. Only the
permanent record is now conditional.
- **The log stops lying.** A run that ends short says how far it got, that it is deliberately not
being recorded, that it will resume on the next load, and that an auto-pause above is the usual
reason. It previously said "world-enter pregen finished; releasing the world. It will not run again
on this world." on exactly this path, with a `Task stopped` line immediately above it.
### Notes
- **If a world is already stuck, it stays stuck until the record is removed** -- this build cannot
un-write what a previous one recorded. Delete `<world>/chunksmith/worldenter-done.json`, or raise
`worldEnterPregenRadius` above the recorded value, and the feature re-arms.
- No change to auto-pause, to the radius, to the shape, or to the selection. The reported symptom of
a square area is what a partial concentric run looks like: the pattern walks square rings outward
from the centre, so a run that stops early leaves a filled square well inside the circular
selection. That part was working as designed and only looked wrong because it had been declared
finished.
release
4.3.0+26.x-plugin
4.3.0+26.x-plugin18 сент. 2026 г.24Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.3
4.3.0+26.318 сент. 2026 г.189Minecraft: 26.3fabric
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.3-neoforge
4.3.0+26.3-neoforge18 сент. 2026 г.7Minecraft: 26.3neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.2
4.3.0+26.218 сент. 2026 г.136 тыс.Minecraft: 26.2fabric
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.2-neoforge
4.3.0+26.2-neoforge18 сент. 2026 г.6Minecraft: 26.2neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.1
4.3.0+26.118 сент. 2026 г.19Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+26.1-neoforge
4.3.0+26.1-neoforge18 сент. 2026 г.6Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.x-plugin
4.3.0+1.21.x-plugin18 сент. 2026 г.23Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.8
4.3.0+1.21.818 сент. 2026 г.3Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.8-neoforge
4.3.0+1.21.8-neoforge18 сент. 2026 г.3Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.8-forge
4.3.0+1.21.8-forge18 сент. 2026 г.2Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.5
4.3.0+1.21.518 сент. 2026 г.4Minecraft: 1.21.5fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.5-forge
4.3.0+1.21.5-forge18 сент. 2026 г.5Minecraft: 1.21.5forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.4
4.3.0+1.21.418 сент. 2026 г.7Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.4-neoforge
4.3.0+1.21.4-neoforge18 сент. 2026 г.3Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.4-forge
4.3.0+1.21.4-forge18 сент. 2026 г.2Minecraft: 1.21.3, 1.21.4forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.11
4.3.0+1.21.1118 сент. 2026 г.24Minecraft: 1.21.11fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.11-neoforge
4.3.0+1.21.11-neoforge18 сент. 2026 г.0Minecraft: 1.21.11neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.11-forge
4.3.0+1.21.11-forge18 сент. 2026 г.0Minecraft: 1.21.11forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.10
4.3.0+1.21.1018 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.10-neoforge
4.3.0+1.21.10-neoforge18 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.10-forge
4.3.0+1.21.10-forge18 сент. 2026 г.2Minecraft: 1.21.10forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.1
4.3.0+1.21.118 сент. 2026 г.44Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.1-neoforge
4.3.0+1.21.1-neoforge18 сент. 2026 г.196Minecraft: 1.21, 1.21.1neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.21.1-forge
4.3.0+1.21.1-forge18 сент. 2026 г.6Minecraft: 1.21, 1.21.1forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.x-plugin
4.3.0+1.20.x-plugin18 сент. 2026 г.3Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.6
4.3.0+1.20.618 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.6-neoforge
4.3.0+1.20.6-neoforge18 сент. 2026 г.1Minecraft: 1.20.6neoforge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.6-forge
4.3.0+1.20.6-forge18 сент. 2026 г.1Minecraft: 1.20.6forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.4
4.3.0+1.20.418 сент. 2026 г.3Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.4-forge
4.3.0+1.20.4-forge18 сент. 2026 г.2Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.1
4.3.0+1.20.118 сент. 2026 г.16Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.3.0+1.20.1-forge
4.3.0+1.20.1-forge18 сент. 2026 г.64Minecraft: 1.20.1forge
Что нового
The world-enter pregen always centred on (0, 0). Any mod that moves world spawn -- and plenty do --
therefore had it pregenerate the wrong part of the world: the player waits behind a progress screen
while terrain nobody is going to stand on is built, and the terrain around them is generated on foot
afterwards anyway. Reported on mod_support #34.
### Added
- **`worldEnterPregenCenter`** -- where the world-enter pregen is centred. `origin` (the default,
and what every existing world already did), `spawn` to follow the world's spawn point, or an
explicit `x,z`. Settable in `config/chunksmith/config.json` or with
`/cs set worldEnterPregenCenter spawn`.
In a command the coordinate form needs quotes -- `/cs set worldEnterPregenCenter "512,-64"` --
because an unquoted command argument cannot contain a comma. `origin` and `spawn` need no quotes,
and the config file takes the bare form either way. All three were checked on a live server, not
assumed: the unquoted pair is the one thing that does not parse, and it fails loudly rather than
storing something nobody asked for.
- **The server now tells you when no client has ever reached the LOD backchannel.** It has always
logged the port at startup and said to open it; three separate operators have now missed that line
in a modded server's boot spam and reported the symptom instead. The server can tell the
difference on its own -- a client is connected, a download credential was issued, and yet nothing
has served AND nothing has been rejected, which together mean no request ever arrived -- so it
says so, once, to the operator, at the moment it matters rather than at boot. Throttled to one
message per player every ten minutes.
The consequence differs by platform and the message says which applies to you: on the mod the LOD
falls back to the game connection, so it still arrives, just slowly. **The plugin has no such
fallback, so an unreachable backchannel there means no LOD at all** -- which makes the plugin the
side that needed this notice most, and the side that did not have it until now.
The notice now also names the cause it used to leave out. `lodBackchannelBindAddress` defaults to
empty, which means "bind wherever the game bound" -- that is, whatever `server-ip=` says in
server.properties. Unset, which is the normal case, that is every interface and all is well. But a
hosted panel behind a proxy routinely sets `server-ip=127.0.0.1`, and the backchannel then binds
loopback only: unreachable however carefully the port is forwarded, and producing exactly the
signature this notice fires on. It now says so, and gives the override --
`/cs set lodBackchannelBindAddress 0.0.0.0`.
- **`/cs set` names the accepted forms when it refuses a value.** A rejected setting used to say
only that the value was invalid, leaving you to guess the shape it wanted.
### Fixed
- **`/cs status` and `/cs progress` could answer with silence while a pregen was running.** Both
read the list of tasks, then printed only those whose world matched one the server currently
listed -- and when none matched they printed nothing at all, not even "no tasks", because there
were tasks. A player watching chunks generate could ask what was running and be told nothing, in
two different ways. Both now report every task they hold; each line already named its own world,
so the filtering was never buying anything. Reported on mod_support #33.
- **The world-enter estimate no longer swings by an hour between redraws.** Reported from real play:
"time remaining" jumping from 1-2 hours down to 30 minutes, several times a second. The estimate
is measured over a window of eight samples, which was written for samples about a second apart --
but it is fed `GenerationProgressEvent`, which fires once per finished chunk, throttled to ten a
second rather than to one. Eight of those is under a second of history, so on a bursty run the
"rate" was whichever side of a burst it happened to catch. Samples closer together than a second
are now ignored, so the window really is the few seconds it claims to be.
Nothing about the window length or the arithmetic was wrong; the samples were simply arriving an
order of magnitude faster than the code consuming them assumed. A rate is only as meaningful as
the interval it is measured over.
### Changed
- **Every cell was rebuilt against a current loader and a current fabric-api.** This is not a
behaviour change; it is a coverage one. The pins had drifted -- NeoForge 26.3 was three betas
behind, 26.2 four builds, and several pre-26 cells more -- and because the declared ranges are
deliberately wider than the build pins, nothing was ever broken by it: the jars loaded on the
newer loaders perfectly well. What had drifted was that the jars players run were not the jars
that were tested. NeoForge is now 26.1 `26.1.2.109` / 26.2 `26.2.0.88` / 26.3 `26.3.0.4-beta`,
fabric-api 26.1 `0.155.3` / 26.2 `0.160.0` / 26.3 `0.160.7`, and the pre-26 Forge and NeoForge
cells are current too.
**Forge 1.21.11 is the one exception and stays at `61.1.0`:** newer builds on that line cannot be
built here at all, because ForgeGradle 6 throws `duplicate entry: mcp/client/Start.class` while
assembling the mapped artifact. The published Forge bundles are not at fault -- they carry no
duplicate -- and `61.1.0` succeeds only because its artifact was derived months ago and is still
cached. That jar declares `[61,)` with an open upper bound, so it loads on newer 61.x regardless.
- **The completion record now stores the centre as well as the radius.** It already stored the
radius so that raising `worldEnterPregenRadius` could re-arm a world that had been finished at a
smaller one. The centre needs the same treatment for the same reason: without it, changing the
centre on a world already recorded as done would be silently ignored forever, which is the exact
failure the stored radius exists to prevent.
release
4.2.0+26.x-plugin
4.2.0+26.x-plugin17 сент. 2026 г.122Minecraft: 26.1, 26.1.1, 26.1.2, 26.2, 26.3bukkit, paper, spigot
Что нового
Minecraft 26.3 shipped stable on 15 September. The 26.3 jar that was live before this release could
not load on it at all -- not degraded, absent -- because every 26.3 pre-release moved the resource
pack format, so that jar was pinned to exactly one build and 26.3 stable was a different one. This
release ends that: 26.3 is a settled line now and takes the same closed range every other 26.X line
has, so one jar serves 26.3 and everything after it up to 26.4.
### Added
- **NeoForge on 26.3.** The first NeoForge build Chunksmith has ever shipped for a 26.3 line --
NeoForge only published a 26.3 loader (26.3.0.1-beta) this week, which is why the line was
Fabric-only until now. Requires NeoForge 26.3.0-alpha or newer.
### Changed
- **The Fabric 26.3 jar now declares `>=26.3- <26.4` instead of a single exact build.** It is the
same range shape 26.1 and 26.2 have carried since they settled. Nothing about the mod changed
between 26.3-rc-1 and 26.3 stable; the eight files Mojang touched are window handling, the
multiplayer screen and version stamps.
- **The Bukkit / Paper / Spigot plugin now claims 26.3.** One plugin jar already covered the whole
26 line; this is the metadata catching up so the 26.3 build is listed for it.
release
4.2.0+26.3
4.2.0+26.317 сент. 2026 г.672Minecraft: 26.3fabric
Что нового
Minecraft 26.3 shipped stable on 15 September. The 26.3 jar that was live before this release could
not load on it at all -- not degraded, absent -- because every 26.3 pre-release moved the resource
pack format, so that jar was pinned to exactly one build and 26.3 stable was a different one. This
release ends that: 26.3 is a settled line now and takes the same closed range every other 26.X line
has, so one jar serves 26.3 and everything after it up to 26.4.
### Added
- **NeoForge on 26.3.** The first NeoForge build Chunksmith has ever shipped for a 26.3 line --
NeoForge only published a 26.3 loader (26.3.0.1-beta) this week, which is why the line was
Fabric-only until now. Requires NeoForge 26.3.0-alpha or newer.
### Changed
- **The Fabric 26.3 jar now declares `>=26.3- <26.4` instead of a single exact build.** It is the
same range shape 26.1 and 26.2 have carried since they settled. Nothing about the mod changed
between 26.3-rc-1 and 26.3 stable; the eight files Mojang touched are window handling, the
multiplayer screen and version stamps.
- **The Bukkit / Paper / Spigot plugin now claims 26.3.** One plugin jar already covered the whole
26 line; this is the metadata catching up so the 26.3 build is listed for it.
release
4.2.0+26.3-neoforge
4.2.0+26.3-neoforge17 сент. 2026 г.39Minecraft: 26.3neoforge
Что нового
Minecraft 26.3 shipped stable on 15 September. The 26.3 jar that was live before this release could
not load on it at all -- not degraded, absent -- because every 26.3 pre-release moved the resource
pack format, so that jar was pinned to exactly one build and 26.3 stable was a different one. This
release ends that: 26.3 is a settled line now and takes the same closed range every other 26.X line
has, so one jar serves 26.3 and everything after it up to 26.4.
### Added
- **NeoForge on 26.3.** The first NeoForge build Chunksmith has ever shipped for a 26.3 line --
NeoForge only published a 26.3 loader (26.3.0.1-beta) this week, which is why the line was
Fabric-only until now. Requires NeoForge 26.3.0-alpha or newer.
### Changed
- **The Fabric 26.3 jar now declares `>=26.3- <26.4` instead of a single exact build.** It is the
same range shape 26.1 and 26.2 have carried since they settled. Nothing about the mod changed
between 26.3-rc-1 and 26.3 stable; the eight files Mojang touched are window handling, the
multiplayer screen and version stamps.
- **The Bukkit / Paper / Spigot plugin now claims 26.3.** One plugin jar already covered the whole
26 line; this is the metadata catching up so the 26.3 build is listed for it.
release
4.1.0+26.x-plugin
4.1.0+26.x-plugin16 сент. 2026 г.80Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, paper, spigot
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
beta
4.1.0+26.3
4.1.0+26.316 сент. 2026 г.34Minecraft: 26.3-rc-1fabric
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+26.2
4.1.0+26.216 сент. 2026 г.384Minecraft: 26.2fabric
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+26.2-neoforge
4.1.0+26.2-neoforge16 сент. 2026 г.30Minecraft: 26.2neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+26.1
4.1.0+26.116 сент. 2026 г.59Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+26.1-neoforge
4.1.0+26.1-neoforge16 сент. 2026 г.21Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.x-plugin
4.1.0+1.21.x-plugin16 сент. 2026 г.51Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.8
4.1.0+1.21.816 сент. 2026 г.21Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.8-neoforge
4.1.0+1.21.8-neoforge16 сент. 2026 г.12Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.8-forge
4.1.0+1.21.8-forge16 сент. 2026 г.2Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.5
4.1.0+1.21.516 сент. 2026 г.4Minecraft: 1.21.5fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.5-forge
4.1.0+1.21.5-forge16 сент. 2026 г.1Minecraft: 1.21.5forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.4
4.1.0+1.21.416 сент. 2026 г.22Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.4-neoforge
4.1.0+1.21.4-neoforge16 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.4-forge
4.1.0+1.21.4-forge16 сент. 2026 г.6Minecraft: 1.21.3, 1.21.4forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.11
4.1.0+1.21.1116 сент. 2026 г.103Minecraft: 1.21.11fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.11-neoforge
4.1.0+1.21.11-neoforge16 сент. 2026 г.9Minecraft: 1.21.11neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.11-forge
4.1.0+1.21.11-forge16 сент. 2026 г.12Minecraft: 1.21.11forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.10
4.1.0+1.21.1016 сент. 2026 г.9Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.10-neoforge
4.1.0+1.21.10-neoforge16 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.10-forge
4.1.0+1.21.10-forge16 сент. 2026 г.1Minecraft: 1.21.10forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.1
4.1.0+1.21.116 сент. 2026 г.107Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.1-neoforge
4.1.0+1.21.1-neoforge16 сент. 2026 г.514Minecraft: 1.21, 1.21.1neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.21.1-forge
4.1.0+1.21.1-forge16 сент. 2026 г.8Minecraft: 1.21, 1.21.1forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.x-plugin
4.1.0+1.20.x-plugin16 сент. 2026 г.3Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.6
4.1.0+1.20.616 сент. 2026 г.6Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.6-neoforge
4.1.0+1.20.6-neoforge16 сент. 2026 г.1Minecraft: 1.20.6neoforge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.6-forge
4.1.0+1.20.6-forge16 сент. 2026 г.3Minecraft: 1.20.6forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.4
4.1.0+1.20.416 сент. 2026 г.16Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.4-forge
4.1.0+1.20.4-forge16 сент. 2026 г.0Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.1
4.1.0+1.20.116 сент. 2026 г.90Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.1.0+1.20.1-forge
4.1.0+1.20.1-forge16 сент. 2026 г.243Minecraft: 1.20.1forge
Что нового
Pregen throughput. The default pipeline width was wrong on every machine that was not an 8-core
dedicated server, and on the Bukkit plugin it was wrong everywhere.
### Changed
- **`dispatchMaxConcurrent` now defaults to 200 on every platform, and no longer scales with core
count.** It used to be `cores * 25`, which reads like protecting a small machine and does the
opposite. Benched on a 2-core server (625 chunks, every JVM thread pinned): 8 -> 15.6 cps,
16 -> 17.7, 24 -> 19.5, 50 -> 16.9, 100 -> 21.5, **200 -> 29.8**, 400 -> about 25 and stalling.
The 8-core bench behind the old default agrees: 50 -> 31.6, 200 -> 43.9, 600 -> 42.4. Two
machines four core-counts apart, the same knee -- because a chunk request spends almost all of
its life waiting on vanilla walking it up its statuses, so width buys concurrency against
latency, and latency does not shrink when you remove cores. On two cores the old formula gave 50
and cost that machine 43 percent of its throughput.
- **The Paper / Spigot plugin gets the same default for the first time.** `BukkitConfig` carried
its own hard-coded 50, separate from the mod's, so no plugin server ever saw any dispatch tuning
-- old or new. Both platforms now read one constant.
- **Single-player gets the same 200 as a dedicated server, and that was measured too.** On a
4-core client with voxy and Sodium (16640 chunks, interleaved arms), width 200 took 275s and
298s with a worst pause of 6.0s; width 16 took 458s and 379s with worst pauses of 20.9s and
16.4s. Narrowing the pipeline costs throughput AND makes the longest stall worse; it does not
trade one for the other.
### Fixed
- **The dispatch controller converges instead of oscillating.** It backed off one slot at a time
and then climbed all the way back to the ceiling, so a machine that could not sustain the
ceiling re-entered overload every time it recovered -- generate, pause, generate. A sustained
overload now halves the width instead of stepping, and the controller remembers the widest
setting that ran healthily and will not burst past it. Reported on mod_support #20 and #33.
### Added
- **`/cs debug` reports the dispatch pipeline**, and `/cs diag` is a new alias for it. The width
the controller settled on only ever appeared in a throttle notice and the threshold it steers
against appeared nowhere, so "the pregen keeps pausing" could not be answered by looking.
Requested on mod_support #32.
### Changed (diagnostics)
- **`/csclient status` no longer describes multiplayer when there is no server.** Transport,
token, injected, download and the store counters are the multiplayer client path and are inert
on an integrated server; printed unconditionally they read as a broken feature. It now leads
with the mode and omits what does not apply.
release
4.0.0+26.x-plugin
4.0.0+26.x-plugin13 сент. 2026 г.129Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, paper, spigot
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
beta
4.0.0+26.3
4.0.0+26.313 сент. 2026 г.18Minecraft: 26.3-rc-1fabric
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+26.2
4.0.0+26.213 сент. 2026 г.307Minecraft: 26.2fabric
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+26.2-neoforge
4.0.0+26.2-neoforge13 сент. 2026 г.15Minecraft: 26.2neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+26.1
4.0.0+26.113 сент. 2026 г.75Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+26.1-neoforge
4.0.0+26.1-neoforge13 сент. 2026 г.12Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.x-plugin
4.0.0+1.21.x-plugin13 сент. 2026 г.52Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, paper, spigot
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.8
4.0.0+1.21.813 сент. 2026 г.13Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.8-neoforge
4.0.0+1.21.8-neoforge13 сент. 2026 г.13Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.8-forge
4.0.0+1.21.8-forge13 сент. 2026 г.46Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.5
4.0.0+1.21.513 сент. 2026 г.35Minecraft: 1.21.5fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.5-forge
4.0.0+1.21.5-forge13 сент. 2026 г.21Minecraft: 1.21.5forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.4
4.0.0+1.21.413 сент. 2026 г.6Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.4-neoforge
4.0.0+1.21.4-neoforge13 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.4-forge
4.0.0+1.21.4-forge13 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.11
4.0.0+1.21.1113 сент. 2026 г.81Minecraft: 1.21.11fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.11-neoforge
4.0.0+1.21.11-neoforge13 сент. 2026 г.9Minecraft: 1.21.11neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.11-forge
4.0.0+1.21.11-forge13 сент. 2026 г.1Minecraft: 1.21.11forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.10
4.0.0+1.21.1013 сент. 2026 г.12Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.10-neoforge
4.0.0+1.21.10-neoforge13 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.10-forge
4.0.0+1.21.10-forge13 сент. 2026 г.8Minecraft: 1.21.9, 1.21.10forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.1
4.0.0+1.21.113 сент. 2026 г.150Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.1-neoforge
4.0.0+1.21.1-neoforge13 сент. 2026 г.518Minecraft: 1.21, 1.21.1neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.21.1-forge
4.0.0+1.21.1-forge13 сент. 2026 г.7Minecraft: 1.21, 1.21.1forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.x-plugin
4.0.0+1.20.x-plugin13 сент. 2026 г.5Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, paper, spigot
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.6
4.0.0+1.20.613 сент. 2026 г.0Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.6-neoforge
4.0.0+1.20.6-neoforge13 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6neoforge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.6-forge
4.0.0+1.20.6-forge13 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.4
4.0.0+1.20.413 сент. 2026 г.10Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.4-forge
4.0.0+1.20.4-forge13 сент. 2026 г.1Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.1
4.0.0+1.20.113 сент. 2026 г.68Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
release
4.0.0+1.20.1-forge
4.0.0+1.20.1-forge13 сент. 2026 г.254Minecraft: 1.20.1forge
Что нового
Breaking. The command surface is reorganised by who can run a command and where it executes, and
`/cslod` is retired. Protocol version moves to 4.
### Changed
- **Commands are split by audience, not by feature.** `/cslod` grouped things by subsystem, which put
three client-side operations behind a server permission gate and gave the client's own state no
readout at all. Server operator commands now live under the existing `/cs` root, which already
carries the permission gate; everything a player runs for their own client lives under a new
`/csclient`.
| was | now |
|---|---|
| `/cslod status` | `/cs lod status` |
| `/cslod token <player>` | `/cs lod token <player>` |
| `/cslod set` | `/csclient set` |
| `/cslod inject` | `/csclient inject_voxy` |
| `/cslod dhpush` | `/csclient inject_dh` |
- **`/csclient` is a real client command**, registered through Fabric's
`ClientCommandRegistrationCallback` and NeoForge/Forge's `RegisterClientCommandsEvent`. It therefore
works when connected to a server that has never heard of Chunksmith, which is exactly when you want
to ask why no LODs are arriving. It does not exist on the Bukkit plugin; there is no client there.
- **`inject` and `dhpush` became `inject_voxy` and `inject_dh`.** One was named for its verb and the
other for its target, so neither said what it did.
- **Both status commands print one value per line** instead of a single packed line.
- The per-subcommand operator gates are gone. `/cs` gates at its root, and `/csclient` needs no gate.
- **The client store is keyed to the WORLD, not the server address.** A client used to file LOD under
the host it connected to, so a world that changed address looked brand new and was downloaded again,
while two unrelated worlds behind one address shared a store and overwrote each other. The server now
mints a stable id per world and the client files under that. Stores from before 4.0 are left alone,
listed by `/csclient status` as `pre-4.0 stores`, and cleared by `/csclient reset` when you want the
space back. Against a 3.x server the client falls back to the old host key, because that server has
no id to give.
### Added
- **`/csclient reset`** returns the client to the state it was in before it first connected: the store
for that server is deleted across every dimension, the injected-region bookkeeping is cleared, and
the handshake runs again, all without a relog. Until now the only way out of a bad client store was
to disconnect and delete the directory by hand.
It cannot give you a clean slate on its own, and says so when it runs. Distant Horizons and Voxy keep
their own databases, which Chunksmith does not touch by design, so a world that was regenerated
server-side may still render its old terrain out of the renderer's copy.
- **`/csclient status`** reports the client store: which server it is keyed to, the path, per-dimension
region counts, transport, renderers, injection progress, and the settings in force. It also reports
the **renderer queue depth** -- the number `throttleLodDrainTo` below is measured against. Without it
there was no way to tell whether that setting could ever engage on your machine.
- **`max-disk-mb`** (client) caps what Chunksmith keeps on disk for a world, in megabytes. **Default 0,
meaning no cap**, which is the behaviour every earlier release had: how much a client wrote was
decided entirely by the server's index budget, a number the client cannot see and was never told.
Nearest terrain is kept first.
Declining regions does not put the client into a permanent re-download loop. The summary the two
sides compare is an XOR aggregate, which is its own inverse, so declined regions fold back out of
the server's number exactly and a capped client settles at "I have everything I intend to have".
- **`throttleLodDrainTo`** (server) makes the LOD governor a barrier: stop dispatching entirely and let
the renderer drain to that depth before resuming, rather than merely slowing down. **Default 0,
meaning off, and it should stay off unless you have measured your own machine.**
It is off by default because the measurement argues against it. On a four-core client with voxy the
barrier ran about 11% SLOWER than the existing governor and did not change how often the run paused.
It is here because alternating should beat competing on a machine with no cores to spare -- but that
has not been demonstrated, and guessing the threshold is how a throttle ends up tuned for one box.
### Removed
- **`/cslod` is gone**, and a 4.x client does not register it under any name. See Compatibility.
- The `SETTING_LIST` / `SETTING_SHOW` / `SETTING_SET` relay. A client command reads and writes
`config/chunksmith-lod.properties` directly, so the server no longer has to ask the client on the
player's behalf.
### Plugin (Paper / Spigot)
- **`/cs lod status` and `/cs lod token <player>` work on the plugin too.** Status is reported per
WORLD rather than per dimension, because that is the shape a Bukkit server actually has: the mod
keeps one save folder with its dimensions nested inside, Bukkit gives each world its own folder and
therefore its own store. It answers from the console for the same reason.
- There is no `/csclient` on the plugin and there will not be. That command runs on a client, and a
Bukkit server does not have one.
- The plugin serves the new world id, anchored to the primary world -- the one `level-name` names and
the one the others are derived from, so it is the folder whose replacement really does mean "this is
a different world now".
- **Folia is no longer declared supported.** `folia-supported` is gone from `plugin.yml`, so Folia
will refuse to load the plugin rather than running it untested. This was announced in 3.3.0 and a
major release is where it lands. Nothing changes for Paper or Spigot.
The reasoning is not that Folia is broken -- it is that the Folia harness could not be kept working,
and a platform nobody tests is an unverifiable claim, which is worse than an absent one. The
region-scheduler code paths and the `folia-api` compile dependency are still in the tree and come out
separately; removing them means moving three cells onto `paper-api` and unwinding the JVM-version
workarounds `folia-api` forces, which is its own change and does not belong in this one.
### Compatibility
`CsLodProtocol.VERSION` goes from 2 to **4**, matching the major version from here on. There was never
a protocol 3.
**4.0.0 is a coordinated upgrade: move the server and the client together.** The two protocols do not
interoperate, so a mixed 3.x/4.x pair turns LOD off in BOTH directions -- the client will not fetch and
the server will not serve. Everything else in Chunksmith keeps working; what stops arriving is the
distant terrain.
This is worth saying plainly because a launcher will offer 4.0.0 to anyone running 3.x, so a client can
be updated into the mismatch without the server being touched by anyone. A 4.x client that lands on a
3.x server now says so in chat on join, rather than leaving you to work out why the horizon went empty.
- **4.x server, 4.x client.** `/cslod` does not exist on either side.
- **3.x server, 4.x client.** The client registers no `/cslod`, so the server's own still arrives in the
command tree and `/cslod set` still reaches this client's settings. LOD data does not transfer.
- **4.x server, 3.x client.** `/cslod` answers "update your cs client" and does nothing else.
All of that lives in one `legacy` package and comes out in 5.x.
beta
3.18.2+26.3
3.18.2+26.310 сент. 2026 г.32Minecraft: 26.3-rc-1fabric
Что нового
### Changed
- **The 26.3 target moves from `26.3-pre-3` to `26.3-rc-1`.** This is the whole release. The 26.3
pin is exclusive by construction -- one `pack_format` per jar -- so on rc-1 the `3.18.1+26.3` jar
does not load at all, and "does not load" is the state every 26.3 pre-release leaves the previous
build in. `pack_format` is UNCHANGED at **97** (rc-1's own `version.json` still reads resource
97.1 / data 121.0, the first 26.3 build in a while not to move it), fabric-api goes to
`0.160.3+26.3`, and the dependency predicate is `26.3-rc.1`.
- **No code change was needed.** The pre-3 to rc-1 source diff is 14 text files with nothing added,
removed or binary-changed, and Chunksmith names none of the six symbols it touches. The one that
came closest is `ChunkMap`: rc-1 widened its chunk-load-failure branch to report and substitute an
empty chunk for EVERY non-`Error` cause, where before only `IOException` and `NbtException` took
that path. Chunksmith's `ChunkMapMixin` is accessors plus an `@Invoker` on `tick`
(`visibleChunkMap`, `toDrop`, `unloadQueue`, `pendingUnloads`, `getMainThreadExecutor`), none of
which that branch touches.
### Notes
- **Two rc-1 behaviours change how a pregen run should be READ, not how it runs.**
`SharedConstants.CRASH_EAGERLY` flips to `false` and `BlockableEventLoop` now rethrows only what
`isNonRecoverable` admits, so an exception thrown from a task on the main loop LOGS under the
FATAL marker and the server keeps going. A run that would have crashed on a pre-release comes back
green on rc-1: grep the log, do not trust the exit code. Separately, that widened `ChunkMap`
branch means a chunk that fails to load now yields an EMPTY chunk plus a report instead of
throwing, so a bad chunk can be COUNTED as generated rather than surfacing. Neither is a
Chunksmith change; both are worth knowing before reading a benchmark off this build.
- **fabric-api must be `0.160.3+26.3` or newer on rc-1.** Earlier builds on the line install and
then crash the client: every 26.3 fabric-api declares `depends.minecraft = "~26.3-"`, which cannot
tell one prerelease from another, while `fabric-renderer-api-v1`'s `LevelExtractorMixin` wraps
`lambda$getViewBlockingState$1` -- a lambda rc-1 deleted when it rewrote `getViewBlockingState`.
Match the Modrinth `game_versions` label to the exact build. The dedicated server boots clean on
the wrong API because that mixin is client-only.
beta
3.18.1+26.3
3.18.1+26.310 сент. 2026 г.14Minecraft: 26.3-pre-3fabric
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+26.2
3.18.1+26.210 сент. 2026 г.481Minecraft: 26.2fabric
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+26.2-neoforge
3.18.1+26.2-neoforge10 сент. 2026 г.64Minecraft: 26.2neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+26.1
3.18.1+26.110 сент. 2026 г.84Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+26.1-neoforge
3.18.1+26.1-neoforge10 сент. 2026 г.27Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.8
3.18.1+1.21.810 сент. 2026 г.23Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.8-neoforge
3.18.1+1.21.8-neoforge10 сент. 2026 г.6Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.8-forge
3.18.1+1.21.8-forge10 сент. 2026 г.8Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.5
3.18.1+1.21.510 сент. 2026 г.8Minecraft: 1.21.5fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.5-forge
3.18.1+1.21.5-forge10 сент. 2026 г.6Minecraft: 1.21.5forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.4
3.18.1+1.21.410 сент. 2026 г.20Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.4-neoforge
3.18.1+1.21.4-neoforge10 сент. 2026 г.5Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.4-forge
3.18.1+1.21.4-forge10 сент. 2026 г.5Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.11
3.18.1+1.21.1110 сент. 2026 г.134Minecraft: 1.21.11fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.11-neoforge
3.18.1+1.21.11-neoforge10 сент. 2026 г.12Minecraft: 1.21.11neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.11-forge
3.18.1+1.21.11-forge10 сент. 2026 г.11Minecraft: 1.21.11forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.10
3.18.1+1.21.1010 сент. 2026 г.12Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.10-neoforge
3.18.1+1.21.10-neoforge10 сент. 2026 г.2Minecraft: 1.21.9, 1.21.10neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.10-forge
3.18.1+1.21.10-forge10 сент. 2026 г.6Minecraft: 1.21.9, 1.21.10forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.1
3.18.1+1.21.110 сент. 2026 г.187Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.1-neoforge
3.18.1+1.21.1-neoforge10 сент. 2026 г.785Minecraft: 1.21, 1.21.1neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.21.1-forge
3.18.1+1.21.1-forge10 сент. 2026 г.11Minecraft: 1.21, 1.21.1forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.6
3.18.1+1.20.610 сент. 2026 г.9Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.6-neoforge
3.18.1+1.20.6-neoforge10 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6neoforge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.6-forge
3.18.1+1.20.6-forge10 сент. 2026 г.4Minecraft: 1.20.5, 1.20.6forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.4
3.18.1+1.20.410 сент. 2026 г.25Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.4-forge
3.18.1+1.20.4-forge10 сент. 2026 г.3Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.1
3.18.1+1.20.110 сент. 2026 г.160Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.1+1.20.1-forge
3.18.1+1.20.1-forge10 сент. 2026 г.399Minecraft: 1.20.1forge
Что нового
### Changed
- **An LOD renderer on a DEDICATED SERVER is now reported as an ERROR, in red, instead of a
warning.** Distant Horizons, Voxy and the neo-voxy fork all count. Nothing else changed about it:
Chunksmith starts and runs normally, nothing is refused, and no `breaks` is declared. A renderer is
a client mod -- Chunksmith builds LOD while it pregenerates and serves it to each player's client,
which injects it into the renderer THEY have installed -- so one on the server generates a second
copy of terrain this server is already generating.
The message was already there and was a single grey `WARN` line, which is exactly how it was
missed by the operator it was written for (mod_support #27: nothing was wrong with the mod, and
removing Distant Horizons from the server was the entire fix). It is now a red block that says
what to do, when keeping it is nevertheless correct, and -- because red looks like a crash -- that
Chunksmith itself is fine.
The reasoning is per-renderer, because the reasons differ. Distant Horizons has a server half that
can legitimately serve vanilla DH clients, so the banner names that as the one case for keeping
it, and only a DH report mentions the `/cslod dhpush` console spam. Voxy and neo-voxy have no
server half at all, so they get no such carve-out.
Single-player is untouched. An integrated server runs inside a client that needs its renderer, and
telling that player to remove it would be wrong.
- **Renderers are called what their authors call them.** Every operator-facing line now says
"Distant Horizons", "Voxy" and "neo-voxy" rather than the raw mod ids `distanthorizons`, `voxy`
and `neovoxy`. Detection is still by id -- that is the only name a loader has -- but nobody
installed a mod called `distanthorizons`. This also settles a smaller drift: the startup error and
the LOD auto-enable notice were reading from two different renderer lists, one of which had never
heard of the neo-voxy fork, and printed their two vocabularies two lines apart in the same log.
Both now read from one place.
release
3.18.0+26.x-plugin
3.18.0+26.x-plugin5 сент. 2026 г.417Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, folia, paper, spigot
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
beta
3.18.0+26.3
3.18.0+26.35 сент. 2026 г.59Minecraft: 26.3-pre-2fabric
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+26.2
3.18.0+26.25 сент. 2026 г.569Minecraft: 26.2fabric
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+26.2-neoforge
3.18.0+26.2-neoforge5 сент. 2026 г.46Minecraft: 26.2neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+26.1
3.18.0+26.15 сент. 2026 г.98Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+26.1-neoforge
3.18.0+26.1-neoforge5 сент. 2026 г.48Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.x-plugin
3.18.0+1.21.x-plugin5 сент. 2026 г.123Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, folia, paper, spigot
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.8
3.18.0+1.21.85 сент. 2026 г.29Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.8-neoforge
3.18.0+1.21.8-neoforge5 сент. 2026 г.11Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.8-forge
3.18.0+1.21.8-forge5 сент. 2026 г.19Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.5
3.18.0+1.21.55 сент. 2026 г.27Minecraft: 1.21.5fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.5-forge
3.18.0+1.21.5-forge5 сент. 2026 г.7Minecraft: 1.21.5forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.4
3.18.0+1.21.45 сент. 2026 г.29Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.4-neoforge
3.18.0+1.21.4-neoforge5 сент. 2026 г.13Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.4-forge
3.18.0+1.21.4-forge5 сент. 2026 г.5Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.11
3.18.0+1.21.115 сент. 2026 г.150Minecraft: 1.21.11fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.11-neoforge
3.18.0+1.21.11-neoforge5 сент. 2026 г.25Minecraft: 1.21.11neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.11-forge
3.18.0+1.21.11-forge5 сент. 2026 г.20Minecraft: 1.21.11forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.10
3.18.0+1.21.105 сент. 2026 г.19Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.10-neoforge
3.18.0+1.21.10-neoforge5 сент. 2026 г.10Minecraft: 1.21.9, 1.21.10neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.10-forge
3.18.0+1.21.10-forge5 сент. 2026 г.8Minecraft: 1.21.9, 1.21.10forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.1
3.18.0+1.21.15 сент. 2026 г.256Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.1-neoforge
3.18.0+1.21.1-neoforge5 сент. 2026 г.1 тыс.Minecraft: 1.21, 1.21.1neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.21.1-forge
3.18.0+1.21.1-forge5 сент. 2026 г.15Minecraft: 1.21, 1.21.1forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.x-plugin
3.18.0+1.20.x-plugin5 сент. 2026 г.16Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, folia, paper, spigot
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.6
3.18.0+1.20.65 сент. 2026 г.7Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.6-neoforge
3.18.0+1.20.6-neoforge5 сент. 2026 г.6Minecraft: 1.20.5, 1.20.6neoforge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.6-forge
3.18.0+1.20.6-forge5 сент. 2026 г.10Minecraft: 1.20.5, 1.20.6forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.4
3.18.0+1.20.45 сент. 2026 г.18Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.4-forge
3.18.0+1.20.4-forge5 сент. 2026 г.7Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.1
3.18.0+1.20.15 сент. 2026 г.167Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
release
3.18.0+1.20.1-forge
3.18.0+1.20.1-forge5 сент. 2026 г.449Minecraft: 1.20.1forge
Что нового
### Added
- **World-enter pre-generation comes to Minecraft 1.20 through 1.21.11.** The feature that shipped in
3.17.0 for 26.x only -- your single-player world pre-generates itself behind a progress screen
before you start playing it, and the world (you included) is held still while it runs -- now works
all the way down to 1.20. Same settings, same behaviour: `worldEnterPregen` to turn it off,
`worldEnterPregenRadius` to size it.
Covered: **every 1.21 release, 1.21 through 1.21.11**, and **1.20 through 1.20.6**, on Fabric,
NeoForge and Forge wherever each loader exists there. The gaps are the loaders' own, not the
feature's -- Forge never shipped a 1.21.2 or 1.20.3 build, and Forge 1.21.9 is unsupported
everywhere.
**Below 1.20.5, Chunksmith supplies the freeze itself.** Minecraft gained a tick freeze in 1.20.3;
before that there was nothing to borrow. Rather than leave those versions out, Chunksmith re-adds
the same guards Minecraft's own freeze uses, so the world is held exactly as it is everywhere else
-- and pre-generation keeps running behind the screen, which is the whole point.
Otherwise very little changed to get here. The tick freeze is identical from 1.20.3 to the current
snapshots, so holding the world needed no per-version work at all. What genuinely differs is small:
26.1 renamed the screen's render entry point and its centred-text call, 1.21.11 moved the
time-advance game rule to a new package and changed how it is both read and written, and older
Forge builds report a client tick differently. Those are the seams; the rest is one shared source.
beta
3.17.2+26.3
3.17.2+26.34 сент. 2026 г.31Minecraft: 26.3-pre-2fabric
Что нового
### Changed
- **The 26.3 build now targets `26.3-pre-2`.** Chunksmith pins its 26.3 jar to one exact
Minecraft build rather than a range, because `pack_format` has moved on nearly every 26.3
build and a jar carries exactly one. 26.3-pre-2 shipped the same day this release was
prepared, so the jar targets it rather than going out already a build behind. `pack_format`
is unchanged at 97 -- read from 26.3-pre-2's own `version.json`, not assumed.
Nothing else differs between the two builds for this mod: the only Minecraft change on a
surface Chunksmith attaches to was `ServerChunkCache.tickChunks` losing a parameter, and
Chunksmith does not hook that method.
### Fixed
- **The world no longer runs on underneath the "Preparing your world" screen.** The progress screen
drew a panel in the middle and left the live world rendering behind it at full brightness, so you
could watch yourself standing there -- and, if the spawn was not flat ground, watch yourself fall.
It reads as though the freeze is not working. It was: Minecraft's tick freeze deliberately exempts
players, so everything else really was held while the player alone kept moving. The screen is a
full backdrop now, and there is nothing to misread. (mod_support #20, reported by Maker261)
- **You are no longer the only thing still ticking while your world pre-generates.** Because of that
same exemption, the player kept running for the whole freeze -- which is 80 minutes or more at the
default radius. Hunger drained, fall damage applied, and a spawn over water could drown you while
you watched a progress bar. The player is now frozen along with everything else until the run
finishes or you press **Enter World Now**, and is released with the rest of the world.
release
3.17.2+26.2
3.17.2+26.24 сент. 2026 г.215Minecraft: 26.2fabric
Что нового
### Changed
- **The 26.3 build now targets `26.3-pre-2`.** Chunksmith pins its 26.3 jar to one exact
Minecraft build rather than a range, because `pack_format` has moved on nearly every 26.3
build and a jar carries exactly one. 26.3-pre-2 shipped the same day this release was
prepared, so the jar targets it rather than going out already a build behind. `pack_format`
is unchanged at 97 -- read from 26.3-pre-2's own `version.json`, not assumed.
Nothing else differs between the two builds for this mod: the only Minecraft change on a
surface Chunksmith attaches to was `ServerChunkCache.tickChunks` losing a parameter, and
Chunksmith does not hook that method.
### Fixed
- **The world no longer runs on underneath the "Preparing your world" screen.** The progress screen
drew a panel in the middle and left the live world rendering behind it at full brightness, so you
could watch yourself standing there -- and, if the spawn was not flat ground, watch yourself fall.
It reads as though the freeze is not working. It was: Minecraft's tick freeze deliberately exempts
players, so everything else really was held while the player alone kept moving. The screen is a
full backdrop now, and there is nothing to misread. (mod_support #20, reported by Maker261)
- **You are no longer the only thing still ticking while your world pre-generates.** Because of that
same exemption, the player kept running for the whole freeze -- which is 80 minutes or more at the
default radius. Hunger drained, fall damage applied, and a spawn over water could drown you while
you watched a progress bar. The player is now frozen along with everything else until the run
finishes or you press **Enter World Now**, and is released with the rest of the world.
release
3.17.2+26.2-neoforge
3.17.2+26.2-neoforge4 сент. 2026 г.20Minecraft: 26.2neoforge
Что нового
### Changed
- **The 26.3 build now targets `26.3-pre-2`.** Chunksmith pins its 26.3 jar to one exact
Minecraft build rather than a range, because `pack_format` has moved on nearly every 26.3
build and a jar carries exactly one. 26.3-pre-2 shipped the same day this release was
prepared, so the jar targets it rather than going out already a build behind. `pack_format`
is unchanged at 97 -- read from 26.3-pre-2's own `version.json`, not assumed.
Nothing else differs between the two builds for this mod: the only Minecraft change on a
surface Chunksmith attaches to was `ServerChunkCache.tickChunks` losing a parameter, and
Chunksmith does not hook that method.
### Fixed
- **The world no longer runs on underneath the "Preparing your world" screen.** The progress screen
drew a panel in the middle and left the live world rendering behind it at full brightness, so you
could watch yourself standing there -- and, if the spawn was not flat ground, watch yourself fall.
It reads as though the freeze is not working. It was: Minecraft's tick freeze deliberately exempts
players, so everything else really was held while the player alone kept moving. The screen is a
full backdrop now, and there is nothing to misread. (mod_support #20, reported by Maker261)
- **You are no longer the only thing still ticking while your world pre-generates.** Because of that
same exemption, the player kept running for the whole freeze -- which is 80 minutes or more at the
default radius. Hunger drained, fall damage applied, and a spawn over water could drown you while
you watched a progress bar. The player is now frozen along with everything else until the run
finishes or you press **Enter World Now**, and is released with the rest of the world.
release
3.17.2+26.1
3.17.2+26.14 сент. 2026 г.48Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Changed
- **The 26.3 build now targets `26.3-pre-2`.** Chunksmith pins its 26.3 jar to one exact
Minecraft build rather than a range, because `pack_format` has moved on nearly every 26.3
build and a jar carries exactly one. 26.3-pre-2 shipped the same day this release was
prepared, so the jar targets it rather than going out already a build behind. `pack_format`
is unchanged at 97 -- read from 26.3-pre-2's own `version.json`, not assumed.
Nothing else differs between the two builds for this mod: the only Minecraft change on a
surface Chunksmith attaches to was `ServerChunkCache.tickChunks` losing a parameter, and
Chunksmith does not hook that method.
### Fixed
- **The world no longer runs on underneath the "Preparing your world" screen.** The progress screen
drew a panel in the middle and left the live world rendering behind it at full brightness, so you
could watch yourself standing there -- and, if the spawn was not flat ground, watch yourself fall.
It reads as though the freeze is not working. It was: Minecraft's tick freeze deliberately exempts
players, so everything else really was held while the player alone kept moving. The screen is a
full backdrop now, and there is nothing to misread. (mod_support #20, reported by Maker261)
- **You are no longer the only thing still ticking while your world pre-generates.** Because of that
same exemption, the player kept running for the whole freeze -- which is 80 minutes or more at the
default radius. Hunger drained, fall damage applied, and a spawn over water could drown you while
you watched a progress bar. The player is now frozen along with everything else until the run
finishes or you press **Enter World Now**, and is released with the rest of the world.
release
3.17.2+26.1-neoforge
3.17.2+26.1-neoforge4 сент. 2026 г.19Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Changed
- **The 26.3 build now targets `26.3-pre-2`.** Chunksmith pins its 26.3 jar to one exact
Minecraft build rather than a range, because `pack_format` has moved on nearly every 26.3
build and a jar carries exactly one. 26.3-pre-2 shipped the same day this release was
prepared, so the jar targets it rather than going out already a build behind. `pack_format`
is unchanged at 97 -- read from 26.3-pre-2's own `version.json`, not assumed.
Nothing else differs between the two builds for this mod: the only Minecraft change on a
surface Chunksmith attaches to was `ServerChunkCache.tickChunks` losing a parameter, and
Chunksmith does not hook that method.
### Fixed
- **The world no longer runs on underneath the "Preparing your world" screen.** The progress screen
drew a panel in the middle and left the live world rendering behind it at full brightness, so you
could watch yourself standing there -- and, if the spawn was not flat ground, watch yourself fall.
It reads as though the freeze is not working. It was: Minecraft's tick freeze deliberately exempts
players, so everything else really was held while the player alone kept moving. The screen is a
full backdrop now, and there is nothing to misread. (mod_support #20, reported by Maker261)
- **You are no longer the only thing still ticking while your world pre-generates.** Because of that
same exemption, the player kept running for the whole freeze -- which is 80 minutes or more at the
default radius. Hunger drained, fall damage applied, and a spawn over water could drown you while
you watched a progress bar. The player is now frozen along with everything else until the run
finishes or you press **Enter World Now**, and is released with the rest of the world.
release
3.17.0+26.x-plugin
3.17.0+26.x-plugin3 сент. 2026 г.106Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, folia, paper, spigot
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
beta
3.17.0+26.3
3.17.0+26.33 сент. 2026 г.28Minecraft: 26.3-pre-1fabric
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+26.2
3.17.0+26.23 сент. 2026 г.248Minecraft: 26.2fabric
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+26.2-neoforge
3.17.0+26.2-neoforge3 сент. 2026 г.9Minecraft: 26.2neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+26.1
3.17.0+26.13 сент. 2026 г.31Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+26.1-neoforge
3.17.0+26.1-neoforge3 сент. 2026 г.14Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.x-plugin
3.17.0+1.21.x-plugin3 сент. 2026 г.57Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, folia, paper, spigot
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.8
3.17.0+1.21.83 сент. 2026 г.24Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.8-neoforge
3.17.0+1.21.8-neoforge3 сент. 2026 г.12Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.8-forge
3.17.0+1.21.8-forge3 сент. 2026 г.5Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.5
3.17.0+1.21.53 сент. 2026 г.9Minecraft: 1.21.5fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.5-forge
3.17.0+1.21.5-forge3 сент. 2026 г.6Minecraft: 1.21.5forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.4
3.17.0+1.21.43 сент. 2026 г.17Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.4-neoforge
3.17.0+1.21.4-neoforge3 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.4-forge
3.17.0+1.21.4-forge3 сент. 2026 г.2Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.11
3.17.0+1.21.113 сент. 2026 г.76Minecraft: 1.21.11fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.11-neoforge
3.17.0+1.21.11-neoforge3 сент. 2026 г.7Minecraft: 1.21.11neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.11-forge
3.17.0+1.21.11-forge3 сент. 2026 г.7Minecraft: 1.21.11forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.10
3.17.0+1.21.103 сент. 2026 г.9Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.10-neoforge
3.17.0+1.21.10-neoforge3 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.10-forge
3.17.0+1.21.10-forge3 сент. 2026 г.2Minecraft: 1.21.9, 1.21.10forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.1
3.17.0+1.21.13 сент. 2026 г.95Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.1-neoforge
3.17.0+1.21.1-neoforge3 сент. 2026 г.489Minecraft: 1.21, 1.21.1neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.21.1-forge
3.17.0+1.21.1-forge3 сент. 2026 г.12Minecraft: 1.21, 1.21.1forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.x-plugin
3.17.0+1.20.x-plugin3 сент. 2026 г.5Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, folia, paper, spigot
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.6
3.17.0+1.20.63 сент. 2026 г.6Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.6-neoforge
3.17.0+1.20.6-neoforge3 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6neoforge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.6-forge
3.17.0+1.20.6-forge3 сент. 2026 г.4Minecraft: 1.20.5, 1.20.6forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.4
3.17.0+1.20.43 сент. 2026 г.16Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.4-forge
3.17.0+1.20.4-forge3 сент. 2026 г.4Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.1
3.17.0+1.20.13 сент. 2026 г.83Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.17.0+1.20.1-forge
3.17.0+1.20.1-forge3 сент. 2026 г.268Minecraft: 1.20.1forge
Что нового
### Added
- **Your world can pre-generate itself before you start playing it.** On a single-player world,
Chunksmith now freezes the world on entry and pre-generates a 4096-block radius behind a progress
screen, with a filling bar, a live estimate of the time remaining, and an **Enter World Now**
button. Pressing it hands the world straight back to you -- it does **not** stop the run.
Generation carries on in the background and yields to you from then on.
Freezing does **not** make generation faster. It stops the world moving while it runs, so nothing
ages, wanders off or starves while you wait.
**Once a world has finished, it never does this again.** A completed run is recorded, so loading
that world afterwards goes straight in. Leaving early with the button records nothing, so the next
load simply continues where it stopped, and raising `worldEnterPregenRadius` asks for more world
and starts it again.
It works in a world created without cheats -- the settings are changed directly rather than through
the command interpreter -- and everything it borrows is written down before it is touched, so a
crash mid-freeze is put back on the next start rather than leaving your world frozen.
On by default, MC 26+ on Fabric and NeoForge, single-player only. Turn it off with
`worldEnterPregen`, or size it with `worldEnterPregenRadius` (default 4096).
(mod_support #20)
### Fixed
- **An IPv6 address can now actually be set with `/cs set`.** Quoting it -- the obvious thing to
try once the bare form is refused by Minecraft's command parser -- used to fail too: the quotes
were arriving as part of the value, so `"2001:db8::1"` was rejected as malformed. Both routes
were closed on a setting whose whole job is naming an address. Quoted values now work
everywhere, on every loader and the plugin. (Bare IPv6 still cannot work -- Minecraft's parser
stops at the first colon -- so quote it: `/cs set lodBackchannelHost "2001:db8::1"`.)
- **Impossible addresses are refused instead of stored.** `256.1.1.1` was accepted and kept: four
numeric labels satisfy every ordinary hostname rule, so the setting held an address that could
never resolve and the only symptom was a backchannel that quietly did not work. Also refused
now: `1.1.1.999`, `1.2.3`, `1.2.3.4.5`, `010.1.1.1` (a leading zero means octal to some
resolvers and decimal to others) and `example.123`. Fully-qualified names ending in a dot, like
`example.com.`, are accepted -- they were being refused.
- **`0.0.0.0` is no longer accepted as the address to advertise to clients.** It is exactly right
for `lodBackchannelBindAddress` (listen on every interface) and meaningless for
`lodBackchannelHost`: a client told to connect to `0.0.0.0` has been told nothing. Leave that
key empty if you want each client to use the address it connected on.
- **A server whose hostname contains an underscore can now serve LOD over the backchannel.**
`myserver_minecraft.example.com` broke it in two places at once: the address was rejected outright
by the config, so `lodBackchannelHost` silently reset to empty and could not be set at all; and the
download itself failed on every region without ever falling back to the slower in-band channel, so
it looked like the mod had simply stopped. Both are fixed -- such a host is now accepted, and the
downloader resolves it and reports plainly in the log what it did. If a host genuinely cannot be
reached, it now says so and falls back instead of going quiet.
(mod_support #26, reported by arsenelupin0)
### Removed
- The standalone Chunksmith-Client mod is gone -- the project has been retired and its repository
deleted -- so everything that referenced it has come out: the `chunksmithclient` incompatibility
declarations from the Fabric and NeoForge manifests, and the startup check that warned when both
were installed.
**If you still have an old Chunksmith-Client jar installed, remove it.** Chunksmith no longer
refuses to start alongside it; both mods register the same `chunksmith:lod` channel, so having both
is now a duplicate registration rather than a clear error message. Its multiplayer LOD job has been
built into Chunksmith itself since 3.1.0 -- you lose nothing by deleting it.
release
3.16.0+26.x-plugin
3.16.0+26.x-plugin2 сент. 2026 г.64Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, folia, paper, spigot
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
beta
3.16.0+26.3
3.16.0+26.32 сент. 2026 г.13Minecraft: 26.3-pre-1fabric
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+26.2
3.16.0+26.22 сент. 2026 г.152Minecraft: 26.2fabric
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+26.2-neoforge
3.16.0+26.2-neoforge2 сент. 2026 г.12Minecraft: 26.2neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+26.1
3.16.0+26.12 сент. 2026 г.27Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+26.1-neoforge
3.16.0+26.1-neoforge2 сент. 2026 г.22Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.x-plugin
3.16.0+1.21.x-plugin2 сент. 2026 г.19Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, folia, paper, spigot
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.8
3.16.0+1.21.82 сент. 2026 г.9Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.8-neoforge
3.16.0+1.21.8-neoforge2 сент. 2026 г.2Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.8-forge
3.16.0+1.21.8-forge2 сент. 2026 г.6Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.5
3.16.0+1.21.52 сент. 2026 г.8Minecraft: 1.21.5fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.5-forge
3.16.0+1.21.5-forge2 сент. 2026 г.4Minecraft: 1.21.5forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.4
3.16.0+1.21.42 сент. 2026 г.3Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.4-neoforge
3.16.0+1.21.4-neoforge2 сент. 2026 г.3Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.4-forge
3.16.0+1.21.4-forge2 сент. 2026 г.3Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.11
3.16.0+1.21.112 сент. 2026 г.24Minecraft: 1.21.11fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.11-neoforge
3.16.0+1.21.11-neoforge2 сент. 2026 г.3Minecraft: 1.21.11neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.11-forge
3.16.0+1.21.11-forge2 сент. 2026 г.8Minecraft: 1.21.11forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.10
3.16.0+1.21.102 сент. 2026 г.7Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.10-neoforge
3.16.0+1.21.10-neoforge2 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.10-forge
3.16.0+1.21.10-forge2 сент. 2026 г.3Minecraft: 1.21.9, 1.21.10forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.1
3.16.0+1.21.12 сент. 2026 г.137Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.1-neoforge
3.16.0+1.21.1-neoforge2 сент. 2026 г.221Minecraft: 1.21, 1.21.1neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.21.1-forge
3.16.0+1.21.1-forge2 сент. 2026 г.7Minecraft: 1.21, 1.21.1forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.x-plugin
3.16.0+1.20.x-plugin2 сент. 2026 г.3Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, folia, paper, spigot
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.6
3.16.0+1.20.62 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.6-neoforge
3.16.0+1.20.6-neoforge2 сент. 2026 г.2Minecraft: 1.20.5, 1.20.6neoforge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.6-forge
3.16.0+1.20.6-forge2 сент. 2026 г.3Minecraft: 1.20.5, 1.20.6forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.4
3.16.0+1.20.42 сент. 2026 г.14Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.4-forge
3.16.0+1.20.4-forge2 сент. 2026 г.2Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.1
3.16.0+1.20.12 сент. 2026 г.61Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.16.0+1.20.1-forge
3.16.0+1.20.1-forge2 сент. 2026 г.72Minecraft: 1.20.1forge
Что нового
### Changed
- The 2 GB ceiling on a LOD index answer is a setting now, instead of a number compiled into the
jar. A server answers "here is what is in range" by listing regions nearest-first until it has
named two gigabytes of them, and then stops. **That default has not changed, so upgrading changes
no server's behaviour.** What changed is that you can raise it, and that the log now tells you it
happened and why (mod_support #23).
Why it matters: the budget does not scale with how far a client says it can draw, so it binds at
the same distance on every answer. At a Distant Horizons radius of 8192, roughly 800 regions are
in range at about 5 MB each -- a little over 4 GB -- and 2 GB allows about 395 of them. Terrain
past that ring never arrives at all for a player standing still. At radius 4096 the same world
needs about 1.5 GB and never reaches the ceiling, which is why this only ever looks like a problem
at large radii.
**If your players run large render distances, raise `lodIndexBudgetMb` or set it to 0.** 2048 is a
bandwidth default, not a safety limit -- nothing downstream requires it. The index message has its
own region cap, the backchannel serves over HTTP at the client's pace, and the in-band path drips
fixed 24 KB slices four to a tick rather than sending a total.
- The "capped at N of M regions" warning stopped promising that travelling would fix it. It only
appears now when the region cap actually binds, it says whether moving will help, and it is
logged once per player per ten minutes instead of once per scan.
### Added
- `lodBackchannelBindAddress` (`lod-backchannel-bind-address`) and `lodBackchannelHost`
(`lod-backchannel-host`): the backchannel's address is settable now, not only its port
(mod_support #24).
Two keys, because they answer two different questions. The bind address is where the socket
LISTENS, and it exists because the backchannel followed whatever the game bound: a host that sets
`server-ip` to `127.0.0.1`, which is normal behind a proxy, got a backchannel on loopback that no
player could reach, and the only symptom was every client quietly falling back to the slow in-band
channel while the log said `listening on /127.0.0.1:25566`. Set `0.0.0.0` to listen everywhere
regardless.
Binding everywhere does not finish the job, though, which is why there is a second key. The client
has always worked out where to fetch from by reusing the address it connected to, and that is a
better answer than anything the server can guess -- it is an address that demonstrably reaches
this server from where that player is sitting. It is wrong in one shape: the backchannel reachable
at a different address from the game port. `lodBackchannelHost` is how a server says so.
Both rebind and re-advertise on the spot, the way `lodBackchannelPort` does. An address key that
waited for a restart would be no use to the operator it is for. Set either to `none` to clear it.
No protocol version change, and no upgrade order to worry about. The host rides after the last
field a 3.15.0 client reads, so an old client never sees it, and a 3.16.0 client talking to an old
server just finds nothing there and carries on using the connect address.
- `lodIndexBudgetMb` (`lod-index-budget-mb` in the plugin's `config.yml`): the ceiling in megabytes
on how much LOD one answer may offer a client. **Default `2048`**, which is exactly what the old
hard-coded constant was, so nothing moves on upgrade. `0` means no limit. Settable live with
`/cs set lodIndexBudgetMb`. See the note above on when to raise it -- roughly, a Distant Horizons
radius of 4096 fits inside 2 GB and a radius of 8192 does not.
### Note
- The budget is what limits a client's LOD download, and there is deliberately no client-side disk
limit: the server admin sets the ceiling, and 2048 MB per dimension is what a client accumulates
by default. Raising `lodIndexBudgetMb` raises that too -- a server set to `0` hands a radius-8192
client roughly 4 GB per dimension. Worth knowing before setting it.
release
3.15.0+1.21.11-forge
3.15.0+1.21.11-forge27 авг. 2026 г.78Minecraft: 1.21.11forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.x-plugin
3.15.0+1.20.x-plugin27 авг. 2026 г.59Minecraft: 1.20, 1.20.1, 1.20.2, 1.20.3, 1.20.4, 1.20.5, 1.20.6bukkit, folia, paper, spigot
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.4
3.15.0+1.20.427 авг. 2026 г.47Minecraft: 1.20.2, 1.20.3, 1.20.4fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+26.x-plugin
3.15.0+26.x-plugin27 авг. 2026 г.264Minecraft: 26.1, 26.1.1, 26.1.2, 26.2bukkit, folia, paper, spigot
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
beta
3.15.0+26.3
3.15.0+26.327 авг. 2026 г.15Minecraft: 26.3-snapshot-7fabric
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+26.2
3.15.0+26.227 авг. 2026 г.930Minecraft: 26.2fabric
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+26.2-neoforge
3.15.0+26.2-neoforge27 авг. 2026 г.59Minecraft: 26.2neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+26.1
3.15.0+26.127 авг. 2026 г.144Minecraft: 26.1, 26.1.1, 26.1.2fabric
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+26.1-neoforge
3.15.0+26.1-neoforge27 авг. 2026 г.55Minecraft: 26.1, 26.1.1, 26.1.2neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.x-plugin
3.15.0+1.21.x-plugin27 авг. 2026 г.108Minecraft: 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11bukkit, folia, paper, spigot
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.8
3.15.0+1.21.827 авг. 2026 г.27Minecraft: 1.21.6, 1.21.7, 1.21.8fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.8-neoforge
3.15.0+1.21.8-neoforge27 авг. 2026 г.10Minecraft: 1.21.5, 1.21.6, 1.21.7, 1.21.8neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.8-forge
3.15.0+1.21.8-forge27 авг. 2026 г.7Minecraft: 1.21.6, 1.21.7, 1.21.8forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.5
3.15.0+1.21.527 авг. 2026 г.14Minecraft: 1.21.5fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.5-forge
3.15.0+1.21.5-forge27 авг. 2026 г.8Minecraft: 1.21.5forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.4
3.15.0+1.21.427 авг. 2026 г.30Minecraft: 1.21.2, 1.21.3, 1.21.4fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.4-neoforge
3.15.0+1.21.4-neoforge27 авг. 2026 г.6Minecraft: 1.21.2, 1.21.3, 1.21.4neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.4-forge
3.15.0+1.21.4-forge27 авг. 2026 г.7Minecraft: 1.21.2, 1.21.3, 1.21.4forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.11
3.15.0+1.21.1127 авг. 2026 г.165Minecraft: 1.21.11fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.11-neoforge
3.15.0+1.21.11-neoforge27 авг. 2026 г.24Minecraft: 1.21.11neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.10
3.15.0+1.21.1027 авг. 2026 г.26Minecraft: 1.21.9, 1.21.10fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.10-neoforge
3.15.0+1.21.10-neoforge27 авг. 2026 г.6Minecraft: 1.21.9, 1.21.10neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.10-forge
3.15.0+1.21.10-forge27 авг. 2026 г.5Minecraft: 1.21.9, 1.21.10forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.1
3.15.0+1.21.127 авг. 2026 г.322Minecraft: 1.21, 1.21.1fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.1-neoforge
3.15.0+1.21.1-neoforge27 авг. 2026 г.1,9 тыс.Minecraft: 1.21, 1.21.1neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.21.1-forge
3.15.0+1.21.1-forge27 авг. 2026 г.20Minecraft: 1.21, 1.21.1forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.6
3.15.0+1.20.627 авг. 2026 г.11Minecraft: 1.20.5, 1.20.6fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.6-neoforge
3.15.0+1.20.6-neoforge27 авг. 2026 г.2Minecraft: 1.20.5, 1.20.6neoforge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.6-forge
3.15.0+1.20.6-forge27 авг. 2026 г.4Minecraft: 1.20.5, 1.20.6forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.4-forge
3.15.0+1.20.4-forge27 авг. 2026 г.5Minecraft: 1.20.2, 1.20.3, 1.20.4forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.1
3.15.0+1.20.127 авг. 2026 г.352Minecraft: 1.20, 1.20.1fabric, quilt
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.
release
3.15.0+1.20.1-forge
3.15.0+1.20.1-forge27 авг. 2026 г.799Minecraft: 1.20.1forge
Что нового
### Added
- **The Bukkit/Paper plugin can now send LOD to players.** Until today it generated the data and had
no way to deliver it, so anyone running the plugin got a store on disk and players who saw nothing
-- and no combination of client mods could change that (mod_support #18).
The awkward part of that story: every piece of the machinery had been shipping inside the plugin
jar since 3.2.0, because it lives in the shared code. The wire format, the token store, the HTTP
backchannel -- all present, all unreachable, because nothing registered a channel or started the
server. This release is the connection that was missing.
Nothing to configure. If LOD is on, the plugin registers the channel, opens the backchannel port
and answers clients exactly as the mod does. `lod-backchannel-port` in `config.yml` works the same
way it does on the mod, and the startup line tells you which port your players need to reach.
**One honest limitation:** the mod falls back to streaming LOD down the game connection when the
backchannel port is unreachable. The plugin does not do that yet -- if the port is blocked, players
get nothing rather than something slow. The log says so plainly instead of going quiet, and the
fix is to open the port or set one your host allows.
- **A client on a Paper server now actually receives LOD -- measured, not inferred.** The first
cut of the above answered the client's hello and stopped there, which looks exactly like
working: the server logs the greeting, opens the port, mints a download credential, and serves
nothing at all, because the client is waiting on a region index that never comes. Two things
were missing.
**The index and sync requests are answered.** The hello is only the introduction. The client
then asks what is near it, compares that against what it already has, and downloads the
difference -- and it asks again every few minutes as it travels. The plugin answers both now,
off the main thread, filtered to the draw distance the client actually reported.
**Bukkit is told to accept the reply.** A Bukkit server only delivers a plugin message on a
channel the client announced with `minecraft:register`, and drops everything else without a
word -- no exception, no log line, no packet. A modern Fabric client never makes that
announcement, so the server could hear the client perfectly while the client heard nothing
back. The plugin now registers the channel for a player who has already spoken to it on that
channel, which is proof enough that they speak it.
Measured on Paper 26.2 with a Fabric client and voxy: 16 regions, 27 MB, 5928 chunks handed to
the renderer. The symptom this replaces was `0 files, 0 bytes` with a live token beside it.
### Changed
- **The plugin's startup message no longer says it cannot serve LOD**, because it can.
- **One region scan, shared by every platform** (`CsLodIndexScan`). "Which regions can this
player see?" has to give the same answer on a Fabric server and a Paper server, and a second
copy of that rule would have drifted with nothing to catch it -- the symptom being a client that
fetches the wrong regions on one platform only. The loaders and the plugin now call the same
code, and sixteen tests pin the range, settle, ordering and cap behaviour.