2026-10-23 15:40:06 +02:00
parent cd694a67b6
commit 8226642be5
3 changed files with 66 additions and 67 deletions
@@ -5,19 +5,9 @@
1. Install [Fjord Launcher Unlocked](https://github.com/hero-persson/FjordLauncherUnlocked) normally on your own machine.
2. Create a new instance: Minecraft **1.20.1**, **Forge**. Name it exactly `LANParty` (or change `INSTANCE_NAME`/`$InstanceName` in both scripts to match).
3. Add the mods from `modpack.md` (use the launcher's built-in Modrinth/CurseForge browser, or drop jars straight into the instance's `mods/` folder).
4. **Set up the server and pregenerate first** — do the "Set up the dedicated venue box" and "Pre-generate chunks before the party starts (Chunky)" steps below *before* continuing here. Distant Horizons can only cache real terrain that already exists; it can't backfill detail after the fact.
5. Launch the client, go to **Multiplayer → Add Server**, enter `minecraft.mivanchenko.de:25565` (not a raw IP — see "Moving the server to the venue" below), and join for real. Set your preferred video settings (these land in `options.txt`). Then do a flying pass to populate the Distant Horizons cache — client-only DH can't backfill terrain it hasn't actually received as real chunks, so this has to be done by hand:
   - Switch to **Creative**, double-tap **Space** for creative flight (hold sprint to go faster).
   - Temporarily bump your client's **render distance** up (Video Settings) — DH only caches what the server actually sends within that range, so a higher render distance covers more ground per pass.
   - Fly a spiral or back-and-forth grid centered on spawn, covering roughly the same radius you pregenerated with Chunky (800 blocks ≈ 50 chunks), spacing passes about 1–1.5× your render distance apart so coverage overlaps slightly.
   - Partial coverage is fine — anywhere you don't reach just falls back to the normal fog edge, same as skipping this step, not an error.
   - Quit when you've covered the zone. This is what actually populates `Distant_Horizons_server_data/` in the instance with real LOD data — do **not** try to shortcut this by installing Distant Horizons on the dedicated server instead (see the warning in `modpack.md`'s Performance section — DH-on-server crashes when Chunky is also present).
6. Quit the launcher, then export the instance via **right-click the instance → Export Instance** (don't blindly zip the raw folder — the exporter lets you pick what's included). Check: `mods/`, `config/`, `options.txt`, `servers.dat`, `Distant_Horizons_server_data/`. Uncheck: `logs/`, `crash-reports/`, `screenshots/`, and any asset/library caches — those regenerate automatically on first launch and just bloat the zip. Name the result `modpack.zip`, with the instance's folder (`LANParty/...`) as the zip's top-level entry.
**Caveats for this to actually pay off for participants:**
- Don't rename the server list entry or change Distant Horizons' "Server Folder Name Mode" setting afterward — both are part of the cache key (`"<server name> <ip>:<port>"` by default). Change either and participants' clients won't find the cache you built.
- Don't regenerate/reset the server world after this point. If the actual party world differs from the one you explored, the cached LOD will show stale terrain that doesn't match reality.
- This cache is for *scenery beyond render distance* only — it doesn't substitute for the server having `online-mode=false` or for Chunky's pregen; all three pieces (pregen, DH cache, offline accounts) are independent and all need to land in the final zip/setup.
4. **Set up the server first** — do the "The server" and "Pre-generate terrain before the party starts (Distant Horizons Full-mode)" steps below *before* continuing here.
5. Launch the client, go to **Multiplayer → Add Server**, enter `minecraft.mivanchenko.de:25565`, and join for real. Set your preferred video settings (these land in `options.txt`). No manual flying pass needed — Distant Horizons is installed server-side (same build both sides) and streams accurate LOD data directly to any connected client with Distant Generation enabled, so coverage is automatic for every participant, not just something baked in by the host ahead of time.
6. Quit the launcher, then export the instance via **right-click the instance → Export Instance** (don't blindly zip the raw folder — the exporter lets you pick what's included). Check: `mods/`, `config/`, `options.txt`, `servers.dat`. Uncheck: `logs/`, `crash-reports/`, `screenshots/`, `Distant_Horizons_server_data/` (not needed — each client builds its own via the server-side streaming), and any asset/library caches — those regenerate automatically on first launch and just bloat the zip. Name the result `modpack.zip`, with the instance's folder (`LANParty/...`) as the zip's top-level entry.
## 2. The server: `mivanchenko.de` (always-on, not a box you carry to the venue)
@@ -63,23 +53,29 @@ Practical knobs to turn if the box is lighter than the table:
- `MIN_RAM`/`MAX_RAM` in `setup-server.sh` default to `2G`/`4G` — bump `MAX_RAM` to match the table above for your headcount before running the script (or edit `lazymc.toml`'s `command` line afterward and `sudo systemctl restart mc-lazymc`).
- An SSD matters more than raw disk size here — Create's block-entity-heavy contraptions do a lot of small, frequent chunk saves; a spinning HDD will show up as tick-time spikes.
### Pre-generate chunks before the party starts (Chunky)
### Pre-generate terrain before the party starts (Distant Horizons Full-mode)
Chunky (server-side mod, already listed in `modpack.md`) fills in a radius of real terrain ahead of time so nobody hits on-the-fly generation lag while exploring. Do this once, before participants arrive:
Distant Horizons (same build, both client and server `mods/`) handles pregeneration itself now — Chunky is not used (see `modpack.md`'s Performance section for why). Edit `mcserver/config/DistantHorizons.toml`, under `[common.worldGenerator]`:
1. Make sure `mcserver/mods/` has the Chunky jar, then `sudo systemctl restart mc-lazymc` and let the server boot (connect once from a client, or `sudo journalctl -u mc-lazymc -f` and wait for "Done").
2. Run the commands below either from the server console (attach via `sudo systemctl stop mc-lazymc && cd mcserver && bash run.sh nogui`, temporarily bypassing lazymc so you get an interactive console) or via RCON (`mcrcon -H 127.0.0.1 -P 25575 -p <password from server.properties> "<command>"`):
```toml
chunkGeneratorMode = "INTERNAL_SERVER"   # default is "FEATURES" (LOD-only, doesn't save real chunks) — change to this
generationCenterChunkX = 0               # or your build area's center, in chunk coords (block coords / 16)
generationCenterChunkZ = 0
generationMaxChunkRadius = 50            # 50 chunks ≈ 800 blocks. 0 (the default) means unbounded/follows render distance instead
```
   ```
   /chunky center 0 0        # or your build area's coordinates
   /chunky radius 800        # 800 blocks ≈ 50 chunks (1 chunk = 16 blocks)
   /chunky start
   /chunky confirm           # if it warns about area size
   ```
3. Watch progress with `/chunky status`. For ~50 chunks radius this finishes in seconds to a couple minutes depending on the box.
4. If you stopped lazymc to get console access in step 2, restart it afterward: `sudo systemctl start mc-lazymc`.
`INTERNAL_SERVER` mode is the one that matters — unlike the other modes, it actually generates and saves real chunks to the region files (not just LOD approximation), which is the same job Chunky would've done.
Repeat with `/chunky world the_nether` / `/chunky world the_end` first if you want the Nether/End build areas pregenerated too (useful since the roadmap sends people there for Nether's/End's Delight dishes).
This only runs while the actual Java process is up, and **lazymc will stop it again after the idle timeout if nobody's connected** — so for this one-time pregen session, bypass lazymc and run the server directly instead of waiting on the sleep/wake cycle:
```bash
sudo systemctl stop mc-lazymc
cd mcserver && bash run.sh nogui
```
Watch the console for `DH-Request Module Ticker` / world-gen-queue log lines — generation runs automatically in the background once the world is loaded, no command needed to kick it off (unlike Chunky's `/chunky start`). Let it run until the console goes quiet / chunks-per-second drops to near zero, then `stop` from the console (or Ctrl+C) and bring lazymc back: `sudo systemctl start mc-lazymc`.
Repeat for Nether/End build areas if you want those pregenerated too (useful since the roadmap sends people there for Nether's/End's Delight dishes) — DH generates per-dimension automatically as each is loaded; no separate per-dimension command needed, just make sure you (or a connected client) actually visit those dimensions once during the pregen session to trigger their world-gen queues.
## 3. File distribution: Gitea, not a local file server
@@ -100,4 +96,6 @@ Make sure your Minecraft server itself is running with `online-mode=false` in `s
- Re-running either script is safe/idempotent: it skips re-downloading the modpack if the instance folder already exists, and just overwrites `accounts.json` with the (same, deterministic) account if the nickname is unchanged.
- lazymc's first wake after a sleep takes as long as the Forge server normally does to boot (expect 20–60s depending on the box) — the client will show a "starting" MOTD/kick message during that window; just reconnect after a few seconds.
- `setup-server.sh` pins a Forge build (`47.4.28` for `1.20.1`) — check [files.minecraftforge.net](https://files.minecraftforge.net/net/minecraftforge/forge/index_1.20.1.html) if it's gone stale by the time you run this.
- 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.
- 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.