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)