Builders » Guide

Offline builder — deep dive & submission

How the single-file HTML builder works under the hood, full feature reference, save/load/import workflow, .json snapshots, what each export tab does, common patterns, and how to submit finished zones to staff for in-game merge.

Last updated: 2026-05-19

📥 Download as Markdown

Offline builder — deep dive & submission

The offline builder is a single-file HTML editor for building JediMUD zones without being connected to the game. Draft your zone offline, export the four canonical files, submit to staff. This doc explains how it actually works + the submission workflow.

What it is — technically

  • One HTML file (jedimud-builder.html, ~1700 lines, ~60 KB).
  • Embedded CSS + JavaScript — no external resources, no fetch calls, no analytics.
  • Runs in any modern browser. Works offline after the first download.
  • State persists to localStorage automatically on every keystroke (no Save button needed for in-progress work).
  • Exports the four canonical zone files plus a portable .json snapshot.

The builder doesn’t connect to the MUD or to the website. It’s a calculator — input boxes in, validated text files out.

Where state lives

SurfacePersistence
In-memory stateThe state JS object — lost on tab close
Browser localStorageAuto-saved on every change. Survives reload. Lost on Clear Browsing Data.
.json snapshot fileExplicit download via “Save .json”. Portable across browsers/devices.
Four exported files (.wld/.mob/.obj/.zon)Explicit download from the Preview tab. The deliverable to staff.

The localStorage auto-save uses key STATE_KEY (single key, full state blob as JSON). If two tabs are editing in the same browser, the most recent write wins — work in one tab at a time.

The five tabs

Zone

Top-level metadata:

FieldNotes
VnumPick a free vnum (ask staff). Defaults to 0.
NameDisplay name (zedit ... Z).
BuildersSpace-separated character names — appears in zone info.
Bot / TopVnum range. Auto-computed as vnum × 100 to vnum × 100 + 99. Override if you need a non-standard range.
Lifespan min / maxReset interval range in minutes. Engine picks a random value each cycle.
Reset mode0=never, 1=when empty, 2=normal. Default: 1.
Zone flagsDESERT/WATER/OPENLAND/MOUNTAIN/FOREST/CITY/ISLAND/ARTIC (terrain) + WORLDMAP/NOBUILD (behavior).
Mort + Imm level rangeSoft restrictions — see Building zones.
Zone historyFree-text changelog field. Use it.

Rooms

Each room editor:

  • Name (single line, ≤ 60 chars practical)
  • Description (multi-line)
  • Sector type — drop-down with inside/city/field/forest/hills/mountain/water_swim/water_noswim/underwater/flying/desert/cave
  • Room flags — multi-select (DARK, NOMOB, INDOORS, PEACEFUL, SOUNDPROOF, etc.)
  • All 6 cardinal exits + Up/Down (NE/NW/SE/SW available if you toggle diagonal-dir support — depends on tree)
    • Per exit: destination vnum, exit description, door keyword, key vnum, door flags (ISDOOR/CLOSED/LOCKED/PICKPROOF/SECRET)
  • Extra descriptions — keyword-triggered look at X text bits

The builder validates that destination vnums either exist in your zone OR are flagged as cross-zone references. Cross-zone refs export with the destination as-typed; staff verify at merge time.

Mobs

Each mob editor:

  • Keywords / short-desc / long-desc / detail-desc
  • Sex / Position / Default Position
  • Level, AC, hitroll, damroll
  • HP dice (NumDice d SizeDice + Add)
  • Bare-hand damage dice
  • Gold + XP
  • Alignment
  • NPC flags (multi-select — SENTINEL/AGGR/SCAVENGER/STAY_ZONE/HELPER/…)
  • AFF flags
  • Race / Class / Size (placeholder enums — actual values get resolved at import)

No spec procs in v1 — you’ll attach those in-game via medit ... P after the zone merges. See Building mobiles.

Objects

Each object editor:

  • Keywords / short-desc / long-desc / action-desc
  • Item type (drop-down across all 27 types)
  • Extra flags + wear flags
  • Weight + Cost + Cost/Day + Timer
  • Values 0-5 (the builder shows hints about what each val means for the current type — e.g. for WEAPON: val1=dice_count, val2=dice_sides, val3=attack_type)
  • Material
  • Applies (up to 6 — APPLY_STR/HITROLL/AC/…)

Same as mobs: spec procs come later in-game.

Resets

The zone reset command list. Per-command:

  • Letter — M / O / G / E / P / D / R / A (the standard 8). L/C/K/N/U/J/F/H are placeholders in v1; the cross-zone letters are typically authored in-game where staff can validate cross-zone refs.
  • if flag — 0=unconditional, 1=only if previous succeeded
  • Vnums + chance percent + max-in-world

Visual chain-indenting in the UI shows which G/E/P commands belong to which prior M/O.

Preview

Four read-only views of the exported files. Each has:

  • Copy — to clipboard
  • Download — as .<type> file with the right extension

Plus a single “Export zone” button that downloads all four at once.

Save / load / import

Save .json — the portable snapshot

Click “Save .json” in the toolbar. You get <zone-name>.json — a full state blob you can:

  • Email to yourself
  • Sync to Dropbox / a USB stick
  • Open in another browser via “Load .json”
  • Carry between devices

This is the work-in-progress format. Don’t submit this to staff — they want the four canonical files instead.

Load .json

Open a .json snapshot — replaces current state. Confirms first.

Import zone files

If staff have given you the existing source files of a zone you want to extend, click “Import zone files” and select one or more of .wld/.mob/.obj/.zon. The builder parses them back into editable state.

Use cases:

  • Extending an existing zone (download from staff, import, add rooms, re-export, resubmit).
  • Templating off a similar zone (import for the layout pattern, then modify).
  • Rescuing pre-OLC zone files from old MUDs (round-trip through the builder to clean up format).

The parser is forgiving but not perfect — exotic non-standard zone-file formats might lose some details. Always preview after import to confirm the round-trip preserved your data.

Validation

The builder warns inline on common mistakes:

  • Vnum out of range — your zone is 30 (3000-3099), you put a room at vnum 4000.
  • Exit dest doesn’t exist in this zone — flagged as a cross-zone ref (you confirm or fix).
  • Reset command references missing entity — e.g. M 0 3000 1 9999 100 (room 9999 doesn’t exist in your zone).
  • Missing required fields — keywords on a mob, a room name, a sector type.
  • Sector + room flags mismatch — INDOORS on a water_swim room is suspicious.

Validation is non-blocking — you can export with warnings, but staff will flag them on submission.

Common patterns

Three-room mini-zone with one mob

A useful smallest-example. Three connected rooms, one wandering mob with a couple grants.

  1. Zone — vnum 80, range 8000-8099, lifespan 20-30 min.
  2. Rooms — 8001 (entrance), 8002 (middle), 8003 (deep). 8001’s north → 8002; 8002’s north → 8003. 8001’s south → -1 (an exit to the outside world; staff will wire it post-merge).
  3. Mob — 8001, a wandering troll. Lvl 5, no AGGR, STAY_ZONE flag.
  4. Object — 8050, a club. WEAPON, 2d4+1, drops from the troll.
  5. Resets:
    • M 0 8001 1 8002 100 (troll into middle room)
    • G 1 8050 1 100 (give club to troll, if-flag=1)
  6. Export, submit.

Forest with a wandering encounter table

  1. Zone: 90, range 9000-9099, FOREST flag.
  2. Build ~20 rooms in a connected forest layout.
  3. Build 4-5 different mob vnums (wolf, bear, deer, traveler, etc.).
  4. Reset commands: M 0 9001 N <room> <chance> for each mob, with chance 25-50 (instead of 100) — the lower chance produces a varied encounter table on each reset.
  5. Use STAY_ZONE on aggressive mobs so the wolf doesn’t wander into town.

Indoor dungeon with a boss

  1. Zone: 100, range 10000-10099, no terrain flag (it’s a dungeon — INDOORS).
  2. Boss room at 10050. INDOORS, NOMOB (so adds don’t wander out), maybe DARK.
  3. Boss mob — high level, MULTHIT0 or MULTHIT1, MEMORY, AGGR. No STAY_ZONE (boss stays put because the room is NOMOB-flagged).
  4. Boss object — e.g. a unique sword. Reset with chance 100 so it always loads when the boss does.
  5. Death drop comes from a spec proc attached in-game after merge.

Submission to staff

When the zone is ready:

  1. Pre-flight check:

    • Every room reachable from the zone’s entry point.
    • No vnum collisions with other zones (ask staff or check the Zones browser tool).
    • All reset commands reference vnums that exist in your zone or are confirmed cross-zone.
    • Zone history field has your name + date.
  2. Export: Preview tab → “Export zone” → download all four files.

  3. Naming: rename to match the zone’s vnum:

    • 30.wld, 30.mob, 30.obj, 30.zon if your zone vnum is 30
    • Match the zone vnum, not the bot-vnum of the range. (Zone 30 has rooms 3000-3099, but the files are 30.* not 3000.*.)
  4. Submit:

    • Discord: drop into the #zone-submissions channel (or whatever your tree uses) with a short summary.
    • Email: to jedi-admin@jedimud.net with the four files attached + a description of what the zone is.
    • In-game: tell a staff member you have a zone ready; they may want to see it before you send.
  5. Review feedback — staff will reply with merge status. Common feedback:

    • Vnum reassigned (your originally-picked vnum was already taken).
    • Stats out of band (a level-5 mob with 500 HP — staff will ask you to scale).
    • Missing extra descriptions on key rooms.
    • Reset command sequence has a bug.
  6. Iterate — fix and resubmit.

  7. Post-merge OLC — once your zone is in-game, you’ll get access to zedit on it (your name in the builders list grants that). Refine via zedit/redit/medit/oedit going forward. The offline builder is for greenfield work + bulk edits; in-game OLC is for tuning.

See Zone import process for what staff does on the receiving end.

Limitations

The offline builder doesn’t currently handle:

  • Shops (.shp) — author in-game via sedit after merge.
  • DG triggers (.trg) — author via trigedit (or hand-write the file and submit alongside).
  • Quests (.qst) — qedit.
  • Spec procs — attach via the P menu in medit/oedit/redit after merge.
  • Cross-zone reset commands (L/C/K/N/U/J/F/H) — author in-game where staff can validate the cross-zone refs.
  • Per-room motion text (the passive ambient lines) — author via redit ... M.
  • Extra fields: vnum ranges may differ on alpha vs dev vs prod — your zone might import slightly differently. Coordinate with staff if you’re targeting a specific tree.

V2 will close these gaps. For now: do the bulk of the work offline, then refine in-game.

Privacy

The builder is fully client-side:

  • No network requests of any kind.
  • No analytics, no cookies, no telemetry.
  • Your project state is in your browser’s localStorage + the .json files you download.
  • Closing the tab doesn’t delete state, but clearing browser data does — back up to .json regularly.

You can verify this by opening the file in a text editor — every fetch, XMLHttpRequest, or external src= is auditable. There are none.

Tips

  • Save .json before every export. If the export step crashes the browser (large zones can be slow), you don’t want to lose your work.
  • Use git for the .json snapshots. A private repo of your .json snapshots gives you version history for your draft work.
  • Reset chance < 100 is normal. Even staff-built zones use 25-75% chance on many mobs for variety.
  • Don’t over-flag. AGGR + STAY_ZONE + MEMORY + HELPER on every mob makes the zone unplayable.
  • Match your zone’s terrain. If FOREST flag is set, the rooms should be forest sector type or the weather feels disjoint.