Chunksmith

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.