Add BlueMap live-player-markers mod + Caddy failover, document it

BlueMap Forge mod runs in-process on the server for live player
position markers (not possible with the standalone renderer alone).
Caddy now tries the mod first (via the Docker bridge gateway IP,
since the mod binds to the host not a container) and automatically
falls back to the always-on standalone bluemap-lan container the
instant the game server sleeps - verified via distinct map-ID naming
between the two. Flags that the client modpack needs the same
BlueMap jar added before building modpack-final.zip (mod-list match).
This commit is contained in:
Mykhailo Ivanchenko
2026-10-23 17:43:23 +02:00
parent 0617b40412
commit 13aa5c1af8
2 changed files with 14 additions and 8 deletions
+1
View File
@@ -58,6 +58,7 @@ Vivecraft auto-detects whether a headset is actually connected and falls back to
| Mod | Side | Why it's in |
|---|---|---|
| [Distant Horizons](https://modrinth.com/mod/distanthorizons) | **Both client and server** | Renders a simplified level-of-detail view of terrain beyond the server's `view-distance`, so players see far-off scenery without the server having to actually load/send those chunks. Does the same job you were picturing from "Bobby" — Bobby itself is **Fabric-only** (no Forge build exists), so Distant Horizons is the Forge equivalent. Installing the same DH build on the server too lets it push accurate LOD data to clients directly — no manual exploring/flying needed, and it replaces Chunky's job (see below). |
| [BlueMap](https://modrinth.com/plugin/bluemap) (`5.12-mc1.20-6-forge`) | **Both client and server** | Live browser-viewable map of the world at `minecraft.mivanchenko.de`, with live player position markers. **Important:** already added to the server (`mcserver/mods/`) directly by me — but it's not in `modpack-unready.zip`/`modpack-final.zip` yet, since those come from your client instance. Add the exact same version (`BlueMap-5.12-mc1.20-6-forge.jar` from Modrinth) to the client instance before building `modpack-final.zip`, or Forge will refuse to connect on a mod-list mismatch. |
**Chunky is not used.** It was the original plan for pregeneration, but DH-on-server + Chunky-on-server crashes the world on first chunk load — this is a confirmed, currently open DH bug ([GitLab #1329](https://gitlab.com/distant-horizons-team/distant-horizons/-/work_items/1329), exact match for the 3.3.3 build here): DH's Chunky-compat accessor binds to Chunky's provider before Chunky's own init has run, throwing `IllegalStateException: Chunky is not loaded`. No official config toggle exists to disable that integration. Instead, **Distant Horizons' own built-in "Full"/"Internal Server" distant-generation mode generates real, normal chunks itself** — the same job Chunky would have done — so Chunky is redundant once DH is installed server-side this way. Simpler *and* avoids the crash entirely.