This is an old revision of the document!
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.
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.
Who may create
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
The workspace model
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).
Finding free vnums and getting around
@find unused VIDs; index searches prototypes and procs; goto teleports; stat inspects.
> @find room > @find room 3 > index room midgaard > goto 3001 >
Spawning and testing
Immortals spawn with load / create, remove with purge, and exercise zone resets with zone reset. create is stricter than load (ranges and maximum rules).
Persistence, shops, and inventory
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 @shop, @social, @help, @wizhelp, @message, @spell, and @random (inventoried so builders know they share @new / @save; spell timing fields live under @spell).
Rooms
Create rooms, set sector/flags, wire exits, and @dig linked copies.
- See: Rooms
Objects
Neo builds object prototypes with item commands (@item_descr / @item_stats / @item) — there is no separate @object verb and no oedit.
- See: Objects
Items
Once a prototype exists: ItemType, wear/flags/affects, modifiers, values, weight, spawn testing, and maximum caps.
- See: Items
Mobiles
Three-layer npc_descr / npc_stats / npc, then place via zone resets.
- See: Mobiles
Zones
Lifespan, reset command lists, weather affiliation, zone reset|clear, @rezone, approve.
- See: Zones
Caveats that span types
- There is no
redit/oedit/medit/zedit— use the@workspace verbs. - One open draft of each workspace kind;
@newwhile a draft exists errors until@saveor@clear. - Description VIDs cannot be destroyed while still referenced by an item/npc prototype.
createis stricter thanload; ranges andmaximum == 1rules differ — read the echoes.- Room exit targets must exist and lie in the zone VID range of the room being edited.
@wrapreformats 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.
Related
- Script Law — SpecProc / Beanshell
- Code Law — codebase philosophy
- Game Law — player-facing game systems