Show pageOld revisionsBacklinksBack to top You've loaded an old revision of the document! If you save it, you will create a new version with this data. Media Files ====== 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. ===== Who may create ===== 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: [[codelaw|Code Law]] — Beanshell, H2, and coding resources * See: [[scriptlaw|Script Law]] — attaching SpecProc scripts after prototypes exist ===== The workspace model ===== 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: <code mud> > @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. > </code> 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). ===== Finding free vnums and getting around ===== <code mud> > @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 > </code> * ''@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). ===== Rooms ===== ==== Create a room ==== <code mud> > @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. > </code> ''@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 [[scriptlaw|Script Law]]) * ''map <item> <x> <y>'' — map item / coordinates * ''stadium <value>'' — stadium linkage ==== Exits / doors ==== ''@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. <code mud> > @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. > </code> ==== Dig a linked copy ==== ''@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. <code mud> > goto 1200 > @dig south 1203 Okay. > </code> ===== Zones ===== Zones own lifespan, reset command lists, weather affiliation, and placement of mobiles / items. <code mud> > @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. > </code> ''@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): <code mud> > zone reset Okay. > zone clear 1299 Okay. > </code> ''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 (objects) ===== Items are split into **description**, **stats**, and the **item** prototype that ties them together — matching the old Diku split of strings / values / index. ==== Description workspace ==== ''@item_descr'': ''action'', ''general'', ''keywords'', ''proper'', ''room''. <code mud> > @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. > </code> ==== Stats workspace ==== ''@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 <code mud> > @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. > </code> ==== Item prototype ==== ''@item'': ''extras'', ''stats'', ''description'', ''maximum'', ''proc'', ''reset''. <code mud> > @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. > </code> ''approve item <vid>'' marks a prototype approved. Loading/creating respects ''maximum'' instance caps. ===== Mobiles (NPCs) ===== Same three-layer pattern: description, stats, prototype. ==== Description ==== ''@npc_descr'': ''general'', ''keywords'', ''proper'', ''room''. ==== Stats ==== ''@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 <code mud> > @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. > </code> ==== Prototype ==== ''@npc'': ''extras'', ''stats'', ''description'', ''maximum'', ''proc'', ''reset''. <code mud> > @new npc 1210 Okay. > @npc description 1210 Okay. > @npc stats 1210 Okay. > @npc maximum 4 Okay. > @save npc Okay. > </code> Place the mobile on a zone reset with ''@zone npc <mob-vid> <room-vid>'' (and related equip / give / follow / put commands). ===== Spawning, purging, and testing ===== <code mud> > 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. > </code> * ''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). ===== Persistence ===== 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. ===== Shops, socials, help, and other creators ===== 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>''. ===== Common workflows ===== ==== New linked rooms ==== <code mud> > @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 > </code> ==== New weapon and a mob that wields it ==== <code mud> > @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 > </code> ===== Caveats and gotchas ===== * 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 [[scriptlaw|Script Law]]. ===== Related ===== * [[scriptlaw|Script Law]] — SpecProc / Beanshell * [[codelaw|Code Law]] — codebase philosophy * [[gamelaw|Game Law]] — player-facing game systems SavePreviewCancel Edit summary Note: By editing this page you agree to license your content under the following license: CC Attribution-Share Alike 4.0 International creationlaw.1790177059.txt.gz Last modified: 2026/09/23 15:24(external edit)