COWMODSКаталог модов
Chunksmith

ВЕРСИИ (602)

release

4.6.0+26.x-plugin

4.6.0+26.x-plugin
13 окт. 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.3
13 окт. 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-neoforge
13 окт. 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.2
13 окт. 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-neoforge
13 окт. 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.1
13 окт. 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-neoforge
13 окт. 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-plugin
13 окт. 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.8
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.5
13 окт. 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-forge
13 окт. 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.4
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.11
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.10
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.1
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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-plugin
13 окт. 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.6
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.4
13 окт. 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-forge
13 окт. 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.1
13 окт. 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-forge
13 окт. 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-plugin
13 окт. 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.3
13 окт. 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-neoforge
13 окт. 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.2
13 окт. 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-neoforge
13 окт. 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.1
13 окт. 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-neoforge
13 окт. 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-plugin
13 окт. 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.8
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.5
13 окт. 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-forge
13 окт. 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.4
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.11
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.10
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.1
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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-plugin
13 окт. 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.6
13 окт. 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-neoforge
13 окт. 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-forge
13 окт. 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.4
13 окт. 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-forge
13 окт. 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.1
13 окт. 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-forge
13 окт. 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-plugin
10 окт. 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.3
10 окт. 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-neoforge
10 окт. 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.2
10 окт. 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-neoforge
10 окт. 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.1
10 окт. 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-neoforge
10 окт. 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-plugin
10 окт. 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.8
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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.5
10 окт. 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-forge
10 окт. 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.4
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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.11
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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.10
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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.1
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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-plugin
10 окт. 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.6
10 окт. 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-neoforge
10 окт. 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-forge
10 окт. 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.4
10 окт. 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-forge
10 окт. 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.1
10 окт. 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-forge
10 окт. 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.3
8 окт. 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-neoforge
8 окт. 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.2
8 окт. 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-neoforge
8 окт. 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.1
8 окт. 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-neoforge
8 окт. 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.11
8 окт. 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-neoforge
8 окт. 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-forge
8 окт. 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-plugin
1 окт. 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.3
1 окт. 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-neoforge
1 окт. 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.2
1 окт. 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-neoforge
1 окт. 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.1
1 окт. 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-neoforge
1 окт. 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-plugin
1 окт. 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.8
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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.5
1 окт. 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-forge
1 окт. 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.4
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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.11
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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.10
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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.1
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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-plugin
1 окт. 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.6
1 окт. 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-neoforge
1 окт. 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-forge
1 окт. 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.4
1 окт. 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-forge
1 окт. 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.1
1 окт. 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-forge
1 окт. 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-plugin
27 сент. 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.3
27 сент. 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-neoforge
27 сент. 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.2
27 сент. 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-neoforge
27 сент. 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.1
27 сент. 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-neoforge
27 сент. 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-plugin
27 сент. 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.8
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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.5
27 сент. 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-forge
27 сент. 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.4
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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.11
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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.10
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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.1
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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-plugin
27 сент. 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.6
27 сент. 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-neoforge
27 сент. 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-forge
27 сент. 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.4
27 сент. 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-forge
27 сент. 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.1
27 сент. 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-forge
27 сент. 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-plugin
26 сент. 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.3
26 сент. 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-neoforge
26 сент. 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.2
26 сент. 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-neoforge
26 сент. 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.1
26 сент. 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-neoforge
26 сент. 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-plugin
26 сент. 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.8
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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.5
26 сент. 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-forge
26 сент. 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.4
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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.11
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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.10
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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.1
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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-plugin
26 сент. 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.6
26 сент. 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-neoforge
26 сент. 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-forge
26 сент. 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.4
26 сент. 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-forge
26 сент. 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.1
26 сент. 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-forge
26 сент. 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-plugin
24 сент. 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.3
24 сент. 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-neoforge
24 сент. 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.2
24 сент. 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-neoforge
24 сент. 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.1
24 сент. 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-neoforge
24 сент. 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-plugin
24 сент. 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.8
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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.5
24 сент. 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-forge
24 сент. 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.4
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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.11
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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.10
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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.1
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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-plugin
24 сент. 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.6
24 сент. 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-neoforge
24 сент. 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-forge
24 сент. 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.4
24 сент. 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-forge
24 сент. 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.1
24 сент. 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-forge
24 сент. 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-plugin
20 сент. 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.3
20 сент. 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-neoforge
20 сент. 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.2
20 сент. 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-neoforge
20 сент. 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.1
20 сент. 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-neoforge
20 сент. 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-plugin
20 сент. 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.8
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.5
20 сент. 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-forge
20 сент. 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.4
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.11
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.10
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.1
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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-plugin
20 сент. 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.6
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.4
20 сент. 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-forge
20 сент. 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.1
20 сент. 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-forge
20 сент. 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-plugin
20 сент. 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.3
20 сент. 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-neoforge
20 сент. 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.2
20 сент. 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-neoforge
20 сент. 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.1
20 сент. 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-neoforge
20 сент. 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-plugin
20 сент. 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.8
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.5
20 сент. 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-forge
20 сент. 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.4
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.11
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.10
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.1
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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-plugin
20 сент. 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.6
20 сент. 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-neoforge
20 сент. 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-forge
20 сент. 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.4
20 сент. 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-forge
20 сент. 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.1
20 сент. 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-forge
20 сент. 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-plugin
19 сент. 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.3
19 сент. 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-neoforge
19 сент. 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.2
19 сент. 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-neoforge
19 сент. 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.1
19 сент. 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-neoforge
19 сент. 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-plugin
19 сент. 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.8
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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.5
19 сент. 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-forge
19 сент. 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.4
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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.11
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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.10
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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.1
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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-plugin
19 сент. 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.6
19 сент. 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-neoforge
19 сент. 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-forge
19 сент. 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.4
19 сент. 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-forge
19 сент. 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.1
19 сент. 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-forge
19 сент. 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-plugin
18 сент. 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.3
18 сент. 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-neoforge
18 сент. 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.2
18 сент. 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-neoforge
18 сент. 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.1
18 сент. 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-neoforge
18 сент. 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-plugin
18 сент. 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.8
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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.5
18 сент. 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-forge
18 сент. 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.4
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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.11
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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.10
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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.1
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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-plugin
18 сент. 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.6
18 сент. 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-neoforge
18 сент. 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-forge
18 сент. 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.4
18 сент. 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-forge
18 сент. 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.1
18 сент. 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-forge
18 сент. 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-plugin
17 сент. 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.3
17 сент. 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-neoforge
17 сент. 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-plugin
16 сент. 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.3
16 сент. 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.2
16 сент. 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-neoforge
16 сент. 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.1
16 сент. 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-neoforge
16 сент. 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-plugin
16 сент. 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.8
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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.5
16 сент. 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-forge
16 сент. 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.4
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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.11
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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.10
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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.1
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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-plugin
16 сент. 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.6
16 сент. 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-neoforge
16 сент. 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-forge
16 сент. 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.4
16 сент. 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-forge
16 сент. 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.1
16 сент. 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-forge
16 сент. 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-plugin
13 сент. 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.3
13 сент. 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.2
13 сент. 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-neoforge
13 сент. 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.1
13 сент. 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-neoforge
13 сент. 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-plugin
13 сент. 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.8
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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.5
13 сент. 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-forge
13 сент. 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.4
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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.11
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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.10
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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.1
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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-plugin
13 сент. 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.6
13 сент. 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-neoforge
13 сент. 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-forge
13 сент. 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.4
13 сент. 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-forge
13 сент. 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.1
13 сент. 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-forge
13 сент. 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.3
10 сент. 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.3
10 сент. 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.2
10 сент. 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-neoforge
10 сент. 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.1
10 сент. 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-neoforge
10 сент. 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.8
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.5
10 сент. 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-forge
10 сент. 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.4
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.11
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.10
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.1
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.6
10 сент. 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-neoforge
10 сент. 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-forge
10 сент. 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.4
10 сент. 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-forge
10 сент. 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.1
10 сент. 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-forge
10 сент. 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-plugin
5 сент. 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.3
5 сент. 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.2
5 сент. 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-neoforge
5 сент. 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.1
5 сент. 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-neoforge
5 сент. 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-plugin
5 сент. 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.8
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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.5
5 сент. 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-forge
5 сент. 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.4
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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.11
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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.10
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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.1
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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-plugin
5 сент. 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.6
5 сент. 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-neoforge
5 сент. 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-forge
5 сент. 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.4
5 сент. 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-forge
5 сент. 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.1
5 сент. 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-forge
5 сент. 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.3
4 сент. 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.2
4 сент. 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-neoforge
4 сент. 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.1
4 сент. 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-neoforge
4 сент. 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-plugin
3 сент. 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.3
3 сент. 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.2
3 сент. 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-neoforge
3 сент. 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.1
3 сент. 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-neoforge
3 сент. 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-plugin
3 сент. 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.8
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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.5
3 сент. 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-forge
3 сент. 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.4
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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.11
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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.10
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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.1
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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-plugin
3 сент. 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.6
3 сент. 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-neoforge
3 сент. 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-forge
3 сент. 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.4
3 сент. 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-forge
3 сент. 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.1
3 сент. 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-forge
3 сент. 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-plugin
2 сент. 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.3
2 сент. 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.2
2 сент. 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-neoforge
2 сент. 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.1
2 сент. 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-neoforge
2 сент. 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-plugin
2 сент. 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.8
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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.5
2 сент. 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-forge
2 сент. 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.4
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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.11
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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.10
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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.1
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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-plugin
2 сент. 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.6
2 сент. 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-neoforge
2 сент. 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-forge
2 сент. 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.4
2 сент. 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-forge
2 сент. 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.1
2 сент. 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-forge
2 сент. 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-forge
27 авг. 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-plugin
27 авг. 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.4
27 авг. 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-plugin
27 авг. 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.3
27 авг. 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.2
27 авг. 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-neoforge
27 авг. 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.1
27 авг. 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-neoforge
27 авг. 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-plugin
27 авг. 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.8
27 авг. 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-neoforge
27 авг. 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-forge
27 авг. 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.5
27 авг. 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-forge
27 авг. 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.4
27 авг. 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-neoforge
27 авг. 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-forge
27 авг. 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.11
27 авг. 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-neoforge
27 авг. 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.10
27 авг. 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-neoforge
27 авг. 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-forge
27 авг. 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.1
27 авг. 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-neoforge
27 авг. 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-forge
27 авг. 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.6
27 авг. 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-neoforge
27 авг. 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-forge
27 авг. 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-forge
27 авг. 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.1
27 авг. 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-forge
27 авг. 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.