From 9ecdfca06f7b78a61de70c3277091e33b048a116 Mon Sep 17 00:00:00 2001 From: Mykhailo Ivanchenko Date: Fri, 23 Oct 2026 15:50:30 +0200 Subject: [PATCH] Fix lazymc never recognizing the Forge server as ready 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. --- HOSTING.md | 2 ++ server/setup-server.sh | 1 + 2 files changed, 3 insertions(+) diff --git a/HOSTING.md b/HOSTING.md index 31a18e9..fb65c1c 100644 --- a/HOSTING.md +++ b/HOSTING.md @@ -99,3 +99,5 @@ Make sure your Minecraft server itself is running with `online-mode=false` in `s - Double-check the server's mod list is byte-for-byte the same mods as the client instance (same versions) — Forge is strict about mod-list mismatches between client and server and will refuse to connect otherwise. The cleanest way to guarantee this is pulling server-side jars straight out of the exported client zip (`unzip -j modpack.zip "minecraft/mods/*.jar" -d mcserver/mods`), not re-downloading them independently. - **`unzip` can extract files with `0000` permissions from zips built on Windows** (seen when extracting a Prism/Fjord-exported instance zip — the jars came out as `----------`, unreadable even by their owner). If the server fails to load mods right after extracting a client zip with errors that don't match what actually worked on the client, check `ls -la mcserver/mods/` first — `chmod -R u+rwX mcserver/mods` fixes it. - Create bundles **Flywheel** and **Ponder** inside its own jar via Forge's JarJar mechanism (visible in the client log as `"Found 11 dependencies adding them to mods collection"`) — don't go looking for separate `flywheel-*.jar`/`Ponder-*.jar` files to add to `mods/` on either side, they don't exist as standalone files in this setup. +- **`lazymc.toml` needs `forge = true` under `[server]`** if the backend is a Forge server (not in the defaults) — without it, lazymc can't correctly parse the status response (Forge's status ping includes an extra embedded mod-list payload vanilla doesn't have) and never recognizes the server as ready, so it just perpetually shows the "still starting" kick screen even once the real server is long since up. `setup-server.sh` sets this correctly now. +- **The very first connection after a cold sleep can still lose the race and show "Server is starting... try to reconnect."** — this is expected, not a bug: lazymc's hold method is hard-capped at ~25–30s by the Minecraft client's own connection timeout, and this modpack's Forge boot (~17–22s) eats most of that budget, especially cold. If you see that screen, just wait a few seconds and reconnect once — the server is already warm by then and the second attempt connects almost instantly. Worth mentioning to participants up front so nobody assumes it's broken. diff --git a/server/setup-server.sh b/server/setup-server.sh index 13e66ff..9277582 100755 --- a/server/setup-server.sh +++ b/server/setup-server.sh @@ -83,6 +83,7 @@ cat > "$BASE_DIR/lazymc.toml" <