mivanchenko/mc-lan-party
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
HOSTING.md
+13 -8
View File
@@ -51,21 +51,26 @@ python3 rcon.py "op <name>" "gamemode creative <name>" # multiple commands in
Works for any server command — `list`, `whitelist add <name>`, `tp`, `weather clear`, `/chunky`-era commands if relevant, etc. The script reads the password straight from `server.properties`, nothing to copy/paste. Note it only works while the real server is awake — if lazymc has it asleep, wake it first (connect once, or `python3 rcon.py "list"` will just fail to connect).
### Live web map (BlueMap)
### Live web map (BlueMap) — two renderers, automatic failover
`minecraft.mivanchenko.de` serves a live, browser-viewable map (BlueMap) over HTTPS — same hostname the game client connects to, but a completely different port/protocol (80/443 via Caddy for the map, raw TCP 25565 direct to lazymc for gameplay), so the two don't conflict at all.
`minecraft.mivanchenko.de` serves a browser-viewable map over HTTPS — same hostname the game client connects to, but a completely different port/protocol (80/443 via Caddy for the map, raw TCP 25565 direct to lazymc for gameplay), so the two never conflict.
Setup lives at `~/lan-minecraft/bluemap/` on the box, running as its own Docker container (`bluemap-lan`, separate from an older unrelated `bluemap` container the box already had for a different world — reused its config templates, not its data). It mounts the live Forge server's `mcserver/world/` read-only and renders + watches for changes continuously (`-r -u -w` flags), so the map stays current through the party automatically — no manual re-render step needed. Caddy just reverse-proxies `minecraft.mivanchenko.de` to `bluemap-lan:8100`.
There are **two** BlueMap renderers, and Caddy automatically picks whichever is actually up:
1. **BlueMap Forge mod** (`mcserver/mods/BlueMap-5.12-mc1.20-6-forge.jar`) — runs *inside* the live Minecraft server process. Shows **live player position markers** (requires the mod running server-side with access to real player session data — the standalone renderer below can't do this, it only ever sees static world files). Only up while the game server itself is awake. Webserver binds to the host directly on port 8100 (config at `mcserver/config/bluemap/`).
2. **Standalone Docker renderer** (`~/lan-minecraft/bluemap/`, container `bluemap-lan`) — always-on regardless of whether the game server is asleep, reads `mcserver/world/` read-only, renders + watches for changes continuously (`-r -u -w` flags). No live player markers (it has no connection to the running server), but the map itself stays current and always reachable even when nobody's playing.
Caddy tries the mod first (`172.20.0.1:8100` — the Docker bridge gateway IP, since the mod binds to the host, not a container on the `proxy` network) and falls back to `bluemap-lan:8100` the moment the mod's webserver stops responding (health-checked, `lb_policy first`, ~10s detection window) — i.e. the instant lazymc puts the server to sleep. Verified end-to-end: map IDs are `world`/`world_the_end`/`world_the_nether` when the mod is serving, `overworld`/`nether`/`end` when it's fallen back to the standalone container (distinct naming between the two made this easy to confirm via `/settings.json`).
```bash
ssh server
cd ~/lan-minecraft/bluemap
docker compose ps # check it's running
docker compose logs -f # watch render/webserver activity
docker compose restart # if it ever needs a kick
# standalone renderer
cd ~/lan-minecraft/bluemap && docker compose ps / logs -f / restart
# live mod — check via the game server's own logs/RCON, not a separate service
cd ~/lan-minecraft/repo/server/mcserver && python3 rcon.py "bluemap reload"
```
Not committed to the `mc-lan-party` Gitea repo (it's server-local infra, not something that travels with the modpack) — if you ever rebuild this box from scratch, recreate it from this section rather than expecting it from `git clone`.
Caddy config lives in `~/caddy/Caddyfile` (shared with every other site on this box — edited in place, reload via `docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile`, never `docker compose up -d --force-recreate` for a config-only change, that'd bounce every other site too). None of this (BlueMap configs, Caddyfile) is committed to the `mc-lan-party` Gitea repo — it's server-local infra. If this box is ever rebuilt from scratch, recreate it from this section.
### Resource sizing for the venue box (5–15 players)
modpack.md
+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.