Creation Law

Otherwise known as the builder's handbook. Where immortals learn how to create rooms, objects, mobiles, items, zones, and shops in the living world of Nilgiri — using only the commands the Java server actually implements.

Neo-Nilgiri has no classic Diku redit / oedit / medit / zedit. Builders work in a personal @ workspace, then spawn and reset with immortal utilities. Topic pages below carry the full field lists, walkthroughs, and <code mud> sessions.

Creation uses the creator command set (@new, @room, @item, @npc, @zone, …) gated by Immortality.creatorCheck, plus immortal utilities (goto, load / create, purge, index, zone, approve, …). Builders are limited to room / npc / item VID ranges on their immortality record; implementors assign ranges with assign.

Levels: mortal L0–L30, then IMMORTAL, DEITY, IMPLEMENTOR.

• See: Code Law — Beanshell, H2, and coding resources
• See: Script Law — attaching SpecProc scripts after prototypes exist

Open a prototype with @new, edit typed field commands, @examine, @wrap long text, then @save — or @clear to abandon. One open draft of each workspace kind at a time.

> @new room 1200
Okay.
> @room proper
(enter one-line title, then finish the writer)
> @room general
(enter multi-line description in the writer)
> @examine room
--- Room ---
...
> @save room
Okay.
>

Workspace types: help, wizhelp, social, message, item, item_descr, item_stats, npc, npc_descr, npc_stats, room, zone, shop, spell. @load <type> <id> copies an existing prototype into the workspace; @destroy <type> <id> deletes a saved one (with “in use” guards).

• See: Rooms, Objects, Items, Mobiles, Zones, Shops

@find unused VIDs; index searches prototypes and procs; goto teleports; stat inspects.

> @find room
> @find room 3
> index room midgaard
> goto 3001
>

• See: Rooms — @find room, @dig, exits
• See: Items / Mobiles — index, load / create / purge

Immortals spawn with load / create, remove with purge, and exercise zone resets with zone reset. create is stricter than load (ranges and maximum rules).

• See: Items — load / create / purge / maximum caps
• See: Mobiles — place via zone, weapon+mob workflow
• See: Zones — reset lists and zone reset|clear

Prototypes and SpecProcs live in the world H2 database; immortality ranges in the players DB. Automatic saves run on a long real-time cadence (SaveEvent); shutdown also saves. Workspace drafts exist only in memory until @save. There is no separate “ola” / “asave” — @save <type> commits the open draft. The immortal save command is an implementor DB utility, not the builder workspace save.

The same workspace pattern covers @social, @help, @wizhelp, @message, @spell, and @random (inventoried so builders know they share @new / @save; spell timing fields live under @spell). Shops have their own topic page.

Create rooms, set sector/flags, wire exits, and @dig linked copies.

• See: Rooms

Neo builds object prototypes with item commands (@item_descr / @item_stats / @item) — there is no separate @object verb and no oedit.

• See: Objects

Once a prototype exists: ItemType, wear/flags/affects, modifiers, values, weight, spawn testing, and maximum caps.

• See: Items

Three-layer npc_descr / npc_stats / npc, then place via zone resets.

• See: Mobiles

Lifespan, reset command lists, weather affiliation, zone reset|clear, @rezone, approve.

• See: Zones

Shop workspace on an existing mobile VID: room, produces, trades, hours, keeper messages; needs Acts.SHOPKEEPER and zone placement.

• See: Shops

• There is no redit / oedit / medit / zedit — use the @ workspace verbs.
• One open draft of each workspace kind; @new while a draft exists errors until @save or @clear.
• Description VIDs cannot be destroyed while still referenced by an item/npc prototype.
• create is stricter than load; ranges and maximum == 1 rules differ — read the echoes.
• Room exit targets must exist and lie in the zone VID range of the room being edited.
• @wrap reformats long text fields after you write them.
• Builders are expected to be immortal with ranges assigned; special-case creator() sessions exist for named exceptions only.
• After scripting a prototype, attach the proc with @room proc, @item proc, or @npc proc — see Script Law.

• Script Law — SpecProc / Beanshell
• Code Law — codebase philosophy
• Game Law — player-facing game systems