Creation Law

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

Creation is not a free-form OLC menu like classic Diku redit / oedit / medit. Neo-Nilgiri uses a workspace of @ creator commands plus immortal utilities (goto, load / create, purge, index, zone, …).

• Creator command set (Command._creator): @new, @examine, @save, @clear, @load, @destroy, @wrap, @room, @item, @npc, @item_descr, @npc_descr, @item_stats, @npc_stats, @zone, @dig, @rezone, @find, @proc, @shop, @spell, @social, @help, @wizhelp, @message, @random, and related helpers. These require an Immortality session via Immortality.creatorCheck — either a true immortal (level IMMORTAL / DEITY / IMPLEMENTOR with an immortality row) or a rare special creator() exception.
• Immortal utilities (Command._immortal): goto, load, create, purge, index, stat, zone, matrix, approve, assign (implementor), and many admin verbs. Immortal commands use reverse flag logic: the command flag must be set (granted) before you can use it. Implementors receive the full immortal + implementor sets on load.
• Vnum ranges: builders are limited to room / npc / item VID ranges stored on their immortality record. Implementors assign ranges with assign <player> (room|npc|item) [range]. Creating outside your range is rejected by the code.

Levels are defined in Level: mortal L0–L30, then IMMORTAL, DEITY, IMPLEMENTOR.

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

You do not “enter an editor mode” and type field names blindly. Instead you open a new prototype into a personal workspace, edit it with typed field commands, @examine to review, @wrap long text, then @save to commit into the world database — or @clear to abandon the draft.

Typical lifecycle for any prototype type:

> @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 that @new / @examine / @clear / @save / @load / @destroy understand (from Modify.cmdCrNew and siblings):

• 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 your workspace so you can edit and re-save. @destroy <type> <id> deletes a saved prototype (with “in use” guards for descriptions that are still referenced).

> @find room
(lists unused room VID blocks)
> @find room 3
(unused blocks sized for 3 contiguous rooms)
> @find item
> @find npc
> index room midgaard
> index item sword
> index npc guard
> goto 3001
>

• @find — unused VIDs for item / npc / room (rooms may take an optional block size).
• index — search indexes for item, item_descr, item_stats, npc, npc_descr, npc_stats, room, zone, plus proc_item / proc_npc / proc_room.
• goto <vid|name> — teleport to a room VID or to whatever contains a named target.
• stat room, stat item …, stat npc … — inspect live or prototype state (immortal).

> @new room 1200
Okay.
> @room proper
A quiet stone alcove
> @room general
Cool air pools here among worn flagstones.
Shadows cling to the corners.
> @room attrs sector inside
Okay.
> @room flags roomflags healing
Okay.
> @room door add north
Okay.
> @room door room north 1201
Okay.
> @room door type north path
Okay.
> @examine room
> @save room
Okay.
>

@room field commands (ModifyStats.cmdCrRoom):

• proper — one-line room title (writer)
• general — multi-line description (writer)
• attrs <class> <attr> — room attributes; coded attribute classes are Sector and SpecRoom
• flags <class> <flag> — room flags (RoomFlags: DARK, NO_NPC, NO_MAGIC, PRIVATE, HEALING, AIR, SILENCE, ARENA, DUMP, GOD, SAVE, RECALL, NO_TELEPORT_IN / OUT, …). Prefix with ! to clear when the modifier supports it (same pattern as other flag editors).
• door … — exits (see below)
• extras … — extra descriptions (look keywords)
• proc <name> — attach a SpecProc room script name (see Script Law)
• map <item> <x> <y> — map item / coordinates
• stadium <value> — stadium linkage

@room door [add|delete|flags|general|key|keywords|proper|room|type|weight] <direction>

Directions come from Direction (north, east, south, west, up, down, …). Door types (DoorType): PATH, GATE, OBJECT, WINDOW, STADIUM. Door flags (DoorFlags): CLOSED, SECRET, LOCKED, PICKPROOF, WIZLOCKED, KNOCKPROOF.

> @room door add east
Okay.
> @room door room east 1202
Okay.
> @room door type east gate
Okay.
> @room door flags east locked
Okay.
> @room door key east 3102
Okay.
> @room door keywords east add gate
Okay.
>

@dig <direction> <room-vid> copies the room you stand in into a new VID and links the exit (Immortality.createDig → RoomDB.createCopy). The target VID must be in your room range.

> goto 1200
> @dig south 1203
Okay.
>

Zones own lifespan, reset command lists, weather affiliation, and placement of mobiles / items.

> @new zone 1299
Okay.
> @zone name
The Quiet Alcove
> @zone author
> @zone description
> @zone lifespan 900
Okay.
> @zone attrs zonetype …
> @zone flags zoneflags …
> @zone npc 1210 1200
Okay.
> @zone item 3100 1200
Okay.
> @zone list
> @examine zone
> @save zone
Okay.
>

@zone subcommands include: attrs, author, clear, description, delete, door, equip, flags, follow, give, item, levels, list, lifespan, map, max, name, npc, place, put, rndmob, rndobj, ride.

Live zone control (immortal, not the workspace editor):

> zone reset
Okay.
> zone clear 1299
Okay.
>

zone [clear|reset] (<zone-top>) — omit the VID to use the zone of your current room. Resets run the Diku-style zone command list stored on the zone (see server docs ZONES.md).

@rezone <old-top> <new-top> remaps a zone top within your range (implementor/creator tooling).

approve zone <vid> prompts an immortal confirmation to mark a zone approved.

Items are split into description, stats, and the item prototype that ties them together — matching the old Diku split of strings / values / index.

@item_descr: action, general, keywords, proper, room.

> @new item_descr 3100
Okay.
> @item_descr keywords add sword
Okay.
> @item_descr proper
a tempered shortsword
> @item_descr room
A tempered shortsword lies here.
> @item_descr general
Steel catches the light along a plain fuller.
> @save item_descr
Okay.
>

@item_stats: attrs, flags, modifiers, type, values, weight.

• type — ItemType (LIGHT, SCROLL, WAND, STAFF, WEAPON, ARMOR, POTION, RECEPTACLE, NOTE, KEY, FOOD, MONEY, …)
• flags classes — ItemFlags, Affects, Wear (TAKE, WIELD, HOLD, BODY, …)
• attrs — includes SpecItem for hardcoded / scripted item specials
• modifiers add <index> <apply> <value> — apply bonuses (Apply enum)
• values <slot> <value> — type-specific value slots
• weight <n> — positive integer up to coded max

> @new item_stats 3100
Okay.
> @item_stats type weapon
Okay.
> @item_stats flags wear take
Okay.
> @item_stats flags wear wield
Okay.
> @item_stats weight 5
Okay.
> @item_stats modifiers add 0 hitroll 1
Okay.
> @save item_stats
Okay.
>

@item: extras, stats, description, maximum, proc, reset.

> @new item 3100
Okay.
> @item description 3100
Okay.
> @item stats 3100
Okay.
> @item maximum 25
Okay.
> @item proc my_sword_proc
Okay.
> @save item
Okay.
>

approve item <vid> marks a prototype approved. Loading/creating respects maximum instance caps.

Same three-layer pattern: description, stats, prototype.

@npc_descr: general, keywords, proper, room.

@npc_stats: ac, alignment, attacks, attrs, flags, hitpoints.

• attrs classes — NPCType, Level, Gender, Size, Movement, Position, SpecNPC
• flags classes — Acts, Affects, Profession (Acts includes SENTINEL, AGGRESSIVE, STAY_ZONE, SHOPKEEPER, BANKER, …)
• attacks add <index> <type> <dice> — AttackType plus MDM dice string
• hitpoints — dice / MDM form accepted by the stats parser
• ac, alignment — integer ranges enforced in code

> @new npc_stats 1210
Okay.
> @npc_stats attrs level L5
Okay.
> @npc_stats attrs position standing
Okay.
> @npc_stats flags acts sentinel
Okay.
> @npc_stats ac 5
Okay.
> @npc_stats alignment 0
Okay.
> @npc_stats hitpoints 2d8+10
Okay.
> @npc_stats attacks add 0 hit 1d6+1
Okay.
> @save npc_stats
Okay.
>

@npc: extras, stats, description, maximum, proc, reset.

> @new npc 1210
Okay.
> @npc description 1210
Okay.
> @npc stats 1210
Okay.
> @npc maximum 4
Okay.
> @save npc
Okay.
>

Place the mobile on a zone reset with @zone npc <mob-vid> <room-vid> (and related equip / give / follow / put commands).

> load item 3100
You create a tempered shortsword.
> create item 3100
You create a tempered shortsword.
> load npc 1210
You create a quiet watchman.
> purge sword
> purge all
> zone reset
Okay.
>

• load item|npc <vid> — immortal spawn without range checks (still respects instance maximums via create).
• create item|npc <vid> — same handler as load, but also requires the VID in your assigned item/mobile range, and refuses prototypes whose maximum is greater than 1 when used as create (builders use this for careful testing of their own work).
• purge [target|all] — remove an item/mobile from the room, or dump room items.
• expunge — stronger removal tooling (immortal).
• matrix item|mob|npc|zone … — combat/builder matrix inspection (distinct from SpecProc matrix metadata).

Prototypes and SpecProcs live in the world H2 database (rooms, zones, mobiles, items, scripts). Player immortality ranges live in the players DB. Automatic saves run on a long real-time cadence (SaveEvent); shutdown also saves. Workspace drafts exist only in memory on your immortal until @save.

There is no separate “ola” / “asave” verb — @save <type> is the commit for the open workspace entry. The immortal save command is an implementor database utility, not the builder workspace save.

The same workspace pattern covers @shop, @social, @help, @wizhelp, @message, @spell, and @random. These are inventoried here so builders know they share @new / @save lifecycles; detailed spell timing fields live under @spell (beats, mana, target, usage, …). Shop produce lists and hours are edited with @shop subcommands after @new shop <id>.

> @find room 2
> @new room 4500
> @room proper
> @room general
> @room attrs sector city
> @save room
> goto 4500
> @dig east 4501
> goto 4501
> @room proper
> @room general
> @save room
>

> @new item_descr 4502
… edit strings …
> @save item_descr
> @new item_stats 4502
> @item_stats type weapon
> @item_stats flags wear take
> @item_stats flags wear wield
> @save item_stats
> @new item 4502
> @item description 4502
> @item stats 4502
> @save item
> @new npc_descr 4503
… 
> @save npc_descr
> @new npc_stats 4503
…
> @save npc_stats
> @new npc 4503
> @npc description 4503
> @npc stats 4503
> @save npc
> @load zone 4599
> @zone npc 4503 4500
> @zone equip 4502 wield
> @save zone
> zone reset
> create npc 4503
>

• There is no redit / oedit / medit / zedit command — those names do not exist in Command.java. Use the @ workspace verbs above.
• You can only hold one open draft of each workspace kind at a time; @new while a draft exists returns an error until @save or @clear.
• Description VIDs cannot be destroyed while still referenced by an item/npc prototype.
• create (builder-safe spawn) is stricter than load; ranges and maximum == 1 rules differ — read the echoes carefully.
• Room exit targets must exist and lie in the zone VID range of the room being edited.
• @wrap reformats long text fields (help, descriptions, extras, zone text) after you write them.
• Granting @ commands to mortals is not the normal path; builders are expected to be immortal with ranges assigned. Special-case creator() sessions exist in code 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