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.
 
@@ -35,7 +35,7 @@ Target: **Minecraft 1.20.1, Forge**. This version/loader combo has the widest, m
| [FTB Teams (Forge)](https://www.curseforge.com/minecraft/mc-mods/ftb-teams-forge) | Required dependency of FTB Quests — also lets you decide whether quest progress is per-player or shared per-team, worth deciding before building the quest line (per-player means everyone cooks everything themselves; shared team means the group completes the roadmap together). |
| [Architectury API](https://modrinth.com/mod/architectury-api) | Required dependency (cross-loader API FTB's mods are built on). |
All four go in **both** client and server `mods/` folders — unlike Distant Horizons/Chunky above, quest progress is synced through the server, so it's not optional on either side.
All four go in **both** client and server `mods/` folders — quest progress is synced through the server, so it's not optional on either side (same as Distant Horizons and the VR mods, see below).
**Install via Fjord's built-in CurseForge/Modrinth browser, not manual jars** — these four mods have had real version-mismatch bugs between each other on 1.20.1 ([example](https://github.com/FTBTeam/FTB-Mods-Issues/issues/1168)), and the in-launcher browser resolves compatible dependency versions automatically instead of you having to hand-pick a working combination.
@@ -45,24 +45,23 @@ All four go in **both** client and server `mods/` folders — unlike Distant Hor
| Mod | Side | Why it's in |
|---|---|---|
| [Vivecraft](https://modrinth.com/mod/vivecraft) | Client only | Adds VR rendering/motion controls for anyone with a **PC-tethered or PC-streamed headset** (Index, Vive, or a Quest using Air Link/Virtual Desktop into a gaming PC). Pure client-side — connects to the same server as everyone else playing on a flat screen, no server mod required for basic play. |
| [ViveCraft Compat](https://www.curseforge.com/minecraft/mc-mods/vivecraft-compat) | Client only | Patches specific interactions between Vivecraft and other mods in this pack — notably **Create** (fixes driving trains, track hitboxes, elevator controls in VR) and HUD overlay support for Jade. Requires Vivecraft. |
| Customizable Player Models | Client only (likely also needs server-side for other players to see the model — verify) | Pulled in by Fjord's dependency resolver alongside Vivecraft; lets a player's in-VR avatar/body be customized rather than using the default. |
| [Vivecraft](https://modrinth.com/mod/vivecraft) | **Both client and server** | Adds VR rendering/motion controls for anyone with a **PC-tethered or PC-streamed headset** (Index, Vive, or a Quest using Air Link/Virtual Desktop into a gaming PC). Correction from earlier: this needs the Vivecraft mod on the dedicated server too, not just the client — without it, other players (VR *and* flatscreen alike) only see the VR player's vanilla default swing animation instead of their actual arm/head/body movement. (The "Vivecraft Spigot Extensions" plugin that does this job on Spigot/Paper servers doesn't apply here since we're Forge — it's the same Vivecraft mod jar on both sides.) |
| [ViveCraft Compat](https://www.curseforge.com/minecraft/mc-mods/vivecraft-compat) | **Both client and server** | Patches specific interactions between Vivecraft and other mods in this pack — notably **Create** (fixes driving trains, track hitboxes, elevator controls in VR) and HUD overlay support for Jade. Requires Vivecraft. Since those interactions (e.g. train physics) are server-authoritative, this goes server-side too. |
| Customizable Player Models | **Both client and server** | Pulled in by Fjord's dependency resolver alongside Vivecraft; lets a player's in-VR avatar/body be customized. Same pattern as Vivecraft — other players need the server to relay that data to see the custom model/movement. |
**Note on standalone Quest headsets (no PC):** this is for *PC-tethered/streamed* VR only. A standalone Meta Quest with no gaming PC involved would use **QuestCraft** instead — a separate sideloaded Android app that bundles its own Minecraft+Vivecraft runtime directly on the headset. QuestCraft does **not** go through Fjord/`install.sh`/`install.ps1` at all; it's installed on the headset itself via sideloading tools (SideQuest etc.), connects to the same server address, but has its own separate mod manager with less certain compatibility against a heavy pack like this one (Create/Flywheel especially). If anyone at the party wants to join standalone without a PC, treat that as a separate per-person setup, not something this repo's scripts handle.
Vivecraft auto-detects whether a headset is actually connected and falls back to normal flatscreen play otherwise — so it's safe to leave in the single shared `modpack.zip` for everyone rather than maintaining a separate VR-only instance; people without a headset just won't notice it's there.
Vivecraft auto-detects whether a headset is actually connected and falls back to normal flatscreen play otherwise — so it's safe to leave in the single shared `modpack.zip` for everyone rather than maintaining a separate VR-only instance; people without a headset just won't notice it's there. The server-side requirement above means these three mods need to be in the dedicated server's `mods/` folder unconditionally too, even if nobody ends up using VR that day — it's not optional/elective like Distant Horizons.
## Performance utility
| Mod | Side | Why it's in |
|---|---|---|
| [Distant Horizons](https://modrinth.com/mod/distanthorizons) | Client only | 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. Caches the LOD data locally per-world, same idea as Bobby's chunk cache. |
| [Chunky](https://www.curseforge.com/minecraft/mc-mods/chunky-pregenerator-forge) | Server only | Pre-generates a fixed radius of chunks around a chosen center (e.g. spawn/build area) **once, before the party**, via console/RCON commands (`/chunky radius`, `/chunky start`) — eliminates on-the-fly world-gen lag while people explore. **Not** a per-player dynamic follower on Forge — that variant ("Chunky Pregenerator") is Fabric-only, same restriction as Bobby. See `HOSTING.md` for the exact commands. |
| [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). |
**Do not install Distant Horizons on the dedicated server, even though DH has an optional server-side mode for pushing accurate LOD data without clients needing to explore.** DH-on-server + Chunky-on-server together crashes the world on first chunk load (`IllegalStateException: Chunky is not loaded`, thrown from DH's Chunky-compat accessor trying to bind to a provider API that's only properly initialized on Bukkit/Paper's Chunky plugin, not the Forge mod port). Keep DH strictly client-only as documented above; get accurate distant terrain by having the host physically explore the pregenerated area once (creative-flight spiral pattern, see `HOSTING.md`) and bundling the resulting `Distant_Horizons_server_data/` cache into `modpack.zip` instead.
**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.
**Important:** install Distant Horizons in the client instance's `mods/` folder only — do **not** put it in the server's `mods/` folder. It tags itself as client-side in its mod metadata, so Forge won't reject the mismatched mod list between client and server. Keep the server's `server.properties` `view-distance` modest (6–8, see `HOSTING.md` sizing section) and let Distant Horizons fill in the rest visually on each client. Chunky, conversely, only needs to go in the **server's** `mods/` folder — it has no client-side purpose here.
**Setup:** same DH jar/version on both client and server `mods/` folders (mismatched builds between the two sides are the officially recommended-against configuration). On the server, set Distant Generation mode to `FULL` (or `INTERNAL_SERVER`) and a generation radius in DH's config — this pregenerates real terrain *and* builds the LOD cache in one automatic background pass, no manual flying required. See `HOSTING.md` for exact config.
## Optional / stretch (only if the group wants more scope)
@@ -70,37 +69,39 @@ Vivecraft auto-detects whether a headset is actually connected and falls back to
|---|---|---|
| [Aether's Delight](https://modrinth.com/mod/the-aethers-delight) | Aether-themed dishes (Holystone/Zanite knives, berry bowls, buffed meals) | Requires installing **The Aether** too — a full extra dimension mod. Only add if someone really wants to make the trip. |
## Installed list (as actually downloaded)
## Installed list (ground truth, from the actual exported client `mods/` folder)
What Fjord's dependency-resolver pulled in when adding the mods above — several of these are auto-added dependencies/QoL mods I hadn't called out individually. Transcribed from the "You're about to download the following mods" confirmation dialog on 2026-10-23; **the dialog was scrolled/cut off in the screenshot, so this list may be incomplete** — if there were more entries below `Nether's Delight`, let me know and I'll fold them in (expecting at least `Flywheel` and possibly `FarmersCreate` to still be in there).
Confirmed by extracting `LANParty.zip` directly — 25 jars, superseding the earlier screenshot-based guess (the FTB `(NeoForge)`-labeling concern resolved itself: all three loaded as their Forge builds fine). Side column reflects what's actually in `mcserver/mods/` on the deployed server as of this writing.
| Mod | Role |
|---|---|
| AppleSkin | QoL — HUD overlay showing exact hunger/saturation/exhaustion values instead of guessing from the icon. |
| Architectury API | Dependency — cross-loader API FTB's mods are built on. |
| Chunky (Forge/NeoForge) | Listed above — server-side pregen. |
| Create | Listed above — core. |
| Create Slice & Dice | Create addon — automates cutting/dicing-style food prep via Create contraptions; pulled in alongside Delightful Creators for the Create↔food bridge. |
| Delightful | Listed above. |
| Delightful Creators [Forge] | Listed above. |
| Distant Horizons: A Level of Detail mod | Listed above — client-only LOD rendering. |
| End's Delight | Listed above. |
| Farmer's Delight | Listed above — base. |
| Farmer's Respite | Farmer's Delight addon — adds tea/drinks (kettle, brewed teas) as another food category; worth adding a quest or two for this if you want a drinks stage in the roadmap. |
| Farmers Structures | Adds farmhouse-style structures that generate in the world — gives the Overworld food chapter something to explore toward, not just build from scratch. |
| [FerriteCore](https://modrinth.com/mod/ferritecore) | Performance — reduces RAM usage by deduplicating/compacting in-memory data structures (block states, chunk storage) that Forge normally keeps bloated. Pure upside, no gameplay effect; lowers how much of the `HOSTING.md` sizing-table RAM budget actually gets used. Goes in **both** client and server `mods/` folders. |
| FTB Library (NeoForge) | Listed above — FTB Quests dependency. |
| FTB Quests (NeoForge) | Listed above — the quest book. |
| FTB Teams (NeoForge) | Listed above — FTB Quests dependency. |
| Jade | QoL — "look at" overlay showing block/entity info on hover (WAILA-style), handy with this many new mod blocks/crops to identify. |
| Just Enough Items (JEI) | Listed above — recipe lookup. |
| Kotlin for Forge | Library dependency — several newer mods (Jade and others) are written in Kotlin and need this runtime present. |
| MezzConfig | Library dependency — shared in-game config-menu framework used by multiple mods here. |
| ModernFix | Performance — reduces startup/load time and fixes various vanilla/Forge memory leaks; pure upside for a 3-day session that stays up a long time. |
| Mouse Tweaks | QoL — shift-click/drag item sorting in inventories, genuinely load-bearing once Create/Farmer's Delight items start filling chests. |
| Nether's Delight | Listed above. |
| Mod | Side | Role |
|---|---|---|
| AppleSkin | Both | QoL — HUD overlay showing exact hunger/saturation/exhaustion values instead of guessing from the icon. |
| Architectury API | Both | Dependency — cross-loader API FTB's mods are built on. |
| Create | Both | Listed above — core. Bundles **Flywheel** and **Ponder** internally via Forge's JarJar mechanism — they auto-extract at runtime, no separate jar needed on either side. |
| Create Slice & Dice | Both | Create addon — automates cutting/dicing-style food prep via Create contraptions; pulled in alongside Delightful Creators for the Create↔food bridge. |
| Delightful | Both | Listed above. |
| Delightful Creators | Both | Listed above. |
| [Distant Horizons](https://modrinth.com/mod/distanthorizons) | Both | Listed above — same build both sides, server-side Full-mode pregen replaces Chunky (see Performance section). |
| End's Delight | Both | Listed above. |
| Farmer's Delight | Both | Listed above — base. |
| Farmer's Respite | Both | Farmer's Delight addon — adds tea/drinks (kettle, brewed teas) as another food category; worth adding a quest or two for this if you want a drinks stage in the roadmap. |
| Farmers Structures | Both | Adds farmhouse-style structures that generate in the world — gives the Overworld food chapter something to explore toward, not just build from scratch. |
| [FerriteCore](https://modrinth.com/mod/ferritecore) | Both | Performance — reduces RAM usage by deduplicating/compacting in-memory data structures (block states, chunk storage) that Forge normally keeps bloated. Pure upside, no gameplay effect; lowers how much of the `HOSTING.md` sizing-table RAM budget actually gets used. |
| FTB Library | Both | Listed above — FTB Quests dependency. |
| FTB Quests | Both | Listed above — the quest book. |
| FTB Teams | Both | Listed above — FTB Quests dependency. |
| Jade | Both | QoL — "look at" overlay showing block/entity info on hover (WAILA-style), handy with this many new mod blocks/crops to identify. |
| Just Enough Items (JEI) | Both | Listed above — recipe lookup. |
| Kotlin for Forge | Both | Library dependency — several newer mods (Jade and others) are written in Kotlin and need this runtime present. Note: distributed as `kotlinforforge-4.12.0-all.jar` (the "-all" / fat-jar variant), not the bare `kffmod` name. |
| MezzConfig | Both | Library dependency — shared in-game config-menu framework used by multiple mods here. |
| ModernFix | Both | Performance — reduces startup/load time and fixes various vanilla/Forge memory leaks; pure upside for a 3-day session that stays up a long time. |
| Mouse Tweaks | Both | QoL — shift-click/drag item sorting in inventories, genuinely load-bearing once Create/Farmer's Delight items start filling chests. |
| Nether's Delight | Both | Listed above. |
| Customizable Player Models | Both | Listed above (VR section) — corrected from client-only to both sides. |
| Vivecraft | Both | Listed above (VR section) — corrected from client-only to both sides. |
| ViveCraft Compat | Both | Listed above (VR section) — corrected from client-only to both sides. |
Note the dependency-resolver pulled in `(NeoForge)`-labeled builds for the FTB mods — double-check in Fjord that these are actually resolving against your Forge 1.20.1 instance correctly (Fjord's CurseForge integration sometimes labels the underlying artifact by its primary platform name even when serving the Forge-compatible build); if the instance fails to load with a loader-mismatch error on these three, swap to the explicitly-"Forge"-tagged FTB Library/Quests/Teams listings instead.
**Chunky is explicitly not in this list** — removed from the client early on (it was causing the DH crash before we understood the root cause), and never added back server-side either now that DH's own Full-mode generation replaces its job. See the Performance section above for why.
## Why this shape
 
@@ -15,7 +15,7 @@ FORGE_MC_VERSION="1.20.1"
FORGE_BUILD="47.4.28"                 # current recommended build for 1.20.1 — check files.minecraftforge.net if this is stale
MC_PUBLIC_PORT=25565                  # what players connect to (lazymc listens here)
MC_INTERNAL_PORT=25566                # real server listens here, lazymc proxies to it
SLEEP_AFTER="5m"                      # idle time before lazymc stops the real server
SLEEP_AFTER=300                       # idle seconds before lazymc stops the real server (this lazymc build wants a plain integer, not "5m")
MIN_RAM="2G"
MAX_RAM="6G"                          # 5-8 players; see ../HOSTING.md sizing table — bump to 8G (9-12p) or 10-12G (13-15p)
# ------------------
@@ -82,8 +82,8 @@ wake_whitelist = false
address = "0.0.0.0:${MC_PUBLIC_PORT}"
[time]
sleep_after = "${SLEEP_AFTER}"
minimum_online_time = "1m"
sleep_after = ${SLEEP_AFTER}
minimum_online_time = 60
[motd]
sleeping = "☀ Server is asleep, join to wake it up"