modpack-final.zip is 78MB, well over Gitea's upload limit. Served
directly from Caddy's existing static/ mount instead (path-routed
within the minecraft.mivanchenko.de block, alongside the BlueMap
failover) - no new container or mount needed. install.sh/install.ps1
MODPACK_URL updated accordingly; install scripts themselves stay on
Gitea since they're small text files. Verified full byte-exact
download end-to-end. Also drops the stale "moving to the venue"
comments now that the server is permanently on mivanchenko.de.
Matches the 9-12p sizing tier from HOSTING.md. Verified clean boot
(Done in 5.3s, no OOM) and checked actual headroom on the box
(~2.3GB container overhead, 14GB total) before applying.
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).
Server-local Docker setup (not committed), reverse-proxied by Caddy
on the same hostname the game client connects to — different
port/protocol (80/443 HTTP vs 25565 raw TCP), no conflict.
No interactive console exists since lazymc/systemd run the server in
the background, and mcrcon isn't packaged for Debian 13. Plain
Python3 RCON client instead, reads the password straight from
server.properties. setup-server.sh now copies it into mcserver/.
v0.2.11 has a confirmed open regression (timvisee/lazymc#65, #86):
it never recognizes a Forge server as online regardless of uptime,
so every connection just times out on the "still starting" screen
forever. forge=true alone doesn't fix it. 0.2.10 correctly detects
readiness (verified: "Server is now online" + successful relay).
Missing forge = true under [server] meant lazymc couldn't parse the
Forge status response (extra embedded mod-list payload vanilla
doesn't have), so it never detected the backend as online and always
showed the "still starting" kick screen. Also documents the inherent
~25-30s client-timeout race on the very first cold-boot connection.
lazymc's command line forwarded -Xms/-Xmx straight to run.sh, which
passes trailing args to Minecraft's own arg parser (not the JVM) —
crashed with "X is not a recognized option" on every wake attempt.
Heap flags now go in user_jvm_args.txt where Forge actually expects
them.
Chunky + DH-on-server crashes on first chunk load (confirmed open
upstream bug, DH GitLab #1329). DH's own INTERNAL_SERVER generation
mode does the same pregen job without the conflict, plus streams
accurate LOD to clients automatically (no manual flying pass needed).
Corrects Vivecraft/CPM/ViveCraft Compat to both-sides (needed for
other players to see VR body movement, not just client-only). Fixes
lazymc.toml duration-string bug (sleep_after wants an integer, not
"5m"). Replaces the screenshot-derived mod list with ground truth
from the actual exported client zip.
Drops the standalone fileserver systemd unit from setup-server.sh in
favor of Gitea's already-public raw-file serving. Adds VR (Vivecraft)
and quest (FTB Quests) mod docs, the DH/Chunky server-side crash
warning, and documents the real deployment target (always-on homelab
box, not a venue-local machine).
Mykhailo Ivanchenko
mivanchenko