Download File

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.