MadROM Builder's Compendium

This compendium collects the complete set of MadROM building rules, balance guidelines, bit flag references, and mob program documentation into a single reference.

How to Use This Document

Table of Contents


MadROM Area Building Guide

Source: docs/manuals/madrom-area-building-guide.md

This is an Area Building Help file for MadROM. If you want to build for other Rom or Merc 2.1 based muds, consult the legacy builder guide noted in the references section. Enjoy - Ozy.


This file contains material and information from the Merc release 2.1 Area help files (done by Furey, Hatchet, and Kahn), material from the Merc Diku Mud code itself, material and examples from various area files that are found in both ROM2 and MadROM, as well as coding material that was adapted and modified by Alander for ROM2, and later by Madman, Etaine, Zump, Soapbox, Faramir, Neuromancer and Amiga for MadROM.

Overview of Areas

An area is one place of the world. Each are is defined in a separate file. When naming your area FILE, common format is

'areaname.are'.

An area is a collection of sections:

AREA, #HELPS, #MOBILES, #OBJECTS, #ROOMS, #RESETS, #SHOPS,

SPECIALS, #$. The minimum an area needs is the #AREA and #$ section.

All other sections are optional, though your area would be pretty boring with no rooms, objects or mobiles. If you do choose to have no rooms, and/or mobiles or objects or resets in your area, put the header and end of section flag in anyway..eg #OBJECTS #0 If you choose to have no shops or specials in your area, you can skip putting in those sections completely.

Vnums: Individual MOBILES, OBJECTS and ROOMS are identified by their own Vnum. A vnum is just a number specific to that mobile, object or room. The numbers should be consecutive within each #MOBILE, #OBJECT and #ROOMS section. No mobile should have the same vnum as any other, but a room, object, and monster may each have the same vnum. When sending in your area, vnum number like this:

MOBILES

ZX001, #ZX002, #ZX003...etc

OBJECTS

ZX001, #ZX002, #ZX003...etc

ROOMS

ZX001, #ZX002, #ZX003..etc


And here we go, with info on the sections in the order they should appear in your area file:

I. The #AREA section. This MUST be included in the file. This is the easiest section to do. The format is as follows:

AREA {30 60} ~

Here's an example from an area already designed:

AREA {30 60} Ozymandias Hades~

The first two numbers are the recommended level range of the area. The first name is your own name or alias and the last phrase is the name of the area itself.

II. The #HELPS section. (optional, you can skip this section)

This section is rarely used. It is simply for placing keywords and a help section about your area for players/immortals to read and to get help about your area or its format. However, it is really only necessary if you feel there may be some complications in your area. If you desire to use a #HELPS section, its format is:

HELPS

~ ~ 0 $

The level number is the minimum level a player must be to read the helps. The 'key-words' are a set of keywords for this help text. The 'help-text' is the help text itself.

Example:

51 Ozy Awoo~ Hi this is the help text for Ozy Awoo area. If you are level 51 and higher and you type 'help ozy' or 'help awoo' on the mud, you'd be reading this right now! ~ 0 $

III. The #MOBILES section (optional, but the area may be boring with no mobiles)

Example:

MOBILES

ZX001

prisoner amazon~ an amazon prisoner~ An amazon prisoner rests here in shackles. ~ You see a tall, beautiful female warrior in glittering armor. ~ human~ BT Na 850 S 35 3 1d1+749 1d1+297 12d4+10 5 -5 -5 -5 0 EDFHIKLNU 0 0 0 8 8 2 0 0 0 M 0 X sound 30 An amazon prisoner screams in fear!~ X tribe Dance~

ZX002 <----- Vnum for next mobile, and so on...

Explanation of each line:

MOBILES <--- the beginning of the mobile section.

22001 <---

prisoner amazon~ <--- an amazon prisoner~ <--- An amazon prisoner rests here in shackles. <--- ~ <--- put the tilde for the long desc. on the next line You see a tall, beautiful female in glittering armor. ~ <--- the extended description, with tilde on next line. human~ <-- the race of the monster BT Na 850 S <--- is the: (Note: ALWAYS end this above line with a capital 'S' after the alignment number, as is shown here, for code reasons) 35 3 1d1+749 1d1+297 12d4+10 5 <--- this contains the following: Please see mobstats.doc for all values in this line except DAMAGE TYPE, of which you can choose any you want, from the table a bit further down. -5 -5 -5 0 <--- Armor Class (AC) values for . Please see mobstats.doc for all values on this line. EDFHIKLNU 0 0 0 <--- A list of the Off_bits, and the immunities, resistances and vulnerabilities is at the end of this section, as well as a list of affected_by and ACT_flags. If you want to put no values in a section, for example none in resistances, as on this line, just put in a '0'. 8 8 2 0 <---- The position numbers most commonly used are the 8 8 combination, which means the mobile is normally standing. The first position number is the position the monster resets in, the second is the position the monster will return to after fighting. A list of all position numbers is below. Sex: 0 = neutral, 1 = male, 2 = female Gold is the amount of gold the monster starts with. 0 0 M 0 <--- The first two, and the last numbers are always 0 0, as they represent body parts the monster drops when it dies, which the code now automatically takes care of. The third field is the SIZE of the monster (M = medium as shown, T=Tiny, S=Small, L=Large, H=huge G=giant) X sound 30 An amazon prisoner screams in fear!~ <- Mob Sounds line (see MobSounds.txt for how to add these in..its easy) X tribe Druid~ <- flags a mob as a member of a Tribe. Must be an existing Tribe, and must use the Tribe abbrev for the Tribe word.

(the last two lines, starting with 'X' are optional)

Note: - 'Keywords' are the names of the mobile. Choose 1-3 of these.


IMPORTANT: Consult the ROM mob statistics reference listed in the references section to find out the values you should put in for +hitroll, damage, hitpoints, mana, and AC for your monsters.

-- TABLES and tables and tables of flags for your Monsters --

Now here are the listings of all the necessary values for making your mobiles; the flags will be on the left, and the letter or number values you use are on the right column. Please note: if there is a n/a beside the flag, it means we have the flag in the code, but have not yet written any code to make it DO anything...the information is there for you, but don't use any flag that has n/a beside it.

ACT FLAGS:

ACT_IS_NPC (A) <-- Auto set for mobs: do NOT use ACT_SENTINEL (B) <-- stays in one room ACT_SCAVENGER (C) <-- picks up objects ACT_SMART (D) <-- makes mobiles smarter ACT_UNUSED (E) <-- legacy act flag (unused) ACT_AGGRESSIVE (F) <-- attacks PC's ACT_STAY_AREA (G) <-- Won't leave area

ACT_WIMPY (H) <-- will flee if hp gets too low ACT_PET (I) <-- Auto set for pets: do NOT use ACT_TRAIN (J) <-- can train PC's ACT_PRACTICE (K) <-- can practice PC's ACT_HOLYLIGHT (N) <-- used by mobprogs ACT_UNDEAD (O) n/a

ACT_CLERIC (Q) n/a ACT_MAGE (R) n/a ACT_THIEF (S) n/a ACT_WARRIOR (T) n/a ACT_NOALIGN (U) n/a

ACT_NOPURGE (V) <-- will not be purged by purge command ACT_IS_HEALER (a) <-- acts as a healer ACT_GAIN (b) <-- PC's can use 'gain' command at this mobile ACT_UPDATE_ALWAYS (c) (Don't use, see Amiga if you want info on this one) ACT_NOWANDER (d) <-- Mobs wont wander (See Amiga before using this) ACT_IS_UNDERTAKER (e) <-- handles corpse retrieval

RACES:

Here are all of the current npc races; Race affects what parts the mobile will have and some of the affected_by things it may have, just like the races for players.

unique human elf dwarf giant dragon hobbit orc wolf bat bear cat centipede dog doll fido fox goblin hobgoblin kobold lizard modron pig rabbit school monster snake song bird troll water foul wyvern arachnid demon undead draconian smurf earth elemental air elemental fire elemental water elemental plant fish animal gnome gargoyle shadow ogre minotaur beholder metal golem stone golem flesh golem wood golem clay golem

For other options, see Amiga.

Mobile Size:

T = tiny S = small M = medium L = large H = huge G = giant

Affected_by FLAGS:

If you flag a monster with any of these, it means he is AFFECTED by the flag permanently. For example, if the monster is flagged aff_poison, he is poisoned. (it does NOT mean he can cast poison, rather HE is poisoned)

AFF_BLIND (A) AFF_INVISIBLE (B) invisble to all players under his level AFF_DETECT_EVIL (C) AFF_DETECT_INVIS (D) monster can detect invisible players under his level AFF_DETECT_MAGIC (E)

AFF_DETECT_HIDDEN (F) monster can detect hiding players under his level AFF_SANCTUARY (H) AFF_FAERIE_FIRE (I) AFF_INFRARED (J) monster can see players in dark rooms and/or at night AFF_CURSE (K)

AFF_POISON (M) AFF_PROTECT (N) AFF_SNEAK (P) AFF_HIDE (Q) AFF_SLEEP (R)

AFF_CHARM (S) AFF_FLYING (T) AFF_PASS_DOOR (U) AFF_HASTE (V) AFF_CALM (W)

AFF_PLAGUE (X) AFF_WEAKEN (Y) AFF_DARK_VISION (Z) n/a AFF_BERSERK (a) AFF_SWIM (b) AFF_REGENERATION (c) AFF_LETHARGY (d)

OFF_BITS:

These are the monsters OFFENSE flags..they determine which offense he will use when he fights. eg, if a monster is flagged off_backstab, he will try to backstab when he fights.

OFF_AREA_ATTACK (A) monster attacks all in area OFF_BACKSTAB (B) must be carrying a weapon OFF_BASH (C) OFF_BERSERK (D) OFF_DISARM (E)

OFF_DODGE (F) OFF_FADE (G) OFF_FAST (H) n/a OFF_KICK (I) OFF_KICK_DIRT (J)

OFF_PARRY (K) OFF_RESCUE (L) OFF_TAIL (M) n/a OFF_TRIP (N) n/a OFF_CRUSH (O) n/a

ASSIST_ALL (P) he will assist any who was the victim of an attack ASSIST_ALIGN (Q) will assist those in a fight who are the same align as he is ASSIST_RACE (R) ditto, but same race as he is ASSIST_PLAYERS (S) will assist players who are fighting monsters ASSIST_GUARD (T) will assist cityguards ASSIST_VNUM (U) will assist all monsters of the same vnum as him

IMMUNITIES - IMM bits for mobiles:

These flags make the monster Immune to certain things. eg. if a monster is flagged imm_acid, the acid blast spell cast against him will not hurt him.

IMM_SUMMON (A) IMM_CHARM (B) IMM_MAGIC (C) IMM_WEAPON (D) IMM_BASH (E)

IMM_PIERCE (F) IMM_SLASH (G) IMM_FIRE (H) IMM_COLD (I) IMM_LIGHTNING (J) (chain lighting)

IMM_ACID (K) (acid blast) IMM_POISON (L) IMM_NEGATIVE (M) n/a IMM_HOLY (N) (holy light) IMM_ENERGY (O) n/a

IMM_MENTAL (P) (immune to certain mental spells, ie...FEAR) IMM_DISEASE (Q) (immune to plague) IMM_DROWNING (R) n/a IMM_LIGHT (S) n/a IMM_BLIND (T) IMM_LETH (U) IMM_SLEEP (V)

RESISTANCES - RES bits for mobiles:

Thse flags make the monster resistant, but not totally immune to whatever you flag him with...he can still be hurt by it, but not as easily as if he was not flagged resistant to it.

RES_CHARM (B) RES_MAGIC (C) RES_WEAPON (D) RES_BASH (E) RES_PIERCE (F)

RES_SLASH (G) RES_FIRE (H) RES_COLD (I) RES_LIGHTNING (J) (chain lighting) RES_ACID (K)

RES_POISON (L) RES_NEGATIVE (M) n/a RES_HOLY (N) (holy word) RES_ENERGY (O) n/a RES_MENTAL (P) n/a

RES_DISEASE (Q) RES_DROWNING (R) n/a RES_LIGHT (S)

VULNERABILITIES - VULN bits for mobiles:

These flags make the monster vulnerable. eg if you flag a monster vulnerable to bash, and a player bashes him, he will be hurt much more by the bash then if he was not vulnerable to it.

VULN_MAGIC (C) VULN_WEAPON (D) VULN_BASH (E) VULN_PIERCE (F) VULN_SLASH (G)

VULN_FIRE (H) VULN_COLD (I) VULN_LIGHTNING (J) (chain lighting) VULN_ACID (K) (acid blast) VULN_POISON (L)

VULN_NEGATIVE (M) n/a VULN_HOLY (N) (holy word) VULN_ENERGY (O) n/a VULN_MENTAL (P) n/a VULN_DISEASE (Q)

VULN_DROWNING (R) n/a VULN_LIGHT (S) n/a VULN_WOOD (X) (wooden weapons) VULN_SILVER (Y) (silver weapons) VULN_IRON (Z) (iron weapons)

POSITIONS:

POS_DEAD 0 <--- do not use POS_MORTAL 1 <--- do not use POS_INCAP 2 <--- do not use POS_STUNNED 3 <--- do not use

POS_SLEEPING 4 POS_RESTING 5 POS_SITTING 6 POS_FIGHTING 7 <---* this position also not used. POS_STANDING 8

SEX of mobile:

NEUTRAL 0 MALE 1 FEMALE 2

DAMAGE TYPES (these values also used for weapons in #OBJECTS):

These are the words you will see when the monster hits you...eg 'The big monsters's WHIP annhilates you!' if you chose '4' for whip...etc

0 - HIT 1 - SLICE 2 - STAB 3 - SLASH 4 - WHIP 5 - CLAW 6 - BLAST 7 - POUND 8 - CRUSH 9 - GREP 10 - BITE 11 - PIERCE 12 - SUCTION 13 - BEATING 14 - DIGESTION 15 - CHARGE 16 - SLAP 17 - PUNCH 18 - WRATH 19 - MAGIC 20 - DIVINE POWER 21 - CLEAVE 22 - SCRATCH 23 - PECK (pierce) 24 - PECK (bash) 25 - CHOP 26 - STING 27 - SMASH 28 - SHOCKING BITE 29 - FLAMING BITE 30 - FREEZING BITE 31 - ACIDIC BITE 32 - CHOMP

IV. The #OBJECTS section (optional section, but maybe boring with no objects in your area)

IMPORTANT: please consult the ROM object statistics reference listed in the references section to see what values should be used for each item type and level (in other words, how powerful your objects can be by level).

The #OBJECTS section is similar to the #MOBILES section. However, the main difference is that the values in the #OBJECTS section depend on the TYPE of object being described, i.e., weapon, scroll, potion, treasure, etc. Below I am presenting an example of how an object should look in this section:

Example:

ZX001

sword underworld~ The Sword of the Underworld~ A large, dark sword of solid obsidian gleams evilly here.~ adamantite~ 5 ABCEJL AN 1 11 6 6 DE 50 30 35000 P E sword underworld~ This heavy sword has an evil, dark shine to its metal. The pommel is formed into the shape of a large ram's head and is set with several large rubies. ~ A 18 4 A 19 4 A 1 2 A 5 2 A 23 -8

ZX002 <--- this begins the next object in the #OBJECTS section...

Explanation of each line:

22016 <--- this is the vnum unique to this object

sword underworld~ <--- these are the keywords for the object The Sword of the Underworld~ <--- the short description of the object A large, dark sword of solid obsidian gleams evilly here.~ <-long description adamantite~ <--- the 'material' of the object. A list of materials for MadROM is provided at the end of the help for #OBJECTS section. Objects made of wood, paper and glass CAN be destroyed by dragon fire, for example. 5 ABCEJL AN <--- this line contains: A listing of iiem types, flags and wear flags is provided at the end of the help for #OBJECTS section. 1 11 6 6 DE <-- IMPORTANT This is the VALUES line, and it varies depending on the 'ITEM TYPE' as declared in the above line. At the end of this section, following the value tables, is the breakdown of this line for all the other object types. This example here, therefore, is geared for objects that are weapons, because on the line above '5' was chosen for ITEM TYPE, and '5' is 'weapon'. In the example here, this line is as follows: <# of damage dice> - See the list of damage types given in #OBJECTS - Lists of weapon classes are given a bit below - Lists of weapon types are given a bit below 50 30 35000 P <--- this line contains: <condition of obj.) E <--- this is if you want extra descriptive keywords (optional) sword underworld~ <--- the keywords for the 'E' section. This heavy sword has an evil, dark shine to its metal. The pommel is formed into the shape of a large ram's head and is set with several large rubies. <--- the 'extra description' ~ A <--- this is for adding apply bonuses such as +hit or +strength (optional) 18 4 <--- In this example '18' is 'hitroll' and '4' means add +4 to the hitroll List of the apply bonuses flags are a bit below. A <--- another 'A' value, and so on...

Note: The 'E' and 'A' sections are optional.

Common Materials for the 'material' section:

OBJECT TYPES:

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 (drink container) ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_FOUNTAIN 25 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 (the jukebox crickets) ITEM_PORTAL 30 ITEM_EXPLOSIVE 31 ITEM_LIQUID 32 ITEM_ARENA_WAND 33 ITEM_ARENA_BOMB 34 ITEM_ARENA_GAUNTLET 35 ITEM_ARENA_POWERUP 36 ITEM_ARENA_PORTAL 37 ITEM_ARENA_RED_FLAG 38 ITEM_ARENA_BLUE_FLAG 39 ITEM_ARENA_MINE 40 ITEM_RED_MINE 41 ITEM_BLUE_MINE 42 ITEM_CHAOS_FOOD 43 ITEM_FOOD_BAD_BREATH 44 ITEM_CHARM 45 ITEM_JEWELRY 46

Object FLAGS:

ITEM_GLOW (A) ITEM_HUM (B) ITEM_DARK (C) n/a ITEM_LOCK (D) n/a ITEM_EVIL (E) ITEM_INVIS (F) ITEM_MAGIC (G) n/a ITEM_NODROP (H) ITEM_BLESS (I) ITEM_ANTI_GOOD (J) ITEM_ANTI_EVIL (K) ITEM_ANTI_NEUTRAL (L) ITEM_NOREMOVE (M) ITEM_INVENTORY (N) ITEM_NOPURGE (O) ITEM_ROT_DEATH (P) item will rot a few minutes after the mobile carrying is has died ITEM_VIS_DEATH (Q) while carried by a monster, the item is not visible by either locate spell or by the player looking at the monster, but becomes visible to locate spell and to look once the monster has died ITEM_MELT_DROP (R) item dissolved and dissapears when dropped ITEM_FLOAT (S) containers flagged with this will NOT sink and dissapear in water rooms

WEAR FLAGS:

ITEM_TAKE (A) (all items you want to carry must have this flag) ITEM_WEAR_FINGER (B) ITEM_WEAR_NECK (C) ITEM_WEAR_BODY (D) ITEM_WEAR_HEAD (E) ITEM_WEAR_LEGS (F) ITEM_WEAR_FEET (G) ITEM_WEAR_HANDS (H) ITEM_WEAR_ARMS (I) ITEM_WEAR_SHIELD (J) ITEM_WEAR_ABOUT (K) (worn about body) ITEM_WEAR_WAIST (L) ITEM_WEAR_WRIST (M) ITEM_WIELD (N) ITEM_HOLD (O)

CONDITION OF OBJECT:

PERFECT P GOOD G AVERAGE A WORN W DAMAGED D RUINED R

WEAPON CLASS:

WEAPON_EXOTIC 0 (any player can use these) WEAPON_SWORD 1 (only players with sword skill can use) WEAPON_DAGGER 2 (only players with dagger skill can use.. and the same for the rest) WEAPON_SPEAR 3 WEAPON_MACE 4 WEAPON_AXE 5 WEAPON_FLAIL 6 WEAPON_WHIP 7 WEAPON_POLEARM 8

WEAPON TYPES:

WEAPON_FLAMING (A) n/a WEAPON_FROST (B) n/a WEAPON_VEMON (C) item has venom/poison on it WEAPON_SHARP (D) WEAPON_VORPAL (E) WEAPON_TWO_HANDS (F) need the weapon and the shield wear slot free to use WEAPON_VAMPIRIC (G) WEAPON_SHOCKING (H)

APPLY BONUS TYPES (for the 'A' section of #OBJECTS):

APPLY_STRENGTH 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_CLASS 7 n/a APPLY_LEVEL 8 n/a APPLY_AGE 9 n/a APPLY_HEIGHT 10 n/a APPLY_WEIGHT 11 n/a APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_GOLD 15 APPLY_EXP 16 n/a APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_PARA 20 APPLY_SAVING_ROD 21 APPLY_SAVING_PETRI 22 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24

Container FLAGS (if OBJECT TYPE is container only):

CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8

Portal GATE FLAGS

GATE_NORMAL_EXIT A enter/exit messages from portal are as if its a door GATE_NOCURSE B can enter portal even if cursed or in norecall room GATE_GOWITH C the portal goes with you GATE_BUGGY D small chance of sending you to a random room GATE_RANDOM E sends you to a random room on the mud GATE_RANDOMAREA F sends you to a random room in same area

PORTAL EXIT FLAGS

EX_ISDOOR A when you enter portal it looks like you enter a door EX_CLOSED B EX_LOCKED C EX_PICKPROOF F EX_NOPASS G passproof

Liquid values for DRINK CONTAINERS (value2 on the value line):

LIQ_WATER 0 LIQ_BEER 1 LIQ_RED_WINE 2 LIQ_ALE 3 LIQ_DARK_ALE 4 LIQ_WHISKEY 5 LIQ_LEMONADE 6 LIQ_FIREBREATHER 7 LIQ_LOCAL_SPECIALTY 8 LIQ_SLIME_MOLD_JUICE 9 LIQ_MILK 10 LIQ_TEA 11 LIQ_COFFEE 12 LIQ_BLOOD 13 LIQ_SALT_WATER 14 LIQ_COLA 15 LIQ_ROOT_BEER 16 LIQ_ELVISH_WINE 17 LIQ_WHITE_WINE 18 LIQ_CHAMPAGNE 19 LIQ_MEAD 20 LIQ_ROSE_WINE 21 LIQ_BENEDICTINE_WINE 22 LIQ_VODKA 23 LIQ_CRANBERRY_JUICE 24 LIQ_ORANGE_JUICE 25 LIQ_ABSINTHE 26 LIQ_BRANDY 27 LIQ_AQAVIT 28 LIQ_SCHNAPPS 29 LIQ_ICEWINE 30 LIQ_AMONTILLADO 31 LIQ_SHERRY 32 LIQ_FRAMBOISE 33 LIQ_RUM 34 LIQ_CORDIAL 35

Cheers to Satin, of Tesseract, who brewed up the last 20 liquid types, above.

Value lines for all the various OBJECT TYPES follow:

format -

**note: if a value is shown to be 'unused', place a zero, '0', for that value. DO NOT skip it or leave it blank.

ITEM_PORTAL: <# of charges>

ITEM_LIGHT: <HOURS OF LGT. AVAILABLE 0=dead, 999=infinite

ITEM_EXPLOSIVE:

ITEM_SCROLL:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

**note: spell lvl is the level at which the spell will be cast, NOT the level of the reader of the scroll.

**note: 'sn' stands for SLOT NUMBER; this is the spell number; please consult the ROM spell list referenced at the end of this compendium to find out what number to use to indicate each spell.

ITEM_WAND:

ITEM_ARENA_WAND:

ITEM_STAFF:

ITEM_WEAPON: <# damage dice>

ITEM_TREASURE:

ITEM_ARMOR:

ITEM_POTION:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

ITEM_PILL:

**note: Potions and pills can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values.

ITEM_FURNITURE:

**note: the benches in Southern Midgaard are an example of a furniture object... they basically just sit there.

ITEM_TRASH:

ITEM_SINGING (jukebox/crickets) < -1 > < -1 > < -1 > < -1 > < -1 >

ITEM_CONTAINER:

**note: Use the Container FLAGS listed earlier for this value; the key vnum is ONLY USED if there is a key to unlock the container - otherwise put a zero for that value.

ITEM_DRINK_CONTAINER: <0 <---note: if this value is a NON-ZERO number, the drink is poisoned>

ITEM_KEY: < timer >

nb: the timer value is # of ticks till the key rots, and 1 tick = 30 real seconds

nb: the rot_death flag can also still be used on keys, and if used will make the key start rotting on the death of the monster holding the key. The timer for keys flagged with rot_death is 5-10 seconds. If both the rot_death flag is set and the timer in value0 above is also set to a negative number, the rot_death flag will take precendence IF the player needs to obtain the key by killing a monster (thus starting the rot_death timer) ; however, if the player finds the key on the ground, then the rot_use timer would take precedence when they first use the key.

ITEM_FOOD: * note if this ^^^^^^^ value is 1, food is poison. ITEM_MONEY:

ITEM_BOAT:

ITEM_FOUNTAIN:

ITEM_MAP: < 1 >

V. The #ROOMS section (optional, but if your area really has no rooms it would be BORING, no question)

Example:

ZX001

Rock Carving~ You scramble through this mountain pass, the frightening stony walls reaching to the sky on either side of you. A powerful, eerie wind whips the air into a frenzy about you. Cut into the rock face is an imposing, monolithic statue of a long forgotten king. You feel a sudden sense of uneasiness as you pass beneath his glowering, silent gaze. Ahead, to the north, an immense set of iron gates block further passage. The pass leads north beyond the gates, and back to the south. ~ ZX 0 5 H 200 M 50 D0 A pass through tall iron gates. ~ gate~ 1 ZX002 ZX003 D2 A pass through the mountains. ~ ~ 0 -1 ZX004 E statue~ This impressive statue is a depiction of the ancient king, and now awesomely powerful God, Ozymandias. Bold of gaze and fierce of stature, this being is one you'd NOT like to cross if you ran into him. Brrr! ~ S

ZX002

Explanation of each line:

ZX001 <---

Rock Carving~ <--- You scramble through this mountain pass, the frightening stony walls reaching to the sky on either side of you. A powerful, eerie wind whips the air into a frenzy about you. Cut into the rock face is an imposing, monolithic statue of a long forgotten king. You feel a sudden sense of uneasiness as you pass beneath his glowering, silent gaze. Ahead, to the north, an immense set of iron gates block further passage. The pass leads north beyond the gates, and back to the south. ~ <--- ZX 0 5 <--- H 200 <--- M 50 <--- D0 <--- A pass through tall, iron gates. ~ <--- tilde goes on next line, as here. gate~ <--- 1 ZX002 ZX003 <--- D2 <--- A pass through the mountains. <--- ~ ~ 0 -1 ZX004 <--- E <--- (optional) statue~ <--- This impressive statue is a depiction of the ancient king, and now awesomely powerful God, Ozymandias. Bold of gaze and fierce of stature, this being is one you'd NOT like to cross if you ran into him. Brrr! <--- ~ E <------ (optional) etaine sign~ <---- Ozymandias worships Etaine, or will till he sees how she's been messing in his document. <--- ~ S <--- the 'S' marks the end of the room. It is NOT optional.

ZX002 <---

Note: for Extended descriptions, EACH object/description must start with an E. eg if your room has a sign, chair and plaque, each extended description for these should start with its own individual E., just like the example above. :)

Direction Values for the 'D' section:

NORTH 0 EAST 1 SOUTH 2 WEST 3 UP 4 DOWN 5

(eg D0 = a door or non door exit that allows you to go north)

Door state values for the 'D' section:

Unhindered exit 0 Door with no keyhole -1 Normal door 1 Pick-proof door 2 Pass proof door 3 Pick and passproof door 4

note: a 'hidden' exit that doesn't show in when players type 'exit' is made by flagging your exit to be a door or flag 1.

ROOM-FLAGS:

ROOM_DARK (A) (room is dark if you are not holding a light) ROOM_NO_SUMMIN (B) (can't summon anything into this room) ROOM_NO_MOB (C) (monsters won't wander in) ROOM_INDOORS (D) (room will be dark unless you carry light) ROOM_NO_SUMMOUT (E) (can't summon anything OUT of this room) ROOM_PRIVATE (J) (2 players or monsters only) ROOM_SAFE (K) (can't attack monsters in this room) ROOM_SOLITARY (L) (1 player or monster room) ROOM_PET_SHOP (M) ROOM_NO_RECALL (N) ROOM_IMP_ONLY (O) (ya!) ROOM_GODS_ONLY (P) ROOM_HEROES_ONLY (Q) (level 91+ can get in here only) ROOM_NEWBIES_ONLY (R) ROOM_LAW (S) (no charming monsters here)

SECTOR-TYPES:

SECT_INSIDE 0 (in order 0 -> 5, cost more movement points) SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 (you have to fly or have a boat to get past) SECT_WATER_NOSWIM 7 (its watery, but you can walk in it) SECT_AIR 9 (need to fly over this room) SECT_DESERT 10 SECT_MAX 11 n/a

VI. The #RESETS section: (optional, but if you have rooms or objects you want to reset, better write this section)

This is the section that installs all the mobiles in their various locations, equips the mobiles, locks and closes any necessary doors, randomizes any random room exits, and generally sets up the area and populates it.

The #RESETS section contains a series of single lines.

The reset commands are:

Here is the format for the various reset commands:

M

For the 'unused' value, simply put a '0'. The mobile-vnum is the vnum of the mobile loaded. The limit-number is the limit of how many of this mobile may be present in the world. The last number, the room-vnum, is the vnum of the room where the mobile is loaded.

O

For the 'unused' value, simply put a '0'. The object-vnum is the vnum of the object loaded. If you want more than one of these objects loaded into the room at one time, make it load twice by putting it twice in resets (or more). The last number, the room-vnum, is the vnum of the room where the object is loaded.

P

The number is the number (amount) of the first object that is placed into another object (i.e., a desk, coffer, safe, etc.). The object-vnum is the vnum of the object loaded. To make more than one of the same item load into a container, load it twice (or more) in the resets. The limit-number is the limit of how many of these objects may be present in the world, or 'put' into the other object. The game will load a coffer, for example, a certain amount of times. After that, the coffer will always be empty, until another reboot. The last number, the 'in_object-vnum', is the vnum of the object into which the other object is placed, i.e., the actual container (safe, desk, etc.).

G

For the 'G' command, there is no fourth number. Only use three numbers. The 'G' command MUST follow an 'M' command, as it 'gives' the object to the whatever mobile in a 'M' command is above it. Note the reason for this is due to the fact that no mobile-vnum is listed in the 'G' command. The first number is the number (amount) of this particular object to be given to the mobile. The object- vnum is the vnum of the object given. The limit-number is the amount of times this object will be 'given' to the mobile. I.E., the Calico cat from the Mage Tower area of ROM2 (and other muds as well...) has a spiked collar that is only loaded on the cat at the start of the game, at a reboot. After that, the cat has no collar, until another reboot. It is often a good idea to limit the number of objects in this manner to be given or equipped on a mobile, unless the object is relatively low level. If you wish one item to be given to the mob per AREA RESET, make the limit number a -1. If you are Giving items to a shopkeeper, make the (limit number) -1.

E

The first number is the number (amount) of an object equipped on the mobile. The object-vnum is just that. The limit number is the same as in the 'G' command (see above). The 'wear_loc-number' is the wear location that the object is equipped on the mobile's body. A listing of the wear_loc values is given at the end of this

RESETS help section.

D

For the 'unused' value, simply put a '0'. The room-vnum is the vnum of the room that the door IS IN. The door-number is just that; i.e., 0=north, 1=west, 2=south, etc. (see the help section for #ROOMS, above). The last number, the 'state-number', is the "state" of the door (whether it is open, closed, locked, etc.). A listing for the 'state-number' values is provided at the end of the

RESETS helps section.

R

For the 'R' command, there are only three values, and the first value is always 0 as it is unused. The second number is the vnum of a room. The third number is a last_door-number. When this command is used, the doors from 0 to the indicated 'last_door- number' are shuffled. The room will still have the same exits leading to the same other rooms as before, the DIRECTIONS will be different at each reboot. Thus, a last_door-number of 4 makes a two-dimensional maze room; a door number of 6 makes a three- dimensional maze room.

Use of both the 'D' and 'R' commands on the same room will yield UNPREDICTABLE results, so take care how you utilize the 'R' command.

Any line (except an 'S' line) may have a comment at the end.

**NOTES: IMPORTANT!: End the #RESETS section in your area with an 'S' on the line after the last reset command.

For the 'P' command, the actual container used is the MOST RECENTLY loaded object with the right vnum; for best results, there should be only one such container in the world. The object to put in a container is not loaded if no container object exists, or if someone is carrying it, or if it already contains on of the to-be-loaded objects.

Remember, for all LIMIT-NUMBERS, a '-1' means an infinite number of the objects, mobiles, etc. can exist in the world, and the game will keep loading up these objects/mobiles. Keep this in mind, if you are thinking of using a '-1' for a limit-number.

For the 'E' and 'G' command, if the most recent 'M' command succeeded (e.g. the mobile limit wasn't exceeded), the object is given to that mobile. If the most recent 'M' command FAILED (due to hitting mobile limit), then the object is not loaded.

Also remember, EACH MOBILE in your area (not just each type) must be loaded with the 'M' command. For example, if you have 20 cityguards total wandering about your town, you must do 20 reset lines of the 'M' command; for cityguard 1, cityguard 2, cityguard 3, etc., through cityguard 20. You can see how writing the #RESETS section of your area can rapidly become tiresome, but try to take extra care with this section, as it is easy to make a small typo, and these are a pain to debug if you end up with numerous reset errors!

IMPORTANT!!: For the 'D' command: ROOM EXITS MUST BE COHERENT! If room 1 had an exit East going to room 2, and room 2 has an exit in the reverse direction (West), that exit MUST GO BACK to room 1. This doesn't prevent one-way exits; room 2 doesn't HAVE to have an exit in the reverse direction.

EXAMPLE: The following is an example of several of the above reset commands as they appear in the area Midgaard. Use these to see how #RESETS works (note: this example, while taken from the Midgaard.are file

RESETS section, it is not in the same order as in the actual file,

as only a small part of that section is represented below, just to give you an idea of the various reset commands, and how they should appear):

RESETS

* * -- northern Midgaard -- <--- Comments are useful in keeping * track of your reset commands. M 0 3011 1 3001 Hassan E 1 3005 1 16 wield scimitar * M 0 3060 12 3004 Cityguard 1 E 1 3365 -1 0 equip banner E 1 3364 -1 1 equip signet ring * M 0 3060 12 3014 Cityguard 2 E 1 3365 -1 0 equip banner E 1 3364 -1 1 equip signet ring * M 0 3064 3 3007 A Happy Drunk (at Inn) M 0 3065 2 3044 A Beggar in poor alley * M 0 3012 1 3054 Healer in temple altar * M 0 3100 1 3106 Maid in Park Cafe G 1 3100 -1 A cup of tea G 1 3101 -1 A cup of coffee G 1 3102 -1 A cup of water * O 0 3135 1 3141 load Fountain on Penny Lane O 0 3136 1 3141 load 20 coins on Penny Lane * O 0 3130 1 3142 load the desk P 1 3123 1 3130 put brass key in desk O 0 3131 1 3142 load the safe P 1 3132 1 3131 put money in safe * O 0 3010 1 3054 load Donation pit * D 0 3110 3 2 Lock Captain's door from outside D 0 3142 1 2 Lock Captain's door from inside D 0 3142 2 2 Lock jail from outside D 0 3143 0 2 Lock jail from inside * S <---- REMEMBER: end the #RESETS section with an 'S'.

Wear_loc Values for the 'E' reset command:

WEAR_NONE -1 WEAR_LIGHT 0 WEAR_FINGER_L 1 WEAR_FINGER_R 2 WEAR_NECK_1 3 WEAR_NECK_2 4 WEAR_BODY 5 WEAR_HEAD 6 WEAR_LEGS 7 WEAR_FEET 8 WEAR_HANDS 9 WEAR_ARMS 10 WEAR_SHIELD 11 WEAR_ABOUT 12 WEAR_WAIST 13 WEAR_WRIST_L 14 WEAR_WRIST_R 15 WEAR_WIELD 16 WEAR_HOLD 17 MAX_WEAR 18

VII. The #SHOPS section: (optional; don't add if you have no shops) If you intend on having shops in your area, then you will need a

SHOPS section. This section, in fact, is the easiest of all the

sections in an area to do, and takes very little time.

First, I'll provide an example from the midgaard.are area file of some of the shops from Midgaard's #SHOPS section:

SHOPS

3000 2 3 4 10 0 105 15 0 23 ; The Wizard 3001 0 0 0 0 0 110 100 0 23 ; The Baker 3002 1 8 13 15 19 150 40 0 23 ; The Grocer 3003 5 0 0 0 0 130 40 0 23 ; The Weaponsmith 3004 9 0 0 0 0 100 50 0 23 ; The Armourer 3006 22 0 0 0 0 120 90 6 22 ; The Captain

The syntax of the #SHOPS is as follows:

The first value, the mobile-vnum, is the 'keeper', or the mobile who is the shopkeeper. ALL MOBILES with that vnum will be shopkeepers.

The trade-0 through trade-4 are item types which the shopkeeper will buy. Unused slots should have a '0' in them'; for instance, a shopkeeper who doesn't buy anything would have five zeroes. The item types are the same values from the #OBJECTS section, in the ITEM TYPE table. I am providing this table again, for this purpose, at the end of this #SHOPS help section.

The 'profit-buy' number is a markup for players buying the item, in percentage points. 100 is nominal price; 150 is 50% markup, and so on. The 'profit-sell' number is a markdown for players selling the item, in percentage points. 100 is nominal price, 75 is 25% markdown, and so on. The buying markup should be at least 100, generally greater, and the selling markdown should be no more than 100, generally lower.

The 'open-hour' and 'close-hour' numbers define the hours when the shopkeeper will do business. For a 24-hour shop, these numbers would be 0 and 23.

Everything beyond 'close-hour' to the end of the line is taken to be a comment.

Note that there is no room number for a shop. Just load the shopkeeper mobile in to the room of your choice, via that #RESETS section, and make the mobile a sentinel in the ACT-FLAGS section of the mobile in #MOBILES. Or, for a wandering shopkeeper, just make it non-sentinel.

The objects the shopkeeper sells are exactly those loaded by the 'G' reset command in #RESETS for that shopkeeper. These items replenish automatically. If a player sells an object to a shopkeeper, the shopkeeper will keep it for resale if he, she, or it doesn't already have an identical object. The items a player sells to a shopkeeper, however, do not replenish.

**IMPORTANT!!: You end your #SHOPS section with a '0' on the line after the last shop.

OBJECT TYPES (items a shopkeeper will buy from player):

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 ITEM_PORTAL 30 ITEM_EXPLOSIVE 31

**note: In general, when designing a mobile as a shopkeeper in the

MOBILES section, you should make him/her IMMUNE to all forms of

attack by having the mobile immune to magic, disease, poison, and weapons using the IMM_BITS in the immunities section of the mob in

MOBILES. Also, it is generally a good idea to make these mobiles

NOPURGE by having an 'ACT_FLAG' of ACT_NOPURGE for the mobile in the #MOBILES section. After all, you don't want your players killing the shopkeepers, or a purge-happy immortal accidentally purging the shopkeeper with a purge command.

VIII. The #SPECIALS section: (optional, don't add if none of your mobiles have specials)

Like the #RESETS section, the #SPECIALS section has one command per line.

This section defines special functions for mobiles. Note: many special functions, such as those that make the mobiles cast spells also make the monster much harder to fight. Keep this in mind and if you add a hard special to a monster, make the monster itself a bit wussier hitpoint and/or hit or dam or AC wise.

Example of #SPECIALS, as found in midgaard.are area file:

SPECIALS

M 3000 spec_cast_mage M 3005 spec_thief M 3011 spec_executioner M 3012 spec_cast_adept M 3060 spec_guard M 3061 spec_janitor M 3062 spec_fido M 3143 spec_mayor

Explanation:

SPECIALS <--- this begins the #SPECIALS section

M 3000 spec_cast_mage <--- Midgaard's wizard M 3005 spec_thief <--- the thief M 3011 spec_executioner <--- Hassan M 3012 spec_cast_adept <--- the Healer M 3060 spec_guard <--- cityguard M 3061 spec_janitor <--- the janitor M 3062 spec_fido <--- the fido M 3143 spec_mayor <--- Midgaard's Mayor

The syntax is simple, and is as follows: M The mobile vnum is the vnum of the mobile with that particular special function.

List of SPEC-FUN's found in the ROM2 code:

spec_breath_any spec_breath_acid spec_breath_fire spec_breath_frost spec_breath_gas spec_breath_lightning

spec_cast_adept spec_cast_cleric spec_cast_judge spec_cast_mage spec_cast_undead

spec_executioner spec_fido spec_guard spec_janitor spec_mayor spec_poison spec_thief spec_puff spec_wolf spec_batmad spec_smart

The spec_breath's are just that. Breath weapons, such as found with most dragons, many of the gods in Olympus, etc.

The spec_cast's give mobiles the abilities to cast spells, depending on which spec_cast you use. To satisfy your own curiosity, I am including a listing of what each spec_cast type will cast, depending on the level of the mobile.

spec_cast_adept spells: The spec_cast_adept mobile will cast the following spells at random on all characters in the same room, up to characters of level 10 or less (this may have been changed; but this was correct with the Rom2 code): armor bless cure blindness cure light cure poison refresh

spec_cast_cleric spells: The spells cast depend on the level of the mobile with this special function. (Thus, if you wish to have a cleric-spell casting mobile that can cast 'curse', make the mobile at least level 12). The following can be cast by this spec-fun: blindness - min. lvl. 0 cause serious - min. lvl. 3 earthquake - min. lvl. 7 cause critical - min. lvl. 9 dispel evil - min. lvl. 10 curse - min. lvl. 12 change sex - min. lvl. 12 flamestrike - min. lvl. 13 harm - min. lvl. 15 plague - min. lvl. 15 dispel magic - min. lvl. 16

spec_cast_judge: This spec-fun is geared mainly for the Judge mobile in Megacity One. The only spell cast by this spec-fun is 'high explosive'.

spec_cast_mage: The spells cast depend on the level of the mobile with this special function. The following can be cast by this spec-fun: blindness - min. lvl. 0 chill touch - min. lvl. 3 weaken - min. lvl. 7 teleport - min. lvl. 8 colour spray - min. lvl. 11 change sex - min. lvl. 12 energy drain - min. lvl. 13 fireball - min. lvl. 15 plague - min. lvl. 20 acid blast - min. lvl. 20

spec_cast_undead: The spells cast depend on the level of the mobile with this special function. The following can be cast by this spec-fun: curse - min. lvl. 0 weaken - min. lvl. 3 chill touch - min. lvl. 6 blindness - min. lvl. 9 poison - min. lvl. 12 energy drain - min. lvl. 15 harm - min. lvl. 18 plague - min. lvl. 20 teleport - min. lvl. 21

As far as the other spec-fun's go, here is a rough breakdown, just to give you and idea what each does:

spec_fun_executioner: This spec-fun is more useful if you have player stealing and player killing capabilities in the mud. The mobile with this special- function will attack any player, including an immortal, with a KILLER, or THIEF flag. Additionally, this mobile can 'create' additional cityguards in the room to assist his fight against the player.

spec_fun_puff: This amusing special function, written by Seth, of Rivers of Mud, does a number of very silly things, most of which you are probably familiar and therefore I won't go into detail.

spec_fun_fido: This is a spec-fun customized for the fido mobiles of Midgaard. All it really does is cause the mobile to eat any corpse it may see lying in the room with it; players in the room will witness this in the form of " savagely devours a corpse."

spec_fun_guard: This special-function acts in some ways like the spec_fun_executioner. It causes the mobile to attack characters automatically that have the KILLER or THIEF flags, if player stealing and player killing is allowed in the mud. Also, the spec_fun_guard will intervene in a fight, assisting the 'most evil' of the fighters, alignment-wise. This means that a good character fighting an evil mob will often be joined in his/her/it's fight by the spec_fun_guard mobile, and visa-versa for an evil character attacking good mobiles in the presence of a spec_fun_guard mobile. This assisting is always accompanied by the mobile yelling "PROTECT THE INNOCENT!! BANZAI!!"

spec_fun_janitor: This spec-fun causes the mobile to pick up "trash" (objects that are either ITEM_DRINK_CON, or ITEM_TRASH on the ground in the same room as the mobile).

spec_fun_mayor: This is geared originally for the mayor of Midgaard. It adds a bit of humor and personality to the charismatic mayor. Basically, the mobile with this special function wanders around, making comments such as "Vandals! Youngsters have no respect for anything!", and other statements, as well as going to sleep, waking up, touring Midgaard, and opening and closing the gates of Midgaard at various times.

spec_poison: A mobile with the spec_fun_poison will, when fighting a player, 'bite' the player, and thus poisoning him with a 'poison spell'. This is a good spec-fun to give to poison snakes, etc., or any other mobile that might have a poison bite.

spec_fun_thief: This spec-fun causes the mobile to "steal" money from a player in the same room as the mobile. The player also receives a "You discover 's hand's in your wallet!" when this happens to the him/her/it.

spec_wolf Any monster with this special lurks and prowls and howls to all in the area during the night hours.

spec_batmad Any creature with this special will shrivel up and die if the daylight washes over it.

spec_smart This special gives the monster with it the abilities to spell himself up with protection spells, and keep them fresh, as well as undo maladiction spells cast at him AND then turn around and cast them back at his attacker..he also has abilities that a monster with spec_cast_cleric would have...a very evil monster special, use it only for specially hard qwest mobs, temple or tribe room guardians, etc... - This very cool special by Amiga and Neuromancer.

IX. The #$ section: This section marks the end of the whole area file.

The syntax of this section is:

$

X. COMPILATION OF THE TABLES FOR AREA BUILDING: To make it simple to check values on all the multitude of tables for the various flags, etc. used in area building, I am listing again ALL the tables of values from ALL the different area sections, from #MOBILES to #SPECIALS:


 for #MOBILES:

ACT FLAGS:

ACT_IS_NPC (A) <-- Auto set for mobs: do NOT use ACT_SENTINEL (B) <-- stays in one room ACT_SCAVENGER (C) <-- picks up objects ACT_SMART (D) <-- makes mobiles smarter ACT_UNUSED (E) <-- legacy act flag (unused) ACT_AGGRESSIVE (F) <-- attacks PC's ACT_STAY_AREA (G) <-- Won't leave area

ACT_WIMPY (H) <-- will flee if hp gets too low ACT_PET (I) <-- Auto set for pets: do NOT use ACT_TRAIN (J) <-- can train PC's ACT_PRACTICE (K) <-- can practice PC's ACT_HOLYLIGHT (N) <-- used by mobprogs ACT_UNDEAD (O) n/a

ACT_CLERIC (Q) n/a ACT_MAGE (R) n/a ACT_THIEF (S) n/a ACT_WARRIOR (T) n/a ACT_NOALIGN (U) n/a

ACT_NOPURGE (V) <-- will not be purged by purge command ACT_IS_HEALER (a) <-- acts as a healer ACT_GAIN (b) <-- PC's can use 'gain' command at this mobile ACT_UPDATE_ALWAYS (c) (Don't use, see Amiga if you want info on this one) ACT_NOWANDER (d) <-- Mobs wont wander (See Amiga before using this) ACT_IS_UNDERTAKER (e) <-- handles corpse retrieval

RACES:

Here are all of the current npc races; Race affects what parts the mobile will have and some of the affected_by things it may have, just like the races for players.

unique human elf dwarf giant dragon hobbit orc wolf bat bear cat centipede dog doll fido fox goblin hobgoblin kobold lizard modron pig rabbit school monster snake song bird troll water foul wyvern arachnid demon undead draconian smurf earth elemental air elemental fire elemental water elemental plant fish animal gnome gargoyle shadow ogre minotaur beholder metal golem stone golem flesh golem wood golem clay golem

For other options, see Amiga.

Mobile Size:

T = tiny S = small M = medium L = large H = huge G = giant

Affected_by FLAGS:

If you flag a monster with any of these, it means he is AFFECTED by the flag permanently. For example, if the monster is flagged aff_poison, he is poisoned. (it does NOT mean he can cast poison, rather HE is poisoned)

AFF_BLIND (A) AFF_INVISIBLE (B) invisble to all players under his level AFF_DETECT_EVIL (C) AFF_DETECT_INVIS (D) monster can detect invisible players under his level AFF_DETECT_MAGIC (E)

AFF_DETECT_HIDDEN (F) monster can detect hiding players under his level AFF_SANCTUARY (H) AFF_FAERIE_FIRE (I) AFF_INFRARED (J) monster can see players in dark rooms and/or at night AFF_CURSE (K)

AFF_POISON (M) AFF_PROTECT (N) AFF_SNEAK (P) AFF_HIDE (Q) AFF_SLEEP (R)

AFF_CHARM (S) AFF_FLYING (T) AFF_PASS_DOOR (U) AFF_HASTE (V) AFF_CALM (W)

AFF_PLAGUE (X) AFF_WEAKEN (Y) AFF_DARK_VISION (Z) n/a AFF_BERSERK (a) AFF_SWIM (b) AFF_REGENERATION (c) AFF_LETHARGY (d)

OFF_BITS:

These are the monsters OFFENSE flags..they determine which offense he will use when he fights. eg, if a monster is flagged off_backstab, he will try to backstab when he fights.

OFF_AREA_ATTACK (A) monster attacks all in area OFF_BACKSTAB (B) must be carrying a weapon OFF_BASH (C) OFF_BERSERK (D) OFF_DISARM (E)

OFF_DODGE (F) OFF_FADE (G) OFF_FAST (H) n/a OFF_KICK (I) OFF_KICK_DIRT (J)

OFF_PARRY (K) OFF_RESCUE (L) OFF_TAIL (M) n/a OFF_TRIP (N) n/a OFF_CRUSH (O) n/a

ASSIST_ALL (P) he will assist any who was the victim of an attack ASSIST_ALIGN (Q) will assist those in a fight who are the same align as he is ASSIST_RACE (R) ditto, but same race as he is ASSIST_PLAYERS (S) will assist players who are fighting monsters ASSIST_GUARD (T) will assist cityguards ASSIST_VNUM (U) will assist all monsters of the same vnum as him

IMMUNITIES - IMM bits for mobiles:

These flags make the monster Immune to certain things. eg. if a monster is flagged imm_acid, the acid blast spell cast against him will not hurt him.

IMM_SUMMON (A) IMM_CHARM (B) IMM_MAGIC (C) IMM_WEAPON (D) IMM_BASH (E)

IMM_PIERCE (F) IMM_SLASH (G) IMM_FIRE (H) IMM_COLD (I) IMM_LIGHTNING (J) (chain lighting)

IMM_ACID (K) (acid blast) IMM_POISON (L) IMM_NEGATIVE (M) n/a IMM_HOLY (N) (holy light) IMM_ENERGY (O) n/a

IMM_MENTAL (P) n/a IMM_DISEASE (Q) (immune to plague) IMM_DROWNING (R) n/a IMM_LIGHT (S) n/a IMM_BLIND (T) IMM_LETH (U) IMM_SLEEP (V)

RESISTANCES - RES bits for mobiles:

Thse flags make the monster resistant, but not totally immune to whatever you flag him with...he can still be hurt by it, but not as easily as if he was not flagged resistant to it.

RES_CHARM (B) RES_MAGIC (C) RES_WEAPON (D) RES_BASH (E) RES_PIERCE (F)

RES_SLASH (G) RES_FIRE (H) RES_COLD (I) RES_LIGHTNING (J) (chain lighting) RES_ACID (K)

RES_POISON (L) RES_NEGATIVE (M) n/a RES_HOLY (N) (holy word) RES_ENERGY (O) n/a RES_MENTAL (P) n/a

RES_DISEASE (Q) RES_DROWNING (R) n/a RES_LIGHT (S)

VULNERABILITIES - VULN bits for mobiles:

These flags make the monster vulnerable. eg if you flag a monster vulnerable to bash, and a player bashes him, he will be hurt much more by the bash then if he was not vulnerable to it.

VULN_MAGIC (C) VULN_WEAPON (D) VULN_BASH (E) VULN_PIERCE (F) VULN_SLASH (G)

VULN_FIRE (H) VULN_COLD (I) VULN_LIGHTNING (J) (chain lighting) VULN_ACID (K) (acid blast) VULN_POISON (L)

VULN_NEGATIVE (M) n/a VULN_HOLY (N) (holy word) VULN_ENERGY (O) n/a VULN_MENTAL (P) n/a VULN_DISEASE (Q)

VULN_DROWNING (R) n/a VULN_LIGHT (S) n/a VULN_WOOD (X) (wooden weapons) VULN_SILVER (Y) (silver weapons) VULN_IRON (Z) (iron weapons)

POSITIONS:

POS_DEAD 0 <--- do not use POS_MORTAL 1 <--- do not use POS_INCAP 2 <--- do not use POS_STUNNED 3 <--- do not use

POS_SLEEPING 4 POS_RESTING 5 POS_SITTING 6 POS_FIGHTING 7 <---* this position also not used. POS_STANDING 8

SEX of mobile:

NEUTRAL 0 MALE 1 FEMALE 2

DAMAGE TYPES (these values also used for weapons in #OBJECTS):

These are the words you will see when the monster hits you...eg 'The big monsters's WHIP annhilates you!' if you chose '4' for whip...etc

0 - HIT 1 - SLICE 2 - STAB 3 - SLASH 4 - WHIP 5 - CLAW

6 - BLAST 7 - POUND 8 - CRUSH 9 - GREP 10 - BITE 11 - PIERCE 12 - SUCTION 13 - BEATING 14 - DIGESTION 15 - CHARGE 16 - SLAP 17 - PUNCH 18 - WRATH 19 - MAGIC 20 - DIVINE POWER 21 - CLEAVE 22 - SCRATCH 23 - PECK (pierce) 24 - PECK (bash) 25 - CHOP 26 - STING 27 - SMASH 28 - SHOCKING BITE 29 - FLAMING BITE 30 - FREEZING BITE 31 - ACIDIC BITE 32 - CHOMP


 for #OBJECTS

Common Materials for the 'material' section:

OBJECT TYPES:

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 (drink container) ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_FOUNTAIN 25 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 (the jukebox crickets) ITEM_PORTAL 30 ITEM_EXPLOSIVE 31 ITEM_LIQUID 32 ITEM_ARENA_WAND 33

Object FLAGS:

ITEM_GLOW (A) ITEM_HUM (B) ITEM_DARK (C) n/a ITEM_LOCK (D) n/a ITEM_EVIL (E) ITEM_INVIS (F) ITEM_MAGIC (G) n/a ITEM_NODROP (H) ITEM_BLESS (I) ITEM_ANTI_GOOD (J) ITEM_ANTI_EVIL (K) ITEM_ANTI_NEUTRAL (L) ITEM_NOREMOVE (M) ITEM_INVENTORY (N) ITEM_NOPURGE (O) ITEM_ROT_DEATH (P) item will rot a few minutes after the mobile carrying is has died ITEM_VIS_DEATH (Q) while carried by a monster, the item is not visible by either locate spell or by the player looking at the monster, but becomes visible to locate spell and to look once the monster has died ITEM_MELT_DROP (R) item dissolved and dissapears when dropped ITEM_FLOAT (S) containers flagged with this will NOT sink and dissapear in water rooms

WEAR FLAGS:

ITEM_TAKE (A) (all items you want to carry must have this flag) ITEM_WEAR_FINGER (B) ITEM_WEAR_NECK (C) ITEM_WEAR_BODY (D) ITEM_WEAR_HEAD (E) ITEM_WEAR_LEGS (F) ITEM_WEAR_FEET (G) ITEM_WEAR_HANDS (H) ITEM_WEAR_ARMS (I) ITEM_WEAR_SHIELD (J) ITEM_WEAR_ABOUT (K) (worn about body) ITEM_WEAR_WAIST (L) ITEM_WEAR_WRIST (M) ITEM_WIELD (N) ITEM_HOLD (O)

CONDITION OF OBJECT:

PERFECT P GOOD G AVERAGE A WORN W DAMAGED D RUINED R

WEAPON CLASS:

WEAPON_EXOTIC 0 (any player can use these) WEAPON_SWORD 1 (only players with sword skill can use) WEAPON_DAGGER 2 (only players with dagger skill can use.. and the same for the rest) WEAPON_SPEAR 3 WEAPON_MACE 4 WEAPON_AXE 5 WEAPON_FLAIL 6 WEAPON_WHIP 7 WEAPON_POLEARM 8

WEAPON TYPES:

WEAPON_FLAMING (A) n/a WEAPON_FROST (B) n/a WEAPON_VAMPIRIC (C) item has venom/poison on it WEAPON_SHARP (D) WEAPON_VORPAL (E) WEAPON_TWO_HANDS (F) need the weapon and the shield wear slot free to use

APPLY BONUS TYPES (for the 'A' section of #OBJECTS):

APPLY_STRENGTH 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_CLASS 7 n/a APPLY_LEVEL 8 n/a APPLY_AGE 9 n/a APPLY_HEIGHT 10 n/a APPLY_WEIGHT 11 n/a APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_GOLD 15 APPLY_EXP 16 n/a APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_PARA 20 APPLY_SAVING_ROD 21 APPLY_SAVING_PETRI 22 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24

Container FLAGS (if OBJECT TYPE is container only):

CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8

Portal GATE FLAGS

GATE_NORMAL_EXIT A enter/exit messages from portal are as if its a door GATE_NOCURSE B can enter portal even if cursed or in norecall room GATE_GOWITH C the portal goes with you GATE_BUGGY D small chance of sending you to a random room GATE_RANDOM E sends you to a random room on the mud GATE_RANDOMAREA F sends you to a random room in same area

PORTAL EXIT FLAGS

EX_ISDOOR A when you enter portal it looks like you enter a door EX_CLOSED B EX_LOCKED C EX_PICKPROOF F EX_NOPASS G passproof

Liquid values for DRINK CONTAINERS (value2 on the value line):

LIQ_WATER 0 LIQ_BEER 1 LIQ_RED_WINE 2 LIQ_ALE 3 LIQ_DARK_ALE 4 LIQ_WHISKEY 5 LIQ_LEMONADE 6 LIQ_FIREBREATHER 7 LIQ_LOCAL_SPECIALTY 8 LIQ_SLIME_MOLD_JUICE 9 LIQ_MILK 10 LIQ_TEA 11 LIQ_COFFEE 12 LIQ_BLOOD 13 LIQ_SALT_WATER 14 LIQ_COLA 15 LIQ_ROOT_BEER 16 LIQ_ELVISH_WINE 17 LIQ_WHITE_WINE 18 LIQ_CHAMPAGNE 19 LIQ_MEAD 20 LIQ_ROSE_WINE 21 LIQ_BENEDICTINE_WINE 22 LIQ_VODKA 23 LIQ_CRANBERRY_JUICE 24 LIQ_ORANGE_JUICE 25 LIQ_ABSINTHE 26 LIQ_BRANDY 27 LIQ_AQAVIT 28 LIQ_SCHNAPPS 29 LIQ_ICEWINE 30 LIQ_AMONTILLADO 31 LIQ_SHERRY 32 LIQ_FRAMBOISE 33 LIQ_RUM 34 LIQ_CORDIAL 35

Cheers to Satin, of Tesseract, who brewed up the last 20 liquid types, above.

Value lines for all the various OBJECT TYPES follow:

format -

**note: if a value is shown to be 'unused', place a zero, '0', for that value. DO NOT skip it or leave it blank.

ITEM_PORTAL: <# of charges>

ITEM_LIGHT: <HOURS OF LGT. AVAILABLE 0=dead, 999=infinite

ITEM_EXPLOSIVE:

ITEM_SCROLL:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

**note: spell lvl is the level at which the spell will be cast, NOT the level of the reader of the scroll.

**note: 'sn' stands for SLOT NUMBER; this is the spell number; please consult the ROM spell list referenced at the end of this compendium to find out what number to use to indicate each spell.

ITEM_WAND:

ITEM_STAFF:

ITEM_WEAPON: <# damage dice>

ITEM_TREASURE:

ITEM_ARMOR:

ITEM_POTION:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

ITEM_PILL:

**note: Potions and pills can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values.

ITEM_FURNITURE:

**note: the benches in Southern Midgaard are an example of a furniture object... they basically just sit there.

ITEM_TRASH:

ITEM_SINGING (jukebox/crickets) < -1 > < -1 > < -1 > < -1 > < -1 >

ITEM_CONTAINER:

**note: Use the Container FLAGS listed earlier for this value; the key vnum is ONLY USED if there is a key to unlock the container - otherwise put a zero for that value.

ITEM_DRINK_CONTAINER: <0 <---note: if this value is a NON-ZERO number, the drink is poisoned>

ITEM_KEY:

ITEM_FOOD: * note if this ^^^^^^^ value is 1, food is poison. ITEM_MONEY:

ITEM_BOAT:

ITEM_FOUNTAIN:

ITEM_MAP: < 1 >


 for #ROOMS

Direction Values for the 'D' section:

NORTH 0 EAST 1 SOUTH 2 WEST 3 UP 4 DOWN 5

(eg D0 = a door or non door exit that allows you to go north)

Door state values for the 'D' section:

Unhindered exit 0 Door with no keyhole -1 Normal door 1 Pick-proof door 2 Pass proof door 3 Pick and passproof door 4

note: a 'hidden' exit that doesn't show in when players type 'exit' is made by flagging your exit to be a door or flag 1.

ROOM-FLAGS:

ROOM_DARK (A) (room is dark if you are not holding a light) ROOM_NO_SUMMIN (B) (can't summon anything into this room) ROOM_NO_MOB (C) (monsters won't wander in) ROOM_INDOORS (D) (room will be dark unless you carry light) ROOM_NO_SUMMOUT (E) (can't summon anything OUT of this room) ROOM_PRIVATE (J) (2 players or monsters only) ROOM_SAFE (K) (can't attack monsters in this room) ROOM_SOLITARY (L) (1 player or monster room) ROOM_PET_SHOP (M) ROOM_NO_RECALL (N) ROOM_IMP_ONLY (O) (ya!) ROOM_GODS_ONLY (P) ROOM_HEROES_ONLY (Q) (level 91+ can get in here only) ROOM_NEWBIES_ONLY (R) ROOM_LAW (S) (no charming monsters here)

SECTOR-TYPES:

SECT_INSIDE 0 (in order 0 -> 5, cost more movement points) SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 (you have to fly or have a boat to get past) SECT_WATER_NOSWIM 7 (its watery, but you can walk in it) SECT_AIR 9 (need to fly over this room) SECT_DESERT 10 SECT_MAX 11 n/a


 for #RESETS

Wear_loc Values for the 'E' reset command:

WEAR_NONE -1 WEAR_LIGHT 0 WEAR_FINGER_L 1 WEAR_FINGER_R 2 WEAR_NECK_1 3 WEAR_NECK_2 4 WEAR_BODY 5 WEAR_HEAD 6 WEAR_LEGS 7 WEAR_FEET 8 WEAR_HANDS 9 WEAR_ARMS 10 WEAR_SHIELD 11 WEAR_ABOUT 12 WEAR_WAIST 13 WEAR_WRIST_L 14 WEAR_WRIST_R 15 WEAR_WIELD 16 WEAR_HOLD 17 MAX_WEAR 18


 for #SHOPS

OBJECT TYPES (items a shopkeeper will buy from player):

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29


 for #SPECIALS

List of SPEC-FUN's found in the ROM2 code:

spec_breath_any spec_breath_acid spec_breath_fire spec_breath_frost spec_breath_gas spec_breath_lightning

spec_cast_adept spec_cast_cleric spec_cast_judge spec_cast_mage spec_cast_undead

spec_executioner spec_fido spec_guard spec_janitor spec_mayor spec_poison spec_thief spec_puff spec_wolf spec_batmad


This ends my area help file, and I hope that by thoroughly reading ALL the above information that you now feel confident in beginning your area building.

FINAL HINT: For the end of this help section, I would like to part with some advice to aid you in your building interesting and fun areas for players to delve into and explore. When writing the room descriptions, object descriptions, and mobile descriptions, MAKE THEM INTERESTING TO READ! No one likes to see room after room AFTER ROOM of something like "You have entered a large chamber. It is very dark in here.", or some such nonsense for your room descriptions. Vary EACH room description and spice it up with some CREATIVITY. After all, that is what you must enjoy, if you are considering building an area. Try to use this combination of variety, intelligence, and imagination in the building of your area. One of the greatest joys most players find while mudding is the exploration and discovery of new and interesting rooms, items, treasures, and monsters. For those of you familiar with TSR's Dungeons & Dragons, or similar roleplaying games, this creative use of description and atmosphere should be well-known to you. Otherwise, consider looking over other areas YOU like before beginning your own, and see how that area was done. But most of all, do not bore your players.

Also, keep in mind what level your area is geared for, and the type of characters/players that it may be geared for as well. For example, some areas may be constructed with fighter-types in mind, others maybe mainly for grouped characters, or magic-using characters (lots of weapon-resistant mobiles for example), or for people that like to explore and/or map out new areas, and even areas for characters that just like blood, slaughter, and 'kill kill kill!'. So decide exactly WHAT type of area you are building, and follow through with it. And most important, MAKE IT FUN and CHALLENGING for the players. Despite what some may say, no one likes to be given tons of treasure, gold, and magic-items with little or no struggle. Monty Hall areas grow quickly tiresome. So endeavor to make a well-rounded, cleverly constructed area for all to enjoy. - Ozymandias


ROM Area Building Reference

Source: docs/manuals/rom-area-building-reference.md

This is an Area Building Help file for ROM-based code and other Merc 2.1 based MUDs, using the new format. Enjoy - Ozy.


compiled/written by: Ozymandias

-+-+ MadROM muds at: telnet madrom.net 1536 -+-+-

Acknowledgement:

This file contains material and information from the Merc release 2.1 Area help files (done by Furey, Hatchet, and Kahn), material from the Merc Diku Mud code itself, material and examples from various area files that are found in both ROM2 and MadROM, as well as coding material that was adapted and modified by Alander for ROM2, and later by Madman for MadROM.

Purpose:

The purpose of this file is to update other area building help files that are floating around out there that are either sorely outdated, or are simply lacking needed material and are thus confusing. This file should make it possible for even the most computer-illiterate individual to code an area.

Overview of Areas

An area is one place of the world. Each are is defined in a separate file. When naming your area file, for purposes of FTP'ing it or sending it by email, the common format is as follows: name.are, with the name being the name of the area.

An area is a collection of sections starting with #AREA until the next #AREA. Each of these sections, listed below, contains its own format. Each section will end, and the next section is written, until you come to the end of your area building. The sections used are #AREA, #HELPS, #MOBILES, #OBJECTS, #ROOMS, #RESETS, #SHOPS,

SPECIALS, and lastly #$. These 9 sections do not include

MOBPROGS. If you are interested in doings MOBPROGS, that information will not be contained in this file, as it is not commonly used by most beginning area builders.

Data Types

All of the data in an area file (even the section headers) consists of a series of values. Each value has a specific type. The server parses the file by reading in data values one at a time according to the types it expects.

Blank characters (spaces, tabs, new lines, carriage returns) at the beginning of a data value are always ignored (this includes strings). Thus you can format the area files in whatever way suits your taste and your needs.

However, I personally like using a word processor, converting it to DOS (this is easy to do... check with whatever wp program you are using), and uploading it to my account via PC TRANS (or whatever program your account uses to upload files from a PC) to be able to be sent to whomever I need to send it to. But you can use whatever editor or method you desire. Additionally, I recommend doing the area sections in the order they are explained in this help file, just to keep things simple and organized for proofreading and debugging.

Types of data you should know:

A 'letter' is a single non-blank character.

A 'word' is a sequence of non-blank characters terminated by a blank.

A 'string' is a sequence of non-tilde characters terminated by a tilde. A 'tilde', by the way, is this character on your keyboard: '~ '. Thus strings may contain blanks, and may be multiple lines long. There is no limit on the length of an individual strings; however, all strings go into a common memory pool whose size is fixed when the server is compiled.

A 'number' is a decimal number with an optional leading '-' or '+', as in the hit points section of a mobile, for example: 5d6+250. The 'd' in this example stands for (5) 6-sided dice PLUS 250, ranging for a hit point range of 255 to 280... 250 plus 5 to 30.

IMPORTANT: Mobiles, objects, and rooms are ALL IDENTIFIED by vnum (virtual number). The range of vnums is 1 to 32767, and each object, mobile, etc, has its own UNIQUE vnum. No two rooms, for example, can possess the same vnum. However, you can have an Object with vnum 3100 and a room with vnum 3100, for example. Just no two objects, two mobiles, or two rooms can have the same one as the other. Vnums no not have to be in increasing order.

Typically an area uses the same range of vnum's for mobile vnum's, object vnum's, and room vnum's, starting with a multiple of 100. This facilitates adding the area into an existing set of areas. So, you may pick something like 16000 to 16500 for your range of vnums for all objects, mobiles and rooms, just as an example. Check with the implementor of the MUD your area is intended for BEFORE choosing a vnum range, as many vnums may already be in use in other areas.

I. The #AREA section. This is the easiest section to do. The format is as follows:

AREA

The 'area-name' can be any string. The 'areas' command provides a list of areas, so it's worth while to follow the standard Merc format for this string. This format would look as follows, to take an example from an area already designed:

AREA {30 60} Ozymandias Hades~

The first two numbers are the recommended level range of the area. The first name is your own name or alias as it shows with the 'areas' command, and the last phrase is the name of the area itself.

II. The #HELPS section.

This section is rarely used. It is simply for placing keywords and a help section about your area for players/immortals to read and to get help about your area or its format. However, it is really only necessary if you feel there may be some complications in your area. If you desire to use a #HELPS section, its format as it appeared in the Merc 2.1 code is as follows:

HELPS

~ ~ 0 $

The 'level' number is the minimum character level needed to read this section. This allows for immortal-only help text.

The 'key-words' are a set of keywords for this help text.

The 'help-text' is the help text itself.

Normally when a player uses 'help', both the keywords and the help- text are shown. If the 'level' is negative, however, the keywords are suppressed. This allows the help file mechanism to be used for certain other commands, such as the initial 'greetings' text.

If a 'help-text' begins with a leading '.', the '.' is stripped off. This provides for an escape mechanism from the usual leading- blank stripping of strings, so that picturesque greeting screens may be used.

Remember, ALL strings must be followed by a tilde, the '~' symbol, to end that particular string. FAILURE to place the tilde will result in an error in your area file.

III. The #MOBILES section. O.K., here where it gets to be more confusing. First of all, let me provide an example of what part of the #MOBILES section may look like, by providing an example of one of my own mobiles, and then by following with the syntax explanation of each line.

MOBILES

22001

prisoner amazon~ an amazon prisoner~ An amazon prisoner rests here in shackles. ~ You see a tall, beautiful female warrior in glittering armor. ~ human~ BT Na 850 S 35 3 1d1+749 1d1+297 12d4+10 5 -5 -5 -5 0 EDFHIKLNU 0 0 0 8 8 2 0 0 0 M 0 X sound 30 An amazon prisoner screams in fear!~ X tribe Dance~

22002 <----- THIS BEGINS THE NEXT MOBILE, AND SO ON....

Explanation of each line:

MOBILES <--- the beginning of the mobile section.

22001 <---

prisoner amazon~ <--- an amazon prisoner~ <--- An amazon prisoner rests here in shackles. <--- ~ <--- put the tilde for the long desc. on the next line, like so. You see a tall, beautiful female in glittering armor. ~ <--- the extended description, with tilde on next line. BT Na 850 S <--- is the: (Note: ALWAYS end this above line with a capital 'S' after the alignment number, as is shown here. In the original Diku mob format, 'S' stands for simple. Merc supports only simple mobs, so the 'S' is redundant. It is retained not only for compatibility with the Diku format, but also because it helps the server report errors more accurately. 35 3 1d1+749 1d1+297 12d4+10 5 <--- this contains the following: -5 -5 -5 0 <--- Armor Class (AC) values for . NOTE!!: A common misconception is that these values you install in this line will be the mob's TOTAL ACs for the 4 AC values. This is not so. Simply put, an AC that reads in your file as: -15 -15 -15 -15 0 will read on the mud as -150 -150 -150 -150 0 EDFHIKLNU 0 0 0 <--- this line is: . A list of the Off_bits, and the immunities, resistances and vulnerabilities is at the end of this section, as well as listings of the Affected_by and ACT bits of above. The 'Off_bits' are composed of the 'skills' that the mobile has, as well as whether or not this mobile will assist other mobiles of the same vnum, alignment, etc. In the case here, with this amazon mobile having EDFHIKLNU, as you will see by looking up these values below, gives this mobile the following skills: Disarm, Berserk, Dodge, Fast, Kick, Parry, Rescue, Trip, and Assist_vnum. A nice combination for a warrior-type mobile, over all. This amazon mobile also, as can be seen by the three '0's, has no particular immunities or vulnerabilities. 8 8 2 0 <---- this line is: . The position numbers most commonly used are the 8 8 combination, which means the mobile is normally standing, rather than sitting, sleeping, etc. A listing of all the position values is given at the end of this section, with the other value listings. For the sex, 0 = neutral, 1 = male, 2 = female. The last value is the gold that the mobile has in its possession. As this particular example is an amazon 'prisoner', I elected to make the amazon poor... as prisoners rarely have money. =) 0 0 M 0 <--- this last line is the easiest. The first two numbers and the last number are always zeros, ('0's), as they represent part-types (brains, legs, guts, tail, arms, heart, etc.) for when they die, and other values that are now taken care of by the Merc code. Most of this is calculated based on the 'race' of the mobile, from one of the earlier lines. So just simply use zeros for these three values. The 'M' represents the SIZE of the mobile. A listing of the size values are given later, but I can also list them here: T=tiny, S=small, M=medium, L=large, H=huge, and G=giant.

X sound 30 An amazon prisoner screams in fear!~ <- mob sounds line (see MobSounds.txt for how to add these in..its easy) X tribe Druid~ <- flags a mob as a member of a Tribe. Must be an existing Tribe, and must use the Tribe abbrev for the Tribe word.

Note:

The 'vnum' is the virtual number of the mobile.

The 'keywords' are the words which can be used in commands to identify the mobile.

The 'short-description' is the description used to identify the mobile.

The 'long-description' is the description used when a character walks in the room and the mobile is visible.

The 'description' is the longest description. It is used when a character explicitly looks at the mobile.

The 'Act-flags' define how the mobile acts, and the 'affected_by flags' define more attributes of the mobile. Affected_by flags generally define what the mobile is 'affected' by. Therefore the affected_by flag of AFF_BLIND for example means that this particular mobile will be blind, and NOT that the mobile casts a blindness spell.

The 'alignment' of the mobile ranges from -1000 to 1000, the higher being good, the lower being evil, with '0' being true neutral. Keep in mind that certain spells ('protection' and 'dispel evil') give characters fighting evil monsters an advantage, and that experience earned is influenced by alignment.

The 'level' is typically a number from 1 to 100 (for MadROM; other Diku MUDs may have lower levels, i.e., 1 to 60, etc.), although there is no upper limit.

IMPORTANT: When writing your mobiles, you may be having trouble deciding how many hit points and mana to give your monsters and NPCS. For mana, this is easy: the mobiles don't use the mana really for spell casting..so you must put an amount, but it is not vital that you spend hours worrying about it..I would put an amount that seems reasonable for that level mob..for appearances sake. For deciding on hit points, here is a simple guideline: For Normal mobiles- 10 - 15 hps per level, up to maybe 40th level; then perhaps 20 or more hps per additional level above 40. However, for the extremely high level mobiles, > lvl. 60, for example, the hit points can vary tremendously, from in the several thousands, up to 20,000 hit points, in the case of Asgard's Heimdall, etc. However, by following this guideline for an normal toughness mobile, a level 28 mobile may have around 280 to 420 hit points, or something in that range.

For Very Tough mobiles- For inherently TOUGH mobiles, such as dragons, demons, Gods, devils, very large giants, titans, and other unusually powerful beings, hit points may be much higher than other mobiles of similar levels. For example, you may decide to give a 40th level dragon something like 1200 hps, while a 40th level ogre warrior of some sort, for example, may only have 400-600 hit points! And they are both the same level. This can reflect the inherent power of the dragon or whatever. For example, all the Greater Daemons in my area Hades have around 2000 to 4000 hit points, and are only around 50 - 60th level. This reflects the natural "toughness" of these lords and rulers of the Underworld, the greater daemons.

Again, all this is subject to the goals of the area builder, and can entail much variation from the above suggested guidelines. An area designer may have an area with lots of particularly desirable treasures, and thus may elect to "boost" the hit points somewhat of his/her mobiles in order to give the area an overall tougher feel to it. But try not to get carried away. An area filled mostly with mobiles of 10,000 and 20,000 hit points is not going to be an affective area. Try to limit the number of mobiles with EXTREMELY high hit points.

Now here are the listings of all the necessary values for making your mobiles; the flags will be on the left, and the letter or number values you use are on the right column:

ACT FLAGS:

ACT_IS_NPC (A) <-- Auto set for mobs: do NOT use ACT_SENTINEL (B) <-- stays in one room ACT_SCAVENGER (C) <-- picks up objects ACT_AGGRESSIVE (F) <-- attacks PC's ACT_STAY_AREA (G) <-- Won't leave area

ACT_WIMPY (H) <-- will flee if hp gets too low ACT_PET (I) <-- Auto set for pets: do NOT use ACT_TRAIN (J) <-- can train PC's ACT_PRACTICE (K) <-- can practice PC's ACT_UNDEAD (O) (ACT flags O to U are not imped on MadROM, yet)

ACT_CLERIC (Q) ACT_MAGE (R) ACT_THIEF (S) ACT_WARRIOR (T) ACT_NOALIGN (U)

ACT_NOPURGE (V) <-- will not be purged by purge command ACT_IS_HEALER (a) <-- acts as a healer ACT_GAIN (b) <-- PC's can use 'gain' command at this mobile ACT_UPDATE_ALWAYS (c)

RACES:

Here are some common races; remember, the race you pick for the mobile does not have to reflect what the mobile is. You can have an Ogre mobile with a race of human, elf, dragon, etc. The race only affects the parts of the mobile, etc. A dragon has more parts than a human (i.e. wings, tail, etc.)

human dragon elf dwarf orc giant unique

There are others, but these are usually the most common. In fact, many area builders use 'human' as the race for nearly all their mobiles, except for dragons, and winged monsters, etc., as that is the simplest.

Mobile Size:

T = tiny S = small M = medium L = large H = huge G = giant

Affected_by FLAGS:

AFF_BLIND (A) AFF_INVISIBLE (B) AFF_DETECT_EVIL (C) AFF_DETECT_INVIS (D) AFF_DETECT_MAGIC (E)

AFF_DETECT_HIDDEN (F) AFF_SANCTUARY (H) AFF_FAERIE_FIRE (I) AFF_INFRARED (J) AFF_CURSE (K)

AFF_POISON (M) AFF_PROTECT (N) AFF_SNEAK (P) AFF_HIDE (Q) AFF_SLEEP (R)

AFF_CHARM (S) AFF_FLYING (T) AFF_PASS_DOOR (U) AFF_HASTE (V) AFF_CALM (W)

AFF_PLAGUE (X) AFF_WEAKEN (Y) AFF_DARK_VISION (Z) AFF_BERSERK (a) AFF_SWIM (b) AFF_REGENERATION (c)

Remember: unless you desire your mobile to be poisoned, plagued, weakened, cursed, or sleeping, do not use those particular 'Affected_by' flags. However, it could be amusing to have a 'walking plague spreader' in an area, for example, and you may desire to have a mobile affected by the plague, and consequently spreading it to other PC's it runs in contact with. =)

OFF_BITS:

OFF_AREA_ATTACK (A) OFF_BACKSTAB (B) OFF_BASH (C) OFF_BERSERK (D) OFF_DISARM (E)

OFF_DODGE (F) OFF_FADE (G) OFF_FAST (H) OFF_KICK (I) OFF_KICK_DIRT (J)

OFF_PARRY (K) OFF_RESCUE (L) OFF_TAIL (M) OFF_TRIP (N) OFF_CRUSH (O)

Note: these are also part of Off_bits. ASSIST_ALL (P) ASSIST_ALIGN (Q) ASSIST_RACE (R) ASSIST_PLAYERS (S) ASSIST_GUARD (T) ASSIST_VNUM (U)

IMMUNITIES - IMM bits for mobiles:

IMM_SUMMON (A) IMM_CHARM (B) IMM_MAGIC (C) IMM_WEAPON (D) IMM_BASH (E)

IMM_PIERCE (F) IMM_SLASH (G) IMM_FIRE (H) IMM_COLD (I) IMM_LIGHTNING (J)

IMM_ACID (K) IMM_POISON (L) IMM_NEGATIVE (M) IMM_HOLY (N) IMM_ENERGY (O)

IMM_MENTAL (P) IMM_DISEASE (Q) IMM_DROWNING (R) IMM_LIGHT (S)

RESISTANCES - RES bits for mobiles:

RES_CHARM (B) RES_MAGIC (C) RES_WEAPON (D) RES_BASH (E) RES_PIERCE (F)

RES_SLASH (G) RES_FIRE (H) RES_COLD (I) RES_LIGHTNING (J) RES_ACID (K)

RES_POISON (L) RES_NEGATIVE (M) RES_HOLY (N) RES_ENERGY (O) RES_MENTAL (P)

RES_DISEASE (Q) RES_DROWNING (R) RES_LIGHT (S)

VULNERABILITIES - VULN bits for mobiles:

VULN_MAGIC (C) VULN_WEAPON (D) VULN_BASH (E) VULN_PIERCE (F) VULN_SLASH (G)

VULN_FIRE (H) VULN_COLD (I) VULN_LIGHTNING (J) VULN_ACID (K) VULN_POISON (L)

VULN_NEGATIVE (M) VULN_HOLY (N) VULN_ENERGY (O) VULN_MENTAL (P) VULN_DISEASE (Q)

VULN_DROWNING (R) VULN_LIGHT (S) VULN_WOOD (X) VULN_SILVER (Y) VULN_IRON (Z)

POSITIONS:

POS_DEAD 0 <--- POS_MORTAL 1 <--- POS_INCAP 2 <--- POS_STUNNED 3 <--- these 4 positions not used.

POS_SLEEPING 4 POS_RESTING 5 POS_SITTING 6 POS_FIGHTING 7 <---* this position also not used. POS_STANDING 8

SEX of mobile:

NEUTRAL 0 MALE 1 FEMALE 2

DAMAGE TYPES (these values also used for weapons in #OBJECTS):

0 - HIT 1 - SLICE 2 - STAB 3 - SLASH 4 - WHIP 5 - CLAW

6 - BLAST 7 - POUND 8 - CRUSH 9 - GREP 10 - BITE 11 - PIERCE 12 - SUCTION 13 - BEATING 14 - DIGESTION 15 - CHARGE 16 - SLAP 17 - PUNCH 18 - WRATH 19 - MAGIC 20 - DIVINE POWER 21 - CLEAVE 22 - SCRATCH 23 - PECK (pierce) 24 - PECK (bash) 25 - CHOP 26 - STING 27 - SMASH 28 - SHOCKING BITE 29 - FLAMING BITE 30 - FREEZING BITE 31 - ACIDIC BITE 32 - CHOMP

IV. The #OBJECTS section: The #OBJECTS section is similar to the #MOBILES section. However, the main difference is that the values in the #OBJECTS section depend on the TYPE of object being described, i.e., weapon, scroll, potion, treasure, etc. Below I am presenting an example of how an object should look in this section:

Example:

22016

sword underworld~ The Sword of the Underworld~ A large, dark sword of solid obsidian gleams evilly here.~ adamantite~ 5 ABCEJL AN 1 11 6 6 DE 50 30 35000 P E sword underworld~ This heavy sword has an evil, dark shine to its metal. The pommel is formed into the shape of a large ram's head and is set with several large rubies. ~ A 18 4 A 19 4 A 1 2 A 5 2 A 23 -8

22017 <--- this begins the next object in the #OBJECTS section...

Explanation of each line:

22016 <--- this is the vnum unique to this object

sword underworld~ <--- these are the keywords for the object The Sword of the Underworld~ <--- the name of the object A large, dark sword of solid obsidian gleams evilly here.~ <-long description adamantite~ <--- the 'material' of the object. Use the common materials that are already in the const.c table in the ROM code. A list of materials for MadROM is provided at the end of the help for #OBJECTS section. This is similar to the 'race' part of the #MOBILES, and is what prevents some objects from being burned, while objects made of wood, paper and glass CAN be destroyed by dragon fire, for example. 5 ABCEJL AN <--- this line contains: . A listing of item types, flags and wear flags is provided at the end of the help for #OBJECTS section. The item type is just that; 5 = weapon, as reflected here. The flags add additional flags to the item, i.e., evil, magic, humming, glowing, etc. The wear flags tell where and if an item can be worn and where. A and N tell the code that this sword can be 'taken' and 'wielded' as a weapon; A = take, and N= wield. Without the 'A', this item could not even be picked up from the ground. 1 11 6 6 DE <-- IMPORTANT This is the VALUES line, and it varies depending on the 'ITEM TYPE' as declared in the above line. At the end of this section, following the value tables, is the breakdown of this line for all the other object types. This example here, therefore, is geared for objects that are weapons. In the example here, this line is as follows: .

      The weapon class is what sort of weapon it is; sword,
      polearm, whip, etc.  A '1' = sword in this example.
      Damage is calculated by the 'dice' method.  The first
      number is the number of dice;  the second is the type of
      dice rolled.  In this example, The Sword of the
      Underworld has 11 and 6 as values;  that is 11d6, or 11
      six-sided dice for damage.  In other words, 11 times 6 is
      the max damage, and roughly half that is the average
      damage.  Thus, this sword has an average damage of 33.
      The DAMAGE TYPE is crush, slash, pound, etc., and uses
      the same damage type chart from #MOBILES.

      The WEAPON TYPES gives the weapon additional
      characteristics, i.e., two-handed, vorpal, vampiric, etc.
      Listings for the WEAPON CLASS, DAMAGE TYPES, and WEAPON
      TYPES can be found at the end of this #OBJECTS help
      section.

50 30 35000 P <--- this line contains: . This line should be self-explanatory; the value of the object is what you would purchase it for, in gold, if it was for sale in the Weapons Shop. E <--- this is if you want extra descriptive keywords; the 'E' section in #OBJECTS allows for this. When someone 'looks' at the object they will be given an additional description; this is optional. sword underworld~ <--- the keywords for the 'E' section. This heavy sword has an evil, dark shine to its metal. The pommel is formed into the shape of a large ram's head and is set with several large rubies. <--- the 'extra description' ~ A <--- this is for adding abilities and other attributes to the object. An 'A' section ('apply' section) contains an apply-type and an apply-value. When a character uses this object as equipment (holds, wields, or wears it), then the value of the 'apply-value' is added to the character attribute identified by the 'apply-type'. In other words, if you construct an 'A' value for +strength for an object, of say +2, for example, when a character uses it as equipment, the strength of the character increases by 2. 18 4 <--- ; this example here gives plus 4 to the hitroll with this weapon. 18 is +hitroll, and the 'apply-value' of 4 gives it plus 4. A <--- another 'A' value, and so on...

NOTE The optional 'E' sections and 'A' sections come after the main data. An 'E' section ('extra description section' contains a keyword-list and a string associated with those keywords. This description string is used when a character looks at a word on the keyword list, as explained above. A single object may have an unlimited number of 'E' and 'A' sections.

Common Materials for the 'material' section:

(For a complete list, check the const.c table in the mud code itself... however, this list probably contains all that you would use for most objects).

  • cloth
  • leather
  • pill
  • paper
  • vellum
  • glass
  • wood
  • steel
  • bronze
  • brass
  • iron
  • gold
  • silver
  • adamantite
  • stone

These are the ones mainly used... for a complete list, you would need to look up the const.c table in the actual mud code itself.

OBJECT TYPES:

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_FOUNTAIN 25 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 ITEM_PORTAL 30 ITEM_EXPLOSIVE 31

Object FLAGS:

ITEM_GLOW (A) ITEM_HUM (B) ITEM_DARK (C) ITEM_LOCK (D) ITEM_EVIL (E) ITEM_INVIS (F) ITEM_MAGIC (G) ITEM_NODROP (H) ITEM_BLESS (I) ITEM_ANTI_GOOD (J) ITEM_ANTI_EVIL (K) ITEM_ANTI_NEUTRAL (L) ITEM_NOREMOVE (M) ITEM_INVENTORY (N) ITEM_NOPURGE (O) ITEM_ROT_DEATH (P) ITEM_VIS_DEATH (Q) ITEM_MELT_DROP (R) ITEM_FLOAT (S)

WEAR FLAGS:

ITEM_TAKE (A) ITEM_WEAR_FINGER (B) ITEM_WEAR_NECK (C) ITEM_WEAR_BODY (D) ITEM_WEAR_HEAD (E) ITEM_WEAR_LEGS (F) ITEM_WEAR_FEET (G) ITEM_WEAR_HANDS (H) ITEM_WEAR_ARMS (I) ITEM_WEAR_SHIELD (J) ITEM_WEAR_ABOUT (K) ITEM_WEAR_WAIST (L) ITEM_WEAR_WRIST (M) ITEM_WIELD (N) ITEM_HOLD (O)

CONDITION OF OBJECT:

PERFECT P GOOD G AVERAGE A WORN W DAMAGED D RUINED R

WEAPON CLASS:

WEAPON_EXOTIC 0 WEAPON_SWORD 1 WEAPON_DAGGER 2 WEAPON_SPEAR 3 WEAPON_MACE 4 WEAPON_AXE 5 WEAPON_FLAIL 6 WEAPON_WHIP 7 WEAPON_POLEARM 8

WEAPON TYPES:

WEAPON_FLAMING (A) WEAPON_FROST (B) WEAPON_VAMPIRIC (C) WEAPON_SHARP (D) WEAPON_VORPAL (E) WEAPON_TWO_HANDS (F)

APPLY TYPES (for the 'A' section of #OBJECTS):

APPLY_STR 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_CLASS 7 APPLY_LEVEL 8 APPLY_AGE 9 APPLY_HEIGHT 10 APPLY_WEIGHT 11 APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_GOLD 15 APPLY_EXP 16 APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_PARA 20 APPLY_SAVING_ROD 21 APPLY_SAVING_PETRI 22 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24

Container FLAGS (if OBJECT TYPE is container only):

CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8

Portal GATE FLAGS

GATE_NORMAL_EXIT A enter/exit messages from portal are as if its a door GATE_NOCURSE B can enter portal even if cursed or in norecall room GATE_GOWITH C the portal goes with you GATE_BUGGY D small chance of sending you to a random room GATE_RANDOM E sends you to a random room on the mud GATE_RANDOMAREA F sends you to a random room in same area

PORTAL EXIT FLAGS

EX_ISDOOR A EX_CLOSED B EX_LOCKED C EX_PICKPROOF F EX_NOPASS G passproof

Liquid values for DRINK CONTAINERS (value2 on the value line):

LIQ_WATER 0 LIQ_BEER 1 LIQ_RED_WINE 2 LIQ_ALE 3 LIQ_DARK_ALE 4 LIQ_WHISKEY 5 LIQ_LEMONADE 6 LIQ_FIREBREATHER 7 LIQ_LOCAL_SPECIALTY 8 LIQ_SLIME_MOLD_JUICE 9 LIQ_MILK 10 LIQ_TEA 11 LIQ_COFFEE 12 LIQ_BLOOD 13 LIQ_SALT_WATER 14 LIQ_COLA 15 LIQ_ROOT_BEER 16 LIQ_ELVISH_WINE 17 LIQ_WHITE_WINE 18 LIQ_CHAMPAGNE 19 LIQ_MEAD 20 LIQ_ROSE_WINE 21 LIQ_BENEDICTINE_WINE 22 LIQ_VODKA 23 LIQ_CRANBERRY_JUICE 24 LIQ_ORANGE_JUICE 25 LIQ_ABSINTHE 26 LIQ_BRANDY 27 LIQ_AQAVIT 28 LIQ_SCHNAPPS 29 LIQ_ICEWINE 30 LIQ_AMONTILLADO 31 LIQ_SHERRY 32 LIQ_FRAMBOISE 33 LIQ_RUM 34 LIQ_CORDIAL 35

**note: LIQUID VALUES greater than 35 ARE A PROBLEM..do NOT use any liquid value except 0-15 in your drink containers, unless you are writing for a mud that has values higher than 35. Madrom liquid values are 0-35.

Cheers to Satin, of Tesseract, who brewed up the last 20 liquid types, above.

Value lines for all the various OBJECT TYPES follow:

format -

**note: if a value is shown to be 'unused', place a zero, '0', for that value. DO NOT skip it or leave it blank.

ITEM_PORTAL: <# of charges>

ITEM_LIGHT: <HOURS OF LGT. AVAILABLE 0=dead, 999=infinite

ITEM_EXPLOSIVE:

ITEM_SCROLL:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

**note: spell lvl is the level at which the spell will be cast, NOT the level of the reader of the scroll.

**note: 'sn' stands for SPELL NUMBER; this is the number unique to that particular spell in the game. If you are an immortal with the 'vnum' command, you can type 'vnum spell ' to get this number. If not, ask an immortal for the spell number of a particular spell you may be thinking of using for a potion, scroll, wand, staff, or pill in your #OBJECTS section.

ITEM_WAND:

ITEM_STAFF:

ITEM_WEAPON: <# damage dice>

ITEM_TREASURE:

ITEM_ARMOR:

ITEM_POTION:

**note: Potions, pills and scrolls can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values. Try to use all 3 slots though, it makes the pill more interesting :)

ITEM_PILL:

**note: Potions and pills can have up to 3 spells in them. If you use only 1 or 2, put a zero for each of the unused values.

ITEM_FURNITURE:

**note: the benches in Southern Midgaard are an example of a furniture object... they basically just sit there.

ITEM_TRASH:

ITEM_SINGING < -1 > < -1 > < -1 > < -1 > < -1 >

ITEM_CONTAINER:

**note: Use the Container FLAGS listed earlier for this value; the key vnum is ONLY USED if there is a key to unlock the container - otherwise put a zero for that value.

ITEM_DRINK_CONTAINER: <0 <---note: if this value is a NON-ZERO number, the drink is poisoned>

**note: Use already existing drink containers in the game to get an idea as to a reasonable liquid capacity. For example, the water skin for sale at the Grocers Shop in Midgaard has a liquid capacity of 20. Additionally, the 'liquid #' value here tells whether it is beer, water, ale, etc., that is in the container. I have provided a listing above of the liquid numbers found in the 'liq_table' in the const.c section of the mud code. Liqid # MUST be one of 0 through 15.

ITEM_KEY:

ITEM_FOOD: * note if this ^^^^^^^ value is 1, food is poison. ITEM_MONEY:

ITEM_BOAT:

ITEM_FOUNTAIN:

ITEM_MAP: < 1 >

V. The #ROOMS section: This section should be fairly self-explanatory. Here is an example of a room from the #ROOMS section of an area:

22203

Rock Carving~ You scramble through this mountain pass, the frightening stony walls reaching to the sky on either side of you. A powerful, eerie wind whips the air into a frenzy about you. Cut into the rock face is an imposing, monolithic statue of a long forgotten king. You feel a sudden sense of uneasiness as you pass beneath his glowering, silent gaze. Ahead, to the north, an immense set of iron gates block further passage. The pass leads north beyond the gates, and back to the south. ~ 22 0 5 D0 A pass through tall iron gates. ~ gate~ 1 22012 22002 D2 A pass through the mountains. ~ ~ 0 -1 22004 E statue~ This impressive statue is a depiction of the ancient king, and now awesomely powerful God, Ozymandias. Bold of gaze and fierce of stature, this being is one you'd NOT like to cross if you ran into him. Brrr! ~ S

22204

Explanation of each line:

22203 <---

Rock Carving~ <--- You scramble through this mountain pass, the frightening stony walls reaching to the sky on either side of you. A powerful, eerie wind whips the air into a frenzy about you. Cut into the rock face is an imposing, monolithic statue of a long forgotten king. You feel a sudden sense of uneasiness as you pass beneath his glowering, silent gaze. Ahead, to the north, an immense set of iron gates block further passage. The pass leads north beyond the gates, and back to the south. ~ <--- 22 0 5 <--- D0 <--- A pass through tall, iron gates. ~ <--- tilde goes on next line, as here. gate~ <--- 1 22012 22002 <--- D2 <--- A pass through the mountains. <--- ~ ~ 0 -1 22004 <--- E <--- statue~ <--- This impressive statue is a depiction of the ancient king, and now awesomely powerful God, Ozymandias. Bold of gaze and fierce of stature, this being is one you'd NOT like to cross if you ran into him. Brrr! <--- ~ E <------ etaine sign~ <---- Ozymandias worships Etaine, or will till he sees how she's been messing in his document. <--- ~ S <--- the 'S' marks the end of the room. It is NOT optional.

22204 <---

Note: for Extended descriptions, EACH object/description must start with an E. eg if your room has a sign, chair and plaque, each extended description for these should start with its own individual E., just like the example above. :) The 'area number' is the first 2 digits of the area's vnum range..Hades is 22000 to 22whatever..the area number will be 22.

The 'room vnum' is the virtual number of the room.

The 'room name' is the name of the room.

The 'room description' is the long multi-line description of the room.

The 'area number' is obsolete and UNUSED. Rooms belong to whatever area was most recently defined in your #AREA section. The use of the number '0' for this value is adequate, since this value is unused.

The 'ROOM-FLAGS' describe more attributes of the room, and a listing of possible FLAGS is given at the end of the #ROOMS help section in this file.

The 'SECTOR-TYPE' identifies the type of terrain. This affects movement cost through the room. Certain sector types (AIR and WATER) require special capabilities to enter, i.e., a flying potion or spell for air, and a boat or raft for water.

Unlike mobiles and objects, rooms don't have any keywords associated with them. One may not manipulate a room in the same way one manipulates a mobile or object.

The optional 'D' sections and 'E' sections come after the main data. A 'D' section contains one or more 'doors' in the range from 0 to 5. The numbers represent the 6 possible directions. These direction values are given at the end of this #ROOMS section. A 'D' command also contains a 'description' for that direction, and 'keywords' for manipulating the door. 'Doors' include not just real doors, but ANY kind of exit from the room. The 'locks-number' defines whether or not the door is locked or not, and if it can be picked or not. The values for the 'locks-numbers' is given at the end of the #ROOMS section. The 'key-number' is the vnum of an object which locks and unlocks the door. IMPORTANT: If there is NO key for opening the door, either because the door is unlocked, is a simple, unhindered exit, or because you want a locked door with no key in the game, use '-1' for the 'key-number', NOT a '0'. Lastly, 'to_room-number' is the vnum of the room to which this door leads.

Unless you want a one-way exit, you must specify two 'D' sections, one for each side of the door; i.e., one leaving one room and one in the other room the door goes to. Otherwise, you will end up with a one-way exit.

An 'E' section (extended description) contains a 'keywords' string and a 'description' string. As you might guess, looking at one of the words in the 'keywords' yields the 'description' string.

The 'S' at the end marks the end of the room. IT IS NOT OPTIONAL.

**IMPORTANT!! When your #ROOMS sections is complete, to end the

ROOMS section, you must put '#0' on the line after the 'S' line

of the last room in the #ROOMS section of your area.

Direction Values for the 'D' section:

NORTH 0 EAST 1 SOUTH 2 WEST 3 UP 4 DOWN 5

Locks-numbers Values for the 'D' section:

Unhindered exit 0 Door with no keyhole -1 Normal door 1 Pick-proof door 2 Pass proof door 3 Pick and passproof door 4

note: a 'hidden' exit that doesn't show in when players type 'exit' is made by flagging your exit to be a door or flag 1.

ROOM-FLAGS:

ROOM_DARK (A) ROOM_NO_SUMMIN (B) ROOM_NO_MOB (C) ROOM_INDOORS (D) ROOM_NO_SUMMOUT (E) ROOM_PRIVATE (J) ROOM_SAFE (K) ROOM_SOLITARY (L) ROOM_PET_SHOP (M) ROOM_NO_RECALL (N) ROOM_IMP_ONLY (O) ROOM_GODS_ONLY (P) ROOM_HEROES_ONLY (Q) ROOM_NEWBIES_ONLY (R) ROOM_LAW (S)

SECTOR-TYPES:

SECT_INSIDE 0 SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 SECT_WATER_NOSWIM 7 SECT_AIR 9 SECT_DESERT 10 SECT_MAX 11

VI. The #RESETS section:

This is the section that installs all the mobiles in their various locations, equips the mobiles, locks and closes any necessary doors, randomizes any random room exits, and generally sets up the area and populates it.

To reset an area, the server executes each command in the list of reset commands once. Each area is reset once when the server loads, and again periodically as it ages. An area is reset if it is at least 3 area-minutes old and is empty of players, or if it is 15 area-minutes old and has players in it.

An 'area-minute' varies between 30 and 90 seconds of real time, with an average of 60 seconds. The variation defeats area time- keepers.

The #RESETS section contains a series of single lines.

The reset commands are:

  • comment M read a mobile O read an object P put an object in an object (gold in a safe, etc.) G give an object to mobile E equip object to mobile D set state of door R randomize room exits S stop (END OF LIST)

Here is the format for the various reset commands:

M

For the 'unused' value, simply put a '0'. The mobile-vnum is the vnum of the mobile loaded. The limit-number is the limit of how many of this mobile may be present in the world. The last number, the room-vnum, is the vnum of the room where the mobile is loaded.

O

For the 'unused' value, simply put a '0'. The object-vnum is the vnum of the object loaded. If you want more than one of these objects loaded into the room at one time, make it load twice by putting it twice in resets (or more). The last number, the room-vnum, is the vnum of the room where the object is loaded.

P

The number is the number (amount) of the first object that is placed into another object (i.e., a desk, coffer, safe, etc.). The object-vnum is the vnum of the object loaded. To make more than one of the same item load into a container, load it twice (or more) in the resets. The limit-number is the limit of how many of these objects may be present in the world, or 'put' into the other object. The game will load a coffer, for example, a certain amount of times. After that, the coffer will always be empty, until another reboot. The last number, the 'in_object-vnum', is the vnum of the object into which the other object is placed, i.e., the actual container (safe, desk, etc.).

G

For the 'G' command, there is no fourth number. Only use three numbers. The 'G' command MUST follow an 'M' command, as it 'gives' the object to the whatever mobile in a 'M' command is above it. Note the reason for this is due to the fact that no mobile-vnum is listed in the 'G' command. The first number is the number (amount) of this particular object to be given to the mobile. The object- vnum is the vnum of the object given. The limit-number is the amount of times this object will be 'given' to the mobile. I.E., the Calico cat from the Mage Tower area of ROM2 (and other muds as well...) has a spiked collar that is only loaded on the cat at the start of the game, at a reboot. After that, the cat has no collar, until another reboot. It is often a good idea to limit the number of objects in this manner to be given or equipped on a mobile, unless the object is relatively low level. If you wish one item to be given to the mob per AREA RESET, make the limit number a -1. If you are Giving items to a shopkeeper, make the (limit number) -1.

E

The first number is the number (amount) of an object equipped on the mobile. The object-vnum is just that. The limit number is the same as in the 'G' command (see above). The 'wear_loc-number' is the wear location that the object is equipped on the mobile's body. A listing of the wear_loc values is given at the end of this

RESETS help section.

D

For the 'unused' value, simply put a '0'. The room-vnum is the vnum of the room that the door IS IN. The door-number is just that; i.e., 0=north, 1=west, 2=south, etc. (see the help section for #ROOMS, above). The last number, the 'state-number', is the "state" of the door (whether it is open, closed, locked, etc.). A listing for the 'state-number' values is provided at the end of the

RESETS helps section.

R

For the 'R' command, there are only three values, and the first value is always 0 as it is unused. The second number is the vnum of a room. The third number is a last_door-number. When this command is used, the doors from 0 to the indicated 'last_door- number' are shuffled. The room will still have the same exits leading to the same other rooms as before, the DIRECTIONS will be different at each reboot. Thus, a last_door-number of 4 makes a two-dimensional maze room; a door number of 6 makes a three- dimensional maze room.

Use of both the 'D' and 'R' commands on the same room will yield UNPREDICTABLE results, so take care how you utilize the 'R' command.

Any line (except an 'S' line) may have a comment at the end.

**NOTES: IMPORTANT!: End the #RESETS section in your area with an 'S' on the line after the last reset command, much the same as you do for the

ROOMS section.

For the 'P' command, the actual container used is the MOST RECENTLY loaded object with the right vnum; for best results, there should be only one such container in the world. The is not loaded if no container object exists, or if someone is carrying it, or if it already contains on of the to-be-loaded objects.

Remember, for all LIMIT-NUMBERS, a '-1' means an infinite number of the objects, mobiles, etc. can exist in the world, and the game will keep loading up these objects/mobiles. Keep this in mind, if you are thinking of using a '-1' for a limit-number.

For the 'E' and 'G' command, if the most recent 'M' command succeeded (e.g. the mobile limit wasn't exceeded), the object is given to that mobile. If the most recent 'M' command FAILED (due to hitting mobile limit), then the object is not loaded.

Also remember, EACH MOBILE in your area (not just each type) must be loaded with the 'M' command. For example, if you have 20 cityguards total wandering about your town, you must do 20 reset lines of the 'M' command; for cityguard 1, cityguard 2, cityguard 3, etc., through cityguard 20. You can see how writing the #RESETS section of your area can rapidly become tiresome, but try to take extra care with this section, as it is easy to make a small typo, and these are a pain to debug if you end up with numerous reset errors!

IMPORTANT!!: For the 'D' command: ROOM EXITS MUST BE COHERENT! If room 1 had an exit East going to room 2, and room 2 has an exit in the reverse direction (West), that exit MUST GO BACK to room 1. This doesn't prevent one-way exits; room 2 doesn't HAVE to have an exit in the reverse direction.

EXAMPLE: The following is an example of several of the above reset commands as they appear in the area Midgaard. Use these to see how #RESETS works (note: this example, while taken from the Midgaard.are file

RESETS section, it is not in the same order as in the actual file,

as only a small part of that section is represented below, just to give you an idea of the various reset commands, and how they should appear):

RESETS

* * -- northern Midgaard -- <--- Comments are useful in keeping * track of your reset commands. M 0 3011 1 3001 Hassan E 1 3005 1 16 wield scimitar * M 0 3060 12 3004 Cityguard 1 E 1 3365 -1 0 equip banner E 1 3364 -1 1 equip signet ring E 1 3350 -1 16 equip sword E 1 3353 -1 5 equip vest E 1 3355 -1 4 equip cloak * M 0 3060 12 3014 Cityguard 2 E 1 3365 -1 0 equip banner E 1 3364 -1 1 equip signet ring E 1 3350 -1 16 equip sword E 1 3353 -1 5 equip vest E 1 3356 -1 6 equip helmet * M 0 3064 3 3007 A Happy Drunk (at Inn) M 0 3065 2 3044 A Beggar in poor alley M 0 3065 2 3048 A Beggar in Grubby Inn * M 0 3012 1 3054 Healer in temple altar * M 0 3100 1 3106 Maid in Park Cafe G 1 3100 -1 A cup of tea G 1 3101 -1 A cup of coffee G 1 3102 -1 A cup of water * O 0 3135 1 3141 load Fountain on Penny Lane O 0 3136 1 3141 load 20 coins on Penny Lane * O 0 3130 1 3142 load the desk P 1 3123 1 3130 put brass key in desk O 0 3131 1 3142 load the safe P 1 3132 1 3131 put money in safe * O 0 3010 1 3054 load Donation pit * D 0 3110 3 2 Lock Captain's door from outside D 0 3142 1 2 Lock Captain's door from inside D 0 3142 2 2 Lock jail from outside D 0 3143 0 2 Lock jail from inside * S <---- REMEMBER: end the #RESETS section with an 'S'.

Wear_loc Values for the 'E' reset command:

WEAR_NONE -1 WEAR_LIGHT 0 WEAR_FINGER_L 1 WEAR_FINGER_R 2 WEAR_NECK_1 3 WEAR_NECK_2 4 WEAR_BODY 5 WEAR_HEAD 6 WEAR_LEGS 7 WEAR_FEET 8 WEAR_HANDS 9 WEAR_ARMS 10 WEAR_SHIELD 11 WEAR_ABOUT 12 WEAR_WAIST 13 WEAR_WRIST_L 14 WEAR_WRIST_R 15 WEAR_WIELD 16 WEAR_HOLD 17 MAX_WEAR 18

VII. The #SHOPS section: If you intend on having shops in your area, then you will need a

SHOPS section. This section, in fact, is the easiest of all the

sections in an area to do, and takes very little time.

First, I'll provide an example from the midgaard.are area file of some of the shops from Midgaard's #SHOPS section:

SHOPS

3000 2 3 4 10 0 105 15 0 23 ; The Wizard 3001 0 0 0 0 0 110 100 0 23 ; The Baker 3002 1 8 13 15 19 150 40 0 23 ; The Grocer 3003 5 0 0 0 0 130 40 0 23 ; The Weaponsmith 3004 9 0 0 0 0 100 50 0 23 ; The Armourer 3006 22 0 0 0 0 120 90 6 22 ; The Captain

The syntax of the #SHOPS is as follows:

The first value, the mobile-vnum, is the 'keeper', or the mobile who is the shopkeeper. ALL MOBILES with that vnum will be shopkeepers.

The trade-0 through trade-4 are item types which the shopkeeper will buy. Unused slots should have a '0' in them'; for instance, a shopkeeper who doesn't buy anything would have five zeroes. The item types are the same values from the #OBJECTS section, in the OBJECT TYPE table. I am providing this table again, for this purpose, at the end of this #SHOPS help section.

The 'profit-buy' number is a markup for players buying the item, in percentage points. 100 is nominal price; 150 is 50% markup, and so on. The 'profit-sell' number is a markdown for players selling the item, in percentage points. 100 is nominal price, 75 is 25% markdown, and so on. The buying markup should be at least 100, generally greater, and the selling markdown should be no more than 100, generally lower.

The 'open-hour' and 'close-hour' numbers define the hours when the shopkeeper will do business. For a 24-hour shop, these numbers would be 0 and 23.

Everything beyond 'close-hour' to the end of the line is taken to be a comment.

Note that there is no room number for a shop. Just load the shopkeeper mobile in to the room of your choice, via that #RESETS section, and make the mobile a sentinel in the ACT-FLAGS section of the mobile in #MOBILES. Or, for a wandering shopkeeper, just make it non-sentinel.

The objects the shopkeeper sells are exactly those loaded by the 'G' reset command in #RESETS for that shopkeeper. These items replenish automatically. If a player sells an object to a shopkeeper, the shopkeeper will keep it for resale if he, she, or it doesn't already have an identical object. The items a player sells to a shopkeeper, however, do not replenish.

**IMPORTANT!!: You end your #SHOPS section with a '0' on the line after the last shop.

OBJECT TYPES (items a shopkeeper will buy from player):

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 ITEM_PORTAL 30 ITEM_EXPLOSIVE 31

**note: In general, when designing a mobile as a shopkeeper in the

MOBILES section, you should make him/her IMMUNE to all forms of

attack by having the mobile immune to magic, disease, poison, and weapons using the IMM_BITS in the immunities section of the mob in

MOBILES. Also, it is generally a good idea to make these mobiles

NOPURGE by having an 'ACT_FLAG' of ACT_NOPURGE for the mobile in the #MOBILES section. After all, you don't want your players killing the shopkeepers, or a purge-happy immortal accidentally purging the shopkeeper with a purge command.

VIII. The #SPECIALS section:

Like the #RESETS section, the #SPECIALS section has one command per line.

This section defines special functions (spec-fun's) for mobiles. A spec-fun is a C function which gives additional behavior to all mobiles with a given vnum, such as the peripatetic mayor, the beholder casting spells in combat, Tiamat the dragon breathing her breath weapons in combat, and the Grand Mistress teleporting characters she is fighting.

The 'M' command assigns 'spec-fun' to all mobiles of that vnum. An 'M' line may have a comment at the end.

Every three seconds, the server function 'mobile_update' examines every mobile in the game. If the mobile has an associated spec- fun, then 'mobile_update' calls that spec=fun with a single parameter, the 'ch' pointer for that mob. The spec-fun returns TRUE if the mobile did something, or FALSE if it did not. If the spec-fun returns TRUE, then further activity by that mobile is suppressed. All this just basically means that the game checks periodically for mobiles with spec-fun's and causes them to act out their assigned functions, either while wandering about Midgaard and locking the gates, as the mayor does, or while in combat and casting spells and breath weapons, as Tiamat, or the Beholder do.

For this help file, I am not including material on how to add a NEW special function to the code. That information can be found elsewhere, and needs to be coded by the IMP into the 'C' code itself. However, below you can see how to use ALREADY existing spec-funs for your mobiles. I have also provided a listing of the spec-funs available in the game so far.

**NOTE: As spec_fun's DO add (much more than other things) to lag in the game, try NOT to OVER DO IT. Feel free to use a #SPECIALS section, but don't make 100 different dragon or spell-casting type mobiles each with special functions!

Example of #SPECIALS, as found in midgaard.are area file:

SPECIALS

M 3000 spec_cast_mage M 3005 spec_thief M 3011 spec_executioner M 3012 spec_cast_adept M 3020 spec_cast_mage M 3060 spec_guard M 3061 spec_janitor M 3062 spec_fido M 3143 spec_mayor

Explanation:

SPECIALS <--- this begins the #SPECIALS section

M 3000 spec_cast_mage <--- Midgaard's wizard M 3005 spec_thief <--- the thief M 3011 spec_executioner <--- Hassan M 3012 spec_cast_adept <--- the Healer M 3020 spec_cast_mage <--- the Mage Guildmaster M 3060 spec_guard <--- cityguard M 3061 spec_janitor <--- the janitor M 3062 spec_fido <--- the fido M 3143 spec_mayor <--- Midgaard's Mayor M 6102 spec_wolf <--- does what it says :)

The syntax is simple, and is as follows: M The mobile vnum is the vnum of the mobile with that particular special function.

List of SPEC-FUN's found in the ROM2 code:

spec_breath_any spec_breath_acid spec_breath_fire spec_breath_frost spec_breath_gas spec_breath_lightning

spec_cast_adept spec_cast_cleric spec_cast_judge spec_cast_mage spec_cast_undead

spec_executioner spec_fido spec_guard spec_janitor spec_mayor spec_poison spec_thief spec_puff spec_wolf spec_batmad spec_smart (by Amiga and coded by Neuromancer..a very cool special)

The spec_breath's are just that. Breath weapons, such as found with most dragons, many of the gods in Olympus, etc.

The spec_cast's give mobiles the abilities to cast spells, depending on which spec_cast you use. To satisfy your own curiosity, I am including a listing of what each spec_cast type will cast, depending on the level of the mobile.

spec_cast_adept spells: The spec_cast_adept mobile will cast the following spells at random on all characters in the same room, up to characters of level 10 or less (this may have been changed; but this was correct with the Rom2 code): armor bless cure blindness cure light cure poison refresh

spec_cast_cleric spells: The spells cast depend on the level of the mobile with this special function. (Thus, if you wish to have a cleric-spell casting mobile that can cast 'curse', make the mobile at least level 12). The following can be cast by this spec-fun: blindness - min. lvl. 0 cause serious - min. lvl. 3 earthquake - min. lvl. 7 cause critical - min. lvl. 9 dispel evil - min. lvl. 10 curse - min. lvl. 12 change sex - min. lvl. 12 flamestrike - min. lvl. 13 harm - min. lvl. 15 plague - min. lvl. 15 dispel magic - min. lvl. 16

spec_cast_judge: This spec-fun is geared mainly for the Judge mobile in Megacity One. The only spell cast by this spec-fun is 'high explosive'.

spec_cast_mage: The spells cast depend on the level of the mobile with this special function. The following can be cast by this spec-fun: blindness - min. lvl. 0 chill touch - min. lvl. 3 weaken - min. lvl. 7 teleport - min. lvl. 8 colour spray - min. lvl. 11 change sex - min. lvl. 12 energy drain - min. lvl. 13 fireball - min. lvl. 15 plague - min. lvl. 20 acid blast - min. lvl. 20

spec_cast_undead: The spells cast depend on the level of the mobile with this special function. The following can be cast by this spec-fun: curse - min. lvl. 0 weaken - min. lvl. 3 chill touch - min. lvl. 6 blindness - min. lvl. 9 poison - min. lvl. 12 energy drain - min. lvl. 15 harm - min. lvl. 18 plague - min. lvl. 20 teleport - min. lvl. 21

As far as the other spec-fun's go, here is a rough breakdown, just to give you and idea what each does:

spec_fun_executioner: This spec-fun is more useful if you have player stealing and player killing capabilities in the mud. The mobile with this special- function will attack any player, including an immortal, with a KILLER, or THIEF flag. Additionally, this mobile can 'create' additional cityguards in the room to assist his fight against the player.

spec_fun_puff: This amusing special function, written by Seth, of Rivers of Mud, does a number of very silly things, most of which you are probably familiar and therefore I won't go into detail.

spec_fun_fido: This is a spec-fun customized for the fido mobiles of Midgaard. All it really does is cause the mobile to eat any corpse it may see lying in the room with it; players in the room will witness this in the form of " savagely devours a corpse."

spec_fun_guard: This special-function acts in some ways like the spec_fun_executioner. It causes the mobile to attack characters automatically that have the KILLER or THIEF flags, if player stealing and player killing is allowed in the mud. Also, the spec_fun_guard will intervene in a fight, assisting the 'most evil' of the fighters, alignment-wise. This means that a good character fighting an evil mob will often be joined in his/her/it's fight by the spec_fun_guard mobile, and visa-versa for an evil character attacking good mobiles in the presence of a spec_fun_guard mobile. This assisting is always accompanied by the mobile yelling "PROTECT THE INNOCENT!! BANZAI!!"

spec_fun_janitor: This spec-fun causes the mobile to pick up "trash" (objects that are either ITEM_DRINK_CON, or ITEM_TRASH on the ground in the same room as the mobile).

spec_fun_mayor: This is geared originally for the mayor of Midgaard. It adds a bit of humor and personality to the charismatic mayor. Basically, the mobile with this special function wanders around, making comments such as "Vandals! Youngsters have no respect for anything!", and other statements, as well as going to sleep, waking up, touring Midgaard, and opening and closing the gates of Midgaard at various times.

spec_poison: A mobile with the spec_fun_poison will, when fighting a player, 'bite' the player, and thus poisoning him with a 'poison spell'. This is a good spec-fun to give to poison snakes, etc., or any other mobile that might have a poison bite.

spec_fun_thief: This spec-fun causes the mobile to "steal" money from a player in the same room as the mobile. The player also receives a "You discover 's hand's in your wallet!" when this happens to the him/her/it.

spec_wolf Any monster with this special lurks and prowls and howls to all in the area during the night hours.

spec_batmad Any creature with this special will shrivel up and die if the daylight washes over it.

spec_smart This special gives the monster with it the abilities to spell himself up with protection spells, and keep them fresh, as well as undo maladiction spells cast at him AND then turn around and cast them back at his attacker..he also has abilities that a monster with spec_cast_cleric would have...a very evil monster special, use it only for specially hard qwest mobs, temple or tribe room guardians, etc... this special by Amiga and Neuromancer.

IX. The #$ section: This section marks the end of an area file. If you concentrate several area files into one, remember to delete the terminating '#$' from all but the last file. Conversely, if you split area files, remember to terminate EACH NEW FILE with a '#$'.

The syntax of this section is:

$

X. COMPILATION OF THE TABLES FOR AREA BUILDING: To make it simple to check values on all the multitude of tables for the various flags, etc. used in area building, I am listing again ALL the tables of values from ALL the different area sections, from #MOBILES to #SPECIALS:


 for #MOBILES:

ACT FLAGS:

ACT_IS_NPC (A) <-- Auto set for mobs ACT_SENTINEL (B) <-- stays in one room ACT_SCAVENGER (C) <-- picks up objects ACT_AGGRESSIVE (F) <-- attacks PC's ACT_STAY_AREA (G) <-- Won't leave area

ACT_WIMPY (H) <-- will flee if hp gets too low ACT_PET (I) <-- Auto set for pets ACT_TRAIN (J) <-- can train PC's ACT_PRACTICE (K) <-- can practice PC's ACT_UNDEAD (O)

ACT_CLERIC (Q) ACT_MAGE (R) ACT_THIEF (S) ACT_WARRIOR (T) ACT_NOALIGN (U)

ACT_NOPURGE (V) <-- will not be purged by purge command ACT_IS_HEALER (a) <-- acts as a healer ACT_GAIN (b) <-- PC's can use 'gain' command at this mobile ACT_UPDATE_ALWAYS (c)

RACES:

human dragon elf dwarf orc giant unique

Mobile Size:

T = tiny S = small M = medium L = large H = huge G = giant

Affected_by FLAGS:

AFF_BLIND (A) AFF_INVISIBLE (B) AFF_DETECT_EVIL (C) AFF_DETECT_INVIS (D) AFF_DETECT_MAGIC (E)

AFF_DETECT_HIDDEN (F) AFF_SANCTUARY (H) AFF_FAERIE_FIRE (I) AFF_INFRARED (J) AFF_CURSE (K)

AFF_POISON (M) AFF_PROTECT (N) AFF_SNEAK (P) AFF_HIDE (Q) AFF_SLEEP (R)

AFF_CHARM (S) AFF_FLYING (T) AFF_PASS_DOOR (U) AFF_HASTE (V) AFF_CALM (W)

AFF_PLAGUE (X) AFF_WEAKEN (Y) AFF_DARK_VISION (Z) AFF_BERSERK (a) AFF_SWIM (b) AFF_REGENERATION (c)

OFF_BITS:

OFF_AREA_ATTACK (A) OFF_BACKSTAB (B) OFF_BASH (C) OFF_BERSERK (D) OFF_DISARM (E)

OFF_DODGE (F) OFF_FADE (G) OFF_FAST (H) OFF_KICK (I) OFF_KICK_DIRT (J)

OFF_PARRY (K) OFF_RESCUE (L) OFF_TAIL (M) OFF_TRIP (N) OFF_CRUSH (O)

Note: these are also part of Off_bits. ASSIST_ALL (P) ASSIST_ALIGN (Q) ASSIST_RACE (R) ASSIST_PLAYERS (S) ASSIST_GUARD (T) ASSIST_VNUM (U)

IMMUNITIES - IMM bits for mobiles:

IMM_SUMMON (A) IMM_CHARM (B) IMM_MAGIC (C) IMM_WEAPON (D) IMM_BASH (E)

IMM_PIERCE (F) IMM_SLASH (G) IMM_FIRE (H) IMM_COLD (I) IMM_LIGHTNING (J)

IMM_ACID (K) IMM_POISON (L) IMM_NEGATIVE (M) IMM_HOLY (N) IMM_ENERGY (O)

IMM_MENTAL (P) IMM_DISEASE (Q) IMM_DROWNING (R) IMM_LIGHT (S)

RESISTANCES - RES bits for mobiles:

RES_CHARM (B) RES_MAGIC (C) RES_WEAPON (D) RES_BASH (E) RES_PIERCE (F)

RES_SLASH (G) RES_FIRE (H) RES_COLD (I) RES_LIGHTNING (J) RES_ACID (K)

RES_POISON (L) RES_NEGATIVE (M) RES_HOLY (N) RES_ENERGY (O) RES_MENTAL (P)

RES_DISEASE (Q) RES_DROWNING (R) RES_LIGHT (S)

VULNERABILITIES - VULN bits for mobiles:

VULN_MAGIC (C) VULN_WEAPON (D) VULN_BASH (E) VULN_PIERCE (F) VULN_SLASH (G)

VULN_FIRE (H) VULN_COLD (I) VULN_LIGHTNING (J) VULN_ACID (K) VULN_POISON (L)

VULN_NEGATIVE (M) VULN_HOLY (N) VULN_ENERGY (O) VULN_MENTAL (P) VULN_DISEASE (Q)

VULN_DROWNING (R) VULN_LIGHT (S) VULN_WOOD (X) VULN_SILVER (Y) VULN_IRON (Z)

POSITIONS:

POS_DEAD 0 <--- POS_MORTAL 1 <--- POS_INCAP 2 <--- POS_STUNNED 3 <--- these 4 positions not used.

POS_SLEEPING 4 POS_RESTING 5 POS_SITTING 6 POS_FIGHTING 7 <---* this position also not used. POS_STANDING 8

SEX of mobile:

NEUTRAL 0 MALE 1 FEMALE 2

DAMAGE TYPES (these values also used for weapons in #OBJECTS):

0 - HIT 1 - SLICE 2 - STAB 3 - SLASH 4 - WHIP 5 - CLAW

6 - BLAST 7 - POUND 8 - CRUSH 9 - GREP 10 - BITE 11 - PIERCE 12 - SUCTION 13 - BEATING 14 - DIGESTION 15 - CHARGE 16 - SLAP 17 - PUNCH 18 - WRATH 19 - MAGIC 20 - DIVINE POWER 21 - CLEAVE 22 - SCRATCH 23 - PECK (pierce) 24 - PECK (bash) 25 - CHOP 26 - STING 27 - SMASH 28 - SHOCKING BITE 29 - FLAMING BITE 30 - FREEZING BITE 31 - ACIDIC BITE 32 - CHOMP


 for #OBJECTS

Common Materials for the 'material' section:

  • cloth
  • leather
  • pill
  • paper
  • vellum
  • glass
  • wood
  • steel
  • bronze
  • brass
  • iron
  • gold
  • silver
  • adamantite
  • stone

OBJECT TYPES:

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_FOUNTAIN 25 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29 ITEM_PORTAL 30 ITEM_EXPLOSIVE 31

Object FLAGS:

ITEM_GLOW (A) ITEM_HUM (B) ITEM_DARK (C) ITEM_LOCK (D) ITEM_EVIL (E) ITEM_INVIS (F) ITEM_MAGIC (G) ITEM_NODROP (H) ITEM_BLESS (I) ITEM_ANTI_GOOD (J) ITEM_ANTI_EVIL (K) ITEM_ANTI_NEUTRAL (L) ITEM_NOREMOVE (M) ITEM_INVENTORY (N) ITEM_NOPURGE (O) ITEM_ROT_DEATH (P) ITEM_VIS_DEATH (Q) ITEM_MELT_DROP (R) ITEM_FLOAT (S)

WEAR FLAGS:

ITEM_TAKE (A) ITEM_WEAR_FINGER (B) ITEM_WEAR_NECK (C) ITEM_WEAR_BODY (D) ITEM_WEAR_HEAD (E) ITEM_WEAR_LEGS (F) ITEM_WEAR_FEET (G) ITEM_WEAR_HANDS (H) ITEM_WEAR_ARMS (I) ITEM_WEAR_SHIELD (J) ITEM_WEAR_ABOUT (K) ITEM_WEAR_WAIST (L) ITEM_WEAR_WRIST (M) ITEM_WIELD (N) ITEM_HOLD (O)

WEAPON CLASS:

WEAPON_EXOTIC 0 WEAPON_SWORD 1 WEAPON_DAGGER 2 WEAPON_SPEAR 3 WEAPON_MACE 4 WEAPON_AXE 5 WEAPON_FLAIL 6 WEAPON_WHIP 7 WEAPON_POLEARM 8

WEAPON TYPES:

WEAPON_FLAMING (A) WEAPON_FROST (B) WEAPON_VAMPIRIC (C) WEAPON_SHARP (D) WEAPON_VORPAL (E) WEAPON_TWO_HANDS (F)

APPLY TYPES (for the 'A' section of #OBJECTS):

APPLY_STR 1 APPLY_DEX 2 APPLY_INT 3 APPLY_WIS 4 APPLY_CON 5 APPLY_SEX 6 APPLY_CLASS 7 APPLY_LEVEL 8 APPLY_AGE 9 APPLY_HEIGHT 10 APPLY_WEIGHT 11 APPLY_MANA 12 APPLY_HIT 13 APPLY_MOVE 14 APPLY_GOLD 15 APPLY_EXP 16 APPLY_AC 17 APPLY_HITROLL 18 APPLY_DAMROLL 19 APPLY_SAVING_PARA 20 APPLY_SAVING_ROD 21 APPLY_SAVING_PETRI 22 APPLY_SAVING_BREATH 23 APPLY_SAVING_SPELL 24

Container FLAGS (if OBJECT TYPE is container only):

CONT_CLOSEABLE 1 CONT_PICKPROOF 2 CONT_CLOSED 4 CONT_LOCKED 8

Portal GATE FLAGS

GATE_NORMAL_EXIT A enter/exit messages from portal are as if its a door GATE_NOCURSE B can enter portal even if cursed or in norecall room GATE_GOWITH C the portal goes with you GATE_BUGGY D small chance of sending you to a random room GATE_RANDOM E sends you to a random room on the mud GATE_RANDOMAREA F sends you to a random room in same area

PORTAL EXIT FLAGS

EX_ISDOOR A EX_CLOSED B EX_LOCKED C EX_PICKPROOF F EX_NOPASS G passproof

Liquid values for DRINK CONTAINERS (value2 on the value line):

LIQ_WATER 0 LIQ_BEER 1 LIQ_WINE 2 LIQ_ALE 3 LIQ_DARK_ALE 4 LIQ_WHISKEY 5 LIQ_LEMONADE 6 LIQ_FIREBREATHER 7 LIQ_LOCAL_SPECIALTY 8 LIQ_SLIME_MOLD_JUICE 9 LIQ_MILK 10 LIQ_TEA 11 LIQ_COFFEE 12 LIQ_BLOOD 13 LIQ_SALT_WATER 14 LIQ_COLA 15


 for #ROOMS

Direction Values for the 'D' section:

NORTH 0 EAST 1 SOUTH 2 WEST 3 UP 4 DOWN 5

Locks-numbers Values for the 'D' section:

Unhindered exit 0 Normal door 1 Pick-proof door 2 Passproof 3 Pick+pass-proof 4

ROOM-FLAGS:

ROOM_DARK (A) ROOM_NO_SUMMIN (B) ROOM_NO_MOB (C) ROOM_INDOORS (D) ROOM_NO_SUMMOUT (E) ROOM_PRIVATE (J) ROOM_SAFE (K) ROOM_SOLITARY (L) ROOM_PET_SHOP (M) ROOM_NO_RECALL (N) ROOM_IMP_ONLY (O) ROOM_GODS_ONLY (P) ROOM_HEROES_ONLY (Q) ROOM_NEWBIES_ONLY (R) ROOM_LAW (S)

SECTOR-TYPES:

SECT_INSIDE 0 SECT_CITY 1 SECT_FIELD 2 SECT_FOREST 3 SECT_HILLS 4 SECT_MOUNTAIN 5 SECT_WATER_SWIM 6 SECT_WATER_NOSWIM 7 SECT_AIR 9 SECT_DESERT 10 SECT_MAX 11


 for #RESETS

Wear_loc Values for the 'E' reset command:

WEAR_NONE -1 WEAR_LIGHT 0 WEAR_FINGER_L 1 WEAR_FINGER_R 2 WEAR_NECK_1 3 WEAR_NECK_2 4 WEAR_BODY 5 WEAR_HEAD 6 WEAR_LEGS 7 WEAR_FEET 8 WEAR_HANDS 9 WEAR_ARMS 10 WEAR_SHIELD 11 WEAR_ABOUT 12 WEAR_WAIST 13 WEAR_WRIST_L 14 WEAR_WRIST_R 15 WEAR_WIELD 16 WEAR_HOLD 17 MAX_WEAR 18


 for #SHOPS

OBJECT TYPES (items a shopkeeper will buy from player):

ITEM_LIGHT 1 ITEM_SCROLL 2 ITEM_WAND 3 ITEM_STAFF 4 ITEM_WEAPON 5 ITEM_TREASURE 8 ITEM_ARMOR 9 ITEM_POTION 10 ITEM_CLOTHING 11 ITEM_FURNITURE 12 ITEM_TRASH 13 ITEM_CONTAINER 15 ITEM_DRINK_CON 17 ITEM_KEY 18 ITEM_FOOD 19 ITEM_MONEY 20 ITEM_BOAT 22 ITEM_CORPSE_NPC 23 ITEM_PILL 26 ITEM_MAP 28 ITEM_SINGING 29


 for #SPECIALS

List of SPEC-FUN's found in the ROM2 code:

spec_breath_any spec_breath_acid spec_breath_fire spec_breath_frost spec_breath_gas spec_breath_lightning

spec_cast_adept spec_cast_cleric spec_cast_judge spec_cast_mage spec_cast_undead

spec_executioner spec_fido spec_guard spec_janitor spec_mayor spec_poison spec_thief spec_puff spec_wolf spec_batmad


This ends my area help file, and I hope that by thoroughly reading ALL the above information that you now feel confident in beginning your area building.

FINAL HINT: For the end of this help section, I would like to part with some advice to aid you in your building interesting and fun areas for players to delve into and explore. When writing the room descriptions, object descriptions, and mobile descriptions, MAKE THEM INTERESTING TO READ! No one likes to see room after room AFTER ROOM of something like "You have entered a large chamber. It is very dark in here.", or some such nonsense for your room descriptions. Vary EACH room description and spice it up with some CREATIVITY. After all, that is what you must enjoy, if you are considering building an area. Try to use this combination of variety, intelligence, and imagination in the building of your area. One of the greatest joys most players find while mudding is the exploration and discovery of new and interesting rooms, items, treasures, and monsters. For those of you familiar with TSR's Dungeons & Dragons, or similar roleplaying games, this creative use of description and atmosphere should be well-known to you. Otherwise, consider looking over other areas YOU like before beginning your own, and see how that area was done. But most of all, do not bore your players.

Also, keep in mind what level your area is geared for, and the type of characters/players that it may be geared for as well. For example, some areas may be constructed with fighter-types in mind, others maybe mainly for grouped characters, or magic-using characters (lots of weapon-resistant mobiles for example), or for people that like to explore and/or map out new areas, and even areas for characters that just like blood, slaughter, and 'kill kill kill!'. So decide exactly WHAT type of area you are building, and follow through with it. And most important, MAKE IT FUN and CHALLENGING for the players. Despite what some may say, no one likes to be given tons of treasure, gold, and magic-items with little or no struggle. Monty Hall areas grow quickly tiresome. So endeavor to make a well-rounded, cleverly constructed area for all to enjoy. - Ozymandias


ROM 2.4 Area Format Guide

Source: docs/manuals/rom24-area-format-guide.md

A. Last modification date

B. Credits

C. Basic format

D. Organization I. Area headers II. Numbering III. Mailing IV. A note about help files V. Potential errata

E. The area format breakdown 1. #AREA: (not sure) I. #AREA II. filename.are~ III. Area Name IV. {1 50} Builder Sample Area V. ZX00 ZX99

2.  #MOBILES
    I.  <vnum>
    II.     name list
    III.    short description
    IV.     long description
    V.  look description
    VI.     race
    VII.  Act, Affect, Alignment and group
    VIII.   Level, hit bonus, hit dice, mana dice, damage, damtype
    IX. Armor classes
    X.  Offenses, Immunities, Resistances, Vulnerabilites
    XI. Positions, Gender and Treasure
    XII.    Form, Parts, Size and Material

3.  #OBJECTS
    I.    <vnum>
    II.   <object_name>
    III.  <object_short>
    IV.   <object_long>
    V.    <description>
    VI.   <material>
    VII.  Flags, Extras, Wear locations
    VIII.   V0 through V4
    IX.   <level> <weight> <cost>
    X.  <applies>
    XI.  <flags>
    XII.  Object extra descriptions

4.  #ROOMS
    I.  #<vnum>
    II. <room header>
    III.  <room description>
    IV.   <room flags>
    V.    <exit direction>
    VI.   <extended description of what is seen in direction>
    VII.  <door keyword>
    VIII. <door state> <exit vnum> <key vnum>
    IX.   <extra descriptions>
    X.    Mana and hp recovery adjustments
    XI.   <S>

5.  #RESETS
    I.    M    load a mobile into a room
    II.   O    load an object into a room
    III.  P    put an object in an object (gold in a safe, etc.)
    IV.   G    give an object to mobile
    V.    E    equip an object to mobile
    VI.   D    set state of door
    VII.  S    stop (END OF LIST)

6.  #SHOPS
    <mob#> <items> <profit-buy> <p-sell> <op-hour> <close>

7.  #SPECIALS
    M <mobvnum> <special>

8.  #$  -- closing the area file

F. Definitions 1. vnum 2. warpstone 3. trash 4. pickproof 5. dice 6. mobile 7. jukebox

G. Closing notes

A. Last modification date

Rom 2.4/2.5 docs version 1, compiled by Satin (Gabrielle Taylor) 7-9-1995.

Don't forget to look for appendices dated past this document on the ftp site! There may be additional area-related code added in future Rom releases, and rather than force you to print out a whole new copy each time, a dated appendix will be placed on this ftp site.

B. Credits

This file contains material and information from the Merc release 2.1 Area help files (done by Furey, Hatchet, and Kahn), material from the Merc Diku Mud code itself, material and examples from various area files that are found in both ROM2 and MadROM, as well as coding material that was adapted and modified by Alander for ROM1 and ROM2, and later by Madman for MadROM. It also contains information from Alander written for ROM 2.3 and ROM2.4x, from Zump for Rom 2.4x, and information from The legacy builder guide by Ozymandias. It was compiled and rewritten by Satin for Tesseract (hypercube.org 9000), and then adapted by her to Rom 2.4x.

Many of my examples are drawn from Diku's Midgaard, and my example of a fountain is drawn from Conner's New Thalos area.

C. Basic Format An area file consists of 8 basic sections, as follows:

The area header: vital statistics for the area The mobiles: the stats and descriptions of all monsters in the area The objects: the stats and descriptions of all objects in the area The rooms: a listing of all rooms and exits in the area Area resets: instructions for loading/maintaining the area The shops: a listing of any shops that the area contains Specials: procedures to enchance the performance of mobiles

Areas may also include special notes and procedures, such as a help file, information on where on the area should be placed, and any special code that should be written to make the area work properly. This should be included outside the main body of the area, but within the same file.

D. Organization

I. The sections should all be contained in one large file, organized in the following manner (the file proto.are can be used as a template):

AREA

MOBILES

0

OBJECTS

0

ROOMS

0

RESETS

S

SHOPS

0

SPECIALS

S

$

II. Numbering

You will notice below that all these sections require numbers. For example, Hassan is mobile #1203, and the temple of Midgaard is room

3001. To make your area as simple to add as possible, number your

files as follows:

XX00-XX99 (1st 100 of anything) XY00-XY99 (2nd 100 of anything) And so on. Thus, your mobile, object, and world files should ALL begin with XX00 as the first entry.

III. mailing

If you are on a unix system, please use the following protocol for mailing your area: ([name] is the name of the area, preferably a short one, i.e. shire.are or chapel.are.

If you have gzip: gzip [name] uuencode [name].gz [name].gz | mail target@address (make SURE you type the name twice here)

Otherwise use compress and the .Z suffix (instead of .gz).

If you can't compress your area and it is over 100k, make sure the person you are mailing it to can handle receiving large files.

IV. A note about help files

It used to be possible to include help files in areas. However, it is now preferred that the help file be sent in a separate file for inclusion in another file set aside specifically for helps.

V.

If you notice anything wrong or confusing in these docs, please mail me at gtaylor@pacinfo.com, and I will attempt to explain the confusion or correct the error -- these docs weren't exactly banged out overnight, but pretty damn close. :)

E. The area format

  1. AREA:

I. #AREA II. filename.are~ III. Area Name~ IV. {1 50} Builder Sample Area~ V. ZX00 ZX99

Breakdown:

I. #AREA is the signifier that the code uses to mark the beginning of a zone.

II. Select an appropriately unique filename for your area to be saved as. Keep it short -- for instance, if your area is titled 'The Dell of the Darkness' an appropriate name is darkdell.are. Do not forget to close with a tilde.

III. Type in the area name here as you expect it to appear when the 'area' command is typed, plus a closing tilde.

IV. This is the line that will appear in the 'area' command. The numbers in brackets signify the minimum and maximum levels that a player character should be before venturing into the area. Insert the area author's name in the spot labeled 'Builder' above, and the area name where the example says 'Sample Area'. Do not forget to close with a tilde.

V. This is the virtual number (vnum) range your area is using. You must declare a range from 0 to 99 here even if you don't use that many numbers, or a range from 0 to 199 if you use more than 100, etc. Use a placeholder or variable such as 'ZX' instead of a specific range unless you have been assigned a range by the implementor of the mud you are writing for.

  1. MOBILES

I. II. name list~ III. short description~ IV. long description ~ V. look description ~ VI. race~ VII. VIII. <+ to hit> IX. X. XI. XII.

example mobile:

ZX01

Sample~ Sample~ A sample mobile is here, waiting for a face. ~ It looks bland and boring, and like it belongs nowhere near an area file, but is a good example of a mobile. ~ human~ ABTV CDFJVZ 1000 3000 45 30 1d1+3999 1d1+499 5d4+40 crush -25 -25 -25 -15 ACDEFHIKLNOT ABP CD 0 stand stand either 0 0 0 medium 0

Breakdown:

I. The vnum is the number used to reference your mobile. There may only be one mobile of any given vnum at one time. (see definitions)

II. name list~ This is a list of names that the mobile can be referenced by, for example a fat, ugly worm might have a name list of: fat worm~ It's best to have more than one name per mobile. Don't forget the ~ at the end of the line.

III. short description~ The short description is seen when the mobile fights or performs actions, i.e. "The large orc". It should be kept fairly short, preferably 20 characters or less. Don't forget the ~ at the end of the line.

IV. long description~ The long description is seen whenever a character looks at the room a mobile is in (provided, of course, that they can see the mobile in question). Example: The large orc peers suspiciously at you. ~ Ideally it should be one line in length, but in some cases two line or longer long descriptions are justified. Be sure to put a ~ BELOW the description (not at the end of the line).

V. look description~ This is the equivalent of a character's description, and is seen when you look at a mobile. It can be as long as you like, but 1-5 lines is probably best. Try and make it at least a little descriptive, players should feel rewarded for looking at a mobile. Be sure to put a ~ BELOW the description (not at the end of the line).

VI. race~ Every mobile should have a race, whether it be goblin, orc, troll, or whatever. See the list below for races that already exist. If you feel your race is sufficiently distinct to merit creation of a new one, include a note containing the abilities the race should have to the implementor you are working with. Do not forget to put a ~ at the end of the line.

The following is a list of acceptable races on Tesseract. Your mileage on other muds may vary.

bat affect flags: flying, dark vision offensive flags: dodge, fast vulnerabilities: light form: edible, animal, mammal parts: ACDEFHJKP

bear offensive flags: crush, disarm, berserk resistances: bash, cold form: edible, animal, mammal parts: ABCDEFHJKUV

cat affect flags: dark vision offensive flags: fast, dodge form: edible, animal, mammal parts: ACDEFHJKQUV

centipede affect flags: dark vision resistances: pierce, cold vulnerabilities: bash form: edible, poison, animal, insect parts: ACK

dog offensive flags: fast form: edible, animal, mammal parts: ACDEFHJKUVo

doll immunities: cold, poison, holy, negative, mental, disease, drowning resistances: bash, light vulnerabilities: slash, fire, acid, lightning, energy form: other, construct, biped, cold-blooded parts: ABCGHK

dragon (NPC dragons will typically have some flags stripped) affect flags: infravision, flying resistances: fire, bash vulnerabilities: pierce, cold form: edible, sentient, dragon parts: ACDEFGHIJKPQUVX

dwarf affect flags: infravision resistances: poison, disease vulnerabilities: drowning form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

elf affect flags: infravision resistances: charm vulnerabilities: iron form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

fido offensive flags: dodge, assist race vulnerabilities: magic form: edible, poison, animal, mammal parts: ACDEFHJKQV

fox affect flags: dark vision offensive flags: fast, dodge form: edible, animal, mammal parts: ACDEFHJKQV

giant resistances: fire, cold vulnerabilities: mental, lightning form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

goblin affect flags: infravision resistances: disease vulnerabilities: magic form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

hobgoblin affect flags: infravision resistances: disease, poison form: edible, sentient, biped, mammal parts: ABCDEFGHIJKY

human form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

kobold affect flags: infravision resistances: poison vulnerabilities: magic form: edible, poison, sentient, biped, mammal parts: ABCDEFGHIJKQ

lizard resistances: poison vulnerabilities: cold form: edible, animal, reptile, cold-blooded parts: ACDEFHKQV

modron affect flags: infravision offensive flags: assist race, assist alignment immunities: charm, disease, mental, holy, negative resistances: fire, cold, acid form: sentient parts: ABCGHJK

orc affect flags: infravision resistances: disease vulnerabilities: light form: edible, sentient, biped, mammal parts: ABCDEFGHIJK

pig form: edible, animal, mammal parts: ACDEFHJK

rabbit offensive flags: dodge, fast form: edible, animal, mammal parts: ACDEFHJK

school monster action flags: no alignment immunities: charm, summon vulnerabilities: magic form: edible, biped, mammal parts: ABCDEFHJKQU

snake resistances: poison vulnerabilities: cold form: edible, animal, reptile, snake, cold-blooded parts: ADEFKLQVX

song bird affect flags: flying offensive flags: fast, dodge form: edible, animal, bird parts: ACDEFHKP

troll affect flags: regeneration, infravision, detect hidden offensive flags: berserk resistances: charm, bash vulnerabilities: fire, acid form: edible, poison, sentient, biped, mammal parts: ABCDEFGHIJKUV

water fowl affect flags: swim, flying resistances: drowning form: edible, animal, bird parts: ACDEFHKP

wolf affect flags: dark vision offensive flags: fast, dodge form: edible, animal, mammal parts: ACDEFJQV

wyvern affect flags: flying, detect invisible, detect hidden offensive flags: bash, fast, dodge immunities: poison vulnerabilities: light form: edible, poison, animal, dragon parts: ACDEFHJKQVX

VII. Act, Affects, Aggression, Alignment, Mobile group

Act flags (short for "action") determine the in-game behavior of your mobile. Input all of the flags you have chosen into the proper mobile section (as shown in the examples above). Following is a listing of act flags:

A NPC Mobile is an NPC (set automatically by the game) B sentinel Mobile doesn't wander C scavenger Mobile picks up items on the floor F aggressive Mobile attacks any character in the same room (see the section dealing with aggression) G stay area Mobile will not leave a zone (this should be set) H wimpy Mobile will fly when badly hurt J pet Mobile is a pet (and hence safe from attack) K train Mobile can train statistics O undead Mobile has special undead powers (i.e. life draining) Q cleric Mobile has cleric casting powers R mage Mobile has mage casting powers S thief Mobile has thief combat skills (backstab, etc.) T warrior Mobile has warrior combat skills (disarm, parry, etc.) U noalign Mobile is unaligned (unintelligent animals, golems, etc.) V nopurge Mobile isn't removed by the purge command W outdoors Mobile will not wander outside a building Y indoors Mobile will not wander into a building a healer Mobile can heal characters (i.e. the heal command) b gain Mobile can grant new skills (i.e. the gain command) c update Mobile is always updated, even in idle zones (rarely needed) d changer Mobile can change coins (i.e. Otho the Money Changer)

Affect Flags Affect flags are used to assign various spell and spell-like effects to a mobile, such as sanctuary, hidden, or detections. The following list contains all usable affect flags:

B invisible Mobile is invisible C detect evil Mobile can sense evil D detect invis Mobile can see invisible. ** E detect magic Mobile can see magic F detect hide Mobile can see hidden (sneaking/hiding) characters G detect good Mobile can sense good H sanctuary Mobile is protected by a sanctuary spell. ** I faerie fire Mobile is surrounded by faerie fire (a hindrance) J infravision Mobile can see heat sources in the dark N protect evil Mobile takes less damage from evil characters O protect good Mobile takes less damage from good characters P sneaking Mobile is sneaking (hard to detect while moving) Q hiding Mobile is hiding (cannot be seen without detect hidden) T flying Mobile is flying U pass door Mobile can walk through closed doors V haste Mobile is affected by a haste spell Z dark vision Mobile can see in the dark without a light source b swimming Mobile is swimming (or capable of swimming) c regeneration Mobile recovers hit points and mana faster than usual

** Sanctuary and detect invisible are often overused, so please be careful with them. Not every mobile should be able to see invisible, or the spell is worthless, and similarly not every hard mobile should have a sanctuary spell.

Example: a glowing ghost might have faerie fire, flying, and protect good, for an affect flag of IOT. There is no limit to the number of affect flags that may be set on a mobile, but be sure not to type the same letter twice.

Alignment Alignment is a number between -1000 and 1000, meant to represent the ethos of your creature. -1000 is irredeemably evil, 1000 is saintly. All but the most extreme monsters should fall between -500 and 500, and in particular it is hard to justify any low-level mobiles having extreme alignment.

Mobile Group The mobile is used to group mobiles into allied groups. They are assigned by XXYY, where XX is your zone number (for Midgaard 30) and YY is some increasing number (so Midgaard's groups will be 3000, 3001, etc.). Any mobile in the same group as another mobile will assist it in combat. The actual number has no real meaning, but please use the numbering system above so that each area keeps unique grouping.

VIII. Level, Hit bonus, Hit dice, Mana dice, Damage, Damage type: (See the appendix at the end of the documentation for details on recommended values depending on the mobile level)

Level This is a very important statistic, as it determines the recommended values for your mobile's combat abilities. Try and make the level choice reasonable to believe. Just as a level 2 Ancient Blue Wyrm makes no sense, neither does a level 50 snail. Look over the recommended values for the level and please try to stay fairly close to them, otherwise your mobile may well be out of balance with the others in the game.

Hit bonus This statistic is normally 0, but in mobiles with exceptional (and I do mean exceptional) combat abilities it may be higher. Clumsy mobiles may deserve a -1 or -2.

Hit dice Hit dice are expressed as ndn+n (so many d-whatevers + a bonus). Consult the recommended mobile values to get a rough idea how many hit points your mobile should have. The hit points will determine how much raw damage your monster can take before expiring. For a fixed quantity of hit points enter it as x+1d1: i.e., for 100 hps, 1d1+99.

Mana dice Mana dice are expressed as ndn+n. Consult the recommended mobile values to get a rough idea how much mana your mobile should have. This value will determine how many spells your mobile can cast in a combat (non-spellcasters have a mana value as well, as their mana can be tapped by the energy drain spell). Note that the mana value is not currently used, but mobiles WILL in future use it (and therefore be able to run out of it) so don't forget to define this section.

Damage The damaging power of a mobile is expressed as ndn+n, just like hit points and mana. It is very important to stay close to the values recommended, in particular where the damage bonus is concerned, or the mobile's balance will be skewed.

Damage Types A mobile's damage type defines three things: what message is seen when it attacks in combat, what armor class is used to defend against the attack, and what type of resistance or vulnerability affects the damage received from the attack. The following damage types are supported, listed by the type of attack and the damage messaged sent (if a name follows the damage message, you should use that name in your area file, otherwise just use the message itself). If you can't find a damage type that fits your mobiles, by all means make a new one (but be sure to note that a new damage type was added and how it should be defined, or your mobile will not function properly!)

piercing attacks (pierce ac): bite pierce sting chomp scratch thrust peck stab

bashing attacks (bash ac): beating crush smash blast peck(peckb) suction pound punch thwack charge slap

slashing attacks (slash ac): claw grep slice cleave slash whip

acid attacks (magic ac): acidic bite (acbite) digestion slime

cold attacks (magic ac): chill freezing bite (frbite)

energy attacks (magic ac): magic wrath

fire attacks (magic ac): flame flaming bite (flbite)

holy attacks (magic ac): divine power (divine)

lightning attacks (magic ac): shock shocking bite(shbite)

negative attacks (magic ac): life drain (drain)

The acceptable kinds of damage (some with no damage messages as yet) are: bash disease light pierce drowning lightning slash energy mental acid fire negative charm harm poison cold holy sound

Harm, disease, and poison are generally used only on spells, but are included here on the outside chance that a mobile might need them.

This list is by no means exhaustive, so please feel free to expand it as your write your area.

IX. Armor Classes In order, the 4 armor class values for a mobile are piercing (i.e. daggers and spears), bashing (i.e. clubs, rocks), slashing (swords and axes), and magical (everything else). Usually the first three will be fairly close to each other (it's nice to have them be a little different, however), and the magical AC will be considerably weaker. Please adhere to the AC guidelines set out in the appendix dealing with recommended values for such.

X. Offensive flags, Vulnerabilities, Resistances and Immunities:

Offensive Flags Offensive flags control mobile behavior in combat -- allowing some variety in how your mobiles fight back against players. A typical mobile should have a few (2-3) attack abilities and one or none defensive abilities, more skilled mobiles may have more, but try not to make them too flexible.

The following offensive flags are available, although not all are currently active (please use them anyway if they are appropriate, as they will be enabled at some future date):

A area attack Mobile hits all characters fighting against it. Very powerful. B backstab Mobile can backstab to start a combat C bash Mobile can bash characters off their feet D berserk Mobile may go berserk in a fight E disarm Mobile can disarm without a weapon wielded F dodge Mobile dodges blows G fade* Mobile can fade "out of phase" to avoid blows H fast Mobile is faster than most others, so has extra attacks I kick Mobile can kick in combat for extra damage J kick dirt Mobile kicks dirt, blinding opponents K parry Mobile can parry without a weapon wielded L rescue Mobile may rescue allies in a fight M tail Mobile can legsweep with its tail or tentacles N trip Mobile trips in combat O crush* Mobile can crush opponents in its arms

  • not yet enabled ** warrior and thief mobs (see action bits) can disarm and parry with a weapon wielded automatically

Offensive flags also control the assisting behavior of a mobile, by using the following flags:

P all Mobile helps all other mobiles in combat Q align Mobile assists mobiles of like alignment R race Mobile will assist other mobiles of the same race S players Mobile will assist players (by race/alignment) T guard Mobile assists as a cityguard U vnum Mobile assists mobiles of the same number only

Assisting by race and vnum are by the far the most common assist types. Mobiles also assist mobiles in the same group, as defined by the group number.

Notes: The area attack and fast flags are quite powerful, and mustn't be overused. Only the most powerful mobiles should be capable of area attack, and only mobiles that really are faster than most should be fast. Proper assist flag setting can greatly enhance the cooperation within an area.

Example: An orc might have bash, kick, and kick dirt (it will probably be a warrior, so will parry and disarm if armed), and will assist by race and alignment, for an offensive flag of CIJQR. There is no limit to the number of offensive flags that may be set on a mobile, but be sure not to use the same letter twice.

Immunities, resistances, and vulnerabilities Mobiles have differing immunities, resistances, and vulnerabilites both to better explain certain creatures (i.e. dragons) and to make fighting them take a little more strategy than just mindlessly pumping out damage. Most normal mobiles probably won't have much in the way of these flags, so don't add flags without sound reason. It's important to make shopkeeper-type mobiles (as well as guild masters, healers, et cetera) immune to summon, charm, magic, and weapons (immunity flag ABCD) just to insure that they cannot be killed. Similarly, weak, low-level mobiles (goblins, for example) might be made vulnerable to magic just to accent their weakness. All three flags share the same fields, which are as follows:

A summon Summoning and gating magic B charm Charm spells (the beguiling spell group) C magic All magic (be very careful using this flag) D weapons All physical attacks (be very careful using this flag) E bash Blunt weapons F pierce Piercing weapons G slash Slashing weapons H Fire Flame and heat attacks and spells I Cold Cold and ice attacks and spells J Lightning Electrical attacks and spells K Acid Corrosive attacks and spells L Poison Venoms and toxic vapors M Negative Life draining attacks and spells, or unholy energies N Holy Holy or blessed attacks O Energy Generic magical force (i.e. magic missile) P Mental Mental attacks (such as a mind flayer's mind blasts) Q Disease Disease, from the common cold to the black death R Drowning Watery attacks and suffocation S Light Light-based attacks, whether blinding or cutting T Sound Sonic attacks and weapons, or deafening noises X Wood Wooden weapons and creatures Y Silver Silver or mithril weapons and creatures Z Iron Iron and steel weapons and creatures

Note: Resist the temptation to make "Achilles Heel" style mobiles, that is creatures that are immune (or almost immune) to all but a single attack type. Such mobiles are extremely boring to fight, and ultimately not very hard to defeat. Strive to make a balanced mobile, with no flags that aren't explainable by its nature.

Important Note: the two generic categories (weapon and magic) are merged with more specific flags, so that a mobile which is (for example) immune to magic but vulnerable to fire will take normal damage from fire.

Example: a fire demon might be immune to fire and negative energy (HM), resistant to mental attacks and weapons (DP), and vulnerable to holy attacks as well as cold (IN).

XI. Start position, Default position, Gender, Treasure

start and default position The start position is the position a mobile will be loaded in, the default position is the position it returns to after a fight. These are often the same, but a sleeping mobile (for example) is not likely to go back to sleep.

The acceptable positions are stand, sit, rest, and sleep.

sex Mobile sex (as in gender, mobiles don't reproduce) can be none, male, female, or either (either will be set randomly for each mobile of that type which is loaded). It has no real game effects, but does add color. It's a good idea to make generic mobiles (i.e. rabbits) sex 'either', just for variety.

treasure The average treasure carried by the mobile, in silver pieces. Most mobiles should carry no more than 100 coins per level, and usually much less unless they are supposed to be wealthy. Non-intelligent mobiles should usually have no treasure.

XII. Form, Part, Size, Material

Form flags

The forms flag is used to define a body form for your mobile, and also related data like what happens to its corpse when it dies, and whether or not it is edible. Much of the forms code is not yet implemented, but please be as thorough as possible when defining your mobile, as it will all be used at some future point in time. The acceptable flags for body form are as follows (use your best judgment to determine which flags should be mutually exclusive):

corpse-related flags:

A edible Mobile can be eaten B poison Mobile is poisonous when eaten (should also be edible) C magical Mobile's magic nature causes strange effects when eaten D vanishes Mobile vanishes after death (i.e. a wraith) E other* Mobile is not flesh and blood (defined by material type)

form-related flags: G animal Mobile is a "dumb" animal H sentient Mobile is capable of higher reasoning I undead Mobile is an undead, and not truly alive at all J construct Mobile is a magical construct, such as a golem K mist Mobile is a partially material mist L intangible Mobile is immaterial (like a ghost) M biped Mobile is bipedal (like a human) N centaur Mobile has a humanoid torso, but a beast's lower body O insect Mobile is an insect P spider Mobile is an arachnid Q crustacean Mobile is a crustacean (i.e. a crab or lobster) R worm Mobile is a worm, that is a tube-shaped invertebrate S blob Mobile is a formless blob (when used with mist, a cloud) V mammal Mobile is a mammal W bird Mobile is a bird X reptile Mobile is a reptile (and should be cold-blooded) Y snake Mobile is a snake (and should be a reptile) Z dragon Mobile is a dragon a amphibian Mobile is an amphibian (and should be able to swim) b fish Mobile is a fish (and should be able to swim) c cold blood Mobile is cold-blooded, cannot be seen with infravis.

  • Not yet implemented

parts flags The body parts flag is used to detail what limbs and organs a creature has, and currently has no game effect beyond determining what hits the ground when you kill a monster. In the future, body parts will also determine what can be worn by the creature in question, and possibly special attacks (i.e. the tail attack) that the mobile may do, so please do try to be thorough in describing your mobile's body parts. The following body parts are defined:

A head Mobile has a head B arms Mobile has arm(s) (usually assumed to be 2) C legs Mobile has leg(s) D heart Mobile has a heart E brains Mobile has brains (not all mobs with heads have brains) F guts Mobile has intestines G hands Mobile has hands capable of manipulating objects H feet Mobile has feet I fingers Mobile has fingers capable of wearing rings J ear Mobile has ear(s) K eye Mobile has eye(s) L tongue Mobile has a long tongue (like a lizard) M eyestalks Mobile has eyestalks (it should also have eyes) N tentacles Mobile has one or more tentacles O fins Mobile has fins P wings Mobile has wings Q tail Mobile has a usable tail (no stubs) U claws Mobile has combat-capable claws V fangs Mobile has combat-capable teeth W horns Mobile has horns, not necessarily dangerous ones X scales Mobile is covered with scales Y tusks Mobile has some teeth elongated into tusks

size The size of the mobile has many game effects, and should be chosen carefully. The acceptable sizes are as follows: tiny: small birds and anything smaller small: large birds (ducks and up) to halflings medium: elves and dwarves to humans large: ogres, gnolls, and other large humanoids huge: giants, small dragons, and wyverns giant: for VERY large critters, i.e. dragons, titans, and the biggest giants

material The material type for mobiles is not currently supported. It should be left blank (0) for flesh-and-blood creatures, or spirits, but golems and other animated beings should have a material appropriate to their body construction (i.e. stone, iron, diamond). Put the material in single quotes if it is longer than one word.

Appendix A: Recommended Values The following values should be followed closely for all mobiles -- try not to go more than 1 level away from the recommended values unless you are absolutely sure you want your mobile to be harder or easier than a default monster. In particular, avoid making them easier. Certain action flags (namely the 4 class-related flags) can modify the recommendations, they are explained in detail at the end of this section.

level hit pts ac damage level hit pts ac damage 1 2d6+10 9 1d4+0 31 6d12+928 -10 4d6+9 2 2d7+21 8 1d5+0 32 10d10+1000 -10 6d4+9 3 2d6+35 7 1d6+0 33 10d10+1100 -11 6d4+10 4 2d7+46 6 1d5+1 34 10d10+1200 -11 4d7+10 5 2d6+60 5 1d6+1 35 10d10+1300 -11 4d7+11

6 2d7+71 4 1d7+1 36 10d10+1400 -12 3d10+11 7 2d6+85 4 1d8+1 37 10d10+1500 -12 3d10+12 8 2d7+96 3 1d7+2 38 10d10+1600 -13 5d6+12 9 2d6+110 2 1d8+2 39 15d10+1700 -13 5d6+13 10 2d7+121 1 2d4+2 40 15d10+1850 -13 4d8+13

11 2d8+134 1 1d10+2 41 25d10+2000 -14 4d8+14 12 2d10+150 0 1d10+3 42 25d10+2250 -14 3d12+14 13 2d10+170 -1 2d5+3 43 25d10+2500 -15 3d12+15 14 2d10+190 -1 1d12+3 44 25d10+2750 -15 8d4+15 15 3d9+208 -2 2d6+3 45 25d10+3000 -15 8d4+16

16 3d9+233 -2 2d6+4 46 25d10+3250 -16 6d6+16 17 3d9+258 -3 3d4+4 47 25d10+3500 -17 6d6+17 18 3d9+283 -3 2d7+4 48 25d10+3750 -18 6d6+18 19 3d9+308 -4 2d7+5 49 50d10+4000 -19 4d10+18 20 3d9+333 -4 2d8+5 50 50d10+4500 -20 5d8+19

21 4d10+360 -5 4d4+5 51 50d10+5000 -21 5d8+20 22 5d10+400 -5 4d4+6 52 50d10+5500 -22 6d7+20 23 5d10+450 -6 3d6+6 53 50d10+6000 -23 6d7+21 24 5d10+500 -6 2d10+6 54 50d10+6500 -24 7d6+22 25 5d10+550 -7 2d10+7 55 50d10+7000 -25 10d4+23

26 5d10+600 -7 3d7+7 56 50d10+7500 -26 10d4+24 27 5d10+650 -8 5d4+7 57 50d10+8000 -27 6d8+24 28 6d12+703 -8 2d12+8 58 50d10+8500 -28 5d10+25 29 6d12+778 -9 2d12+8 59 50d10+9000 -29 8d6+26 30 6d12+853 -9 4d6+8 60 50d10+9500 -30 8d6+28

Thief* mobiles should read their hp, ac, and damage at one level lower Mage mobiles read hp and ac at one level lower, and damage three levels lower Cleric mobiles read damage at two levels lower Warrior mobiles read hit points one level higher Armor class vs. magical attacks should be computed by this formula: (ac - 10) / n + 10, where n is 4 for most mobiles, 3 for thieves and clerics, and 2 for mages.

Remember, +hit should only be given to very exceptional mobiles.

  • a thief mobile either has ACT_THIEF set or is decidedly thief-like in nature. The same holds true for the other modifiers.

Appendix B: Removing Flags There are times when a mobile will clearly belong to a certain race, but for whatever reason you will not it to have certain flags belonging to that race. For examples, dragons may normally be resistant to fire, but you may wish to make a white dragon that is vulnerable to fire and immune to cold. To remove flags from the mobile, add flag removal commands at the end of the entry (below the form/parts/size/material line).

The base syntax is: F

Flag type may be either action, affect, offensive, immunity, resistance, vulnerability, form, or parts ( usually just written as act, aff, off, imm, res, vul, for, and par).

For example, to make a dragon that is not vulnerable to cold or resistant to fire, use:

F res H F vul I

More than one flag can be removed on the same line, as long as they are all part of the same flag group. So to remove fast and dodge from a wolf, you would type:

F off FH

Don't be afraid to move flags if you have to, and absolutely do NOT define a new race just because a few of the default flags don't agree with you.

  1. OBJECTS

I. # II. ~ III. ~ IV. ~ V. ~ VI. VII. VIII. IX XI. **XII. ~ ~

  • varies by object type, may be nonexistent

** optional

Breakdown:

I. The vnum is the number used to reference your object. There may only be one object of any given vnum at one time. (see glossary)

II. This is a list of names by which the object may be referenced. Do not forget to put a tilde at the end of it.

III. This is the short description of the object. It is seen when the object is used, picked up or worn. Example: a short sword named 'Nightbringer', THE Long Sword, a scale mail coif, etc. Do not forget to put a tilde at the end.

IV. This is the description seen when the object is on the ground. Example: A short sword lies here on the ground.~ Do not forget to put a tilde at the end.

V. This is the substance of which the object is composed. Ie: a sword might have material steel~, or a cloak have material wool~. If you must define a new material type in your area, go ahead, but please make a note of this to the person you are submitting the area to. A listing of material types that are already defined follows:

plastic slime jelly wax rubber oil balm cream hard/soft leather kid leather fur snakeskin gut food meat bread wood hardwood softwood bamboo ebony cork horn light laen sponge elastic silk satin lace wool linen canvas cloth velvet felt paper parchment vellum hemp feathers webbing cardboard steel gold silver mithril platinum iron lead copper electrum bronze brass wire tin pewter metal dark laen porcelain ivory marble stone quartz corundum flint lodestone granite enamel obsidian adamantite glass pottery crystal ice bone shell coral energy fire air water acid coal sandstone clay ash earth diamond etherealness nothingness

dragonscale, blue dragonscale, black dragonscale, white dragonscale, red dragonscale.

Although you would normally have to place multiple words in single quotes, in this instance, do NOT. Do not forget to end the material type with a tilde.

VII. Type, Extras, Wear

Type Type determines what kind of object you are creating. A list of item types used by Rom 2.4x follows:

weapon armor container light food drink money wand staff potion scroll pill furniture portal innkey clothing *fountain key boat map warpstone treasure jewelry gem trash

  • indicates that the item has special values, examples of which will be given at the end of this section.

Many of the item types have no practical purpose aside from to control what shops they may be sold at. A jeweler might buy only jewelry, and not gems or treasure, for example.

V0 through V4

Items marked with an asterisk in the Item Types section have special values that must be given in the area file. Items not marked with an asterisk have no special settings and a 0 must be placed in each slot.

Example of an item with no special values:

3043

ring protection~ a ring of protection~ an enchanted ring of protection sits on the floor.~ silver~ treasure G AB 0 0 0 0 0 <-- vo through v4 slots held with zeroes 8 10 640 P

Examples follow, with explanation of what each special value denotes:

Weapon:

3005

scimitar blade~ Hassan's scimitar~ Hassan's scimitar lies upon the ground, waiting for its owner.~ adamantite~ weapon BI AN sword 4 10 cleave EF 42 450 5600 P E scimitar blade~ It is quite heavy. The blade is made of some metal that you can't even spell. The edge of the blade looks as if it could cut through anything or anyone. ~ For weapons, v0 is the weapon type (sword in the example), v1 is the number of dice (4 here), v2 is the number of sides each die has (10), v3 is the damage message (cleave) and v4 holds the weapon flags (E is vorpal, F is two-handed). Acceptable damage messages are listed in the mobiles section, and a listing of acceptable weapon flags follows:

  A   flaming     D  sharp      G  shocking (electrical)
  B   frost       E  vorpal     H  poisoned
  C   vampiric    F  two-handed
    (energy drain)

Armor:

3045

jacket scale mail~ a scale mail jacket~ A scale mail jacket is lying on the ground.~ steel~ armor 0 AD 3 4 4 0 2 5 160 850 G

V0 is armor vs. pierce, v1 is armor vs. bash, v2 is armor vs. slash, v3 is armor vs. exotic weapons, v4 is bulk. Bulk is currently unused by the code, but please enter it so that when it is implemented, your file will be current. A listing of example bulks follows:

clothing 0 buckler 0 hard leather 1 small shield 1 scale/chainmail 2 medium shield 2 platemail 3 kite shield 3 light plate armor 4 tower shield 4 heavy plate armor 5

Light:

3031

lantern~ a hooded brass lantern~ A hooded brass lantern has been left here.~ brass~ light 0 A 0 0 250 0 0 0 40 75 P E letters~ They say, "Use 'hold lantern' to activate." ~ E lantern~ It is a large and robust but somewhat battered oil lantern made from brass, equipped with a handle to make it handy and a hood to protect its flame. Some letters have been scratched on its bottom. ~

V0 and V1 are empty, held with a 0. V2 is light duration in game hours, (250 hours in this case). If V2 is set to -1 the light is permanent. V3 and V4 are empty and held with zeroes.

Money:

3132

silver coins~ the silver coins~ A lot of silver is here.~ silver~ money 0 A 1000 0 0 0 0 0 0 0 P E silver~ Looks like at least a thousand coins. ~

V0 is the silver value (in this case, 1000) of the money object. V1 is the gold value (remember that Rom 2.4x uses both silver and gold coins). V2, V3 and V4 are held with zeroes.

Drink containers:

3138

skin water buffalo~ a buffalo water skin~ A bloated dead buffalo is on the floor.~ leather~ drink 0 A 64 64 'water' 0 0 0 40 24 G

V0 is the maximum amount of liquid the container may hold (64 here). V1 is the current amount it holds (64 here, as the container is full, but it will decrease as the player drinks from it. You may also make half-full containers that may be filled up.) V2 is the type of liquid the container holds when it is loaded (water here). V3 has two settings: 0 for normal and A for poisoned. V4 is unused.

A listing of acceptable liquid types follows:

Name               Color        Proof  Hunger Thirst

water                  clear           0,   1,    10,
beer                   amber          12,   1,         8,
red wine               burgundy       30,   1,         8,
ale                    brown          15,   1,         8,
dark ale               dark           16,   1,         8,
whisky                 golden        120,   1,         5,
lemonade               pink            0,   1,         9,
firebreather           boiling       190,   0,         4,
local specialty        clear         151,   1,         3,
slime mold juice       green           0,   2,      -8,
milk                   white           0,   2,         9,
tea                    tan             0,   1,         8,
coffee                 black           0,   1,         8,
blood                  red             0,   2,      -1,
salt water             clear           0,   1,      -2,
coke                   brown           0,   2,         9,
root beer              brown           0,   2,         9,
elvish wine            green          35,   2,         8,
white wine             golden         28,   1,         8,
champagne              golden         32,   1,         8,
mead                   honey-colored  34,   2,         8,
rose wine              pink           26,   1,         8,
benedictine wine       burgundy       40,   1,         8,
vodka                  clear         130,   1,         5,
cranberry juice        red             0,   1,         9,
orange juice           orange          0,   2,         9,
absinthe               green         200,   1,         4,
brandy                 golden         80,   1,         5,
aquavit                clear         140,   1,         5,
schnapps               clear          90,   1,         5,
icewine                purple         50,   2,         6,
amontillado            burgundy       35,   2,         8,
sherry                 red            38,   2,         7,
framboise              red            50,   1,         7,
rum                    amber         151,   1,         4,
cordial                clear         100,   1,         5,

Fountains:

19 2

9601

fountain water~ a fountain~ A large fountain is here gurgling out an endless stream of water.~ marble~ fountain G 0 100000 100000 'water' 0 0 0 0 0 P

V0 and V1 for fountains are technically set the same as drink containers (max capacity and current capacity) but since a fountain holds an endless supply of liquid, usually V0 and V1 are set to some arbitrarily large number. Any number above zero should work fine. :) V2 is the type of liquid the fountain holds. Any liquid in the table associated with drink containers will work in a fountain. V3 and V4 are held with zeroes.

(And yes, you can have fountains of wine, or fountains of coffee :)

Wands and Staves:

3044

wand magic missile missiles~ a wand of magic missiles~ a wooden stick lies on the ground.~ wood~ wand G AO 4 10 10 'magic missile' 0 2 10 320 P E wand~ It has a little note that says 'point this end at target'. ~

Wands and staves have exactly the same v0-v4 formatting. V0 is spell level (the example wand having a 4th level magic missile), v1 is the maximum number of charges, v2 is the current number of charges (the mud will decrement the charge number as the wand is used, but you could also make a half-charged wand that could be refilled with the 'recharge' spell.) V3 is the spell name, which must be enclosed in quotes. V4 is unused and held with a zero.

Potions, Scrolls and Pills:

3241

potion yellow~ a yellow potion of see invisible~ A small yellow potion has carelessly been left here.~ glass~ potion G AO 12 'detect invis' '' '' '' 0 10 220 P E potion yellow~ The potion has a small label 'Detect The Invisible'. ~

V0 holds the level of the spell (this potion having a level 12 detect invisible spell in it). v1 through v4 hold the spells -- potions, scrolls and pills may have up to 4 spells in them. Should you not wish to have all four slots filled, use empty quotes (as shown in the above example, a potion with only one spell) as placeholders.

Containers:

3032

bag~ a bag~ A small bag.~ leather~ container 0 A 50 0 0 5 100 0 10 9 G

V0 holds the maximum weight that the container may store. V1 holds container flags, a list of which follows. V2 is unused. V3 holds the maximum weight of a given object that the container may store. (i.e.: the above bag may be able to hold 50 pounds, but the opening of the bag is so small that nothing larger than a 5 pound object can fit through it. The bag could then hold up to 10 5 pound objects, 50 1 pound objects, some combination thereof, or some other combination of weights.) V4 holds the weight multiplier of the container, which is a number that may not be less than 1.

A weight multiplier of 100 means that the objects, while inside the container, weigh 100% of their normal weight. If v4 were set to, for example, 75, the objects would weigh 75% of normal (a 100 pound object would have an effective weight of 75 pounds); if v4 were set to 125, objects would weigh 125% of normal (the 100 pound object would weigh 125 pounds). Be conservative with weight multipliers -- a container with, for example, a weight multiplier of 1% is an extremely powerful item!

Food:

3014

danish blueberry~ a blueberry danish~ A scrumptious blueberry danish is here.~ food~ food 0 A 8 6 0 0 0 0 10 5 P

V0 holds the number of game hours the food will keep the person who eats it full. V1 holds the number of hours it will keep the person from getting hungry. (Think of it as the distinction between food caloric value and food density -- pasta is both dense and high calorie, so the fullness and hunger values of a plate of linguine should be roughly the same -- whereas cotton candy as a high calorie value but a low density, so you can eat a lot more of it before you get full, but the sugar will keep you from feeling hungry.) V2 is unused and held with a zero. V3 is either 0 for normal or A for poisoned. V4 is unused.

Portals:

XX00

black hole~ a black hole~ A swirling black hole spins in the centre of the room.~ energy~ portal 0 0 0 0 0 0 P

V0 is the number of charges the portal has (for limited use portals) -- similar to how a wand or staff has charges. Set it to -1 for a permanent portal. V1 is exit flags -- see the section of #ROOMS dealing with doors for a listing of usable exit flags. V2 is gate flags, a listing of which is at the end of this example. V3 is the vnum of the room that the portal goes to. V4 is unused, and held with a zero.

Gate flags:

A Normal exit (should be set if no other portal flags are used) B No curse (can't be used by people who are cursed) C Go with (portal entrance moves with the person using it) D Gate buggy (chance it will teleport the person to a random room) E Random (will always teleport the person to a random room)

Furniture:

XX00

white wicker couch~ a white wicker couch~ A white wicker couch with pink cushions is tucked into a corner.~ wood~ furniture 0 0 2 200 BEHKN 100 100 0 0 0 P

V0 is the number of people that can fit onto the piece of furniture (in the case of the couch, 2 people). V1 is the total weight the piece of furniture can support (200 pounds here, meaning while in theory 2 people can sit on the couch, the people sitting on it can't weigh more than a total of 200 pounds). V2 is furniture flags, which determine the message to the room when the person uses the furniture in various different ways. The couch can be sat on, rested on, slept on, stood on, and have things put on it. However, a bathtub might be sit in, rest in, have no setting for sleep (sleeping in a bathtub is a bad idea) and allow things to be put in it -- hence the configurability on the messages. You can only flag the furniture with one of each type of message -- one sit, one rest, one sleep, one stand and one put -- and you don't have to use all of them, like I said in my bathtub example. V3 determines how much of a healing bonus or penalty the person receives for using the furniture -- look at the section dealing with heal/mana bonus/penalty under #ROOMS. V4 determines the mana recovery bonus or penalty. 100 is normal heal/mana recovery.

A list of furniture flags for V2 follows:

A Stand at B Stand on C Stand in D Sit at E Sit on F Sit in G Rest at H Rest on I Rest in J Sleep at K Sleep on L Sleep in M Put at N Put on O Put in P Put inside

(Note that the Put flags in furniture are not yet enabled, but please design your furniture using them anyhow, so that when the code is written, your area will be current to it.)

Extra flags

Extra flags are visual effects and other controls on how the object may be used. A listing of extra flags follows:

(Glowing) A (Humming) B Dark (hidden) C Evil E Invis F Magic G Nodrop H Bless I Anti-good J Anti-evil K Anti-Neutral L Noremove M Inventory N Nopurge O Rot_death P Vis_death Q Nosac R Nolocate T Melt_drop U Sell extract W Burn proof Y

Items with applies or other magical effects should be flagged magic. Anti-good/evil/neutral prevents the item from being worn by persons of those aligns -- you may mix and match two of three, but do NOT flag an item as unwearable by all three aligns, it will cause problems for the mud. Inventory should usually be present on items given to a shopkeeper, and NEVER on any other object. It ensures that the item never runs out in a shop. A shop item not flagged inventory will only be able to be sold once. Nopurge means that the 'purge' command cannot affect this item unless it is directly purged -- stationary objects like furniture should be flagged this. Rot death places a short timer on the object when the mobile carrying it dies and it disintegrates when the timer is up. Vis death means that the item is undetectable until after the mobile carrying it is dead. Nosac means the item cannot be sacrificed. Nolocate prevents locate object from finding the object. Melt drop means that the item dissolves when dropped (used for sub issue eq to prevent clutter). Sell extract ensures that the item will be purchased at the full value it was sold at (this should ONLY be used for gem stores where people may convert gold, which is very heavy, into more valuable and light gemstones). Burn proof makes the item invulnerable to damage by fire or acid.

Wear flags

Wear flags determine where an object may be worn. Note that if you want the item to be able to be picked up it should be flagged Take, AS WELL AS having a wear location flagged if the object should be worn. Leaving off a take flag but flagging it wearable will make it impossible to pick up the object should it be dropped. So to make a ring that can be picked up and worn on finger it should be flagged AB. Note that items can not have multiple wear locations (take does not count as a wear location, it only determines if the item can be picked up).

A Take H Hands O Hold B Finger I Arms Q Float C Neck J Shield D Body K About body E Head L Waist F Legs M Wrist G Feet N Wield

IX. Level, Weight, Cost

Level determines how high of level a character must be to use an item. Higher level items should be more powerful, and lower level correspondingly less powerful.

Weight determines how heavy an object is, which factors into how much a character may carry. It is entered into the area file as tenths of pounds, so a three pound dagger would have an entry of 30.

Cost determines how much an item may be sold to a shop for (although shops virtually always buy for less than they will sell at) or how much a shop will charge for it. When in doubt on an item sold in a shop, overprice it; when in doubt on an item that can be found in an area, underprice it.

The fourth slot on objects is timer, which is not implemented, and should be set to P. So far as I'm aware, setting it to anything other than P can cause the area to not boot.

XI. Applies

apply

Location is the type of affect being placed on the item. Modifier is a positive or negative number that will increase or decrease the location in question. A listing of locations follows:

1 Strength 12 Mana 2 Dexterity 13 Hitpoints 3 Intelligence 14 Movement 4 Wisdom 17 AC 5 Constitution 18 Hitroll 6 Sex 19 Damroll 7 Charisma 20 Spell (includes rods, staves, etc.)

example apply 1 1 apply 13 4 The above would be the pink ice ring's affects.

XII. Flags

flag

Flags let you put what are usually perm aff bits as well as immune/resist and vulnerability bits when wearing an item. Note that you may also specify a location here (or 0 if none) so that spells with two effects can be done (like a ring of haste would have a dex modifier in addition to the bit). A listing of affects follows:

affect bits: A Blind I Faerie_fire Q Hide Y Weaken B Invisible J Infrared R Sleep Z Dark_vis C Detect_evil K Curse S Charm a Berserk D Detect_invis L Flaming T Flying b Swim E Detect_magic M Poisoned U Pass_door c Regen. F Detect_hidden N Prot_evil V Haste d Slow G Detect_good O Prot_good W Calm H Sanctuary P Sneak *X Plague * items will be detrimental to the character, possibly for cursed items. ** not yet implemented

examples: flag affect 2 3 V dex+3 and AFF_HASTE flag affect 0 0 CDEFG a true sight item flag immune 0 0 CD immune to weapons and magic! :)

For obvious reasons, be VERY careful in creating permanent affected items. A permanent sanctuary item, for instance, would be of questionable balance and will likely be stripped from your area unless you have some extreme justification for it.

See the #MOBILES section for a listing of imm/resist/vul flags.

XIII. Extra descriptions.

E extra description~ Yep, this is an extra desc alright. ~

extra signifies the start of an extra description. 'extra description' are the keywords that 'examine' will accept. Typing 'examine extra' or 'examine description' would yield the output of 'Yep, this is an extra desc alright.'

For further examples, see the section dealing with extra descs in #ROOMS.

  1. ROOMS

II. The #ROOMS section

I. <#vnum> II. ~ III. ~ IV. {V. VI. ~ VII. VIII. } IX. ~ ~ X. *XI. XII.

  • denotes optional, not necessary for the room to function.

Sections that are enclosed in braces must be kept together, and placed in the order that the above example shows. Example: if there are doors north, south and west, all of three sets of door data must go before the extended description related information.

Example:

1000

The Lego temple~ You stand in a tiny, red temple; built entirely from Lego bricks. It is, sadly, not a very interesting place, and perhaps you should leave through the portal which leads south to a sunny garden. ~ 0 BC 0 D2 You see the grand portal of the Lego church. Beyond is an inviting garden. ~ portal grand~ 1 1001 1007 extra portal~ The portal is high and arched, built out of lego bricks of the finest quality. ~ extra brick~ The bricks are all in bright different colours. ~ M 110 H 90 S

1001

I. The vnum is the number used to reference your room. There may only be one room of any given vnum at one time. (see glossary)

II. This is the label of the room, and should be short. Characters with 'brief' mode on will only see this section of the room. Do not forget to end it with a tilde.

III. This is the room description. It should be a minimum of three lines, preferably at least four or five, but not more than eight to ten. (if you want more information than that, do it in extra descriptions) Do not forget to end it with a tilde.

IV. Room flags, sector types

The first slot of line IV is a hangover from old file format, retained for compatibility.

The second slot is room flags. A listing of room flags follows:

DARK (A) A light source must be carried to see in this room NO_MOB (C) Monsters cannot enter this room INDOORS (D) Room is inside (i.e. not affected by weather) PRIVATE (J) Room is limited to two characters (i.e. chat rooms) SAFE (K) Safe from pkilling and aggressive mobs SOLITARY (L) One character only can enter this room PET_SHOP (M) see addendum about pet shops NO_RECALL (N) players cannot use the 'recall' command to leave this room

Pet shops: the room that the pets are to be sold in must be flagged act_pet. However, the pets themselves must be loaded into the sequentially next room (ie if the shop is 1036, the pets MUST be loaded into 1037 for the shop to work).

The third slot is sector type. A listing of sector types follows:

Sector types:

type number move pts notes INSIDE 0 1 CITY 1 2 FIELD 2 2 FOREST 3 3 HILLS 4 4 MOUNTAIN 5 6 WATER 6 4 swimmable DEEP WATER 7 - boat required AIR 9 - fly spell required DESERT 10 9 will eventually affect thirst and recovery

V. Exit directions

Exit directions are signified by a line with D# on it, with # replaced by 0 for north, 1 for east, 2 for south, 3 for west, 4 for up and 5 for down. An exit line containing D2 signifies an exit south.

VI. Exit descriptions

This section determines what will be seen if a character looks in the direction the exit designates. Ie:

You see a river south.

Would be what would be seen if a character typed 'look south' and the above was the exit description. Do not forget to put a tilde on the line after. Ie:

You see a river south. ~

VII. Door keyphrase

If the exit you are working on is to be a door, you may define a keyphrase that the character may access to open the door and will see when he opens it. Ie:

D5 You see a dusty trap door. ~ trap door~

as the keyphrase will allow the character to type 'open trap' or 'open door' or 'open down' to open the entryway, and when they do, they will see the message: 'You open the trap door.'

VIII. Door state, Connecting room vnum, Key vnum

Slot one sets the door as open, closed, locked, etc. 0 denotes an open door, 1 denotes closed, and 2 denotes closed and locked.

Slot two denotes the vnum of the room that this exit links to.

Slot three denotes the vnum of the key used to unlock the door, if the door is lockable and if you choose to have a key that allows it to be unlocked.

IX. extra, extra keywords, and extra description text

E denotes the beginning of an extra description. Extras are used to flesh out room descriptions by giving keywords that may be looked at or examined to give more information. Also, to have multiple sets of extras, you must input all of the data under independent extra lines.

Example: in the following room description:

You stand under a trellis on which climb beautiful roses. A lovely flower garden extends to the north and west of here, and a path leads to a small white summerhouse to the south.

with the extended descriptions

E beautiful roses~ They smell sweet and are delicately soft to the touch. ~ E trellis~ It is made of wicker and painted white. ~

would yield the following result when 'exa beautiful', 'exa roses', 'look beautiful' or 'look roses' was typed:

They smell sweet and are delicately soft to the touch.

or the following if 'look trellis' or 'exa trellis' was typed:

It is made of wicker and painted white.

Do not forget to put a tilde after the keywords or the text.

X. Mana recovery adjustments, Healing recovery adjustments

The default recovery rate is 100% (normal). However, you may adjust recovery of mana or hit points up or down to 1% of normal or 200% of normal. To adjust mana, the syntax is M (ie: M 90 to decrease mana to 90% of normal recovery rate) or H to adjust hit point recovery (ie: H 110 to increase healing by 10%).

Example:

M 75 H 125

Note! Increasing healing or mana recovery is a room option that should be used very sparingly. Decrease of healing/mana recovery may be used more frequently.

XI. If your mud has clans, you may wish to have clan halls that are restricted from access by anyone who is not a member of that clan.

Example for a room for the hall of clan Moonstone:

clan Moonstone~

XII. S

S signifies the end of the room. All rooms MUST be ended with S.

  1. RESETS

This is the section that installs all the mobiles in their various locations,equips the mobiles, locks and closes any necessary doors, randomizes any random room exits, and generally sets up the area and populates it.

To reset an area, the server executes each command in the list of reset commands once. Each area is reset once when the server loads, and again periodically as it ages. An area is reset if it is at least 3 area- minutes old and is empty of players, or if it is 15 area-minutes old and has players in it.

An 'area-minute' varies between 30 and 90 seconds of real time, with an average of 60 seconds. The variation defeats area time-keepers.

The #RESETS section contains a series of single lines.

The reset commands are:

I. M load a mobile into a room II. O load an object into a room III. P put an object in an object (gold in a safe, etc.) IV. G give an object to mobile V. E equip an object to mobile VI. D set state of door VII. S stop (END OF LIST)

Note! You may put a comment after an asterisk (*) on any line, but NOT on a line that is blank otherwise.

Breakdown:

I. Loading a mobile into a room

M 0

M signifies that a mobile is being loaded. 0 is a placeholder for a no longer used field. The third slot is the vnum of the mobile to be loaded; the fourth slot is the number of the room that the mobile is being loaded into; the fifth slot is the total number of copies of that mobile that may exist in the game world; the sixth is the number of copies of that mobile that may exist in that room.

Example: M 0 1000 1000 6 1

Will reset mobile 1000 into room 1000 once, but allow you to place five other copies of that mobile in other rooms.

Note that if you wish to have multiple copies of the same mobile you must enter multiple resets for them. Example:

M 0 1000 1000 6 2 M 0 1000 1000 6 2

Will reset mobile 1000 into room 1000 twice.

II. Loading an object into a room

O 0 1000 0 1000

O 0 0

Breakdown:

O denotes that an object is being loaded. 0 in both instances is a placeholder for a defunct reset slot. The third slot is the object vnum and the fifth slot is the room it is being reset into. Ergo, the above example will reset object 1000 into room 1000.

That loads (O)bject ZX01 once into room ZX02. Again, 0 denotes unused.

III. Putting an object into another object:

P 0 1001 0 1000 3

P denotes that this reset is putting an object into another object. Both 0 entries denote placeholders for defunct slots. The third slot is the vnum of the object that is being contained, the fifth slot denotes the vnum of the container. The sixth slot denotes the number of copies of the object that will be loaded into the container. The above example will put 3 copies of object 1001 into container 1000.

Note! If you wish to have, for example, five mobiles carrying containers called 'backpacks' with 'bread' 'cheese' and 'water jug' items in them, and have an abandoned backpack with the same gear as would be in the carried backpacks, you are best off making a total of six individual 'backpack' containers and resetting the same 'bread', 'cheese' and 'water' items.

Let's try explaining that one again. :)

If you wish to have multiple copies of a container resetting with things being Put into them, you are in fact having several identical container objects with different vnums for the things to be put into. If you have six backpacks with bread, cheese and water resetting into them, after it finds the first backpack to place the items into, the mud sometimes becomes confused and misplaces items. If you have different containers, the mud will not become confused. We are not sure what causes containers to become confused, and doubtless this attempt at explanation is confusing, but hopefully you get the idea.

You may use the same items going into the containers but not the same container item. Get it? Good. :)

IV. Giving an object to a mobile

G 0 1006 0

G denotes that a give reset to a mobile is being done. This reset places the object being given into the inventory of the mobile. 0 denotes, as before, a placeholder for a defunct option. The third slot in the reset is the vnum of the object being given.

Note! The give reset MUST be placed, in the reset ordering, DIRECTLY after the loading of the mobile that the object is being given to. Example:

M 0 1000 1000 6 2 G 0 1006 0

V. Equipping an object to a mobile

E 0 1007 0 3

E denotes that an equip reset is being done. 0 denotes unused slots. The third slot indicates the vnum of the object being equipped. The fifth slot is the number of the wear location that is being equipped to (in this instance, 3, which is ).

Wear flags are as follows:

Left finger 1 Right finger 2 Neck (1) 3 Neck (2) 4 On Torso 5 Head 6 Legs 7 Feet 8 Hands 9 Arms 10 Shield 11 About body 12 Waist 13 Left Wrist 14 Right Wrist 15 Wield 16 Held 17 Floating 18

VI. Door resets

D 0 1000 1 BC

D denotes that a door reset is being generated. 0 denotes a placeholder for an unused slot. The third slot is the vnum of the room that the door reset is being generated in. The fourth slot is the direction of the door reset is being generated in (since any room may have up to six doors) and the fifth is the condition that the door is being placed in. The above example shows the eastern door of room 1000 being set in a closed and locked position. The following list shows the correlating numbers for the door directions:

0 North 1 East 2 South 3 West 4 Up 5 Down

The following is a list of door flags that may be used:

0 -- Normal exit, no door A -- door that may be opened and closed, but no lock and resets to open B -- door resets to closed C -- door that is locked F -- door with a lock that cannot be picked (key needed to open) G -- door that the 'pass door' spell will not allow passage through (the lock may still be picked, however) H -- lock that is easy to pick * I -- lock that is hard to pick * J -- lock that is infuriating to pick * K -- door that cannot be closed L -- door that cannot be locked

  • not yet implemented, but use them in conjunction with C (door resets to locked) for when the code is enabled.

So for a closed, locked door that can't be passed through but which is easy to pick, the flags are BCGH.

Note! If you have a door going north from room 1001 to room 1002, you must also have a door going south from room 1002 to room 1001, unless you wish the door in 1001 to be ONE WAY ONLY.

VII. Ending the resets:

S

S denotes the end of the #RESETS section.

Remember, for all LIMIT-NUMBERS, a '-1' means an infinite number of the objects, mobiles, etc. can exist in the world, and the game will keep loading up these objects/mobiles. Keep this in mind, if you are thinking of using a '-1' for a limit-number.

It's a good idea to comment your resets thoroughly for debugging purposes.

  1. SHOPS

0

Example:

3000 2 3 4 10 0 105 15 0 23 * the wizard

All of these options are on the same line. 0 ends the section.

The first value, the mobile-vnum, is the 'keeper', or the mobile who is the shopkeeper. ALL MOBILES with that vnum will be shopkeepers.

The section designates what the keeper will buy. He may buy up to five types of items, and zeroes must be placed in the shop entry for anything less than five. (The wizard above buys scrolls, wands, staves and potions, and a zero is placed in the last option since he only buys four types of things. If all the slots were set to zero, he wouldn't buy anything, but he would still sell what he was loaded as having.)

The following is a list of acceptable object numbers and their corresponding types:

1 Light 2 Scroll 3 Wand 4 Staff 5 Weapon 8 Treasure 9 Armor 10 Potion 11 Clothing 12 Furniture 15 Container 17 Drink container 22 Boat 26 Pill 28 Map 29 Portal 30 Warpstone 32 Gem 33 Jewelry

(Any item type not listed in the above is not listed either because it is not appropriate to have a shopkeeper that would buy that type of item, or because that type of item can't be sold (like money :).)

The 'profit-buy' number is a markup for players buying the item, in percentage points. 100 is nominal price; 150 is 50% markup, and so on. The 'profit-sell' number is a markdown for players selling the item, in percentage points. 100 is nominal price, 75 is 25% markdown, and so on. The buying markup should be at least 100, generally greater, and the selling markdown should be no more than 100, generally lower.

The 'open-hour' and 'close-hour' numbers define the hours when the shopkeeper will do business. For a 24-hour shop, these numbers would be 0 and 23.

Everything beyond 'close-hour' to the end of the line is taken to be a comment.

Note that there is no room number for a shop. Just load the shopkeeper mobile in to the room of your choice, via that #RESETS section, and make the mobile a sentinel in the ACT-FLAGS section of the mobile in #MOBILES. Or, for a wandering shopkeeper, just make it non-sentinel.

The objects the shopkeeper sells are exactly those loaded by the 'G' reset command in #RESETS for that shopkeeper. These items replenish automatically. If a player sells an object to a shopkeeper, the shopkeeper will keep it for resale if he, she, or it doesn't already have an identical object. The items a player sells to a shopkeeper, however, do not replenish.

Shopkeepers should generally be flagged as NO_PURGE.

  1. SPECIALS

M

example M 1000 breath_gas

Special procedures are not assigned in the mobile structure itself, but they do relate directly to mobiles. The procedure for assigning procedures will be detailed in another document, but the basic function is covered here.

A special procedure gives a mobile some added functionality, allowing it do more complicated actions than are normally possible. Examples are Hassan's guardian duties, the fido's ability to eat corpses, and the warring mobiles in the dangerous neighborhood. New specials can be requested, but don't rely on someone else being willing to code one for you. At this time, no mobile may have more than one special procedure.

The following specials are available:

breath_acid Mobile breathes acid in combat breath_fire Mobile breathes fire in combat (area attack) breath_frost Mobile breathes frost in combat (area attack) breath_gas Mobile breathes poison gas in combat area attack) breath_lightning Mobile breathes lightning in combat breath_any Mobile may use any breath weapon cast_adept Mobile casts helpful spells on low-level players cast_cleric Mobile casts clerical spells (ALWAYS cleric act flag) cast_judge Mobile fires bullets (for Mega-City One only) cast_mage Mobile casts mage spells (ALWAYS set the mage act flag) cast_undead Mobile casts spells appropriate for the undead executioner Mobile attacks Killers and Thieves fido Mobile devours corpses guard Mobile protects good-aligned people from attack janitor Mobile cleans up junk lying on the ground poison Mobile has a poison attack thief Mobile steals gold (ALWAYS set the thief act flag) nasty_thief Mobile attacks, robs, and runs (ALWAYS set thief flag)

The following specials are coded, but should NOT be used because they are tailored to specific mobiles. Check them out online for examples of unique or area-specific specials that can possibly be coded for your mobiles:

cast_judge Mobile fires bullets (for Mega-City One only) troll_member Mobile attacks ogre gang members (gangland mobs only) ogre_member Mobile attacks troll gang members (gangland mobs only) patrolman Mobile tries to break up fights (gangland mobs only) mayor The Midgaard mayor special (opens/closes city gates, etc.)

  1. Closing your area file:

The syntax to end the file is:

$

Be sure to put a couple of carriage returns at the end of the file.

F. Definitions

Vnum A vnum is a unique number used to identify a mobile, object or room. You can use the same vnum for a mob as for an object or for a room (since the code keeps track of them separately) but NOT for different mobs, objects or rooms.

Warpstone A component used in the portal and nexus spells. Further spell components will eventually be implemented. Keep them rare and NEVER describe an object in such a way as to suggest that it might be a warpstone. It should be indistinguishable from a normal gem or rock except by identifying it. Lore will eventually identify components (including warpstones) as such.

Trash Mobs will spec_janitor target trash as the first thing to pick up. It's the catch-all for objects that fall under no other categories.

Pickproof Immune to being picked with the pick lock spell.

Dice Role playing games commonly use dice of more or less than six sides for purpose of generating random numbers for damage, hit probability, etc. For example, 1d11 (not possible in real life, but possible in the game) would generate a value from 1 to 11. 2d4 would generate a range from 2 to 8. Usage of multiple dice generates a belled result where a range generates a linear one (for example, 2d4 averages 5, whereas a range from 1 to 8 averages 4.5).

Mobile or mob A being/monster within the game capable of the functions the area builder defines. Note that mobiles that have ACT_SENTINEL (stay in one place) aren't mobile per se, but why quibble? :)

Jukebox The jukebox will 'play' songs either in the room you are in or play them loud (over the MUSIC channel). Ask your implementor for a list of songs that the jukebox (if used on your mud) uses.

G. Closing Notes

Make your rooms direction insensitive unless there is only one exit. If a room has a south exit and a west exit, the line 'You enter through the southern door' is a bad line. However, if the southern door is the only entrance to the room, it's permissible. Also, if you are using one way doors, direction sensitivity is permissible.

Also, a room doesn't know if you've seen it before, so avoid lines like 'you gaze on the mighty mirror of Zenabit for the first time'.

Avoid putting sentiments into the mind of the reader. If the line has 'you think' in it, it's probably bad, since you don't know if that's really what they think. Try to convey things in another manner as to make them think what you want them to think.

Avoid pointless anachronism. It's tacky. Areas should have some internal logic, as well as logic to the rest of the world, instead of just being a lump of anachronism to provoke a titter the first time, and gradually to become tiresome. Strive for cleverness and wit instead.

Put in extra descriptions in rooms especially, but also on objects. It fleshes the area out more. Overdo extra descs rather than underdoing them.

Write utility linker rooms. If you have a long and winding road going up to the castle -- write at least a couple of road rooms. Be sure to say 'the castle to the north' and not 'the castle in front of you' since the person might have left it.

Write 'useless' objects for colour. If the princess is the sort to wear perfume, put some type furniture perfume in a type object vanity table that could be found if looked for. It too fleshes out the world. (Note that Satin wrote 600 useless objects for Cordreas Heart, but you don't have to be asthorough (read, insane) as her. ;)

If there's furniture in a room, write it as an object and load it there, so that it could be sat on/etc.

If you have no_take objects (such as the donation pit) or mobs that cannot be killed and are sentinel (shopkeepers, adepts, etc.) write them as normal objects/mobs, consider giving them no long description, just a ~, and describe them as part of the room, to blend them into the world more. If the mob can be killed, or the object taken, though, you should give it a long desc, since it might not be there.

Do NOT write descriptions of a mobile into the room description if you also load that mobile in the area. Do not do the following:

You are in a throne room. A huge gold throne with the king of the goblins sitting on it is in front of you. He cries out and several bodyguards attack!

Instead do:

You are in a throne room. A huge gold throne is immediately in front of you. Tapestries depicting the greatness of the ruler whose castle you have intruded hang on all walls. The king of the goblins is here. He cries for help! A bodyguard screams and attacks! A bodyguard screams and attacks! A bodyguard screams and attacks! A bodyguard screams and attacks!

NEVER write an area that is too easy, or that has absurdly powerful equipment, just to make it popular. Do not rely on a mobile being 'really tough' as the sole balance to an otherwise overpowered item -- people have soloed 30,000hp mobiles (admittedly, people with nothing better to do, but you get the idea). A well-balanced item (for example, the enchanted leather bracer) will ultimately earn popularity of its own right, and be less likely to be adjusted by a disgusted implementor who was tired of seeing people immort after spending a half day in your zone. Besides, then all the Real Studly Area Builders like Satin and Andersen will laugh at you. :)


MadROM VNUM Ranges

Source: docs/manuals/madrom-vnum-ranges.md

Arioch -- below this page, you'll see the list of areas and their vnum ranges this list indicates the vnum ranges that MadROM is already using, and so can't be used...also there are a couple ranges that are not being used now, but were used in the past (they are indicated below) so don't use those either... HOWEVER: use this list as a guideline only..for example, it might say that newthalos.are is vnum 200-250, but since this list was made, maybe I added some monsters or rooms, so now the range used is 200-260 but I forgot to update (i have updated it whenever i added a whole area, but not whenever i added 1 or 2 objects or monsters)

so..use this list as a guideline, then to see if you have room to add a new room, area, or monster into an existing area, go to the mud and try to load the object, monster or goto the room in the vnum range you are thinking of adding..eg if you are gonna add objects 2201 to 2206, try a 'load obj 2201' and 'load obj 2206' to see that its free.

if you are adding a whole new area, check this list to see the free vnums, then just to make sure check on the mud...eg if you are adding an area vnum range 300-399 (always give it a bit bigger range than it is when you add it, as you might want to add stuff to it later), first check here that 300-399 is free, if it is, test on the mud by doing a 'load obj 300' 'load obj 350' 'load obj 399' 'goto 300' goto 350' goto 399, and load mob 300, load mob 350, load mob 399...if none load or you get huh? when you try to goto the rooms, you can be pretty sure the vnum range is free...then just send me an update so i can update my list and you update your copy...

1-2                 limbo.are
3-100               -

101-129 smurf.are 130-299 - 300-345 plains.are 346-399 - 400-508 Daonima 509-549 - 550-599 Kull's Caverns 600-699 ofcol2.are 700-759 Lennyhouse off the mud 760-799 (range last used Sept/94) 800-900 strange.are 901-948 olympus.are 949-1000 - 1000-1040 air.are off the mud july/96 1041-1099 - 1100-1157 shire.are 1158-1199 - 1200-1231 immortal zone 1232-1299 immortal zone 1300-1399 hitower.are 1400-1483 hitower.are 1484-1500 - 1499 skylar's hideout 1501-1590 gnome.are 1591-1600 - 1601-1652 wyvern.are 1653-1700 - 1701-1717 wyvern.are (centaurs) 1718-1719 - 1720 some stray room (a path of some kind) 1721-1799 - 1800-1899 Sun.are Mithras 1900-1950 warp.are Mithras 1951-2000 - 2001-2069 catacomb.are 2070-2100 - 2101-2170 hood.are (gangland) 2171-2200 - 2201-2253 draconia.are 2254-2299 - 2300-2399 mahntor.are 2400 - 2401-2433 (snow filled lands) 2434-2499 - 2500-2599 woodstock.are 2600-2699 - 2700-2800 - 2801-2805 trollden.are (4 whole rooms?) 2806-2899 - 2900-2924 firenewt.are (off mud Sep 12?) 2925-2931 firenewt.are (do NOT use vnums) 2932-2999 - 3000-3054 midgaard.are (room_law starts at 3000) 3055-3099 midgaard.are 3100-3170 midgaard.are 3171-3199 midgaard.are 3200-3205 midgaard.are (river) 3206-3249 midgaard.are 3250-3273 midgaard.are 3274-3300 midgaard.are 3301-3303 midgaard.are 3304-3399 midgaard.are (room_law ends at 3399) 3400-3472 chapel.are 3473-3499 - 3500-3532 midennir.are 3533-3599 - 3600-3651 grave.are 3652-3699 - 3700-3760 school.are 3761-3800 - 3801-3881 hell.are 3882-3898 - 3899 Icaza & Hachet's Bedroom 3900-3908 moria.are 3909-3999 - 4000-4074 moria.are 4075-4099 - 4100-4173 moria.are 4174-4199 - 4200-4259 pyramid 4260-4299 - 4300-4399 oak.are 4400-4499 - 4500-4599 weird.are 4600-4699 - 4700-4785 juargan.are 4786-4799 - 4800-4899 - 4900-4999 - 5000-5070 eastern.are 5071-5099 - 5100-5150 drow.are 5151-5199 - 5200-5281 thalos.are 5282-5299 - 5300-5386 mirror.are 5387-5399 - 5400-5499 - 5500-5549 - 5550-5556 ofcol.are 5557-5599 - 5577 ravan's hideout 5600-5699 - 5700-5799 - 5800-5899 Mos Eisley 5900-5999 - 6000-6024 haon.are 6025-6099 - 6100-6156 haon.are 6200-6203 arachnos.are 6204-6299 - 6300-6399 arachnos.are 6400-6499 - 6500-6562 dwarven.are 6563-6599 - 6600-6631 daycare.are 6632-6699 - 6700-6799 Reserved 6800-6899 Reserved 6900-6999 - 7000-7099 sewer.are 7100-7199 sewer.are (7190: old death trap?) 7200-7299 sewer.are (7284: old death trap?) 7300-7399 sewer.are (7302-7398 unused actually) 7400-7445 sewer.are 7446-7499 - 7500-7599 - 7600-7699 - 7700-7799 - 7800-7883 valley.are 7884-7899 - 7900-7918 redferne.are 7919-7999 - 8000-8028 megacity one 8100-8199 - 8200-8299 - 8300-8318 old marsh 8319-8399 - 8400-8499 MATTZ ?? 8500-8599 - 8600-8639 void 8640-8698 - 8699 ??? 8700-8799 - 8800-8899 healed.are (note! this area room vnums go by 10s, if redone, it would be very small, so could do) 8900-8951 grove.are 8952-8998 - 8999 the fog (old death trap?) 9000-9059 nirvana 9060-9099 - 9100-9199 dylan.are (9199: old death trap?) 9200-9260 canyon.are 9261-9299 - 9300-9371 galaxy.are 9372-9399 - 9400-9424 mobfact.are 9425-9499 - 9500-9599 nthalos.are (9594-9599 Clan Macleod 9600-9699 nthalos.are 9700-9799 nthalos.are 9800-9809 nthalos.are 9810-9849 - 9850-9899 dragon cult 9898 morpheus' study 9899 sandman's room 9900-9999 baba yaga's hut 10000-10082 crystalmir lake 10083-10099 - 10100-10199 - 10200-10299 solace 10300-10317 solace 10318-10399 - 10400-10499 descent to hell 10500-10541 descent to hell 10542-10599 - 10600-10699 - 10700-10799 - 10800-10899 - 10900-10999 - 11000-11023 yggdrasil 11024-11099 - 11100-11199 - 11200-11299 - 11300-11599 horror.are 11600-11699 - 11700-11799 - 11800-11899 - 11900-11949 - 11950-11999 - 12000-12500 underdark 12501-12999 - 13000-13999 - 14000-14999 - 15000-15100 tavern area/catacombs and halloween 15100-15999 - 16000-16084 pirate ship 16085-16099 - 16100-16113 pirate ship (lance's house) 16114-16199 - 16200-16999 - 17000-17999 - 18000-18079 astral.are 18080-18099 - 18100-18999 - 19000-19999 - 20000-20999 - 21100-21999 - 22000-22099 hades 22100-22199 hades 22200-22243 hades 22244-22299 - 22300-22499 - 22500-22599 sacred.are 22600-22649 Vamps hq (IN sacred.are) 22650-22650 Guard Hq (IN sacred.are) 22651-22674 Pirat Hq (added June 26/96) 22675-22699 Pirat Hq (IN sacred.are) 22700-22749 Midnite Dance Society (IN sacred.are) 22750-22799 RMESociety (IN sacred.are) 22800-22824 Eternal Alliance (IN sacred.are) 22825-22849 Dragon Order (IN sacred.are) 22850-22874 Druids Misty Vale (IN sacred.are) 22875-22899 Beasts of Thera (IN sacred.are) 22900-22924 Savants of Fate 22925-22949 Illuminati 22950-22999 sacred.are (reserved) 23000-23999 - 24000-24099 ultima 24100-24999 - 25000-25084 ultima 25085-25099 - 25100-25199 jurassic park (version I) 25200-25299 (off since at least Jan/95) 25300-25302 jurassic park (version I) 25303-25399 - 25400-25999 - 26000-26034 lycanthrope village 26035-26099 - 26100-26302 jurassic park (version II) 26303-26999 27000-27999 who.are 28000-28999 - 29000-29699 - 29700-29714 darkside castle 29715-29799 - 29800-29999 - 30000-30999 - 31000-31099 - 31100-31156 gilligan's island 31157-31199 - 31200-31999 - 32000-32099 Carnival 32100-321?? gilligan's island


Object Stat Guidelines

Source: docs/manuals/object-stat-guidelines.md

       Objects Values Guide for MadROM area builders.
  • Thanks to Arioch for helping summarize these guidelines.
  • Thanks to Blueblood for his research into objects on MadROM, and suggestions ( not all of which I took, so blame anything you don't like on my final edit - Etaine )

MadROM muds at: telnet madrom.net 1536

Area Builders: please follow these guidelines or your area will not be accepted for MadROM.

General guidelines:

  1. Always write up your objects in an interesting and creative fashion. Please use the 'extended description' section on all objects. When deciding which monsters will carry or wear objects, or which rooms the objects might reset in, please remember that your area is a STORY, a mystical land, and that the objects that are to be found in there should be of a type and description that reflects the tale your area tells. Monsters should wear or carry items that make sense for the type of monster they are. Do NOT make tons of boring objects, just to fill up your area...better to have 10 beautifully written, coherent objects, than 50 of : a sword is here; a bigger sword is here.

  2. If you are resetting objects on monsters, please make sure that the LEVEL of the object is no higher than the level of the monster, and no lower than 5 levels below the monsters level (unless you have good reason to do otherwise, such as in a Qwest type area)

  3. While it is fine to make weapons and armor, also consider making items of other types, such as clothing, and containers, and boats etc, if they might fit in the theme of your area.

  4. The guidelines for values in this document are for MAXIMUM object values. Do NOT exceed them, or the object will be edited. Also, do not set all the objects in your area at maximum value. Any one area should have a range of medium powerful objects and only a few, rare maximum power objects. The objects that have MAXIMUM values should be reset on monsters, so that players have to fight to get them.

  5. This document only tells you the maximum values you may set of objects. Please get the legacy builder guide to find out how to write up your objects, and the list of object types and flags that MadROM uses.

Specific Guidelines:

A. Weapons:

  1. Average damage on weapons at maximum should be: 5 plus 5 per every 10 levels

To calculate average damage do as follows:

dice 1 = X dice 2 = Y ( X * Y ) + X) / 2

Therfore if you want a weapon with 17.5 average damage: Dice would be 5d6.

  1. Bonuses on weapons: See below, the section on bonuses. - If you do add bonuses to weapons, you must lower the average damage of the weapon slightly...eg if the maximum average damage of the weapon can be 10, but you are addding bonuses, make the average damage 8 or 9. - If you do add a hit or damage bonus to the weapon, please add at least one flag of GLOW or HUM.

  2. Weight on weapons - Weapon weight should range from 3 lbs up to 20 lbs, increasing with level range (our levels range from 1 to 90). Higher level weapons, in general, should be heavier to carry.

  3. Cost/Value of weapons

    • This should not exceed 2000 gold, and should not exceed 1000 gold if the weapon is under level 50.

B. Armor

  1. If the armor has NO other BONUSES: The armor class of armor items should be MAXIMUM 1/3 of the level of the items for the first 3 values and 1/8 of the level of the item for the slot AC against magic value.

If the armor HAS other BONUSES: The armor class of the item not exceed 1/4 of the level of the item for the first 3 values, and 1/10 of the level of the item for the slot AC against magic.

  1. Bonuses: see section on Bonuses, below. If you add hit or dam bonuses you must add to the object at least one of the GLOW or HUM flags. If the armor has the max hit/dam bonus of +6 it MUST have BOTH GLOW and HUM flags.

  2. Wear locations. If you make several powerful items of armor, make some the same level and wear location, so that your area is not stuffed with powerful objects that if all worn by the character, adds up to a mega powerful outfit. Make the players choose between say those armplates with the + hitpoint bonus, or those armplates with the hefty + dam bonus.

  3. Value/cost of object: same guidelines Weapon Cost/value.

  4. Weight. Same guidelines as Weapon Weight.

C. Lights, Containers, and Drink Containers

  1. Perpetual lights should not be available for levels under level 20.
  2. Drink containers that hold endless amounts of liquid should not be available for levels under level 65.
    • max liquid a drink container that is not endless should hold is 150. Level 15 or higher should get this amount. Adjust lower level and/or cheaper drink containers accordingly.
    • if the drink container holds specialty drinks, make the max it holds 50, if its for levels under level 50, and 75 for levels higher than level 50.
  3. Containers should not hold more than: Levels 1-10 100 lbs. Levels 11-15 150 lbs Levels 16 to 25 200 lbs. Levels 25+ max a container should hold is 500.

D. Food

  1. Food should not give more than 50 in food value. A good range is 10 to 50, and should depend either on the level of the food, or the cost of the food.

A. Scrolls/Potions/Pills

i. The object level should be no less than the minimum level required to cast the spell normally. (i.e. a heal pill must be at least level 21 because that is the level at which clerics can cast it). See the document 'spell.txt' on the ftp.io.org site, to get a list of slot numbers for each spell, and the lowest level that an object may be for each spell.

ii. The spell level of the item should not be more than 10 levels above, or 40%, of the item level, whichever is less.

iii. The value of the item should reflect the power of the spell. If the spell level of the item is over 50, the value should be NO LESS than 1.25 * cost to create a homemade scroll or potion. (i.e. A heal potion should cost no less than 7500 gold and sanc no less than 10000 coins.) This value guide applies only if you are putting these items for sale, in a shop.

B. Wands/Staves i. The same level restrictions as Scrolls/Potions/Pills for both object level and spell level.

ii. The number of charges should be inversely proportional to the power of the spell. Max charges for any item will be 6. Of course, the lower the item level, the less charges it should have:

        For levels:      Max charges (lower if a more powerful spell)

    1-15        1
    16-25       2
    26-40       3
    41-60       4
    61-91       6

iii. Here are some guidelines for some of the more powerful and popular spells.

    Spell          Minimum item level.

    Mass Heal        38
    Mass Sanc        45
    Heal             21
    Sanc             20
    Acid Blast       37
    Chain Lightning  33

    Spell          Max Charges

    Mass Heal        1
    Mass Sanc        1
    Heal             2
    Sanc             3
    Acid Blast       2
    Chain Lightning  3

F. Bonuses for All items. (the APPLY types)

  1. Items may have either +MANA or +HITPOINT bonuses but not both.

    1-10  - 0
    11-25 - +15 Hp OR Mana
    26-40 - +20
    41-60 - +35
    61-84 - +40
    85+   - +50 (MAX)
    - Scaling these values is advised for a fair distribution of pluses
    

    based on levels. A ratio method is highly suggested.

    If any objects have +hitpoint or +mana bonuses, they can not have any other bonuses UNLESS the hitpoint or mana bonus is not set at the above maximum for the level. For every +2 of other bonuses you add, you must subtract at least +5 of the maximum hitpoint or mana bonus.

  2. Items may have EITHER +HIT or +DAM bonuses but not both.

    1-9   - 0
    10-19 - +1 hit OR dam
    20-39 - +2 hit OR dam
    40-59 - +3 hit OR dam
    60-79 - +4 hit OR dam
    80-89 - +5 hit OR dam
    90-91 - +6 hit OR dam (MAX)
    

    If you add +hit or +dam, you must also add at least one of the GLOW or HUM flags. For armor, you must add BOTH glow and hum flags if the hit or dam bonus is at the maximum of +6.

    If any objects have +hit or +dam bonuses, they can not have any other bonuses UNLESS the hit or dam bonus is not set at the above maximum for the level. For every +2 of other bonuses you add, you must subtract at least +1 of the maximum hit or dam bonus.

  3. Attribute bonuses (int, con, str, wis, dex). These can be mixed and matched on any object, and it is advised you do so for the purpose of balance.

    1-10  - +2
    11-25 - +4
    26-50 - +5
    51+   - +6 (Absolute MAX)
    

The above totals are the total +attributes...eg a level 12 sword could have +2 con and +2 strength. If you have any mana hp dam or hit bonus on the object, as well, the attribute bonuses in this table must be at least 1 lower than the max for each level range shown above.

  1. Save vs. magic bonuses. These should be used sparingly, on rarer magical items only.

    Level Save vs magic bonus

    1-10 0 11-25 -1 26-40 -2 41-50 -3 51-70 -4 71+ -5 ( MAX )

last updated November 15, 1996.


Mob Stat Guidelines

Source: docs/manuals/mob-stat-guidelines.md

MadROM muds at: telnet madrom.net 1536

June 17/96 : please note this file is being updated...use it as a guide only.

This is MadROM's guide to setting the flags and hitpoint and other values for MOBILES when building areas for the mud.

  • Etaine

Mobiles should be balanced: a fairly hard fight should harvest a player around 50 exp. A VERY tough fight might give the player from 80 to 120 exp. The experience that a player will get from a mobile is determined by the level of the player vs the level of the mob, and the mobiles alignment. the amount of hitpoints the mob has, for example). A level 20 player will get around 50 exp for a level 20 mobile, and around 120 experience for a level 25 mobile, and higher if the mobile is oppositely aligned. The toughness of the fight, is determined by the hitpoints, damage, hitroll, other flags, spec_functions, and the weapon the mob may or may not be carrying (which affects the mobs damage). When determing the hitpoint and damroll to put on your mobile, keep in mind how many IMMUNITIES and RESISTANCES you are also adding, and what ACT_FLAGS you are adding, as well as any spec_functions you might be giving that mobile. The more IMMUNITIES and RESISTANCES a mobile has, the tougher it is. If the mobile has a special combat function it is also tougher. If so, you might give it a hitpoint setting at the lower end of its level range. On the other hand, if the mobile has few IMMUNITES and RESISTANCES and no special function for combat, plus lots of VULNERABILITIES, you might give it hitpoints at the higher end of the hitpoint range.

I. Hitpoints

Hitpoints are determined as a roll of the dice: eg 2d10+100 would give that mobile a hitpoint range, on reset, of 100 to 120 hitpoints. - Guide for mobiles: (hp=hitpoints) Level 1-10 10-15 hp per level Level 41-60 20-55 hp per level Level 11-20 15-20 hp per level Level 61-70 35-70 hp per level Level 21-30 15-30 hp per level Level 71+ 50-100 hp per level Level 31-40 20-35 hp per level

II. Mana

Mana is also determined as a roll of the dice, but is not actually implemented on MadROM at present. However, treat the mobile as if it can use mana, and give it the amount of mana a cleric or warrior player (depending on the mobile) at that mobiles level, might have. Ask players on the mud for their mana stats. If you don't want to bother with this, just put in 1d1+99 for all mobiles, in the mana section.

III. Hitroll

Affects how often the mobile will hit you, basically. It doesn't need to be very high, as its an added bonus for the mobile. For a level 50 mobile, a hitroll of 8 is more than fine, and for a level 90 mobile a hitroll of 15 would be great.

IV. Damage

Affects how HARD the mobile will hit you. This value will be augmented by the average damage of the weapon the mobile is carrying if you use the E (equip command) in the resets section to give the mobile a weapon.

An easy guide to setting the damage for your mobile is to set the damage the same way you set average damage for a weapon: 5 + 10 for each level

eg a level 50 mobile would have an average damage of 30 or eg 1d1+30 or a range such as 2d5+25. Keep in mind that giving your mobile a weapon will give it more damage than what you put in in this value in the

MOBILES section.

V. Armor Class

This value is also affected by an armor you give your mobile to wear, using the E (equip) command to give eq to your mobile in the RESETS section. A quick way to decide what value to give your mobile for its armor class is 2/3 of the mobiles level. eg a level 90 mobile would have armor class values around 60. You have 4 values to put in here, each explained in the legacy builder guide. Don't make all values the same. Eg for a level 90 mobile you might have:

-60 -59 -58 -35

The last value, resistance to magic, is usually a bit lower than the resistances to the weapon attacks. NB. the values are multiplied by 10 by the mud. So a mobile with -60 AC in your area file will have around -600 AC. This is taken into account when I am suggesting the values for you to put in.

VI. ACT_FLAGS, IMMUNITIES, RESISTANCES and VULNERABILITIES.

Don't load your mobile up with immunities and resistances OR make it wussy with too many vulnerabilities. Choose a few that reflect the nature of the creature. Choose MORE the higher level the mobile. Keep in mind that the more immunities and resistances the mobile has, the tougher it is, and the weaker you might want it in hitpoints and damage. Any mobile over level 45 should have Sanctuary, OR be Aggressive, or have bash, berserk or frenzy. All at this level or higher should have trip and/or dodge and parry.

VII. Special functions

Special functions for your mobile. Keep in mind that giving your mobile special functions may make it anywhere from a little to a LOT tougher.

Of the combat special functions, the least nasty are the spec_breath ones. Harder yet is the special_cast_cleric function. Mobiles with special_cast_mage and spec_cast_undead are very tough!, and because of the possibility of players being edrained, should be given these special functions only if they are a prize to fight..eg they hold the key to a treasure, or guard the gateway to an area, or wear powerful equipment. Ozy.doc has a list of special functions available, and what spells they contain.

VII. Gold

Don't load your mobile up with gold. 10 000 gold for a level 90 mobiles is MORE than enough, 7000 gold for a level 60 mobile is rich, and mobiles under level 50 should not have more than 300 gold. Those under level 30 should have a maximum of 2000 gold.

Some Examples of Mobiles on MadROM.

Level 60 HP 2000-3700 Armor Class (Value 39, actual, 388) Hit 5 Damage 4d8+27 Flags: Agressive, Assist, Disarm Dodge Trip Kick Bash Detect Invis. Immune to Pierce, Acid Blast and Disease. No resistances. Vulnerable to Holy.

Level 81 HP 5900-6400 Armor Class (Value 52, actual, 520) Hit 7 Damage 6d6+38 Flags: Sanctuary, Disarm, Dodge, Trip, Assist vnum, Bash. Immune to Lighting, Acid blast and Disease. Resists magic. Vulnerable to Holy, and Poison.

Good mobiles to check are the ones in Strange World. Keep in mind that the armor class you see if you check them is the armor class on the mud..eg a mobile that on the mud has an armor class of -600 -500 -300 -100 0

will have values for AC of -59 -50 -29 -10 0 or so, in the #MOBILES section of your area.


Mob Programming Guide

Source: docs/manuals/mob-programming-guide.md

The #MOBPROGS section

** Note: most of this taken from the DOC file which came with the MOBprograms distribution file. The patch work will be pretty bad. Sorry.... it just tells you what you need to know!

Ways to associate programs with MOBS:

The first involves a simple in-file approach. In the mobile section of your area files, at the end of the mobile's block (i.e. on the line following the typical position/default position/sex line), append any number of MOBprograms (using the syntax above) followed by a line starting with a '|' (pipe). This is demonstrated above.

The second method is to add a #MOBPROGS section to the area files. Logically this section should follow the #MOBILE section since otherwise the mobiles probably wont have space allocated for them. In the #MOBPROGS section, list as many lines as you desire of:

"M" {Vnum} {MOBprogram_filename} NL

followed by a line starting with a 'S' (case insensitive) The Vnum is whatever number mobile to which you are associating the MOBprogram. The MOBprogram_filename is the name of the external file of MOBprograms. It is not case insensitive and may include directory heirarchies (foo/bar/xx).

/ It is up to you which method you use. I would prefer that all * builders working on our project pick one and stick with it...makes life * easier for me.... * I don't think it is possible to have a single file with all of your * programs for all of your mobs...might be a suggestion for murph. /

--Trigger Types Triggers are fairly easy to add, but this basic list should hold for most needs. Their names, argument list syntaxes, and translation into more articulate english are given below:

in_file_prog The argument is a single word which is the location of the stored file as referenced from the running directory. -Dummy trigger. Not valid in any file, only for use in loading files from the first method described two sections above.

act_prog The argument is a list of keywords separated by spaces. If the first word is the character 'p' by itself then the rest of the word list is considered to be a phrase. The trigger is activated whenver a keyword (or the phrase) is contained in the act() message. Both the phrase and keywords are case insensitive. -Most general trigger. Applies to almost every event which happens in the mud. Anytime the function act() is called with a message to be delivered TO_CHAR,TO_VICT,TO_ROOM,etc. the act can be triggered. Basically this will trigger on almost everything you'll ever want (and some things you wont as well) For example: MOBprogram: >act_prog p pokes you in the ribs.~ This trigger will only be activated if a mobile receives a message in which the above five words are found in the exact order and spacing given. Note that the period is needed because the words must be found on their own. This eliminates confusion when the keyword is 'hi' and a message with the word 'this' is being checked.

speech_prog The argument is the same as for an act_prog. -This is only triggered when the keyword or phrase is contained in a message which has been said by a PC in the same room as the mob. The PC restriction is not necessary, but makes infinite loops between two talking mobiles impossible. It also makes it impossible for two NPC's to stand and discuss the weather however.

rand_prog The argument is a number betweeen 1 and 100 inclusive. -This trigger is checked at each PULSE_MOBILE and if the argument is greater than a percentage roll the trigger is activated. This will happen even if there is no PC in the room with the mob, but there must be plauers in the same area. It is useful to give mobiles a bit of a personality. For instance a janitor who stops to spit tobacco, or complain about the hours, or wonder why there are no woman janitors on muds, or a fido which barks or growls or pees on the curb is much more alive than one which just sits there scavenging.

fight_prog The argument is a percentage like in rand_prog. -Useful for giving mobiles combat attitude. It is checked every PULSE_VIOLENCE when the mobile is fighting. Can be used to cast spells, curse at the opponent, or whatever. Only the first successful one will be processed to save time. Also, this means that the mobile wont get lucky and 1. curse, cast a fireball and 2. spit on the player, cast another fireball in the same pulse.

hitprcnt_prog The argument is a percentage. -Is activated at each PULSE_VIOLENCE when the mobile is fighting. It checks to see if the hitpoints of the mobile are below the given percentage. Multiple hitprcnt_progs should be listed in increasing order of percent since a 40% will always be activated before a 20% and, only the first successful hitprcnt trigger is performed.

greet_prog Again a percentage argument. -Whenever someone enters the room with the mobile, and the mobile saw the person enter, this is checked. Good for shopkeepers who want to welcome customers, or for pseudo-aggressive mobiles which need to discriminate on who they attack.

all_greet_prog Again a percentage argument. -Like greet_prog, but it can be triggered even if the mobile didnt see the arrival (i.e. sneak, invis, etc). Most useful for faking teleport rooms (if your mobiles can transfer) or for impassable guardians. NOTE: neither greet_prog is activated if the mobile is fighting.

entry_prog Again a percentage argument. -The opposite of a greet_prog. Whenver the mobile itself enters a new room, this can be triggered. Useful for looking around, or waving or other things that real PCs do when they arrive at a crowded room. Only the first successful one of these is done so the mobile doesnt look stupid by repeating commands resulting from multiple MOBprograms.

give_prog The argument is either the complete name of an object, or the word 'all'. A complete name is like: "sword shiny magic" vs "sword". It is whatever is on the line of the object section following the VNUM. -This is triggered whenever something is given to the mobile. Best used for quests. Since the first successful trigger is the only one of this type which is processed, having an "all" argument give_prog at the end of the MOBprogram list is essentially a default response.

bribe_prog The argument is any positive integer number. -This trigger is activated whenever money is given to the mobile. If the amount given exceeds the number, then process the commands. Note again, that an argument of '1' would act as a default response. If money is given to a mobile with this trigger type, instead of the cash being added to mob->gold, the mobile is instead given a pile of coins in the proper amount. In this way, the mobile can drop the coins or refer to the object by "amount" (short description:"%d gold coins") This surely has some drawbacks, but it lets the mobile do something with the bribe (NOTE: dropping it and getting it turns it into cash) This can be done sneakily if a NPC-only "at" command exists.

death_prog The argument is a percent once again. -When the mobile dies, if the random percentage is less than the argument the mobile performs the MOBprogram commands rather than the usual death_cry sequence. This is done before the corpse is made, so the commands can be considered the mobiles last gasp. It could perhaps destroy the items it was holding, or create some, or cast a spell on the killer and the room, or even goto a new location and die there (with a text message, the corpse would seem to vanish) The position of the mobile is set to STANDING, and so it can do all the normal commands, without worrying about being DEAD. However, even if the mobile restores itself to full hitpoints, it will still die. This is not a way to immortal mobiles. However, the last thing this mobile does could be to goto some vacant room, load a fresh version of itself, drop all its items, force the new mobile to get all the items and wear them, send the new mobile back to the character who killed it and force the new mobile to attack that character. Along with a text message which said the mobile restored itself, this might be a convincing effect. (Note that your kitten could turn into a dragon this way too). Of course this assumes that some NPC commands have been implemented.

-- Variables

You can use these anywhere in your program to reference names.

variable mobile actor victim random object 2nd_object

name $i $n $t $r $o $p shrt_desc/title $I $N $T $R $O $P he/she/it $j $e $E $J -- -- '$'symbol=$$ him/her/it $l $m $M $L -- -- his/hers/its $k $s $S $K -- -- a/an -- -- -- -- $a $A

--Control Flow Syntax In place of any legal mud command in a MOBprogram, one can substitute a flow of control command. Here is the syntax for a flow of control command.

"if" " " {if_check_1} "(" {argument} ")" [ {operator} {value} ] NL [ "or" " " {if_check_2} "(" {argument} ")" [ {operator} {value} ] NL ] . . . [ "or" " " {if_check_N} "(" {argument} ")" [ {operator} {value} ] NL ]

[ {program_command_1} NL ]
[ {program_command_2} NL ]
      .   .   .
[ "break" NL ]
      .   .   .
[ {program_command_N} NL ]

[ "else" NL ]

[ {program_command_1} NL ]
[ {program_command_2} NL ]
      .   .   .
[ "break" NL ]
      .   .   .
[ {program_command_N} NL ]

"endif" NL

Basically, it is: an 'if' line, followed by zero or more 'or' lines, followed by zero or more legal mud commands, which may contain a 'break' line, possibly followed by an 'else' line , followed by zero or more legal mud commands, which may contain a 'break' line, followed by an 'endif' line.

The only new syntax labels are all in the IF line: An if_check is a string which describes under what context to compare things. The argument is the reference point from which the LHS of an expression comes. The operator indicates how the LHS and RHS are going to be compared. The value is the RHS of the expression to be compared by the operator.

The break command bails out of the entire MOBprogram regardless of the level if nesting.

These are all the if_checks:

ifcheck argument? meaning

rand(num) Is a random percentage less than or equal to num isnpc($) Is $ an NPC ispc($) Is $ a PC isgood($) Does $ have a good alignment isfight($) Is $ fighting isimmort($) Is the level of $ greater than max_mortal ischarmed($) Is $ affected by charm isfollow($) Is $ a follower with their master in the room isaffected($) & integer Is ($->affected_by & integer) true (person only) hitprcnt($) == percent Is the hit/max_hit of $ equal to percent inroom($) == integer Is the room of $ equal to integer (person only) sex($) == integer Is the sex of $ equal to integer position($) == integer Is the position of $ equal to integer level($) == integer Is the level of $ equal to integer class($) == integer Is the class of $ equal to integer goldamt($) == integer Does $ have a gold total equal to integer objtype($) == integer Is the type of $ equal to integer (armor,boat,etc) objval#($) == integer Is $->value[#] equal to integer (# from 0-3) number($) == integer Is the vnum of $ equal to integer name($) == string Is the name of $ equal to string align($) == integer Is the alignment of $ equal to integer tribe($) == string Is the tribe_abbreviation of $ equal to string isleader($) Is the target equal to true (is a leader?) ispet($) Is the target a pet isntpet($) Is the target NOT a pet race($) == string Is the race of the target equal to string mobhere($) == integer Is target in_room->vnum equal to integer (no integer for local room) objhere(vnum) == integer Is object vnum in room->(integer) hasobj($) == integer Is $* carrying obj->vnum->(integer) in $s inventory?

--Operators Most of the basic numeric operators are legal and perform the same function as in C. The string operators are a bit more confusing. There are negative versions of some of the operators. These are not strictly needed, since the if/else construct of Control Flow commands can handle either case.

Numeric Operators: == != > < >= <= & | String Operators: == != / !/

For strings, == and != check for exact match between the two strings and the other two, / and !/ check to see if the second string is contained in the first one. This is so things like: if name($n) / guard will respond true to "cityguard" "guard" "guardian" etc. Using == on a name implies that you are matching the complete name "cityguard guard" or whatever. The string operators are case SENSITIVE.

--Special commands to use in programs!

Here are the basic MOBcommands that we found to be enticing:

MPDAMAGE {kill} Damages a target according to min and max. Using the kill arg will allow this attack to be lethal, otherwise it'll merely take the target to 0 hp. This is silent and will require descriptive echos.

MPSTAT shows the MOBprograms which are set on the mob of the given name or vnum and some basic stats for the mobile

MPASOUND text_string prints the text string to the rooms around the mobile in the same manner as a death cry. This is really useful for powerful aggressives and is also nice for wandering minstrels or mobiles like that in concept.

MPJUNK destroys the object refered to in the mobiles inven. It prints no message to the world and you can do things like junk all.bread or junk all. This is nice for having janitor mobiles clean out their inventory if they are carrying too much (have a MOBprogram trigger on the 'full inventory'). Use of the "inven" arg will only cause items in the mobiles inventory to be extracted.

MPECHO text_string MPECHOAT text_string MPECHOAROUND text_string prints the text message to the room of the mobile. The three options let you tailor the message to goto victims or to do things sneaky like having a merchant do: mpat guard mpechoat guard rescue_please This coupled with a guard act_prog trigger on rescue_please to mpgoto $n and mpecho $I has arrived. is an affective way of quickly bringing guards to the scene of an attack.

MPLOAD M[obile] MPLOAD O[bject] loads the obj/mobile into the inven/room of the mobile. Even if the item is non-takable, the mobile will receive it in the inventory. This lets a mobile distribute a quest item or load a key or something.

MPKILL lets a mobile kill a player without having to murder and be fifth level. Lots of MOBprograms end up with mpkill $n commands floating around. It works on both mobiles and players.

MPPURGE [argument] destroys the argument from the room of the mobile. Without an argument the result is the cleansing of all NPC's and items from the room with the exception of the mobile itself. However, mppurge $i will indeed purge the mobile, but it MUST be the last command the mobile tries to do, otherwise the mud cant reference the person trying to do the commands and bad things happen.

MPGOTO moves the mobile to the room or mobile or object requested. It makes no message of its departure or of its entrance, so these must be supplied with mpecho commands if they are desired.

MPAT perfoms the command at the designated location. Very useful for doing magic slight of hand tricks that leave players dumbfounded.. such as metamorphing mobiles, or guard summoning, or corpse vanishing.

MPTRANSFER [dest] sends the victim to the destination or to the room of the mobile as a default. if the victim is "all" then all the characters in the room of the mobile are transfered to the destination. Good for starting quests or things like that. There is no message given to the player that it has been transfered and the player doesnt do a look at the new room unless the mob forces them to. Immortals cannot be transfered.

MPTECHO (MadROM only...will work only if the mob with this prog is given an X tribe in the area file, so that he belongs to that tribe). Lets the mob echo a message to all members of the Tribe that the mob belongs to.

MPMORPH (this is available on MadROM, but may not be available on other muds) shapeshifts the victim into a specified mobile. I strongly suggest that the mobile prog include a 'mpoload mob to be morphed into' before the morph command, and that a check for ispc victim be done first.

MPFORCE forces the victim to do the designated command. The victim is not told that they are forced, they just do the command so usually some mpecho message is nice. You can force players to remove belongings and give them to you, etc. The player sees the normal command messages (such as removing the item and giving it away in the above example) Again, if the victim is "all" then everyone in the mobiles room does the command. This cannot be used on immortals.


Mob Programming Alternate Guide

Source: docs/manuals/mob-programming-alt-guide.md

Originally appeared in: Merc release 2.2 Wednesday 24 November 1993

N'atas-Ha natasha@gs118.sp.cs.cmu.edu
Kahn

Modified for ROM 2.4 in January 1996 Newt@Imperium Gothique

TABLE OF CONTENTS

The Basic Idea
About This Version
MOBprogram Syntax
Linking MOBprograms
Trigger Types
Variables
Control Flow Syntax
Operators
If_checks in Control Flow
New Commands of Interest
Regarding CPU Slowdown
Loading Mobiles and Objects
Miscellaneous Information

Quick Reference Sheet
Examples

-----------------------------The Basic Idea---------------------------------

Ever wonder why most muds either seem dead or overcrowded? The answer

is probably partially due to the fact that the mobiles never do anything but wait to be slaughtered. Unless someone has gone to great lengths and added many special procedures, most mobiles have no idea you are in the room with them and rarely listen to what you say. The typical Midgaard mayor wanders happily along even when the populace pokes him, waves his City Key about, unlocks his gates, or frenchs his secretary, etc. So a way to give the mobiles a bit more spirit would be neat. Enter the MOBprograms.

TRIGGERS AND SCRIPTS

The backbone of the MOBprograms shall be called triggers from this

point on. Essentially, they are procedure calls placed in sneaky places in the mud code which provide the context for what is going on around the mobile. So, if something happens in the mobile's room and a trigger is activated, then a list of commands is sent to the interpreter in the mobile's name, thus making her/it/him do an appropriate something.

VARIABLES

Since knowing the appropriate response for every mobile to every

possible trigger is not easy, this command list shouldnt be a rigid script, but needs to be somehow unique for the mobile and the situation. However, in order to know the situation, a mobile needs to know more about the trigger than that it just happened. So, we have to include some sort of variables as well to set the context appropriately.

MOBPROGRAMS VS. SPEC_PROCS

As most implementors know, most area creators are not versed in

coding, but usually have great ideas. Therefore, whatever system is used needs to be quite simple. This is not to demean creators in anyway. Simply, it is useless to have a powerful system, if the only person able to write anything is someone who finds C coding in general to be exciting and non frustrating. If that is going to be the case, then stick to the special procedures, since there is no bound to what a complex special procedure can accomplish. Yet, from experience working on several muds, most admins and implementors prefer not to be writing one shot spec_procs to satisfy the needs of their creators.

Thus, the basic idea: let mobiles react to a myriad of mud

events/situations by having them perform a list of commands which can be tailored to the moment through a simple and unintimidating scheme usable by any creator.

---------------------------About This Version-------------------------------

My implementation of MOBprograms owes a lot to the original MOBprogram

code by Natasha. However, having heard reports about unstability of the code supplied, and because the code seemed unnecessarily complex to me, I decided to rewrite the MOBprogram driver. Admittedly, I have dropped out several features that were present in the original version, such as reacting to several triggers at once and string comparison in if_checks. On the other hand, the MOBprogram code has been simplified and made more stable (there are no memory leaks), and several new if_checks and MOBcommands have been added. The system of linking MOBprograms to mobiles has been changed to allow procedure-like calls. This version is an adaptation of my earlier MOBprogram system I created for Imperium Gothique MUD. The IG system has object and room programs as well, but I chose to omit them from this version.

-- Newt

----------------------------MOBprogram Syntax--------------------------------

The simplest way to describe any syntax is by example, so here goes.

First, define the notation: anything contained in braces {} is required, anything in brackets [] is optional, anything in quotes "" is a case insensitive literal, NL refers to a required new-line. The meanings of the labels used will be described following the syntax diagram. To use MOBprograms, you must add a #MOBPROGS section(s) to your area file(s).

Section syntax:

MOBPROGS

{Vnum}

{program_command_1} NL {program_command_2} NL {program_command_3} NL . . . {program_command_N} NL "~" NL . . .

0

-- Explanations A VNUM is the MOBprogram virtual number that identifies the program the number must be unique across area files (like mobile and object vnums). A PROGRAM_COMMAND can be any legal mud command, or a control flow command.

NOTE 1: Any whitespaces (space, tab, newline) are NOT stripped from the programs when loading the database (why? because I'm too damn lazy to have implemented it). Thus, to save memory and execution time, omit all unnecessary spaces from your MOBprogram scripts. If you must have indentation, use TAB.

NOTE 2: MOBprograms do NOT have to be in the same area file as the mobile definitions, since the programs are linked to the mobiles after the database has been loaded. A MOBprogram can also be used as a subroutine (see MOB CALL command) without having to be linked to any mobile.

-- Example

MOBPROGS

3001

say Hey, no loitering! poke $n ~

0

--------------------------Linking MOBprograms--------------------------------

Once you've written your MOBprograms, you must link the programs

to appropriate mobiles. In the #MOBILES section, for each mobile you wish to have a MOBprogram, add lines of the following type to the end of the mobile definition:

"M" {Keyword} {Vnum} {Argument}~ NL

--Explanations The KEYWORD is a single word, see below for explanations. The VNUM is the MOBprogram virtual number. The ARGUMENT is the argument that triggers the event. --Example

M act 3001 sits down~

In the above example, an ACT trigger is defined. When the mobile sees someone sitting down in the room, the mobile will execute program number 3001 (defined in #MOBPROGS section).

NOTE: Several mobiles can use the same MOBprogram, i.e. MOBprograms can be SHARED with several mobiles. The keyword and trigger argument can be different for each mobile even if they share the same MOBprogram code.

-----------------------------Trigger Types----------------------------------

Here's a summary of triggers:

Triggers are fairly easy to add, but this basic list should hold for

most needs. Their names, argument list syntaxes, and translation into more articulate english are given below:

ACT

Keyword : 'act' Argument: string

The argument is a phrase, a text string. The trigger is activated

whenever the phrase is contained in the act() message.

NOTE: Most general trigger. Applies to almost every event which happens in the mud. Anytime the function act() is called with a message to be delivered TO_CHAR,TO_VICT,TO_ROOM,etc. the act can be triggered. Basically this will trigger on almost everything you'll ever want. Output of "say", "shout" and "emote" do not trigger this event.

SPEECH

Keyword : 'speech' Argument: string

NOTE: This is only triggered when the phrase is contained in a message which has been said by a PC in the same room as the mob. The PC restriction is not necessary, but makes infinite loops between two talking mobiles impossible. It also makes it impossible for two NPC's to stand and discuss the weather however.

RANDOM

Keyword : 'random' Argument: number

The argument is a number betweeen 0 and 99 inclusive.

NOTE: This trigger is checked at each PULSE_MOBILE and if the argument is greater than a percentage roll the trigger is activated. This will happen even if there is no PC in the room with the mob, but there must be players in the same area. It is useful to give mobiles a bit of a personality. For instance a janitor who stops to spit tobacco, or complain about the hours, or wonder why there are no woman janitors on muds, or a fido which barks or growls or pees on the curb is much more alive than one which just sits there scavenging. Note that this trigger is checked only when there are players in the area. If you want this event to be triggered always, you must set the ACT_UPDATE_ALWAYS flag of the mobile.

GREET/GREET ALL

Keyword : 'greet' Argument: number

Again a percentage argument.

NOTE: Whenever someone enters the room with the mobile, and the mobile saw the person enter, this is checked. Good for shopkeepers who want to welcome customers, or for pseudo-aggressive mobiles which need to discriminate on who they attack. Greet trigger activates only when the mobile is not busy (fighting, sitting, sleeping etc.). If you want to be sure to catch all players, use grall.

Keyword : 'grall' Argument: number

Again a percentage argument.

NOTE: Like greet, but it can be triggered even if the mobile didn't see the arrival (i.e. sneak, invis, etc) or is busy. Most useful for faking teleport rooms or for impassable guardians.

ENTRY

Keyword : 'entry' Argument: number

Again a percentage argument.

NOTE: The opposite of greet trigger. Whenver the mobile itself enters a new room, this can be triggered. Useful for looking around, or waving or other things that real PCs do when they arrive at a crowded room. IMPORTANT: In an entry program, the mobile can only refer to a random pc ($r in if checks) -- there's no way to know how many PCs exist in the room the mobile enters! Also, you must check visibility of the target in your program.

EXIT/EXIT ALL

Keyword : 'exit' Argument: number

Argument is the exit number (0:north, 1:east, 2:south 3:west etc.)

NOTE: The opposite of entry trigger. This is activated when PC tries to leave a room through an exit indicated by the argument, and the mobile sees the person leave. Useful for having a single guardian to watch several exits. An exit trigger works better than an entry trigger, since you can refer to a specific PC instead of a random PC. IMPORTANT: If this event is triggered, the victim will not move through the exit. If necessary, you must move the character yourself in your program (see MOB TRANSFER/MOB GTRANSFER). Also, this event is not triggered when a character flees from combat or the mobile is not in its default position.

Keyword : 'exall' Argument: number

Argument is the exit number (0 = north etc.)

The same as exit trigger, but it can be triggered even if the
mobile cannot see the person trying to leave the room or if
the mobile is busy.

GIVE

Keyword : 'give' Argument: string or object vnum

The argument is either the a string containing words to be
matched against the keywords of the object, or the word "all";
e.g. argument "long sword" will match to objects "long bow" and
"small sword".
Alternatively, the argument can be the virtual number of a single
object.

NOTE: This is triggered whenever something is given to the mobile. Best used for quests. Since the first successful trigger is the only one of this type which is processed, having an "all" argument in the script at the end of the MOBprogram list is essentially a default response.

BRIBE

Keyword : 'bribe' Argument: number

The argument is any positive integer number.

NOTE: This trigger is activated whenever money is given to the mobile. If the amount given exceeds the number, then process the commands. Note again, that an argument of '1' would act as a default response. Also note that if the script is not triggered (because of too little money having been given), the mobile still keeps the money...

ROM 2.4 NOTE: Since ROM 2.4 has two different types of currency
(gold and silver coins), for bribe trigger the amount to be given
is converted to silver coins with the rate of 1 gold = 100 silver.
Thus, the number in the argument should be the expected amount in
silver coins.

KILL

Keyword : 'kill' Argument: number

The argument is a percent once again.

NOTE: This trigger is checked whenever a PC attacks the mobile. The check occurs only ONCE, in the beginning of combat. Useful for summoning assistance etc. (See MOB MLOAD).

FIGHT

Keyword : 'fight' Argument: number

The argument is a percentage.

NOTE: Useful for giving mobiles combat attitude. It is checked every PULSE_VIOLENCE when the mobile is fighting. Can be used to cast spells (see MOB CAST), curse at the opponent, or whatever. Only the first successful one will be processed to save time. Also, this means that the mobile wont get lucky and 1. curse, cast a fireball and 2. spit on the player, cast another fireball in the same pulse.

HIT POINT PERCENTAGE

Keyword : 'hpcnt' Argument: number

The argument is a percentage.

NOTE: Is activated at each PULSE_VIOLENCE when the mobile is fighting. It checks to see if the hitpoints of the mobile are below the given percentage. Multiple hpcnt triggers should be listed in increasing order of percent since a 40% will always be activated before a 20% and, only the first successful trigger is performed. (See also MOB FLEE).

DEATH

Keyword : 'death' Argument: number

The argument is a percent once again.

NOTE: When the mobile dies, if the random percentage is less than the argument the mobile performs the MOBprogram commands rather than the usual death_cry() sequence. This is done before the corpse is made, so the commands can be considered the mobiles last gasp. It could perhaps destroy the items it was holding (see MOB REMOVE and MOB JUNK), or create some (see MOB OLOAD), or cast a spell (see MOB CAST) on the killer and the room, or even goto a new location (see MOB GOTO) and die there (with a text message, the corpse would seem to vanish) The position of the mobile is set to STANDING, and so it can do all the normal commands, without worrying about being DEAD. However, even if the mobile restores itself to full hitpoints, it will still die. This is not a way to immortal mobiles. However, the last thing this mobile does could be to goto some vacant room, load a fresh version of itself, drop all its items, force the new mobile to get all the items and wear them, send the new mobile back to the character who killed it and force the new mobile to attack that character. Along with a text message which said the mobile restored itself, this might be a convincing effect. (Note that your kitten could turn into a dragon this way too).

DELAY

Keyword : 'delay' Argument: number

The argument is a percentage chance.

NOTE: This trigger activates when the delay of a mobile (set with the MOB DELAY command) expires. This trigger can be used to create staged mobile behavior, for example, a guardian could see a player entering a room, give a warning and activate a delay. If the player is still present when the delay expires, the guard would attack the player. (See also MOB REMEMBER). A mobile can have several delay triggers, but every time the delay timer expires, all the triggers are checked and the first successful one executed.

SURRENDER

Keyword : 'surr' Argument: number

The argument is a percentage.

NOTE: This trigger activates when the mobile is fighting and the opponent issues a "surrender" command. When triggered, both parties will cease fighting, and the mobile can accept the surrender (perhaps taking all equipment from the character with MOB REMOVE). Note that if the mobile does not accept the surrender, it must resume fighting with MOB KILL. If a character surrenders and the mobile does not have a surrender trigger, or the trigger does not activate, the fight resumes normally.

NOTE: No MOBprograms will be successful when the mobile is charmed (since it has no self volition, it should act like it has none) to protect mobiles which are given special powers from being implemented by a player.

------------------------------Variables------------------------------------

To make things come alive, variables are needed.  These are

represented in the MOBprograms by using a dollar sign convention as in the socials. When the mud command is processed, these variables are expanded into the values shown below. Usually, it is best to use the short descriptions of mobiles and the names of players when speaking them, but if you are performing an action to someone almost always you want the name. The title field for players is an extra that probably wont often be used. Without further hesitation... the variables:

$i the first of the names of the mobile itself. $I the short description of the mobile itself. $n the name of whomever caused the trigger to happen. $N the name and title of whomever caused the trigger to happen. $t the name of a secondary character target (i.e A smiles at B) $T the short description, or name and title of target (NPC vs PC) $r the name of a random PC in the room with the mobile $R the short description, or name and title of the random PC $q the name of the MOBprogram target (see MOB REMEMBER) $Q the short description of the MOBprogram target

$j he,she,it based on sex of $i. $e he,she,it based on sex of $n. $E he,she,it based on sex of $t. $J he,she,it based on sex of $r.

$k him,her,it based on sex of $i. $m him,her,it based on sex of $n. $M him,her,it based on sex of $t. $K him,her,it based on sex of $r.

$l his,hers,its based on sex of $i. $s his,hers,its based on sex of $n. $S his,hers,its based on sex of $t. $L his,hers,its based on sex of $r.

$o the first of the names of the primary object (i.e A drops B) $O the short description of the primary object $p the first of the names of the secondary object (i.e A puts B in C) $P the short description of the secondary object

Also, in if_checks, the accepted variables are the basic ones

(i,n,t,r,o,p,q). If a variable is referenced that doesnt exist, then the value is simply left blank or replaced with "someone"/"something" in output (i.e referring to $o when the trigger is: A kisses B)

If variable $q has not been defined, it is automatically set to the

last player that has triggered the program being executed (i.e. variable $n). Once $q has been defined, it can be modified with MOB REMEMBER and MOB FORGET commands in a program. Variable $q lets the mobile "remember" a player across different programs, which can be useful. Note that $q is set automatically only the FIRST TIME the mobile executes a program, every time thereafter it must be set with MOB REMEMBER.

The only problem with the variables is that the secondary object and

the secondary target are passed by act() in the same location. This means that if you reference $t in an A puts B in C situation, the result will probably be a happy mud crash or some weird side effect, espescially if $t is used in an if_check (i.e. if isnpc($t) in the above situation) The basic fix for this is to change everyone who calls the act() procedure to specify a secondary object and a secondary character. But that is a fairly comprehensive trivial twiddle, so we left it the way it is so that, you arent forced to make all those twiddles to use the MOBprograms.

---------------------------Control Flow Syntax------------------------------

In place of any legal mud command in a MOBprogram, one can substitute a

flow of control command. Here is the syntax for a flow of control command. The parts between [ and ] are optional.

"if" " " {if_check_1} {argument} [ {operator} {value} ] NL [ "or" " " {if_check_2} {argument} [ {operator} {value} ] NL ] [ "or" " " {if_check_N} {argument} [ {operator} {value} ] NL ] . . . [ "and" " " {if_check_N} {argument} [ {operator} {value} ] NL ] [ "and" " " {if_check_N} {argument} [ {operator} {value} ] NL ] . . .

[ {program_command_1} NL ]
[ {program_command_2} NL ]
      .   .   .
[ "break" NL ]
      .   .   .
[ {program_command_N} NL ]

[ "else" NL ]

[ {program_command_1} NL ]
[ {program_command_2} NL ]
      .   .   .
[ "break" NL ]
      .   .   .
[ {program_command_N} NL ]

"endif" NL

Basically, it is: an 'if' line, followed by zero or more 'or' lines,

followed by zero of more 'and' lines ('and' and 'or' lines can be in any order) followed by zero or more legal mud commands, which may contain a 'break' line, possibly followed by an 'else' line , followed by zero or more legal mud commands, which may contain a 'break' line, followed by an 'endif' line.

The only new syntax labels are all in the IF/OR/AND line:

--Explanations

An IF_CHECK is a string which describes under what context to compare things. The ARGUMENT is the reference point from which the LHS of an expression comes. The OPERATOR indicates how the LHS and RHS are going to be compared. The VALUE is the RHS of the expression to be compared by the operator.

The BREAK command bails out of the entire MOBprogram regardless of the level if nesting. (END is a synonym for BREAK).

If that looks confusing, skip to the end of the document and review the examples. Hopefully that should clear things, otherwise you'll probably have to give me a mail since examples are the best way I know to explain syntax.

--------------------------------Operators-----------------------------------

Most of the basic numeric operators are legal and perform the same

function as in C.

Operators: == != > < >= <=

------------------------If_Checks In Control Flow---------------------------

The provided list of if_checks and their arguments are below.  They

should all be fairly obvious in what they do, but some of the more obtuse deserve a slight explanation. Any '==' operator can be replaced with any of the available ones described above. The argument $* refers to any of the variables which make sense for that if_check (i.e. for an if_check which is referencing a person the only valid variables would be $i, $n, $t, $r or $q) A value type of string is a sequence of characters. It does not need to be included in quotes or anything like that (i.e. if name $n fido )

There are five types of if checks:

Type 1: Keyword and value

rand num Is random percentage less than or equal to num mobhere vnum Is a NPC with this vnum in the room mobhere name Is a NPC with this name in the room objhere vnum Is an object with this vnum in the room objhere name Is an object with this name in the room mobexists name Does NPC 'name' exist somewhere in the world objexists name Does object 'name' exist somewhere in the world

Type 2: Keyword, comparison and value

people == integer Is the number of people in the room equal to integer players == integer Is the number of PCs in the room equal to integer mobs == integer Is the number of NPCs in the room equal to integer clones == integer Is the number of NPCs in the room with the same vnum as the NPC who activated the program equal to integer order == integer Is the order (of several similar NPCs) of the NPC who activated the trigger equal to integer hour == integer Is the hour (game time) equal to integer

Type 3: Keyword and actor

isnpc $ Is $ an NPC ispc $ Is $ a PC isgood $ Does $ have a good alignment isneutral $ Does $ have a neutral alignment isevil $ Does $ have an evil alignment isimmort $ Is $ an immortal (level of $ > LEVEL_HERO) ischarm $ Is $ affected by charm isfollow $ Is $ a follower with their master in the room isactive $ Is $'s position > POS_SLEEPING isdelay $ Does $ have a delayed MOBprogram pending isvisible $ Is $ visible to NPC who activated the program hastarget $ Does $ have a MOBprogram target in the room istarget $ Is $* the target of NPC who activated the program

Type 4: Keyword, actor and value

affected $ 'affect' Is $ affected by 'affect' act $ 'act' Is $'s ACT bit 'act' set off $ 'off' Is $'s OFF bit 'off' set imm $ 'imm' Is $'s IMM bit 'imm' set carries $ 'name' Is $ carrying object 'name' wears $ 'name' Is $ wearing object 'name' has $ 'type' Does $ have object of item_type 'type' uses $ 'type' Is $ wearing object of item_type 'type' name $ 'name' Is $'s name 'name' pos $ 'position' Is $'s position 'position' (sleeping etc.) clan $ 'name' Does $ belong to clan 'name' race $ 'name' Is $ of race 'name' class $ 'name' Is $'s class 'name' objtype $ 'type' Is $'s item_type 'type'

Type 5: Keyword, actor, comparison and value

vnum $ == integer Is $'s virtual number equal to integer hpcnt $ == integer Is $'s hitpoint percentage equal to integer room $ == integer Is vnum of the room $ is in equal to integer sex $ == integer Is $'s sex equal to integer level $ == integer Is $'s level equal to integer align $ == integer Is $'s alignment equal to integer money $ == integer Does $ have money (in silver) equal to integer objval# $ == integer Is $->value[#] equal to integer (# from 0-4)

NOTE: The original MERC 2.2 MOBprograms used parenthesis '(' and ')' around variables. In this version, they are not allowed. Also,parameters MUST BE separated with spaces (if level $n<10 is NOT valid, correct syntax is: if level $n < 10).

------------------------New Commands Of Interest----------------------------- 1. GENERAL COMMANDS

Syntax: SURRENDER

This command can be issued in combat. If the one giving the command
is a PC and the opponent is a NPC, the NPC will be checked for
a surrender trigger. If the trigger activates, the fight will be
terminated. Otherwise the combat will resume normally. Note that
the mobile can resume the combat in the MOBprogram (see MOB KILL).
If anyone (PC or NPC) surrenders to a PC, the combat will terminate.
The PC can resume the combat with 'kill' command.
With this command, and the use of surrender trigger, non-lethal
combat can be implemented (arenas etc.).
  1. DIAGNOSTIC COMMANDS

    These two new commands are available to immortal players.

Syntax: MPSTAT [mobile]

Displays the triggers and MOBprogram vnums defined for the mobile.

Syntax: MPDUMP [vnum]

Displays the MOBprogram code of given vnum.
  1. MOBCOMMANDS

    MOBcommands are special commands that allow mobiles to perform immortal-like actions within a MOBprogram (transferring players or loading items, for example). Most MOBcommands them are wiz commands which have been changed to allow for mobiles to perform the commands. In this version of MOBprograms, players have been prevented from using these commands by adding a separate interpreter for MOBcommands. This also speeds up (in most cases) MOBprogram execution when MOBcommands are used. All MOBcommands are preceded with the word 'MOB' on the command line.

Syntax: MOB ASOUND [string] MOB ZECHO [string] MOB GECHO [string]

ASOUND prints the text string to the rooms around the mobile in the
same manner as a death cry. This is really useful for powerful
aggressives and is also nice for wandering minstrels or mobiles like
that in concept.
ZECHO prints the string to all players in the same area with the
mobile. GECHO prints the string to all players in the game.

Syntax: MOB ECHO [string] MOB ECHOAT [victim] [string] MOB ECHOAROUND [victim] [string]

ECHO displays the string to everyone in the room. ECHOAT displays
the string to the victim only. ECHOAROUND displays the string to
everyone except the victim.
The three options let you tailor the message to goto victims or to do
things sneaky like having a merchant do:
mob at guard mob echoat guard rescue_please
This coupled with a guard act trigger on rescue_please to:
mob goto $n
mob echo $I has arrived.
It is an affective way of quickly bringing guards to the scene of
an attack. (Note that the merchant has to be the only one of its
kind in the game or have a unique name, otherwise the guard might
go to different mobile...).

Syntax: MOB MLOAD [vnum] MOB OLOAD [vnum] [level] {'room'|'wear'}

    MLOAD creates a mobile and places it in the same room with the
mobile.
OLOAD loads the object into the inventory of the mobile. Even if the
item is non-takable, the mobile will receive it in the inventory.
This lets a mobile distribute a quest item or load a key or something.
The optional 3rd parameter can be specified; 'room' means to load
the object to the room, 'wear' means to force the mobile to wear
the object loaded (useful for equipping mobiles on the fly).

Syntax: MOB KILL [victim]

Lets a mobile kill a player without having to murder. Lots of
MOBprograms end up with mpkill $n commands floating around. It
works on both mobiles and players.

Syntax: MOB FLEE

Causes a mobile to unconditionally flee from combat. Can be used
for example with the hit point percentage trigger to simulate
"wimpy" behavior.

Syntax: MOB REMOVE [victim] [vnum|'all']

Lets the mobile to strip an object of given vnum from the victim.
Objects removed are destroyed. If the vnum is replaced with "all",
the whole inventory of the victim is destroyed. This command is
probably most useful for extracting quest items from a player
after a quest has been completed.

Syntax: MOB JUNK [object]

Destroys the object refered to in the mobile's inventory. It prints
no message to the world and you can do things like junk all.bread or
junk all. This is nice for having janitor mobiles clean out their
inventory if they are carrying too much (have a MOBprogram trigger on
the 'full inventory')

Syntax: MOB PURGE [argument]

Destroys the argument from the room of the mobile. Without an argument
the result is the cleansing of all NPC's and items from the room with
the exception of the mobile itself.  However, mppurge $i will indeed
purge the mobile, but it MUST be the last command the mobile tries to
do, otherwise the mud cant reference the acting mobile trying to do the
commands and bad things happen.

Syntax: MOB AT [location] [command]

Perfoms the command at the designated location. Very useful for doing
magic slight of hand tricks that leave players dumbfounded.. such as
metamorphing mobiles, or guard summoning, or corpse vanishing.

Syntax: MOB GOTO [location]

Moves the mobile to the room or mobile or object requested. It makes
no message of its departure or of its entrance, so these must be
supplied with echo commands if they are desired.

Syntax: MOB TRANSFER [victim|'all'] [location] MOB GTRANSFER [victim] [location] MOB OTRANSFER [object] [location]

Sends the victim to the destination or to the room of the mobile as a
default.  if the victim is "all" then all the characters in the room
of the mobile are transfered to the destination.  Good for starting
quests or things like that.  There is no message given to the player
that it has been transfered and the player doesnt do a look at the
new room unless the mob forces them to.
Gtransfer works like transfer, except that the group the victim
belongs to is transferred with the victim. Otransfer transfers an
object in the room.

Syntax: MOB FORCE [victim|'all'] [command] MOB GFORCE [victim] [command] MOB VFORCE [vnum] [command]

Forces the victim to do the designated command. The victim is not told
that they are forced, they just do the command so usually some mpecho
message is nice.  You can force players to remove belongings and give
them to you, etc.  The player sees the normal command messages (such as
removing the item and giving it away in the above example)  Again, if
the victim is "all" then everyone in the mobiles room does the command.
Gforce works like force except that it affects the group the victim
belongs to.
Vforce affects all mobiles with given vnum in the game world. This
is useful for, for example, purging certain type of NPCs from the
game (by forcing them to purge themselves).

Syntax: MOB CAST [spell] [victim]

Lets the mobile to cast spells. Beware, this does only crude validity
checking and does not use up any mana. All spells are available
regardless of the race or other abilities of the mobile. Casting the
spell occurs silently, but spell effects are displayed normally.

Syntax: MOB DAMAGE [victim|'all'] [min] [max] {lethal}

Causes unconditional damage to the victim. Specifying "all" as
victim causes damage to all characters in the room except the mobile.
Min and max parameters define the minimum and maximum amounts of
damage caused. By default, the damage is non-lethal, but by supplying
the optional 'lethal' parameter, the damage can kill the victim.
This command is silent, you must echo all messages yourself in the
program. Useful for implementing special attacks for mobiles.

Syntax: MOB DELAY MOB CANCEL

MOB DELAY sets the time in PULSE_MOBILE after which the mobile's
delay trigger is activated. If the mobile has a program defined
for delay trigger, the program is executed when the timer expires.
MOB CANCEL resets the delay timer.

Syntax: MOB REMEMBER [victim] MOB FORGET

This command enables the mobile to remember a player for future
reference in a MOBprogram. The player can subsequently be referred
as '$q' in programs activated by the mobile. MOB FORGET clears
the target. Note that if the first time the mobile runs a program,
$q is automatically set to the player who triggered the event.
Most commonly this command is used in delayed programs, where the
mobile has to remember the player who triggered the original
event, for example to continue conversation.

Syntax: MOB CALL [vnum] {victim} {target1} {target2}

This command lets you call MOBprograms from within a running one,
i.e. to call a MOBprogram subroutine. The first parameter is the
vnum of the program to execute, the second is the victim's name
(for example $n), and the third and fourth are optional object
names. All other parameters except vnum can be replaced with
word 'null' indicating ignored parameter.
MOBprograms can be called recursively, but as a safety measure,
parser allows only 5 recursions.

--------------------------Regarding CPU Slowdown-------------------------------

In the original MERC 2.2 MOBprogram documentation Nata'sha and Kahn wrote: "We have no real idea how slow this makes a mud. However, you will find that if you are judicious with your use of MOBprograms, you can either do little damage, or even reduce the effort on your server! This means that mobile polling (including the rand_progs) need only be checked when players are around. This reduces computation of random_stuff a little, but it is still a polling method, and subject to a basic inefficiency there. However, aside from the rand_progs, the only additional slowdowns will be when the mobile is responding to the situation, and you would get that from a special procedure as well (although MOBprograms are surely not as efficient as compiled C code)" I have used MOBprograms extensively in my own mud without adverse effects. This version of MOBprograms polls random triggers only when there are players in the area, so the load is kept to minimum. I would venture to claim that in most cases, line lag will exceed machine lag even with ample and complex use of MOBprograms.

--------------------------Loading Mobiles and Objects--------------------------

No doubt you want to load objects and mobiles in your MOBprograms

with "mob oload" and "mob mload". There are two problems connected to this. One is that mloaded mobiles will appear without equipment and the other is that it is difficult to keep track of the number of created mobiles and objects. If you want to mobiles to appear in your area as a result of the players' action, create a "storage room". Define resets for the mobiles as usual (equipment etc.) and place them in the storage room. When you need to use the mobiles, just "mob transfer" them to the location you want. This is better than creating mobiles on the fly, since you don't have to worry about creating too many mobiles or equipping them, area resets take care of all that. If you have a MOBprogram that creates new mobiles, you might want to make the mobiles "self-destructing". This is easiest to do with a random trigger that checks if the mobile is doing anything useful and possibly does 'mob purge $i'. Another possibility is to use a "purgemaster". Create a storage room with a single mobile. Attach a random trigger that does 'mob purge' to that mobile. Now, when you need to get rid of anything, just 'mob transfer' the mobile or item to purgemaster, and it will be destroyed sometime later.

-------------------------Miscellaneous Information-----------------------------

There is really no limit to the number of MOBprograms a given mobile

can have. However, the length of a single command block is limited by the value of MAX_STRING_LENGTH. In my version it was around 4k, so that is probably about 100 lines. The indentation spaces shown in the example above are NOT required, but do make it easier to read (and debug). HOWEVER, all spaces and indentations are loaded into memory as a part of the program, so you're using up memory unnecessarily. Memory usage can also be reduced by using subroutines (see MOB CALL).

It IS possible to accidentally make mobiles which can trigger in

loops. Infinite loops have been prevented, but in case of a loop, the mobile behavior is undefined.

The list of variables and triggers and if_checks will grow

continuously as mud creators demand the ability to do certain things. If you have a request or if you have a new one, I don't mind hearing about them, and if you find bugs, I shall gladly attempt to squash them for you. As additions or fixes are made, the code will occasionally be redistributed. However, if you want a current version, please feel free to ask. When the code is redistributed, a file containing the change history from the original release will be provided (when possible) to allow you to patch in the changes with low grief.

----------------------------------Credits-----------------------------------

The reason this code was written was to enhance the playing

experience at ThePrincedom (a Merc 2.0 based world scheduled to open in October 1993)

The original idea for this type of MOBprogram came from playing on:

WORLDS of CARNAGE, a dikumud implemented by Robbie Roberts and Aaron Buhr. Aaron (known as Dimwit Flathead the First) was the original author from what I have been told, and I hope he will not be totally offended and angered by my coding and sharing a mimicked version with the world. This version is probably not as good as the original and I do feel remorse for publishing the idea. However, since Carnage has been down for months without a word of information regarding its return, I am glad to let one of the best features live on in future generations of MUDs.

There are no objections to this code being shared, since, aside from

a nuclear destruction of all the Temples of Midgaard (excepting the original one!!), bland mobiles are the greatest bane of Dikumuds today. It would be nice to get a message saying you are using the code just for our references. We shant answer questions from anyone until told where they are using the code. grin Since this code is not copyrighted, you of course dont have to do anything we say, but it would be nice of you to put the mobprog help screen into your database. and have mobinfo show up somewhere on a more visable help screen (possibly tagged onto the bottom of credits as a see also...)

I acknowledge all the work done by the original Diku authors as well as

those at Merc Industries and appreciate their willingness to share code. Also, quick thanks to Wraith for doing a little beta-installation testing.

N'Atas-Ha June, 1993 natasha@gs118.sp.cs.cmu.edu

In addition to this DOC file credit section, I'd like to add

a thank you to Yaz, Mahatma, Zelda, and the rest of the 4th Realm crew for extensively testing MOBProgram 2.1 for me. You may see MOBPrograms in action as well as their own "flavor" of mud at marble.bu.edu 4000.

Kahn Oct 28th, 1993 MERC Industries

This driver was rewritten by me in summer '95. I also added

room and object programs (not in ROM 2.4 version). While I acknowledge the skill and insight of the above people who conceived the original MOBprogram idea, they should not be held responsible in any way for this release. I can't promise I will be able to support this code in the future, use at your own risk. However, if you're using this code, and/or have bug reports or improvements, I'd be glad to hear from you. The revised MOBprograms can be seen in action at Imperium Gothique, mud.pitek.fi 4000. This code may be freely used and distributed, but some favorable publicity (such as having my name appended to your in-game credits) would encourage me to develop this software.

Newt@Imperium Gothique May 1995-Jan 1996 mn54196@uta.fi (am I lazy or what?)

CUT HERE FOR QUICK REFERENCE SHEET

MOBprogram quick reference to triggers/variables/ifchecks/mobcommands


Area file format

MOBILES

M {trigger} {program vnum} {argument}~

MOBPROGS

{program vnum}

{program code}~


trigger argument and what must happen to activate trigger

act STRING to match from act() to mobile speech STRING to match in dialogue (say, tell) to mobile rand PERCENT chance to check whenever a PC is in the mobiles zone bribe INTEGER miminum amount of silver coins given to mobile give OBJECT NAME, OBJECT VNUM or ALL to match when obj given to mobile greet PERCENT chance to check if visible char enters mobile's room grall PERCENT chance to check when any char enters mobile's room entry PERCENT chance to check when mobile moves to a new room exit EXIT NUMBER a visible char tries to exit mobile's room exall EXIT NUMBER any char tries to exit mobile's room kill PERCENT chance to check when the mobile begins fighting fight PERCENT chance to check at fight_pulse if mobile is fighting hpcnt PERCENT lower than mobile's hit/max_hit if mobile is fighting death PERCENT chance to check after mobile has been slain surr PERCENT chance to activate when a char surrenders to mobile


variable mobile actor victim random target object 2nd_object

name $i $n $t $r $q $o $p shrt_desc/title $I $N $T $R $Q $O $P he/she/it $j $e $E $J $X -- -- him/her/it $l $m $M $L $Y -- -- his/hers/its $k $s $S $K $Z -- -- a/an -- -- -- -- -- -- --


ifcheck argument(s) meaning

rand num Is random percentage less than or equal to num mobhere vnum Is a NPC with this vnum in the room mobhere name Is a NPC with this name in the room objhere vnum Is an object with this vnum in the room objhere name Is an object with this name in the room mobexists name Does NPC 'name' exist somewhere in the world objexists name Does object 'name' exist somewhere in the world


people == integer Is the number of people in the room equal to integer players == integer Is the number of PCs in the room equal to integer mobs == integer Is the number of NPCs in the room equal to integer clones == integer Is the number of NPCs in the room with the same


isnpc $ Is $ an NPC ispc $ Is $ a PC isgood $ Does $ have a good alignment isneutral $ Does $ have a neutral alignment isevil $ Does $ have an evil alignment isimmort $ Is $ an immortal (level of $ > LEVEL_HERO) ischarm $ Is $ affected by charm isfollow $ Is $ a follower with their master in the room isactive $ Is $'s position > POS_SLEEPING isdelay $ Does $ have a delayed MOBprogram pending isvisible $ Is $ visible to NPC who activated the program hastarget $ Does $ have a MOBprogram target in the room istarget $ Is $* the target of NPC who activated the program


affected $ 'affect' Is $ affected by 'affect' act $ 'act' Is $'s ACT bit 'act' set off $ 'off' Is $'s OFF bit 'off' set imm $ 'imm' Is $'s IMM bit 'imm' set carries $ 'name' Is $ carrying object 'name' wears $ 'name' Is $ wearing object 'name' has $ 'type' Does $ have object of item_type 'type' uses $ 'type' Is $ wearing object of item_type 'type' name $ 'name' Is $'s name 'name' pos $ 'position' Is $'s position 'position' (sleeping etc.) clan $ 'name' Does $ belong to clan 'name' race $ 'name' Is $ of race 'name' class $ 'name' Is $'s class 'name' objtype $ 'type' Is $'s item_type 'type'


vnum $ == integer Is $'s virtual number equal to integer hpcnt $ == integer Is $'s hitpoint percentage equal to integer room $ == integer Is vnum of the room $ is in equal to integer sex $ == integer Is $'s sex equal to integer level $ == integer Is $'s level equal to integer align $ == integer Is $'s alignment equal to integer money $ == integer Does $ have money (in silver) equal to integer objval# $ == integer Is $->value[#] equal to integer (# from 0-4)


MOBcommand argument_list MOBcommand argument_list

ASOUND [text_string] ECHO [text_string] GECHO [text_string] ZECHO [text_string] ECHOAT [victim] [text_string] ECHOAROUND [victim] [text_string] MLOAD [vnum] OLOAD [vnum] [level] {wear|room} KILL [victim] FLEE REMOVE [victim] [vnum] MOB JUNK [object] PURGE [argument] AT [dest] [command] GOTO [dest] TRANSFER [victim] [dest] GTRANSFER [victim] [dest] OTRANSFER [object] [dest] FORCE [victim] [command] GFORCE [victim] [command] VFORCE [vnum] [command] CAST [spell] [victim] DAMAGE [victim] [min] [max] {lethal} DELAY CANCEL REMEMBER [victim] FORGET CALL [vnum] [victim] [target1] [target2]

END OF QUICK REFERENCE SHEET

+++++++++++++++++++++++++++++++ EXAMPLES ++++++++++++++++++++++++++++++++++++

In #MOBILES:

M act 1000 pokes you in the ribs.~

In #MOBPROGS:

1000

if isnpc $n chuckle poke $n break else if level $n <= 5 or isgood $n tell $n I would rather you didnt poke me. else if level $n > 15 scream say Ya know $n. I hate being poked!!! if mobhere guard mob force guard kill $n endif kill $n break endif slap $n shout MOMMY!!! $N is poking me. endif endif ~

Ok.. time to translate.. the trigger will only happen when the mobile gets the message "... pokes you in the ..." If the offender (recall the $n and $N refer to the char who did the poking...) is an NPC, then the mobile merely chuckles and pokes back. If the offender was a PC then good and low level characters get a warning, high level chars get attacked, and midlevel chars get slapped and whined at. Also, when attacking, the mobile will check if there are guards in the room (if mobhere guard) and if one is found, it will be forced to attack the player, too (mob force guard mob kill $n). Notice the use of a MOBcommand "mob force".

Note that two of these mobiles could easily get into an infinite poke war which slows down (or frequently crashes) the mud just a bit :( Be very careful about things like that if you can. (i.e dont respond to a poke with a poke, and try not to let heavily programmed robot mobiles wander around together. More on that is given above.)

Also, it is clear that the 'order' command could get confused with the 'or' control flow. However, this is only the case when 'order' is abbreviated to its two letter form, and placed immediately following an 'if' line. Thus, if you want to be that malicious in trying to break the MOBprogram code, noone is going to stand in your way (However, the result of this would be a bug message and a bail out from the ifcheck so things dont really break)

Another example:

This program could be used on a temple guardian mobile, whose job is to prevent evil characters from entering the sanctuary. Let's assume the exit to the temple is north (exit 0) and the temple antechamber is room 2301

In #MOBILES

M exit 1001 0

In #MOBPROGS

1001

if isgood $n say Hail! emote salutes $n. if carries $n holy mob transfer $n 2301 else say If you wish to enter the temple, get a holy symbol. endif else curse $n say Get lost, you scum! endif ~

How this works: The trigger is activated when the player tries to exit north from the room. If the player is of good alignment, the guard will greet the player. However, the guard will not let the player to the temple unless he or she carries a holy symbol. If the player is neutral or evil, the guard will curse and block the way.

Example of using DELAY and REMEMBER:

In #MOBILES

M greet 1002 100 M delay 1003 100

In #MOBPROGS

1002

if isevil $n say You infidel! Go away or face the wrath of mighty Mota! mob remember $n mob delay 10 break endif ~

1003

if hastarget $i growl mob echo $I screams and attacks $Q. mob kill $q else mob forget endif ~

How this works: When the player enters a room, the mobile checks if the player is evil. If this is the case, the mobile makes the player the target (mob remember) and sets up a delay of 10 * PULSE_MOBILE. When the delay expires, program #1003 is activated. The mobile checks if the target is still in the room (hastarget), and if the player hasn't left, the mobile attacks ($q and $Q refer to the target). If the player has left, the mobile will forget the player (mob forget).

Example of MOB CALL:

In #MOBILES:

M greet 1004 100

In #MOBPROGS:

1004

if isgood $n mob call 1005 $n null null else mob call 1006 $n null null endif ~

1005

mob echo Suddenly, a bright aura surrounds $I! mob cast 'heal' $n ~

1006

mob echoat $n $I points $l finger at you in fury! mob echoaround $I points $l finger at $N in fury! mob cast 'curse' $n ~

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Mob Program Reference

Source: docs/manuals/mob-program-reference.md

Mob Program Reference

Overview

Mob programs (mob_progs) allow non-player characters to react to in-game events through a small scripting language interpreted by the MUD engine. Each program is stored in an MPROG_DATA structure linking to the next program and containing its trigger type, argument list, and command list.

Data Structures

  • MPROG_DATA stores next, type, arglist, and comlist fields.
  • MPROG_ACT_LIST queues pending triggers with fields for the triggering character, object, and data pointer.
  • MPROG_CAN_SEE caches visibility checks to temporarily override sight rules.

Trigger Types

Programs use bit flags to declare which events they handle:

Flag Purpose
ACT_PROG reacts to act() messages
SPEECH_PROG triggered by player speech
RAND_PROG random chance every pulse
FIGHT_PROG during combat rounds
DEATH_PROG upon mob death
HITPRCNT_PROG when hit points fall below a percentage
ENTRY_PROG when a player enters the room
GREET_PROG greets a player in the same room
ALL_GREET_PROG greets every player
GIVE_PROG when given an object
BRIBE_PROG when bribed with gold

Programs defined in external files use IN_FILE_PROG to indicate that additional scripts are included from other files.

Program Files

A mob_prog file contains one or more program blocks:

>trigger_type argument~
commands...
~
|  (end of file)

Each block starts with > followed by the textual trigger name (e.g., greet_prog) and an argument list terminated by ~. The command list follows and is also terminated by ~. The file ends with a line containing |.

To attach a program to a mobile, area files use the M directive followed by the mob vnum and the program filename. During boot, load_mobprogs loads the file and sets the mob's progtypes flags.

Variable Expansion

Within commands, $ codes are replaced with context-specific values:

Code Meaning
$i / $I mob's name / short description
$n / $N actor's name / short description
$t / $T secondary target's name / short description (character)
$r / $R random character in room name / short description
$e $m $s actor pronouns
$E $M $S target pronouns
$j $k $l mob pronouns
$J $K $L random character pronouns
$o / $O object name / short description
$p / $P secondary object name / short description
$a / $A article for object / secondary object
$$ a literal dollar sign

Gotcha: Using $t when the secondary target is an object may crash the engine; act() assumes $t refers to a character.

Control Flow

Scripts support structured control flow:

  • if <check> ... endif — conditional execution
  • or — additional condition in the same if
  • else — alternate branch
  • break — aborts the current block

String comparisons accept operators ==, !=, / (contains), and !/ (does not contain). Numeric comparisons accept ==, !=, >, <, >=, <=, &, and |.

If Checks

The if statement evaluates a variety of checks. Arguments typically reference one of the $ variables (e.g., $n). All checks return boolean values or compare against an operator and value.

Check Description
rand(n) true n% of the time
ispc($x) / isnpc($x) whether the referenced character is a player or mob
isgood($x) alignment > 750
isfight($x) character currently fighting
isimmort($x) character has immortal level
ischarmed($x) affected by charm
isfollow($x) has a master in same room
isaffected($x) & flag affected_by bitmask
hitprcnt($x) < n hit points percentage comparison
inroom($x) == vnum room vnum comparison
sex($x) == n sex (0 neutral,1 male,2 female)
position($x) == n position constant
level($x) >= n trust level
align($x) < n alignment value
class($x) == n class index
race($x) == name race check
goldamt($x) > n gold carried
objtype($o) == n object type number
objval0-3($o) == n object value[] fields
number($x) == vnum vnum for mobs/objects
name($x) / 'text' string comparisons on names
tribe($x) == 'name' tribe name
isleader($x) character has leader flag
isntpet($x) character is not flagged as a pet
mobhere(vnum[,room]) mob with vnum present here or in room
objhere(vnum|name) object present in room
hasobj(vnum) actor carries object vnum

Execution

mprog_driver processes each command, temporarily overrides visibility with MOBcansee, and resets the global MOBtrigger flag after each act() to prevent recursive triggers. Random variables $r/$R select a random visible player in the room.

Writing Mob Programs

  1. Create a file under area/MOBProgs following the block format shown above.
  2. Use $ variables and if checks as needed to craft responses.
  3. Add an entry in the area file's MOBPROGS section: M <mob_vnum> <filename>
  4. Reboot or reload the area to activate the script.

Example:

>greet_prog 100~
if ispc($n)
  say Hello, $n!
endif
~
|

Debugging

Use the mpstat command to list programs attached to a mob and verify triggers and arguments.


Area Builder Cheat Sheet

Source: docs/reference/area-builder-cheat-sheet.md

Area Builder Cheat Sheet

Quick reference for building areas in MadROM. The lists below summarize common flags, types, and values used when defining area data.

Mobiles

Act Flags

  • ACT_SENTINEL (B)
  • ACT_SCAVENGER (C)
  • ACT_SMART (D)
  • ACT_AGGRESSIVE (F)
  • ACT_STAY_AREA (G)
  • ACT_WIMPY (H)
  • ACT_PET (I)
  • ACT_TRAIN (J)
  • ACT_PRACTICE (K)
  • ACT_NOPURGE (V)
  • ACT_IS_HEALER (aa)
  • ACT_GAIN (bb)
  • ACT_UPDATE_ALWAYS (cc)
  • ACT_NOWANDER (dd)

Races

unique, human, elf, dragon, hobbit, orc, bear, cat, centipede, difo, fox, goblin, lizard, modron, pig, song bird, troll, water fowl, dwarf, giant, wolf, bat, dog, doll, hobgoblin, kobold, rabbit, snake, wyvern

Mobile Size

  • T — tiny
  • S — small
  • M — medium
  • L — large
  • H — huge
  • G — giant

Affected Flags

  • AFF_BLIND (A)
  • AFF_INVISIBLE (B)
  • AFF_DETECT_EVIL (C)
  • AFF_DETECT_INVIS (D)
  • AFF_DETECT_MAGIC (E)
  • AFF_DETECT_HIDDEN (F)
  • AFF_SANCTUARY (H)
  • AFF_FAERIE_FIRE (I)
  • AFF_INFRARED (J)
  • AFF_CURSE (K)
  • AFF_POISON (M)
  • AFF_PROTECT (N)
  • AFF_SNEAK (P)
  • AFF_HIDE (Q)
  • AFF_SLEEP (R)
  • AFF_CHARM (S)
  • AFF_FLYING (T)
  • AFF_PASS_DOOR (U)
  • AFF_HASTE (V)
  • AFF_CALM (W)
  • AFF_PLAGUE (X)
  • AFF_WEAKEN (Y)
  • AFF_DARK_VISION (Z)
  • AFF_BERSERK (a)
  • AFF_SWIM (b)
  • AFF_REGENERATION (c)

Off Bits

  • OFF_AREA_ATTACK (A)
  • OFF_BACKSTAB (B)
  • OFF_BASH (C)
  • OFF_BERSERK (D)
  • OFF_DISARM (E)
  • OFF_DODGE (F)
  • OFF_FADE (G)
  • OFF_FAST (H)
  • OFF_KICK (I)
  • OFF_KICK_DIRT (J)
  • OFF_PARRY (K)
  • OFF_RESCUE (L)
  • OFF_TAIL (M)
  • OFF_TRIP (N)
  • OFF_CRUSH (O)
  • ASSIST_ALL (P)
  • ASSIST_ALIGN (Q)
  • ASSIST_RACE (R)
  • ASSIST_PLAYERS (S)
  • ASSIST_GUARD (T)
  • ASSIST_VNUM (U)

Immunities

  • IMM_SUMMON (A)
  • IMM_CHARM (B)
  • IMM_MAGIC (C)
  • IMM_WEAPON (D)
  • IMM_BASH (E)
  • IMM_PIERCE (F)
  • IMM_SLASH (G)
  • IMM_FIRE (H)
  • IMM_COLD (I)
  • IMM_LIGHTNING (J)
  • IMM_ACID (K)
  • IMM_POISON (L)
  • IMM_NEGATIVE (M)
  • IMM_HOLY (N)
  • IMM_ENERGY (O)
  • IMM_MENTAL (P)
  • IMM_DISEASE (Q)
  • IMM_DROWNING (R)
  • IMM_LIGHT (S)
  • IMM_BLIND (T)
  • IMM_LETH (U)
  • IMM_SLEEP (V)

Resistances

  • RES_SUMMON (A)
  • RES_CHARM (B)
  • RES_MAGIC (C)
  • RES_WEAPON (D)
  • RES_BASH (E)
  • RES_PIERCE (F)
  • RES_SLASH (G)
  • RES_FIRE (H)
  • RES_COLD (I)
  • RES_LIGHTNING (J)
  • RES_ACID (K)
  • RES_POISON (L)
  • RES_NEGATIVE (M)
  • RES_HOLY (N)
  • RES_ENERGY (O)
  • RES_MENTAL (P)
  • RES_DISEASE (Q)
  • RES_DROWNING (R)
  • RES_LIGHT (S)
  • RES_BLIND (T)
  • RES_LETH (U)
  • RES_SLEEP (V)

Vulnerabilities

  • VULN_SUMMON (A)
  • VULN_CHARM (B)
  • VULN_MAGIC (C)
  • VULN_WEAPON (D)
  • VULN_BASH (E)
  • VULN_PIERCE (F)
  • VULN_SLASH (G)
  • VULN_FIRE (H)
  • VULN_COLD (I)
  • VULN_LIGHTNING (J)
  • VULN_ACID (K)
  • VULN_POISON (L)
  • VULN_NEGATIVE (M)
  • VULN_HOLY (N)
  • VULN_ENERGY (O)
  • VULN_MENTAL (P)
  • VULN_DISEASE (Q)
  • VULN_DROWNING (R)
  • VULN_LIGHT (S)
  • VULN_BLIND (T)
  • VULN_LETH (U)
  • VULN_SLEEP (V)
  • VULN_WOOD (X)
  • VULN_SILVER (Y)
  • VULN_IRON (Z)

Positions

  • POS_SLEEPING — 4
  • POS_RESTING — 5
  • POS_SITTING — 6
  • POS_STANDING — 8

Sex

  • NEUTRAL — 0
  • MALE — 1
  • FEMALE — 2

Damage Types

Value Type Value Type
0 HIT 17 PUNCH
1 SLICE 18 WRATH
2 STAB 19 MAGIC
3 SLASH 20 DIVINE POWER
4 WHIP 21 CLEAVE
5 CLAW 22 SCRATCH
6 BLAST 23 PECK (pierce)
7 POUND 24 PECK (bash)
8 CRUSH 25 CHOP
9 GREP 26 STING
10 BITE 27 SMASH
11 PIERCE 28 SHOCKING BITE
12 SUCTION 29 FLAMING BITE
13 BEATING 30 FREEZING BITE
14 DIGESTION 31 ACIDIC BITE
15 CHARGE 32 CHOMP
16 SLAP

Objects

Object Types and Format Lines

  • ITEM_LIGHT (1): <unused> <unused> <999> <unused> <unused>
  • ITEM_SCROLL (2): <spell lvl> <sn1> <sn2> <sn3> <unused>
  • ITEM_WAND (3): <spell lvl> <maximum charges> <current charges> <sn> <unused>
  • ITEM_STAFF (4): <spell lvl> <max charges> <current charges> <sn> <unused>
  • ITEM_WEAPON (5): <weap class> <# dam dice> <type dam dice> <dam type> <weap type>
  • ITEM_TREASURE (8): <unused> <unused> <unused> <unused> <unused>
  • ITEM_ARMOR (9): <value pierce> <value bash> <value slash> <value magic> <unused>
  • ITEM_POTION (10): <spell lvl> <sn1> <sn2> <sn3> <unused>
  • ITEM_CLOTHING (11)
  • ITEM_FURNITURE (12): <unused> <unused> <unused> <unused> <unused>
  • ITEM_TRASH (13): <unused> <unused> <unused> <unused> <unused>
  • ITEM_CONTAINER (15): <wgt. capacity> <container FLAGS> <key vnum> <unused> <unused>
  • ITEM_DRINK_CON (17): <capacity> <cur qty> <liq#> <0 if NON-ZERO, poisoned> <unused>
  • ITEM_KEY (18): <unused> <unused> <unused> <unused> <unused>
  • ITEM_FOOD (19): <hours value> <unused> <unused> <unused> <unused>
  • ITEM_MONEY (20): <value in gold> <unused> <unused> <unused> <unused>
  • ITEM_BOAT (22): <unused> <unused> <unused> <unused> <unused>
  • ITEM_FOUNTAIN (25): <unused> <unused> <liquid type> <unused> <unused>
  • ITEM_PILL (26): <spell lvl> <sn1> <sn2> <sn3> <unused>
  • ITEM_PROTECT (27)
  • ITEM_MAP (28): <1> <unused> <unused> <unused> <unused>
  • ITEM_JUKEBOX (29): crickets -1 -1 -1 -1 -1
  • ITEM_PORTAL (30): <to_room> <gate flags> <exit flags> <# charges> <key vnum>
  • ITEM_EXPLOSIVE (31): <spell lvl> <sn1> <sn2> <sn3> <unused>
  • ITEM_LIQUID (32)
  • ITEM_CHAOS_FOOD (43)
  • ITEM_FOOD_BAD_BREATH (44)

Common Materials

cloth, leather, pill, paper, vellum, glass, wood, steel, bronze, brass, iron, gold, silver, adamantite, stone

Object Flags

  • ITEM_GLOW (A)
  • ITEM_HUM (B)
  • ITEM_EVIL (E)
  • ITEM_INVIS (F)
  • ITEM_NODROP (H)
  • ITEM_BLESS (I)
  • ITEM_ANTI_GOOD (J)
  • ITEM_ANTI_EVIL (K)
  • ITEM_ANTI_NEUTRAL (L)
  • ITEM_NOREMOVE (M)
  • ITEM_INVENTORY (N)
  • ITEM_NOPURGE (O)
  • ITEM_ROT_DEATH (P)
  • ITEM_VIS_DEATH (Q)
  • ITEM_MELT_DROP (R)
  • ITEM_FLOAT (S)
  • ITEM_GOOD (T)

Wear Flags

  • ITEM_TAKE (A)
  • ITEM_WEAR_FINGER (B)
  • ITEM_WEAR_NECK (C)
  • ITEM_WEAR_BODY (D)
  • ITEM_WEAR_HEAD (E)
  • ITEM_WEAR_LEGS (F)
  • ITEM_WEAR_FEET (G)
  • ITEM_WEAR_HANDS (H)
  • ITEM_WEAR_ARMS (I)
  • ITEM_WEAR_SHIELD (J)
  • ITEM_WEAR_ABOUT (K)
  • ITEM_WEAR_WAIST (L)
  • ITEM_WEAR_WRIST (M)
  • ITEM_WIELD (N)
  • ITEM_HOLD (O)

Weapon Class

  • WEAPON_EXOTIC — 0
  • WEAPON_SWORD — 1
  • WEAPON_DAGGER — 2
  • WEAPON_SPEAR — 3
  • WEAPON_MACE — 4
  • WEAPON_AXE — 5
  • WEAPON_FLAIL — 6
  • WEAPON_WHIP — 7
  • WEAPON_POLEARM — 8

Weapon Types

  • WEAPON_VAMPIRIC (C)
  • WEAPON_SHARP (D)
  • WEAPON_VORPAL (E)
  • WEAPON_TWO_HANDS (F)

Apply Bonus Types

  • APPLY_STRENGTH — 1
  • APPLY_DEX — 2
  • APPLY_INT — 3
  • APPLY_WIS — 4
  • APPLY_CON — 5
  • APPLY_SEX — 6
  • APPLY_MANA — 12
  • APPLY_HIT — 13
  • APPLY_MOVE — 14
  • APPLY_GOLD — 15
  • APPLY_AC — 17
  • APPLY_HITROLL — 18
  • APPLY_DAMROLL — 19
  • APPLY_SAVING_PARA — 20
  • APPLY_SAVING_ROD — 21
  • APPLY_SAVING_PETRI — 22
  • APPLY_SAVING_BREATH — 23
  • APPLY_SAVING_SPELL — 24

Container Flags

  • CONT_CLOSEABLE — 1
  • CONT_PICKPROOF — 2
  • CONT_CLOSED — 4
  • CONT_LOCKED — 8

Portal Gate Flags

  • GATE_NORMAL_EXIT (A)
  • GATE_NOCURSE (B)
  • GATE_GOWITH (C)
  • GATE_BUGGY (D)
  • GATE_RANDOM (E)
  • GATE_RANDOMAREA (F)

Portal Exit Flags

  • EX_ISDOOR (A)
  • EX_CLOSED (B)
  • EX_LOCKED (C)
  • EX_PICKPROOF (F)
  • EX_NOPASS (G)

Liquid Values

Value Name Value Name
0 LIQ_WATER 18 LIQ_WHITE_WINE
1 LIQ_BEER 19 LIQ_CHAMPAGNE
2 LIQ_RED_WINE 20 LIQ_MEAD
3 LIQ_ALE 21 LIQ_ROSE_WINE
4 LIQ_DARK_ALE 22 LIQ_BENEDICTINE_WINE
5 LIQ_WHISKEY 23 LIQ_VODKA
6 LIQ_LEMONADE 24 LIQ_CRANBERRY_JUICE
7 LIQ_FIREBREATHER 25 LIQ_ORANGE_JUICE
8 LIQ_LOCAL_SPECIALTY 26 LIQ_ABSINTHE
9 LIQ_SLIME_MOLD_JUICE 27 LIQ_BRANDY
10 LIQ_MILK 28 LIQ_AQAVIT
11 LIQ_TEA 29 LIQ_SCHNAPPS
12 LIQ_COFFEE 30 LIQ_ICEWINE
13 LIQ_BLOOD 31 LIQ_AMONTILLADO
14 LIQ_SALT_WATER 32 LIQ_SHERRY
15 LIQ_COLA 33 LIQ_FRAMBOISE
16 LIQ_ROOT_BEER 34 LIQ_RUM
17 LIQ_ELVISH_WINE 35 LIQ_CORDIAL

Rooms

Door States

  • 0 — unhindered exit
  • -1 — door with no keyhole
  • 1 — normal door
  • 2 — pick-proof door
  • 3 — pass proof door
  • 4 — pick and passproof door

Room Flags

  • ROOM_DARK (A)
  • ROOM_NO_SUMMIN (B)
  • ROOM_NO_MOB (C)
  • ROOM_INDOORS (D)
  • ROOM_NO_SUMMOUT (E)
  • ROOM_PRIVATE (J)
  • ROOM_SAFE (K)
  • ROOM_SOLITARY (L)
  • ROOM_PET_SHOP (M)
  • ROOM_NO_RECALL (N)
  • ROOM_IMP_ONLY (O)
  • ROOM_GODS_ONLY (P)
  • ROOM_HEROES_ONLY (Q)
  • ROOM_NEWBIES_ONLY (R)
  • ROOM_LAW (S)
  • ROOM_CHAOS (T)

Sector Types

  • SECT_INSIDE — 0
  • SECT_CITY — 1
  • SECT_FIELD — 2
  • SECT_FOREST — 3
  • SECT_HILLS — 4
  • SECT_MOUNTAIN — 5
  • SECT_WATER_SWIM — 6
  • SECT_WATER_NOSWIM — 7
  • SECT_AIR — 9
  • SECT_DESERT — 10

Resets

Wear_loc Values

  • WEAR_NONE — -1
  • WEAR_LIGHT — 0
  • WEAR_FINGER_L — 1
  • WEAR_FINGER_R — 2
  • WEAR_NECK_1 — 3
  • WEAR_NECK_2 — 4
  • WEAR_BODY — 5
  • WEAR_HEAD — 6
  • WEAR_LEGS — 7
  • WEAR_FEET — 8
  • WEAR_HANDS — 9
  • WEAR_ARMS — 10
  • WEAR_SHIELD — 11
  • WEAR_ABOUT — 12
  • WEAR_WAIST — 13
  • WEAR_WRIST_L — 14
  • WEAR_WRIST_R — 15
  • WEAR_WIELD — 16
  • WEAR_HOLD — 17
  • MAX_WEAR — 18

Shops

Object Types

  • ITEM_LIGHT (1)
  • ITEM_SCROLL (2)
  • ITEM_WAND (3)
  • ITEM_STAFF (4)
  • ITEM_WEAPON (5)
  • ITEM_TREASURE (8)
  • ITEM_ARMOR (9)
  • ITEM_POTION (10)
  • ITEM_CLOTHING (11)
  • ITEM_FURNITURE (12)
  • ITEM_TRASH (13)
  • ITEM_CONTAINER (15)
  • ITEM_DRINK_CON (17)
  • ITEM_KEY (18)
  • ITEM_FOOD (19)
  • ITEM_MONEY (20)
  • ITEM_BOAT (22)
  • ITEM_CORPSE_NPC (23)
  • ITEM_PILL (26)
  • ITEM_MAP (28)
  • ITEM_SINGING (29)
  • ITEM_PORTAL (30)
  • ITEM_EXPLOSIVE (31)

Specials

Spec Functions

spec_executioner, spec_fido, spec_guard, spec_janitor, spec_mayor, spec_poison, spec_thief, spec_puff, spec_wolf, spec_batmad, spec_smart, spec_cast_adept, spec_cast_cleric, spec_cast_judge, spec_cast_undead, spec_cast_mage, spec_breath_any, spec_breath_acid, spec_breath_fire, spec_breath_frost, spec_breath_gas, spec_breath_lightning


Command Table

Source: docs/reference/command-table.md

Command table

MadROM dispatches every player command through the global cmd_table defined in src/interp.c. Each entry uses the struct cmd_type layout declared in src/interp.h so that the interpreter can discover the handler function, the positions and trust levels that may execute it, and whether immortals should see it in command listings.

Entry layout

The fields of struct cmd_type describe both how a command is invoked and how it is presented:

Field Declared in Purpose
name src/interp.h Text players type at the prompt. Abbreviations work so long as they are unique.
do_fun src/interp.h Function pointer to the implementation, usually defined in one of the act_*.c files.
position src/interp.h Minimum character position (for example POS_DEAD, POS_STANDING) required before the interpreter will call the handler.
level src/interp.h Minimum level or trust that may use the command.
wizbit[WIZ_BITS] src/interp.h Optional wizard flag requirements. The stock table leaves these as zero but they can gate commands behind custom wiznet-style permissions.
log src/interp.c Controls logging with the LOG_NORMAL, LOG_ALWAYS, and LOG_NEVER constants. Entries flagged LOG_ALWAYS are written to the immortal log even without fLogAll.
show src/interp.c When set to FALSE the command is hidden from the commands listing, though it still works when typed directly.

Because the interpreter checks commands in the order they appear in cmd_table, related entries are commonly grouped together in the source file.

Adding a command

To wire a new command into the game:

  1. Declare the handler – Add a DECLARE_DO_FUN(do_yourcommand); prototype to src/interp.h so the table can reference it.
  2. Register the entry – Insert a row into cmd_table in src/interp.c with the command name, handler, required position, level, wizard bits, logging mode, and visibility flag.
  3. Implement the behavior – Provide the do_yourcommand function in an appropriate source file (often one of the act_*.c modules). Make sure it follows the standard signature so the interpreter can invoke it.

Immortal commands should set the level field to the appropriate trust threshold and toggle log or show to control auditing and visibility. Mortals-only commands typically leave wizbit at zero.

Social commands

Emotes and socials bypass the command table and instead use the social_table array that load_socials populates in src/db2.c. Each entry is a struct social_type with fields such as name, char_no_arg, others_no_arg, char_found, others_found, vict_found, and optional self-targeted strings. To add a social, append the new definition to the socials data file read by load_socials; the loader handles $ sentinels for empty strings and # markers that terminate each definition.

Logging and snooping

When the interpreter dispatches a command it calls the handler after running the logging and snoop hooks in src/interp.c. Commands that set log to LOG_ALWAYS, characters flagged with PLR_LOG, or a server with fLogAll enabled generate entries in the immortal log and on the secure wiznet channel. The snoop system also echoes the final command line to any administrators snooping the player before the handler executes.


Item Tier Boosts

Source: docs/reference/item-tier-boosts.md

Item Tier Boosts

MadROM automatically grants certain items a chance to receive a tier boost when they are created.

Eligibility

  • Item types: armor, light sources, and weapons
  • Level range: 30–91
  • Items already flagged as Ancient, Runic, or Elite are skipped

Tiers and drop rates

Tier Level range Drop chance Effect
Elite 30–59 10% +5 weapon dice or +40 stat boost
Runic 60–89 5% +10 weapon dice or +80 stat boost
Ancient 90–91 1% +25 weapon dice or +120 stat boost, announces to Discord

Boost details

  • Armor and light items receive a random bonus to hit roll, damage roll, mana, hit points, or movement.
  • Weapons gain flat increases to both the number and size of their damage dice.
  • Ancient items send a notification to Discord when generated.

Material Flags

Source: docs/reference/material-flags.md

Material Flags

These constants enumerate the material categories used by the object system.

Constant Value
MAT_PILL 1
MAT_PAPER 2
MAT_SILK 3
MAT_HAIR 4
MAT_CLOTH 5
MAT_PLANT 6
MAT_RUBBER 7
MAT_VELLUM 8
MAT_FOOD 9
MAT_PLASTIC 10
MAT_FLESH 11
MAT_FUNGUS 12
MAT_LEATHER 13
MAT_CHINA 14
MAT_GLASS 15
MAT_PORCELIN 16
MAT_IVORY 17
MAT_BONE 18
MAT_WOOD 19
MAT_PEARL 20
MAT_CRYSTAL 21
MAT_TIN 22
MAT_GOLD 23
MAT_COPPER 24
MAT_SILVER 25
MAT_BRONZE 26
MAT_BRASS 27
MAT_STONE 28
MAT_LEAD 29
MAT_IRON 30
MAT_STEEL 31
MAT_MITHRIL 32
MAT_PLATINUM 33
MAT_TITANIUM 34
MAT_KEVLAR 35
MAT_ADAMANTITE 36
MAT_GEMSTONE 37
MAT_DIAMOND 38
MAT_DARKNESS 39
MAT_CHAOS 40
MAT_LIQUID 41
MAT_ICE 42
MAT_AIR 43
MAT_ENERGY 44
MAT_FIRE 45

Miscellaneous Notes

Source: docs/reference/misc-notes.md

Miscellaneous Notes

BFM Test Server

bfm.iasis.net 1234

Diffing Trees

diff -brc

Sorting Hash Keys in Perl

foreach $key (sort(keys %myhash )) {
   print $key, '=', $myhash{$key}, "\n";
}

Race List

Source: docs/reference/race-list.md

Race Keywords

Playable and NPC race keywords available to builders.

  • unique
  • human
  • elf
  • dwarf
  • giant
  • dragon
  • hobbit
  • orc
  • wolf
  • bat
  • bear
  • cat
  • centipede
  • dog
  • doll
  • fido
  • fox
  • goblin
  • hobgoblin
  • kobold
  • lizard
  • modron
  • pig
  • rabbit
  • school monster
  • snake
  • song bird
  • troll
  • water foul
  • wyvern
  • arachnid
  • demon
  • undead
  • draconian
  • smurf
  • earth elemental
  • air elemental
  • fire elemental
  • water elemental
  • plant
  • fish
  • animal
  • gnome
  • gargoyle
  • shadow
  • ogre
  • minotaur
  • beholder

Race Table Source

Source: docs/reference/race-table-source.md

Race Table Source

/* race table */
const   struct  race_type       race_table      []              =
{
/*
    {
        name,           pc_race?,
        act bits,       aff_by bits,    off bits,
        imm,            res,            vuln,
        form,           parts
    },
*/
    { "unique",         FALSE, 0, 0, 0, 0, 0, 0, 0, A|D|F },

    {
        "human",                TRUE,
        0,              0,              0,
        0,              0,              0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "elf",                  TRUE,
        0,              AFF_INFRARED,   0,
        0,              RES_CHARM,      VULN_IRON,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "dwarf",                TRUE,
        0,              AFF_INFRARED,   0,
        0,              RES_MAGIC|RES_POISON|RES_DISEASE, VULN_DROWNING,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "giant",                TRUE,
        0,              0,              0,
        0,              RES_FIRE|RES_COLD,      VULN_MENTAL|VULN_LIGHTNING,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "dragon",               TRUE,
        0,              0,              0,
        0,              RES_POISON|RES_FIRE|RES_BASH,   0,
        A|C|G|X|Z,      A|C|D|E|F|H|J|K|P|U|V|X|Z
    },

    {
        "hobbit",       TRUE,
        0,              AFF_INFRARED,   0,
        0,              RES_CHARM,      VULN_IRON,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "orc",                  TRUE,
        0,              AFF_INFRARED,   0,
        0,              RES_DISEASE,    VULN_LIGHT,
        A|H|M|cc,       A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "wolf",                 TRUE,
        0,              AFF_DARK_VISION,        OFF_DODGE|OFF_FAST,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|Q|U|V|Z
    },

    {
        "goblin",                  TRUE,
        0,              AFF_INFRARED,   0,
        0,              RES_DISEASE,    VULN_LIGHT|VULN_SILVER,
        A|H|M|cc,       A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "bat",                  FALSE,
        0,              AFF_FLYING|AFF_DARK_VISION,     OFF_DODGE|OFF_FAST,
        0,              0,              VULN_LIGHT,
        A|G|W,          A|C|D|E|F|H|J|K|P|Z
    },

    {
        "bear",                 FALSE,
        0,              0,              OFF_CRUSH|OFF_DISARM|OFF_BERSERK,
        0,              RES_BASH|RES_COLD,      0,
        A|G|V,          A|B|C|D|E|F|H|J|K|U|V|Z
    },

    {
        "cat",                  FALSE,
        0,              AFF_DARK_VISION,        OFF_FAST|OFF_DODGE,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|Q|U|V|Z
    },

    {
        "centipede",            FALSE,
        0,              AFF_DARK_VISION,        0,
        0,              RES_PIERCE|RES_COLD,    VULN_BASH,
        O|Y,  A|F|Q|X
    },

    {
        "dog",                  FALSE,
        0,              0,              OFF_FAST,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|U|V|Z
    },

    {
        "doll",                 FALSE,
        0,              0,              0,
        IMM_MAGIC,      RES_BASH|RES_LIGHT,
        VULN_SLASH|VULN_FIRE|VULN_ACID|VULN_LIGHTNING|VULN_ENERGY,
        E|J|M|cc,       A|B|C|G|H|K|Z
    },

    {
        "fido",                 FALSE,
        0,              0,              OFF_DODGE|ASSIST_RACE,
        0,              0,                      VULN_MAGIC,
        B|G|V,          A|C|D|E|F|H|J|K|Q|V|Z
    },

    {
        "fox",                  FALSE,
        0,              AFF_DARK_VISION,        OFF_FAST|OFF_DODGE,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|Q|U|V|Z
    },

    {
        "hobgoblin",            FALSE,
        0,              AFF_INFRARED,   0,
        0,              RES_DISEASE|RES_POISON, 0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Q|Z   /* includes a tail */
    },

    {
        "kobold",               FALSE,
        0,              AFF_INFRARED,   0,
        0,              RES_POISON,     VULN_MAGIC,
        A|B|H|M|V,      A|B|C|D|E|F|G|H|I|J|K|Q|Z
    },

    {
        "lizard",               FALSE,
        0,              0,              0,
        0,              RES_POISON,     VULN_COLD,
        A|G|X|cc,       A|C|D|E|F|H|K|Q|V|Z
    },

    {
        "modron",               FALSE,
        0,              AFF_INFRARED,           ASSIST_RACE|ASSIST_ALIGN,
        IMM_CHARM|IMM_DISEASE|IMM_MENTAL|IMM_HOLY|IMM_NEGATIVE,
                        RES_FIRE|RES_COLD|RES_ACID,     0,
        H,              A|B|C|G|H|J|K|Z
    },

    {
        "pig",                  FALSE,
        0,              0,              0,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|Z
    },

    {
        "rabbit",               FALSE,
        0,              0,              OFF_DODGE|OFF_FAST,
        0,              0,              0,
        A|D|G|V,                A|C|D|E|F|H|J|K|Z
    },

    {
        "school monster",       FALSE,
        ACT_NOALIGN,            0,              0,
        IMM_CHARM|IMM_SUMMON,   0,              VULN_MAGIC,
        A|M|V,          A|B|C|D|E|F|H|J|K|Q|U|Z
    },

    {
        "snake",                FALSE,
        0,              0,              0,
        0,              RES_POISON,     VULN_COLD,
        A|G|R|X|Y|cc,   A|D|E|F|K|L|Q|V|X|Z
    },

    {
        "song bird",            FALSE,
        0,              AFF_FLYING,             OFF_FAST|OFF_DODGE,
        0,              0,              0,
        A|G|W,          A|C|D|E|F|H|K|P|Z
    },

    {
        "troll",                FALSE,
        0,              AFF_REGENERATION|AFF_INFRARED|AFF_DETECT_HIDDEN,
        OFF_BERSERK,
        0,      RES_CHARM|RES_BASH,     VULN_FIRE|VULN_ACID,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "water fowl",           FALSE,
        0,              AFF_SWIM|AFF_FLYING,    0,
        0,              RES_DROWNING,           0,
        A|G|W,          A|C|D|E|F|H|K|P|Q|Z
    },

    {
        "wyvern",               FALSE,
        0,              AFF_FLYING|AFF_DETECT_INVIS|AFF_DETECT_HIDDEN,
        OFF_BASH|OFF_FAST|OFF_DODGE,
        IMM_POISON,     0,      VULN_LIGHT,
        B|Z|cc,         A|C|D|E|F|H|J|K|P|Q|V|X|Z
    },

    {
        "arachnid",               FALSE,
        0,              AFF_HASTE|AFF_SNEAK|AFF_INFRARED,       OFF_FAST|OFF_PARRY|OFF_DODGE,
        IMM_SUMMON,     RES_CHARM|RES_COLD|RES_POISON|RES_BASH,    0,
        A|B|H|P,          A|C|D|E|F|K|V
    },

    {
        "demon",                FALSE,
        0,              AFF_HASTE|AFF_INFRARED,         OFF_FAST|OFF_PARRY|OFF_DODGE,
        0,              RES_CHARM|RES_MENTAL|RES_POISON,        0,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "undead",               FALSE,
        0,              AFF_SNEAK|AFF_INFRARED|AFF_DETECT_HIDDEN,       OFF_FAST|OFF_PARRY|OFF_DODGE,
        IMM_POISON|IMM_MENTAL|IMM_CHARM,        RES_MAGIC|RES_SLASH|RES_PIERCE,         VULN_BASH,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "draconian",            FALSE,
        0,              AFF_DETECT_HIDDEN|AFF_INFRARED|AFF_FLYING|AFF_REGENERATION,     OFF_BASH|OFF_DISARM|OFF_FAST|OFF_DODG>
        IMM_CHARM,      RES_MAGIC,      0,
        A|C|G|X|Z,      A|C|D|E|F|H|J|K|P|U|V|X|Z
    },

    {
        "smurf",               FALSE,
        0,                     0,              0,
        0,  RES_CHARM,              0,
        A|M|V,          A|B|C|D|E|F|H|J|K|Q|U|Z
    },

    {
        "earth elemental",      FALSE,
        0,      AFF_REGENERATION|AFF_DETECT_HIDDEN,     OFF_BASH|OFF_DISARM,
        IMM_MENTAL,     0,      VULN_FIRE,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "air elemental",        FALSE,
        0,      AFF_REGENERATION|AFF_DETECT_HIDDEN,     OFF_PARRY|OFF_DODGE,
        IMM_MENTAL,     RES_WEAPON|RES_BASH,    0,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "fire elemental",       FALSE,
        0,      AFF_REGENERATION|AFF_DETECT_HIDDEN,     OFF_BASH|OFF_DISARM|OFF_AREA_ATTACK,
        IMM_MENTAL,     RES_BASH,       VULN_COLD,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "water elemental",      FALSE,
        0,      AFF_REGENERATION|AFF_DETECT_HIDDEN,     OFF_BASH|OFF_DISARM|OFF_AREA_ATTACK,
        IMM_MENTAL,     RES_BASH|RES_WEAPON,    0,
        B|M|V,          A|B|C|D|E|F|G|H|I|J|K|U|V|Z
    },

    {
        "plant",        FALSE,
        0,      AFF_REGENERATION,       OFF_DISARM,
        IMM_MENTAL,     RES_POISON|RES_BASH,    VULN_COLD,
        O|Y,  A|F|Q|X
    },

    {
        "fish",         FALSE,
        0,      AFF_REGENERATION|AFF_DETECT_HIDDEN,     OFF_BASH|OFF_TAIL,
        IMM_SUMMON,     RES_CHARM|RES_WEAPON|RES_COLD,  0
    },

    {
        "animal",                FALSE,
        0,              AFF_DETECT_HIDDEN,              OFF_BASH|OFF_TAIL,
        0,              0,              0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "gnome",        FALSE,
        0,              AFF_INFRARED,   0,
        0,              RES_CHARM|RES_MENTAL,      0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "gargoyle",     FALSE,
        0,              AFF_DETECT_HIDDEN|AFF_FLYING,   OFF_TAIL|ASSIST_RACE,
        IMM_POISON,     RES_SLASH|RES_CHARM|RES_MENTAL, VULN_BASH,
        A|C|G|X|Z,      A|C|D|E|F|H|J|K|P|U|V|X|Z
    },

    {
        "shadow",                FALSE,
        0,              AFF_INFRARED|AFF_INVISIBLE|AFF_DETECT_HIDDEN,   OFF_BACKSTAB|OFF_DODGE,
        IMM_MENTAL,     RES_WEAPON,              VULN_LIGHT|VULN_SILVER,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "ogre",         FALSE,
        0,              AFF_INFRARED|AFF_BERSERK,       OFF_BASH|OFF_DISARM,
        0,              0,              0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "minotaur",     FALSE,
        0,              AFF_DETECT_INVIS|AFF_DETECT_HIDDEN,     OFF_BERSERK|OFF_KICK_DIRT,
        0,              RES_CHARM|RES_POISON,           0,
        A|H|M|V,        A|B|C|D|E|F|G|H|I|J|K|Z
    },

    {
        "beholder",     FALSE,
        0,              AFF_DETECT_INVIS|AFF_FLYING,            OFF_AREA_ATTACK|OFF_DODGE|OFF_BASH,
        IMM_SUMMON|IMM_CHARM,   RES_MAGIC,              VULN_LIGHT,
        A|C|S,          E|F|K|M|V|Z
    },

    {
        "rat",          FALSE,
        0,              AFF_DARK_VISION,        OFF_FAST|OFF_DODGE,
        0,              0,              0,
        A|G|V,          A|C|D|E|F|H|J|K|Q|U|V|Z
    },

    {
        NULL, 0, 0, 0, 0, 0, 0
    }
};

Racial Level Gains

Source: docs/reference/racial-level-gains.md

Class and Racial Level-Up Gains

The advance_level function calculates how much a character gains when leveling. These gains may depend on class and the character’s current stats. Races provide no direct bonuses, but their stat caps can influence the values used in the formulas.

Hit Points

Formula: con_app[CON].hitp + number_range(class_table[class].hp_min, class_table[class].hp_max)

Constitution contributes a fixed bonus from con_app. A class-specific random range is added to determine final HP gain.

Mana

Formula: number_range(2, (2 * INT + WIS) / 5)

If the class is flagged with fMana = false, the mana gain is halved. Wisdom and intelligence drive this gain.

Movement

Formula: number_range(1, (CON + DEX) / 6)

Movement gain is influenced by constitution and dexterity, scaled by one-sixth.

Practice Points

Formula: wis_app[WIS].practice

Practice points come directly from the wisdom application table.

Summary of Class and Race Influence

Gain Class Influence Race Influence
Hit Points Random range from hp_min-hp_max in class_table None
Mana Halved if fMana = false None
Movement None None
Practice Points None None

Races do not directly modify the gains above. However, they define maximum stats through pc_race_table, which can indirectly impact the gains by limiting the values returned from get_curr_stat().


Spell Slots

Source: docs/reference/spell-slots.md

Spell Slot Reference

Slot numbers and minimum levels for spells used in object values.

Alphabetical

Spell Slot Minimum Level
acid blast 70 28
armor 1 2
bless 3 7
blindness 4 8
burning hands 5 7
call lightning 6 18
calm 509 16
cancellation 507 18
cause critical 63 13
cause light 62 1
cause serious 64 7
chain lightning 500 33
change sex 82 10
charm person 7 20
chill touch 8 4
colour spray 10 16
continual light 57 4
control weather 11 15
create food 12 5
create spring 80 14
create water 13 3
cure blindness 14 6
cure critical 15 13
cure disease 501 13
cure light 16 3
cure poison 43 14
cure serious 61 10
curse 17 18
demonfire 505 34
detect evil 18 4
detect hidden 44 11
detect invis 19 3
detect magic 20 3
detect poison 21 7
dispel evil 22 15
dispel good 104 15
dispel magic 59 16
earthquake 23 10
enchant armor 510 16
enchant weapon 24 17
energy drain 25 19
exorcise 101 34
faerie fire 72 5
faerie fog 73 14
fireball 26 22
flamestrike 65 20
fly 56 10
frenzy 504 24
gate 83 17
giant strength 39 11
harm 27 23
haste 502 21
heal 28 21
holy word 506 36
identify 53 15
infravision 77 9
invis 29 5
know alignment 58 9
lethargy 108 21
lightning bolt 30 13
locate object 31 9
locate life 45 9
magic missile 32 1
mass healing 508 38
mass invis 69 38
paralysis 51 75
pass door 74 24
observe close 105 10
plague 503 17
poison 33 12
portal 84 27
protection evil 34 9
protection good 102 9
protect container 47 50
refresh 81 8
remove curse 35 18
remove invisible 106 18
regeneration 103 15
sanctuary 36 20
talon 37 40
shield 67 20
shocking grasp 89 10
sleep 38 10
smokescreen 403 20
stoneskin 66 25
summon 40 12
teleport 2 13
teleport object 49 36
undo spell 50 36
vanish 113 25
venom 46 17
ventroliquate 41 5
weaken 68 11
general purpose 401 35
high explosive 402 35

By Slot

Slot Spell Minimum Level
1 amo 2
2 telepot 13
3 bless 7
4 blindness 8
5 buning hands 7
6 call lightning 18
7 cham peson 20
8 chill touch 4
10 colou spay 16
11 contol weathe 15
12 ceate food 5
13 ceate wate 3
14 cue blindness 6
15 cue citical 13
16 cue light 3
17 cuse 18
18 detect evil 4
19 detect invis 3
20 detect magic 3
21 detect poison 7
22 dispel evil 15
23 eathquake 10
24 enchant weapon 17
25 enegy dain 19
26 fieball 22
27 ham 23
28 heal 21
29 invis 5
30 lightning bolt 13
31 locate object 9
32 magic missile 1
33 poison 12
34 potection evil 9
35 emove cuse 18
36 sanctuay 20
37 talon 40
38 sleep 10
39 giant stength 11
40 summon 12
41 ventoliquate 5
43 cue poison 14
44 detect hidden 11
45 locate life 9
46 venom 17
47 potect containe 50
49 telepot object 36
50 undo spell 36
51 paalysis 75
53 identify 15
56 fly 10
57 continual light 4
58 know alignment 9
59 dispel magic 16
61 cue seious 10
62 cause light 1
63 cause citical 13
64 cause seious 7
65 flamestike 20
66 stoneskin 25
67 shield 20
68 weaken 11
69 mass invis 38
70 acid blast 28
72 faeie fie 5
73 faeie fog 14
74 pass doo 24
77 infavision 9
80 ceate sping 14
81 efesh 8
82 change sex 10
83 gate 17
84 potal 27
89 shocking gasp 10
101 exocise 34
102 potection good 9
103 egeneation 15
104 dispel good 15
105 obseve close 10
106 emove invisible 18
108 lethagy 21
113 vanish 25
401 geneal pupose 35
402 high explosive 35
403 smokesceen 20
500 chain lightning 33
501 cue disease 13
502 haste 21
503 plague 17
504 fenzy 24
505 demonfie 34
506 holy wod 36
507 cancellation 18
508 mass healing 38
509 calm 16
510 enchant amo 16

Trust System

Source: docs/reference/trust-system.md

Trust system

MadROM tracks an optional "trust" level that can temporarily raise a player's privileges above their natural level. The value lives on every character record in src/merc.h and is stored in player files when it is non-zero.

Data storage

The CHAR_DATA structure defines sh_int trust; so implementers can grant elevated access without permanently changing a character's level. During save and load the player-file code writes the field as Tru (or the legacy Trust) only when it holds a non-zero value, which keeps ordinary characters from carrying extra clutter in their files.

Determining effective trust

The helper get_trust in src/handler.c resolves a character's effective permission level before any command checks run. It first collapses switched descriptors back to their original bodies, then:

  • Returns the explicit trust value when it is set.
  • Falls back to LEVEL_HERO - 1 for high-level NPCs that lack an explicit trust.
  • Otherwise returns the character's current level.

This logic allows implementers to grant temporary power without permanently altering leveling data.

Setting or clearing trust

Immortals adjust trust with the trust command in src/act_wiz.c. The handler requires the target to be in the same room, validates that the supplied number is between 0 and MAX_LEVEL, and prevents an immortal from granting more trust than they personally hold. Passing 0 clears the field. Other administrative commands such as advance explicitly reset victim->trust to 0 after changing the player's level so stale trust does not linger.

Saving to player files

Because the field is only persisted when non-zero, trusted characters display a Tru <level> line in their save files while others omit it entirely. Either the long (Trust) or short (Tru) key restores the value when a player logs in, keeping compatibility with earlier saves.

Summary

The trust system gives implementers a reversible way to raise or lower a character's authority. trust manages the value, get_trust consults it during permission checks, and the save system adds or omits the Tru field based on whether trust is currently granted.


SQL Overview

Source: docs/reference/sql-overview.md

SQL Overview

This project contains several SQL files and embedded queries that populate or extract data from a MySQL database. The sections below document the tables involved and the fields they map.

Social Definitions

The area/socials.sql script loads emote definitions into a socials table. Each INSERT statement specifies a social name and up to eight context-sensitive messages:

Code Name Human Name
name Social command
message1 Actor text when used without a target
message2 Room text when used without a target
message3 Actor text when targeting another player
message4 Room text when targeting another player
message5 Target text when another player is specified
message6 Message when the target is absent
message7 Actor text when targeting self
message8 Room text when targeting self

Example record:

INSERT INTO socials
  (name, message1, message2, message3, message4, message5, message6, message7, message8)
VALUES
  ('kowtow', 'You kowtow$h before the heavens.', '$n$h kowtows before the heavens.',
   'You kowtow$h before $N. May $E live a thousand years.', '$n kowtows$h before $N.',
   '$n kowtows$h before you. May you live a thousand years.',
   'You kowtow to the spirit of the person you seek.',
   'You kowtow$h to yourself. You wish your life is long and prosperous.',
   '$n kowtows$h to $mself. May he live a long and prosperous life.');

Game Statistics Logging

Two C modules record overall game statistics by inserting rows into a gamestats table.

  • src/mysql.c implements insert_gamestats_db, which composes a single INSERT statement capturing totals such as creations, deletions, logins, locks, and configuration flags.
  • src/sql.c contains a CREATE TABLE gamestats definition mirroring these fields and a duplicate insert_gamestats_db helper used by the do_insertstats command.

Fields written to gamestats include:

Code Name Human Name
tcreations Players created since last reboot
creations Total players created
tdeletions Players deleted since last reboot
deletions Total players deleted
tlogins Logins since last reboot
logins Total logins
bank_hours Bank hour mode (0=unlimited, 1=regular)
mortlock Mortal-lock active flag
wizlock Wizard-lock active flag
newlock Newbie-lock active flag
arena_status Arena running flag
color_notes Colored notes allowed
color_notes_level Minimum level for colored notes
zombies Zombie plague active
bonus_charms Bonus charms active
auto_police Spam auto-policing enabled
spam_threshold Spam message threshold
spam_level Max level subject to spam policing

Note: Use madmode mysql <gamestats|items|helps|mobiles> <on|off> in game to control MySQL exports without recompiling. The command persists your choice to config.cfg, allowing items, helps, or mobiles to stay disabled while gamestats remain available when needed. Use madmode bonus <0-1000> to adjust the global experience bonus, which is stored with the other madmode settings in config.cfg.

Data Export Routines

In-game MySQL export routines were removed to improve stability, and the server no longer serialises runtime data to MySQL. Builders should rely on the offline CSV snapshots in tools/ and item_data.csv if they need structured data for documentation or analysis.

Player Statistics Tooling

The legacy Perl scripts (quick.pl and output.pl) were retired in favour of the PHP front end that drives the MadROM stats dashboard. Two components now handle leaderboards and game summaries:

  • A shared database helper pools mysqli connections for the main, gamestats, and socials databases, sourcing credentials from environment variables before falling back to the legacy development defaults.
  • The public leaderboard endpoint runs predefined SELECT queries (experience, deaths, kills, clan points, saves, and played time) and renders the latest gamestats snapshot for the web dashboard.

These scripts keep SQL strings in code, avoid exposing credentials in documentation, and close pooled connections when each request finishes.

Note: Do not publish live database passwords in changelogs or guides. Use the environment overrides defined in includes/db.php and includes/db2.php for deployment-specific secrets.

Code Name Human Name
name Player name
exp Experience points
kills Total kills
deaths Total deaths
zaps Zaps received
hp Current hit points
age Character age
levl Level

Immortal Security Tools

Source: docs/reference/immortal-security-tools.md

Immortal security tools

MadROM ships with a collection of administrative safeguards that help immortals monitor problem players and protect the world. These features live primarily in src/interp.c, src/act_wiz.c, and supporting modules.

Command logging

Each command entry contains a logging mode that the interpreter enforces before the handler runs. Entries marked LOG_ALWAYS, characters flagged with PLR_LOG, or a server with the global fLogAll switch enabled will generate wiznet announcements and entries in the immortal log (src/interp.c). Immortals toggle targeted logging with the log command in src/act_wiz.c, which either flips PLR_LOG on a victim or turns the global fLogAll mode on and off.

Deny command

The deny command in src/act_wiz.c sets the PLR_DENY flag on a character, saves them, and forces an immediate quit. During login the descriptor code in src/comm.c refuses connections from any player whose saved data carries PLR_DENY, ensuring they cannot re-enter the game until an implementer clears the flag manually.

Ban command

Use the ban command to block incoming connections from a host. The handler delegates to ban_site in src/ban.c, which records the address and optional permanence flag. Subsequent logins check the ban list and disconnect players whose host matches an entry unless they have been explicitly permitted.

Snoop

Immortals can observe player sessions with the snoop command (src/act_wiz.c). Entering a player name attaches your descriptor to theirs so every command they enter is echoed to you; snooping yourself clears all active snoops. The implementation prevents snoop loops and respects trust levels so lower-ranked immortals cannot watch higher-ranked staff.

Wizard invisibility

The invis command toggles the PLR_WIZINVIS flag (src/act_wiz.c). While active, the character's invis_level is set to their trust (or a supplied value), movement messages suppress entry and exit echoes for mortals (src/act_move.c), and their presence is hidden from standard look output. Toggling the flag again fades the immortal back into view.


OS X Build Notes

Source: docs/reference/osx-build-notes.md

macOS Build Notes

Steps used to compile stock ROM and QuickMud on macOS:

    Stock ROM:
    - remove srandom declaration from db.c
    - remove malloc.h from save.c
    - change gcc in cc in Makefile
    - add -Dunix to the C_FLAGS in the Makefile

    QuickMud:
    - remove srandom declaration from db.c
    - remove malloc.h from save.c
    - change gcc in cc in Makefile
    - add -Dunix to the C_FLAGS in the Makefile
    - remove -lcrypt from the L_FLAGS in the Makefile

References

  1. Legacy Builder Guide
  2. ROM 2.4 Documentation
  3. ROM Object Statistics
  4. ROM Spell List