JUMP KING QUEST Multiworld Setup Guide (vertical slice)
This is the setup guide for the JUMP KING QUEST Archipelago vertical slice. It is a minimal,
proof-of-transport world: one location (Cell Key), one item (Axe), and a debug goal (obtain the
Axe). It exists to validate the connection between an Archipelago server and the JUMP KING QUEST
BepInEx client, not to provide a full randomizer.
Required software
- Archipelago 0.6.7 (running from source, or a build that includes this apworld).
- The JUMP KING QUEST game on the single supported build
(
Assembly-CSharp.dllSHA-256bbe52797799b32bae131987073d3dc138b7aa270505dc4221fd340c6b2beef21). - The JKQ Archipelago Network Slice BepInEx plugin
(
client/JKQArchipelago.NetworkSlice), built and deployed separately.
Generating a game
- Create a YAML from the template
JUMP KING QUEST.yaml(inworld/templates/). The slice exposes no game-specific options, so the defaults are sufficient. - Generate a seed with your local Archipelago 0.6.7 (
Generate.py), or host it on a room.
Hosting locally: the Windows Firewall prompt
Most players connect to a remote room (e.g. archipelago.gg): that is an outbound connection, Windows allows it by default, and there is nothing to configure.
If you host the server on your own PC, the first time you launch it Windows shows its standard firewall consent prompt ("Allow access?"). Tick both network types (private and public) and confirm — that single OS prompt creates the correct rule. Do not skip it: a rule scoped to only one network profile can drop your in-game connection mid-session when Windows re-identifies the network (e.g. after a brief line outage). No manual firewall configuration is ever required beyond that prompt, and the client automatically reconnects in-session if the connection hiccups anyway.
One more local-hosting note: the stock server closes a client whose websocket pong is delayed more
than 20 seconds, and heavy game moments (loads, engine pauses) can exceed that. When hosting for
JKQ players, prefer a raised ping tolerance — this repository ships
scripts/jkq_multiserver_tolerant.py, a launcher that starts the unmodified server with
ping_timeout=300 (usage: same arguments as MultiServer.py). Remote/public rooms keep their own
policy; the client's in-session reconnect covers those.
Connecting the client
- Start a local Archipelago server (
MultiServer.py) with the generated.archipelago. - Launch JUMP KING QUEST offline / single-player with the Network Slice plugin deployed.
- Configure
BepInEx/config/jkq.archipelago.networkslice.cfg:Enabled = trueHost,Port,SlotNamematching your room/seed.
- On successful login the client validates
slot_data(protocol, world version, build hash, location/item IDs) and logs the result. In this slice the location check is sent manually and no item is applied to the JKQ save (transport proof only).
See docs/NETWORK_SLICE_DESIGN.md in the repository for the full local test procedure.
Pre-Warden pickup slice (world 0.2.0 / protocol 2)
The randomize_world_pickups YAML option (default on) turns the seven physical Redfin Prison
pickups — Cell Key, Redfin Bandit Hood, Metal Pipe, Hotdog, Pot Lid Shield, Prison Entrance Key, and
the Starter Class Loadout chest — into Archipelago checks, each mapped to one received reward package,
with the goal being the Warden first-clear. Turn it off to keep every pickup vanilla while
still goaling on the Warden.
The BepInEx client engages the pre-Warden slice only when EnablePreWardenSlice is armed (with the
exact confirmation phrase) AND the connected seed is protocol 2 with a matching embedded registry;
otherwise it fails closed (no suppression, no check, no grant) and legacy protocol-1 seeds are
unaffected. The full slice is runtime-validated (2026-07-26): a complete free-placement seed was
played end-to-end — 7/7 checks delivered, 7/7 packages granted exactly-once, Warden goal confirmed —
including automatic in-session reconnection after connection losses.
0.2.1 update
The Hotdog became a single randomizable item; Humoral Slop is a vanilla-only resource (not randomized, no AP id). Old 0.2.0 seeds are not compatible.
0.2.2 update (current)
The pre-Warden slice is world 0.2.2 / registry 2.2.0 (SHA 284a6f20…). It models the
weapon-gated Breakable Wall inside the prison (a runtime-discovered gate): Pot Lid Shield and
the Prison Entrance Key sit beyond it, reachable only with the Metal Pipe or the Starter Class
Loadout, so generation can never softlock a seed behind the wall. Old 0.2.1 seeds are rejected by
the 0.7.x client (softlockable logic). Ids, packages, and plans are unchanged.
0.2.1 / plugin 0.6.2 — Hotdog: randomizable item vs vanilla renewable resource
Product decision. A pre-Warden pickup can contain BOTH a unique Archipelago item AND a vanilla-only renewable resource. The Hotdog pickup is the first such case:
item_hotdog×1 — RANDOMIZABLE. The Hotdog is the AP item: it has AP id231765005(name "Hotdog"), is in the item pool / DataPackage, and is delivered when received from Archipelago.item_humoralslop×3 — VANILLA ONLY. Humoral Slop is the renewable fuel of the Eternal Hotdog (3 Slop are consumed per use; total capacity 15). It has no AP id, is absent from the DataPackage/pool, is never received from the server, never granted by the client, never a package component, and never produces an AP popup. Any Humoral Slop obtained in the game (reward/drop) stays vanilla.
Partial suppression. When randomize_world_pickups=true, the physical Hotdog pickup's two vanilla slots
are handled per their disposition: slot 0 (item_hotdog) is SuppressAndRandomize (vanilla grant
suppressed, AP item delivered instead); slot 1 (item_humoralslop ×3) is PassThroughVanilla (the vanilla
grant is left to run — JKQ adds the Slop, produces its own native popup, and enforces the cap). The AP check
is published only after BOTH slots are observed exactly (observed=2, suppressed=1, passThrough=1, no mismatch,
marker false→true). When randomize_world_pickups=false, both slots stay fully vanilla (no suppressor armed).
Consequences.
- A Hotdog received from Archipelago is granted without charges if the player has no Humoral Slop yet — the AP item is only the Hotdog; the Slop fuel is earned vanilla.
- The physical Hotdog location always grants the vanilla Humoral Slop (pass-through), whether or not the Hotdog item itself was randomized away.
- The client does NOT verify the Slop quantity landed (cap/merge/popup are JKQ's responsibility); it only verifies the correct vanilla call was passed through. Slop at the cap does NOT make anything ambiguous.
Compatibility / migration.
- The registry schema is 2.1.0, world 0.2.1, registry SHA
d5c8dceb98c09ab62bd6fdf566bc045cff57d26f82cbebdbe098d15264f42b45(was 2.0.0 / 0.2.0 /8cac2475…). An old 0.2.0 / 2.0.0 seed is rejected by the new client (SHA/version mismatch); a new seed and profile are required. - The old H1b runtime record (
receivedIndex=4,EffectStatus=ambiguous, packageName "Hotdog Package", two components) is historical evidence: it is never migrated, re-read, completed, re-granted, or presented. The new registry SHA and a new seed/profile produce separate ledgers. - Client protocol stays 2; all 7 location ids and 7 package item ids are unchanged (
231765005kept, now named "Hotdog", single component).