Storms of Times
_________
__ __,----' `-----.__
__ \\/====-____ ___,-' `
\\ _/_/_/ /||\\ `---.____/
______---\ _- / \/ ||| \\ _,'`
__,--' ,--'||\-_ /,--_/--.|- |`\. \\ ,'
_,' ,-' | \\`. ` */ /==/- / || `\. /
.' ,' | \\ \_** /==/- / || \ /
/ _____ / __ | \\**-_/==/|- _/ ,// \ /
,-' `-|--' `--_ \ ***-/===| \-_-===-' _ _/`
`-| **** *|====| \_ __,-- '
.. '* *** *|====| \_ _, /\
... *** * \=====\__ \/ \__ _
... ***-' _/'\=,-' ____-'`-_ `== \
() *. ()| ** //--\ ///--\`._ `- _\ \
#_/ /#_| () / \=======\ `----.________,--- __/
# / # /#_/ __--======`) \-._______________,---
### / \ / # | //,--' `==--___ |-------'
##### / / / \ O##<_ //,-- -\
/ / \
Mud20 ver 1.0 (Updated by Todd H. Johnson 12/2007)
==============================================================================
Word from the Mud20 Team:
This document has been considerably updated from its original content for
both Mortal Realms, and its descendant, Emud. While there are significant
changes in the code of Mud20, to where it looks very little like the inner
workings of either of its predecessors, the basics of building an area are
the same, and entries have been added or updated where necessary.
Word from me (Scandum)
This document was originally written by Chaos and Order for Mortal Realms.
Emud, a clone of mortal realms, is still for 80% compatible with the
source this document was written for. So except for a couple of changes
this guide is an exact duplicate of the MrMud 1.4 builder document.
It should be significantly accurater than the original version though.
(At least, so I hope)
Greetings future area creator!
We (Chaos and me, Order) have put together this collection of documents as
both references and instructions to building areas. Below is a list of the
documents in the order which we recommend reading, along with a brief
description of each.
diku_bld.txt
The official handbook for creating Diku areas as created by the
Curious Area Workshop, it is included in the Emud Area Package because
it does a decent job of describing all of the basics of area building.
This document has been modified to Mud20 specifications.
mob_prog.txt
The instruction document that describes how to implement mob programs.
This does NOT describe how to make special programs in C for mobiles,
but details the functions and triggers used in programming mobiles from
the area file. This is the only method of support that can be given
to creators for making mobiles do special functions.
mud20.txt
the latest set of values used by Mud20. Updates to this document set will
be contained in this file and the online builder help file.
spells.txt
the list of spells and the numbers necessary for specifying the spells in
creating scrolls, potions, pills, scrolls staffs, wands and mobile progs.
==============================================================================
Emud now uses OLC which is short for Online Creation. This means you can create
your entire area online using a build char on the test mud. If you wish you can
skip most sections, and only pay attention to the part describing object and
mobile programs. If you want more information you can read it all, it might
come in handy when you know what you're doing, and should make using the OLC
engine a little easier.
Also there is a help file online on the test mud, type: help builder, and
you will enter it.
==============================================================================
diku_bld.txt
The Builder's Handbook
(version 1.0)
By
Builder_5
(of the Curious Area Workshop)
(Modified by Scandum on 9/12/01)
TABLE OF CONTENTS
1. Overview
2. Terminology
3. Basics
4. The #AREA, #HELPS, and #ROOMS section
5. The #MOBILES section
6. The #OBJECTS section
7. The #SHOPS section
8. The #RESETS section
9. Putting it all together
10. Credits
1. Overview
This document is meant to be a basic tutorial to building areas for Emud.
Readers of this Handbook should have at least have some experience with
Emud or Diku muds, and will understand the basic concepts of armor, levels,
and the et cetera.
Nowadays, many mud-admins express the wish to have an entirely unique world.
Unfortunately, building is time consuming and requires no mean amount of
skill, with the added 'bonus' of being hard to learn; the standard mud-docs
that get bandied about are somewhat vague on certain subjects, and were
originally intended as a reference guide rather than a learning document.
I hope to make this Handbook a 'cookbook' of sorts -- an explanation of the
how's and what's of building a Emud based area for the non-coding inclined.
This document is a tutorial for building in the standard Emud release 2.2.
Most (95% or so) muds have changed or added to the information, but still
follow the basic format. Reading this document should prepare you for most
Diku muds you will encounter out on the net.
The Curious Area Workshops highly recommends that every builder understands
the nuts and bolts of building, even if they have access to one of the
mud-area editors available out there. Being able to build with an editor
is nice, but the knowledge of how the nuts and bolts of building actually
works is of great value when things go wrong. We cannot emphasize this
enough, but we will attempt to refrain from preaching it in the rest of
this document.
2. Terminology
Here are some common terms used in builing, and this handbook:
Desc: Short for 'description'.
Db: Database. The files that make up the 'world' of a mud.
Flag: A bit-vector that tells the mud that a particular monster,
object, or room has a certain quality.
Mob: Mobile. A monster.
Obj: Object.
Tilde: This is a tilde: ~ . It signifies the end of a line or
a field in some of the database files.
Vnum: An object, monster, or room's unique identification number.
Stands for 'Virtual Number'.
Zone: Used synonimously with 'area'.
3. Basics
For all examples, the area under creation will be known as 'handbook' or
'example area'. It is assumed that the builder has access to some standard
type of text editor and knows how to use it.
*** FILES
For each area, one file must be created for inclusion into the dikumud's db:
handbook.are
This file includes the various sections of:
#AREA
#HELPS
#MOBILES
#OBJECTS
#ROOMS
#SHOPS
#RESETS
*** FLAGS
Simply put, a flag tells the mud that there is something 'special' about a
mob, room, or object. In the sections below, lists of flags will be given
with a number, a bitvector, next to it. For example, here is the sample of
room flags that will appear below in the #ROOMS section:
ROOM_DARK 1
ROOM_NO_MOB 4
ROOM_INDOORS 8
ROOM_PRIVATE 512
ROOM_SAFE 1024
ROOM_SOLITARY 2048
ROOM_PET_SHOP 4096
ROOM_NO_RECALL 8192
Now, for example, you are building a room. Deciding that this room is a
small section of tunnel, you would choose the flags:
DARK (1) and INDOORS (8)
These numbers are the important part. When the mud looks at the .wld file,
it looks for _one_ number in a certain particular spot for each room's flags.
Therefore, to give one room _two_ flags, you ADD the bitvectors together
and place that number in the flags spot of that room's data.
Thus for this example:
INDOORS + DARK = 9
Another simple format can be each number separated by a '|' symbol.
The '|' symbol is an logic OR symbol.
INDOORS + DARK = 1|8
The final format is to use the names of the flags in replace of the
numbers. This system is MUCH easier to read, but may not be compatible
with some of the mud-editors.
INDOORS + DARK = ROOM_INDOORS|ROOM_DARK
How does this work, though?
The bitvectors are in binary...the number you arrived at when you added
can only be reached by one combination of adding those numbers together
(you're not allowed to use a flag or number more than once).
Thus, if your number was: 524 you would know that it was PRIVATE (512)
(the highest number that will go into 522)
522-512 = 10
INDOORS (8) is the next highest number that will go into it.
10-8 = 2
NO_MOB (2) is the last one: 2-2 = 0 (no more flags).
It should be obvious that the list is not complete. The blank spots are
flags the are not used but exist for backward compatiblity. PLEASE do not
use any of these. The game may use some of them for temporary values, and
their use may jeopardize the system.
*** Zone Number
Each area must have its own unique number. Usually, the admin of your
particular mud will assign this to you. This number is used as part
of all your area's virtual numbers. (see below).
The system that nearly all mud administrators like is the QQ format.
This system places the symbols 'QQ' in replace of any zone number. The
administrators will later assign a number in replace of the QQs.
*** Virtual Numbers
Every Mob, Obj and Room must have its own Virtual Number for the mud
to identify it with. Each number must be unique among its own type.
For example, If I made the Sword of Cheezy Destruction, I may decide to
make it item number 2200 of my zone. The first two digits
are the zone number (above) of my area, the second two identify which
item it is in that area.
These first two numbers will be assigned by the system administrators.
The first two numbers should be replaced by 'QQ'. Therefore the format
you would write for the item number is QQ00.
However, I can have a mobile with number 2200 as well. A room #2200 too.
The number must be unique among all others of its type (rooms, objs, mobs)
But does not need to be unique in regards to other types of db's.
Emud admins do not allow using any object or mobile that does not solely
exist in the zone of the creator, unless they are special objects provided
for resets in all areas of the game. If such is available you will be given
such a list separately. So all referenced objects or mobiles should start
with the QQs.
If your area has more than 100 rooms then continue using the 'QQ' method,
but change the value to 'QR' for rooms 100-199, and 'QS' for rooms 200-299,
etc...
*** Strings
A string holds the actual data of the text sent to the player, such as a
mobile's name, or a room description. Strings can range in size from zero
length to the MAX_STRING_LENGTH. Emud systems are 20,000 bytes allowed per
string in a description, and 2,000 for names and short descriptions. All
strings end in the tilde '~' symbol. Placing a return after the text, but
before the tilde will display the return to the player.
Custom color may be added to certain strings. Room descriptions, mobiles
descriptions, object descriptions, and extra descriptions may all have
custom color. Adding color is as simple as adding a pair of matching
brackets, with three digits between them. The three numbers are the
parameters of the color change request.
Format: '{abc}' with a,b,c being parameters.
Parameter 'a': VT102 code.
0 - Dim
1 - Bold
3 - Restore color to text default regardless of b,c
4 - Reverse
5 - Underline
7 - Flashing
(All VT102 systems support Dim, Bold, and Restore)
Parameter 'b': Foreground color
Parameter 'c': Background color
0 - Black
1 - Red
2 - Green
3 - Yellow
4 - Blue
5 - Purple
6 - Cyan
7 - White
Example:
The small {130}dog{300} sits by the {114}cat{300}.~
This example starts with normal colors. 'dog' is bold, yellow on black.
The 'cat.' ends up being blue background, with red text.
(be aware to reset after using a background color like in the example)
4.1 The #AREA section
The #AREA section has very few lines but sets up the entire file.
*** Area Name
#AREA <area name>~
example: #AREA Sanitorium~
*** Author Name
#AUTHORS <author names>~
example: #AUTHORS Gregorius~
*** Version Number
This should be kept to the current version number of the running game for
all newly created areas; it is to ensure that major changes in the code
will allow for older areas to remain backward compatible.
As of this writing, the current area version is 4.
#VERSION 4~
*** Reset Message
This message will echo through the area every repop.
#RESETMSG <reset message>~
example: #RESETMSG <You hear the patter of little feet.~
*** Level Range
This is a very arbitrary set of numbers that the creator must decide on.
This field must contain exactly 4 numbers between 0 and 99
#RANGES <low_soft> <hi_soft> <low_hard> <hi_hard>
Example: #RANGES 40 60 1 95
*** Temperature (optional)
This is the daily temperature scale in Fahrenheit. The winter and summer
lows are for night temperature, with the daily adding to it. To reverse
the seasons, simply switch out winter and summer temps.
The 'Wetness Scale' is a number from 0 to 10. 0 is a desert. 10 is a
tropical rain forest. 5 is the default value.
Leaving this optional parameter off uses defualt settings for weather.
#TEMPERATURE <winter low> <summer low> <daily change> <wetness scale>
Example #TEMPRATURE 0 80 20 4
*** Flags (optional)
These flags count for the entire area. Mud20 added population flags that
should be used for all civilized area files. The presence or absence of
these flags determines the availability to use certain skills or not.
#FLAGS <area flags>
example: #FLAGS AFLAG_NORECALL|AFLAG_NOTELEPORT|AFLAG_NORIP
example: #FLAGS AFLAG_NOCASTLE|AFLAG_NOGOHOME|AFLAG_NODEBUG
AFLAG_NODEBUG
Use this flag if you have rooms that are non-standard. Usually this
flag is not necessary.
A non-standard room is one where when you leave room A north to room B.
Then you leave room B south. While trying to get to A, you actually
end up at room C.
AFLAG_NOTELEPORT
This stops a player from teleporting or rifting into the area.
AFLAG_NORECALL
This stops a player from being able to use the recall spell in the area.
AFLAG_NORIP
This stops a player from being able to cast the rip spell in the area.
AFLAG_NOCASTLE
This stops a player from being able to build a castle in the area.
AFLAG_NOGOHOME
This stops a player from being able to use the gohome command in the area.
AFLAG_WEATHER
Enables use of advanced weather settings for an area. See entry for the
#WEATHER header.
AFLAG_VILLAGE|AFLAG_TOWN|AFLAG_CITY|AFLAG_METROPOLIS
These flags are used in population center areas to determine the number of
inhabitants of the area ICly. You can NOT use more than one population flag
in your area flags.
* Villages are small areas with 50-200 inhabitants.
* Towns are larger than villages, up to around 5,000 people.
* Cities are bustling population centers, larger than towns.
* Metropolis' are mega cities of ancient times, half a million or more.
If your area is wilderness, or has less population than this, a single
family, etc, then do not use any of the above flags.
*** Justice System
This determines the crime and punishment for a given player in your are
when he falls afoul of the local law. Note that there does not have to
be a formal legal system ICly in the area, merely that certain mobiles
will execute certain actions if a player commits certain violations upon
their fellows.
Example: #JUSTICE
Courtroom <room vnum>
Dungeon <room vnum>
Judge <judge vnum>
Guard <guard vnum>
Crime CRIME_HIGH_MURDER PUNISHMENT_DEATH
Crime CRIME_ASSAULT PUNISHMENT_SEVER
Crime CRIME_MUGGING PUNISHMENT_SEVER
-1
The headers for the justice system are as follows:
Courtroom: The vnum of the room where the judge presides
Dungeon: The vnum of the room where players are interred for jail time.
Judge: Mobile vnum of the Judge who assigns bounties, jails and releases.
Guard: Mobile vnum that carries out judgements, arrests, executions.
Crime: Sets the punishment for each type of crime in the area, from:
CRIME_MUGGING stealing from a mobile
CRIME_ASSAULT attacking a citizen of the area (flagged ACT_CITIZEN)
CRIME_LOW_MURDER killing a mobile resident of the city
CRIME_HIGH_MURDER killing another player character in the area
NOTE that in order to receive punishment, you must be caught in the act
by either a citizen of the area, or a guard.
The penalties for each crime can be your choice of:
PUNISHMENT_NOT_ENFORCED No punishment is given
PUNISHMENT_RANDOM_ITEM Guard mobile confiscates a random item.
PUNISHMENT_SEVER Guard mobile severs a limb as punishment.
PUNISHMENT_JAIL Player is taken to judge, who places player in jail.
PUNISHMENT_DEATH Player is attacked on site by guards, until killed.
NOTE that the justice entry has to end with a -1. Failure to add this
end flag will crash the mud.
4.2 The #HELPS section
This section allows the addition of new help listings.
Entire help menus may be created.
Begin this section with:
#HELPS
End this section with:
0 $~
*** Help Archetype
<level> <name list>~
<text of help and special menu pointers>
~
example:
5 SWORD CUTLASS "LONG SWORD"~
{300}
The sword is a very strong weapon
But you may find stronger ones.
{120}(A) {050}Information on Knives
{120}(B) {050}Information on Spoons
{120}(-) {050}Return
{a}knife
{b}spoon
{-}cuttlery
~
*** Level
This is the level the player must be to be able to read this help.
Use 0 if you wish everyone to read it.
*** Name List
This field is a list of keywords that will reference the help text.
These may be odd encoded numbers for menu use only, or simple ones
that the player may enter help on directly.
This field should be in all capital letters.
Use " " to cluster multiple words for a search string.
*** Body
The body has several special encoded features.
The first is that all initial spaces and returns are removed unless
the body start with a '.' a color code works just as well though.
*** Menus
The menu stucture shown above has two sections. The first section, where
the options are surrounded by '(' and ')' is the display section.
The display section is shown with the rest of the body text.
The actual decoded menu section is a line that starts with '{'.
Once a menu option is trapped, the following letter is the option
that the user must pick, followed by '}'.
The following letters are what the menu item will reference in the
help system.
These menu items may point to any other item in the help db.
Please use only lower case letters for the menu system, since this
feature is case sensitive, and most people select menus by lower case.
4.3 The #ROOMS section
The #ROOMS section contains all the information necessary for the
mud to make all the rooms of your area, link the exits together, and
all the other little things concerned with the 'where's' of an area.
The file simply consists of all the rooms in sequential order by their
virtual number. Here is a sample room for this section's example:
This section in the .are file will always start first with this line:
#ROOMS
This section in the .are file will always end with with this line:
#0
*** ROOM ARCHETYPE
(the <'s and >'s are used to offset values, and should be ignored)
<#vnum>
<room name>~
<room description>~
<area number> <room flags> <sector type> <room width> <room depth> <room height>
F <vnum to fall to> <slope of cliff> <amount of feet>
E
<extra name list>~
<extra description>~
D<exit direction>
<exit description>~
<door name>~
<door flags> <key number> <vnum of connect room> <exit size>
S
---example follows this line---
#QQ00
The First Room~
You are standing in the first room of this area. Many rooms are sure to
follow, soon to be chock-filled with adventure, danger, romance, and Giant
Green Photosynthetic Death Gerbils from Morovia.
There is a sign hanging from the east wall here, and a large steel grate bars
the way to the north.
~
QQ ROOM_INDOORS|ROOM_NO_MOB SECT_INSIDE 20 30 30
DDIR_NORTH
You spot the Second Room to the north, behind a large steel grate.~
grate steel~
1 QQ00 QQ01 SIZE_NONE
E
sign~
The sign says:
WELCOME TO THE FIRST ROOM!
~
S
---example precedes this line---
Now to explain what each part means, line by line:
#QQ00
The virtual number of this room:
Totally unique, no other room in the db will have this number after the
adminstrators assign a value for the QQ.
The First Room~
room name:
the 'title' of the room. This is typically not more than 5-6 words long.
Note the tilde marking the end of this field.
You are standing .. the way to the north.
~
room description:
This is what a player sees if he or she types 'look' in that room.
What is in this section is up to your own, personal taste.
More about the various description types can be found below.
Note the tilde marking the end of this field.
Advise:
Try to describe the room without telling the one reading it how they feel.
Imagine yourself playing a vampire who according to the area creator:
You feel shivers running down your spine as you see blood dripping down the
wall.
-or the other way around-
You start to drool as you see delicous sparkling red blood dripping down
the wall.
Another advise would be not to describe the area as if the person walks
through it from room A to Z, Venturing through some areas from room Z to A
one gets the feeling they're walking backwards. as in:
Before you leads a hallway northwards (while you just came in from the north)
QQ ROOM_INDOORS SECT_INSIDE 20 30 30
The first number is the owner of the room, used for spells that create a
room, this is the pvnum of the caster. IT SHOULD NEVER BE USED in area
coding.
The second number is the room flag value. Please see 'flags' in
section 3 of this handbook, and Room Flags below.
The Third number is the sector type. Please see 'sector types' below.
Be aware the mud translates these flags to bitvectors, Mud20 prefers
their builders to use these flags instead of numbers. You can however
use numbers, since it only takes a couple of seconds to convert them
to flags with the proper tool.
The last set of numbers is the width, depth and height of the room in feet.
Hence, this room is 20 feet wide, 30 feet deep, with a 30-foot ceiling.
Leaving these values as 0 makes them use the room default of 30 feet square
(with a 15 foot ceiling if flagged indoors).
NOTE: As of version 1.0, room dimensions are not yet used in hard code.
DDIR_NORTH
An exit to direction north. The section on 'Exits' below will
shed more light on this subject.
You spot the Second Room ...
Exit description:
What a player would see if they typed 'look north'.
Note the tilde marking the end of this field.
grate steel~
door name:
What words can be used to manipulate the door. These two words can be
used in conjunction with open, close, pick, and look commands, etc.
1 QQ00 QQ01 SIZE_NONE
The first number is the door flag, 1 being: is_door
This and the other numbers will be explained more fully under 'Exits' below.
The second number is the key number. the virtual number of the object that
can be used to lock or unlock this door.
The third number is the vnum of what room this exit leads to.
The final value is the SIZE_ flag, to determine what the maximum size of
creature who could pass through the exit is, based on standard d20 size
categories:
SIZE_NONE = no restriction
SIZE_FINE
SIZE_DIMINUTIVE
SIZE_TINY
SIZE_SMALL
SIZE_MEDIUM
SIZE_LARGE
SIZE_HUGE
SIZE_GARGANTUAN
SIZE_COLOSSAL
Note that certain race types, and certain skills (escape artist, for example)
and certain spells (pass door, gaseous form, etc) can allow a character to
still bypass this setting.
E
Tells the mud there is an extra description coming.
sign~
extra name list:
The words that can be used to look at the extra description.
(i.e. 'look sign') Note the tilde ending the field.
The sign says:...
The text of the extra description. Again, note the placement of the tilde.
S
End-of-Room character. Each room should end with one of these.
Now, for more explanations...
*** DESCRIPTIONS
Descriptions are fairly self explanatory.
- Short Descriptions
These are the short descriptions a player can see.
They should be kept to half a line long.
The short description of a room is mostly called: room name
- Descriptions
These are the multi-line descriptions of rooms. When creating a description
keep in mind to keep each line under 80 characters unless you use color
codes. Clues to the Extra Descriptions should be included in the room
description, if not elsewhere.
- Extra Descriptions
An extra description, of which there can be many for each room, is
something else specific to look at, not normally seen just by typing
look, or entering the room. An extra desc is started by an
E (a seperate E for each extra desc in the room),
followed by the keywords that can be used to look at this description on
the next line, each separated by a space, followed by a tilde.
Then, the description itself, followed by a tilde.
E
keywords~
You spot the keywords. They look important!
~
*** ROOM FLAGS
Please consult the section on flags in section 3 for how bitvectors are added
and used. Briefly, add each flag that you want for a particular room.
Seperate them with the | (pipe) symbol.
ROOM_NONE 0
ROOM_DARK BV01 Requires light source, no matter what time.
ROOM_FOG BV02 Spell affect, grants partial concealment.
ROOM_NO_MOB BV03 Mobiles cannot wander into room.
ROOM_INDOORS BV04 Has ceiling, no weather affects.
ROOM_BLACKLIGHT BV05 Spell affect, impervious to darkvision.
ROOM_NO_ASTRAL BV06 Cannot teleport in/out.
ROOM_CLANSTOREROOM BV07 Room contents save. Only use with admin approval.
ROOM_ALTAR BV08 No longer used
ROOM_NO_MAGIC BV09 Spells cannot be cast, affects are dispelled.
ROOM_PRIVATE BV10 Only two people allowed in room.
ROOM_SAFE BV11 No aggressive actions allowed.
ROOM_SOLITARY BV12 Only one person allowed in room.
ROOM_PET_SHOP BV13 Uses per shop code, sells mobile from room vnum +1.
ROOM_NO_RECALL BV14 Cannot recall from room.
ROOM_RIP BV15 Spell affect, internal use ONLY.
ROOM_BLOCK BV16 Spell affect, exits are blocked from normal passage.
ROOM_NO_SAVE BV17 Hard code use only. DO NOT USE.
ROOM_MORGUE BV18 Allows lowbie players to retrieve corpse for a price.
ROOM_INN BV19 "Safe" room allows recovery faster and offline.
ROOM_IS_CASTLE BV27 Internal use for dwelling creation engine.
ROOM_IS_ENTRANCE BV28 Internal use for dwelling creation engine.
ROOM_NOTE_BOARD BV29 Room has a not board for posting.
ROOM_NO_CASTLE BV30 Cannot buy a dwelling here.
ROOM_NO_RIP BV31 Cannot use spells to create a virtual room here.
ROOM_MAZE BV32 Randomizes exits, very confusing.
ROOM_ICE BV33 Spell affect, movement/combat require balance check.
ROOM_DYNAMIC BV34 Uses dynamic descriptions. NOT FULLY IMPLEMENTED.
ROOM_WILDERNESS BV35 Room is a wilderness room. NOT FULLY IMPLEMENTED.
ROOM_HASH BV36 Internal use only. DO NOT USE.
ROOM_NOT_VALID BV37 Internal use only. DO NOT USE.
These are complete as of Mud20 v1.0.
*** SECTOR TYPES
The 'sector type' of a room controls how many movement points it costs to
enter that room. It may also require other skills
SECT_INSIDE 0
SECT_CITY 1
SECT_FIELD 2 Can build dwelling here
SECT_FOREST 3 Can build dwelling here
SECT_HILLS 4 Can build dwelling here
SECT_MOUNTAIN 5 Can build dwelling here
SECT_LAKE 6 Deep water requires swim check.
SECT_RIVER 7 Shallow water can be waded.
SECT_OCEAN 8 Deep, turbulent water requires swim check w/penalty.
SECT_AIR 9 Requires flying/incorporeal to travel, obj/mobs fall.
SECT_DESERT 10 Characters take nonlethal heat damage *NOT YET IMPLEMENTED*
SECT_LAVA 11 Burns characters not resistant to fire.
SECT_ETHEREAL 12 Must be ethereal to travel.
SECT_ASTRAL 13 Must be astral to travel.
SECT_UNDER_WATER 14 Swim check/water breathing required.
SECT_UNDER_GROUND 15
SECT_DEEP_EARTH 16
SECT_ROAD 17
SECT_SWAMP 18
SECT_BEACH 19
SECT_TUNDRA 20 Characters take nonlethal cold damage *NOT YET IMPLEMENTED*
SECT_EDGE 21 DO NOT USE
*** EXITS
Exits use the letter D and a number, compass, rather than the letter
abbreviations that most mudders are used to for compass directions.
Hence:
(north)
0 4 (up)
| /
(west) 3-+-1 (east) +
| /
2 5 (down)
(south)
DIR_NORTH 0
DIR_EAST 1
DIR_SOUTH 2
DIR_WEST 3
DIR_UP 4
DIR_DOWN 5
Most muds use: D4 but DDIR_UP to make an upward direction works too for
this mud. Each exit starts with its own direction field, and contains an
exit description and door keyword list, (both of which can be left blank
with a tilde), and a fourth line containing a door type, key number,
and exit-to-room number. Rooms without exits need no direction fields
and the etc...this section may be safely ignored.
The exit description is used for when a player types look <direction>. This
should in most cases be a description of the exit, and is followed by a tilde
on a line by itself. Each exit starts with its own direction field, and
contains a door keyword list and The next field is the door keyword list, used
for manipulative door actions, such as open, close, pick, etc. These words are
separated by a space, and are followed by a tilde on the same line. It is best
to use the keywords as a phrase that makes sense, for the echo when the exit is
manipulated, like the keywords "big iron door" will yield the echo "Bilbo opens
the big iron door."
The door type can be the following values:
0 standard hallway without door
EX_ISDOOR BV01 exit has an open door
EX_CLOSED BV02 door is closed
EX_LOCKED BV03 does not necessarily require a key
EX_HIDDEN BV04 cannot be seen without detect hidden or searching
EX_RIP BV05 internal use, DO NOT USE
EX_PICKPROOF BV06 cannot be picked
EX_BASHPROOF BV07 cannot be bashed open
EX_MAGIC_PROOF BV08 cannot be magically unlocked
EX_BASHED BV09 DO NOT USE
EX_CLIMB BV10 requires climb check to scale.
EX_FLY BV11 sheer or no walls, must fly to enter.
EX_BARRED BV12 physically barred door, penalty to bash.
EX_PASSPROOF BV13 cannot be entered with pass door/incorporaeal.
EX_MAGICAL_LOCK BV14 spell affect cannot pick, penalty to bash.
EX_EASY_PICK BV15 DC to pick is 5 points less.
EX_HARD_PICK BV16 DC to pick is 5 points harder.
EX_AMAZING_PICK BV17 DC to pick is 15 points harder.
EX_WEAK_DOOR BV18 thin/weak door 13 DC to break down (15 with no flag).
EX_HEAVY_DOOR BV19 door is 23 DC to break down.
EX_IRON_DOOR BV20 door is 28 DC to break down
The key number is simply the vnum of the key that can open the door.
A door without a keyhole is represented by a -1 in this spot.
The exit-to-room number is the vnum of the room where the exit leads to.
Use the QQ system here. If the room connects to an outside room leave a
ZZZZ here, with an extra description of where the room should connect.
Try to make geographical correct outside connections.
*** Falls - For Air and Cliffs
Rooms that characters may fall from have a section designated with the
letter 'F'. This is followed by the room that they fall into, and the
distance of the fall.
F <room to fall into> <slope of cliff> <distance of fall in feet>
This modifier for a room takes into play the skill of CLIMB and flying.
The only special case is where the sector type is SECT_AIR. This special
case will check to see if the character is flying, or immediately damage
them. All other sector types are considered cliffs, and will check both
dexterity and the climb skill.
When a player falls, two things happen. They are damaged by the amount
defined by an equation based on how many feet the fall was. And they are
transfered to the room pointed to by the "room to fall into" field.
An area creator can use this to make a dangerous section for players to
cross, such as a path up a mountain. This gives them a chance to fall back
down the path. The SECT_AIR is quite dangerous, in that losing fly causes
an instant fall. A trick that can be used to simulate a rocky terrain is
to have a fall of a few feet, and make the fall room point to itself.
Be aware that more creative tumbles can be created with a mobile program.
*** TIPS and OBSERVATIONS
Make a master plan before you start building, that might prevent having to
delete or rewrite several parts of your area.
For a working door, the rooms on each side must have matching doors
and doorflags. Also the #RESETS section must have the associated close
door command to close, lock, or reopen the door every repop.
5. The #MOBILES section
The #MOBILES section contains everything the mud needs to know about the mobs,
except for where they are and what they're holding. Each mob in the file is
in sequential vnum order.
Mobiles may also contain some form of mob_prog. These programs make the
mobile appear more life-like, and can be used to set up puzzles or quests.
Mob_progs allowing a quest are a "must" for every Mud20 area. Mob_progs are
described later in this text.
This section in the .are file will always start first with this line:
#MOBILES
This section in the .are file will always end with with this line:
#0
*** ARCHETYPE MOB (simple)
<#vnum>
<name list>~
<short description>~
<long description>~
<description>~
U <level> <class> <race> <sex> <position> <deity>
<actions>
<affects>
<natural armor> <deflection armor>
<hit dice> <damage dice> <alignment> <ethos> <gold>
<STR DEX CON INT WIS CHA>
<body part> <attack part> <size> 0 0
0 0 0 0 0
[C <multiclass name> <multiclass level>]
[mob program]
Here's a sample mob:
---example follows this line---
#QQ00
mob example~
the Example Mob~
An example mob stands here, completely clueless.~
The example mob looks indistinct, as if it hasn't been completely fleshed
out yet.
~
U 18 CLASS_FIGHTER RACE_ELF SEX_MALE POS_STANDING GOD_NEUTRAL
ACT_RACE|ACT_WIMPY|ACT_RACE
AFF_DETECT_INVIS
5 0
d8+10 1d2+1 0 0 10
13 13 13 13 13 13
BODY_NONE BODY_NONE SIZE_MEDIUM 0 0
0 0 0 0 0
C CLASS_FIGHTER 12
C CLASS_WIZARD 6
---example precedes this line---
Now, to explain, line-by-line:
#QQ00
The vnum of the mob. Read the section on Virtual Numbers in part 3 of
this document for more information.
mob example~
The namelist of this mob: what words can be used to interact with this mob.
For instance, 'kill mob' or 'kill example' would both be valid for this mob.
Note the tilde following the field.
the Example Mob~
The short desc of the mob. Used in messages such as:
"You poke the Example Mob."
"the Example Mob pounds you!"
This is the last time we'll note the tilde following the description.
An example mob stands...
~
The long desc of the mob. Used as part of a room description when a player
enters or looks in a room.
The example mobs looks...
~
This is the description of the mob; what a player sees when typing:
'look' at the mob.
U 18 CLASS_MONSTER RACE_NONE SEX_MALE POS_STANDING GOD_NEUTRAL
The 'U' stands for unique mob. This feature is not used in Mud20 presently,
and is left there as a placeholder. Always use a 'U' here.
The first number is the level of the mob, or hit dice.
The second value is the CLASS of the mobile. If it is not flagged ACT_CLASS,
this value is ignored, and saved to CLASS_MONSTER. In this case, the level
is purely the HIT DICE of the mobile. NOTE that in order for class levels
to count, you also need to set the mobile's MCLASS level (preceded with a 'C'
flag, below.)
The third value is the RACE of the mobile. if the mobile is not flagged
ACT_RACE, this value is ignored. Otherwise, several racial characteristics
are determined by the race and racial type of the mobile.
The fourth value is the gender of the mobile.
The fifth value is the position of the mobile at reset.
The sixth value is the deity of the mobile. This determines several things
based on the faith of players that interact with the mobile.
ACT_RACE|ACT_WIMPY|ACT_RACE
AFF_DETECT_INVIS
The first line is the ACTION flags, which determine certain behaviours and
actions of the mobile.
The second line is the AFFECT flag, which tells the mud about any special
abilities the mob might have. Both these flag values work as per the section
'FLAGS' in part 3 of this handbook. See 'ACTION & AFFECT FLAGS' below for
more on both of these.
5 0
These are armor class fields for nonstandard mobiles. Mobiles will use the
armor settings for their race by default if flagged ACT_RACE. The first value
is the natural armor bonus, the second is the deflection bonus.
Note that this does not reflect actual armor of the type that is worn. If
you want your mobile to wear armor, you need to equip it in resets with the
proper objects.
d8+10 1d2+1 0 0 10
The first field is the mobs hit dice. There is more on Hitpoints and damage
below in the aptly named 'HITPOINTS and DAMAGE'.
The second field is how much damage a mob does with its bare hands in dice.
The third field is the alignment of the mobile, from good(1000) to evil(-1000).
The fourth field is the mobile's ethos, from lawful(1000) to chaotic(-1000).
The fifth field is how much money the mobile carries in copper.
13 13 13 13 13 13
This is the abilities of the mobile, in the following order:
STR, DEX, CON, INT, WIS, CHA
BODY_NONE BODY_NONE SIZE_MEDIUM 0 0
The first value is the body parts a mobile possesses if it is flagged ACT_BODY.
This value is overridden if the mobile is flagged ACT_RACE, it is used for
generic nonstandard race mobiles.
The second value is the body parts a mobile attacks with if it is not flagged
ACT_RACE. This value is overridden if the mobile is flagged ACT_RACE, it is
used for generic nonstandard race mobiles.
The third value is the size of the mobile, based on standard size categories
in the D20 SRD:
SIZE_FINE
SIZE_DIMINUTIVE
SIZE_TINY
SIZE_SMALL
SIZE_MEDIUM
SIZE_LARGE
SIZE_HUGE
SIZE_GARGANTUAN
SIZE_COLOSSAL
This setting overrides the racial default for mobiles flagged ACT_RACE, to
allow for nonstandard sized creatures (giant bears, miniature giant space
hamsters, etc.)
C CLASS_FIGHTER 24
These are the classes of a mobile flagged ACT_CLASS. This can be as many
classes as is reasonable, so long as the total level of classes does not
exceed the level of the mobile. Note that a mobile flagged ACT_CLASS has
its hit points determined from its classes first, rather than its hit die
field. The total number of class levels does not have to add up to the
mobile level, any additional mobile levels are considered monster hit dice,
and determine the remaining hit points based on the hit die field.
The multiclass flags use the same class flags as the class field above:
class flags
CLASS_BARBARIAN 0
CLASS_BARD 1
CLASS_CLERIC 2
CLASS_DRUID 3
CLASS_FIGHTER 4
CLASS_MONK 5
CLASS_PALADIN 6
CLASS_RANGER 7
CLASS_ROGUE 8
CLASS_SORCERER 9
CLASS_WIZARD 10
CLASS_ADEPT 11
CLASS_NOBLE 12
CLASS_COMMONER 13
CLASS_EXPERT 14
CLASS_WARRIOR 15
CLASS_ARCANE_ARCHER 16
CLASS_ARCANE_BLADE 17
CLASS_ASSASSIN 18
CLASS_BLACKGUARD 19
CLASS_DUELIST 20
CLASS_DWARVEN_DEFENDER 21
CLASS_ELDRITCH_KNIGHT 22
CLASS_LOREMASTER 23
CLASS_MYSTIC_THEURGE 24
CLASS_SHADOWDANCER 25
CLASS_MONSTER 99
The rest of the fields in the mobile entry are not currently utilized, merely
there to make for easy addition of fields in future revisions without the need
to address changes in the room layout.
*** DESCRIPTIONS
Descriptions are done much the same way as those in the section in 'Rooms',
earlier in this handbook. The reader is encouraged to go back and reread
that section if necessary. However, the placement of tilde's is still very
important.
- Name list~ name of the mobile
- Short description~ shown when interacting with the mobile
- Long description~ shown when typing 'look' in the room the mob stands.
- Description~ shown when you look at the mobile.
*** ACTION & AFFECTION FLAGS
Action flags tell the mud how a mob behaves, and affection flags control
the special qualities of a mob. These flags are added together as
described in 'FLAGS', in part 3 of this handbook.
Remeber that the flags can be referenced as the flag name itself. Below
is a listing of flags for each type, with descriptions of what each does:
Action Flags
ACT_STAY_AREA BV01 /* Stays in the Area it resets */
ACT_SENTINEL BV02 /* Stays in one room */
ACT_SCAVENGER BV03 /* Picks up objects */
ACT_DRUNK BV04 /* is drunk and talks so */
ACT_MOUNTABLE BV05 /* Can be mounted */
ACT_AGGRESSIVE BV06 /* Attacks PC's */
ACT_NOWANDER BV07 /* Stays in same sector type */
ACT_WIMPY BV08 /* Flees when hurt */
ACT_PET BV09 /* Auto set for pets */
ACT_TRAIN BV10 /* Can train PC's */
ACT_BANK BV11 /* Mobile is a banker */
ACT_WEAK BV12 /* Cannot carry anything */
ACT_SMART BV13 /* Can talk */
ACT_NOCORPSE BV14 /* Disappears after fight */
ACT_LANGUAGE BV15 /* Can teach languages */
ACT_BODY BV16 /* Body parts are used */
ACT_RACE BV17 /* Uses race table */
ACT_CLAN_GUARD BV18 /* Clan Guards */
ACT_IS_HEALER BV19 /* Sells healing services */
ACT_WILL_DIE BV20 /* Purely Internal */
ACT_NOFIGHT BV21 /* Doesn't attack */
ACT_CLASS BV22 /* Uses class table */
ACT_GUARD BV23 /* Carries out guard functions */
ACT_FAMILIAR BV24 /* is a familiar, and conveys benefits */
ACT_UNDEAD BV25 /* No corpse or body parts */
ACT_IDENTIFY BV26 /* Can identify objects for fee */
ACT_CITIZEN BV27 /* Is a citizen of the are, affects legal status in area - MUST CODE */
ACT_NOASSIST BV28 /* Will not autoassist others - MUST CODE */
ACT_REQUEST BV29 /* Will honor the REQUEST command - MUST CODE */
ACT_MOBINVIS BV30 /* is invisible to mortals like AFF_ETHEREAL */
ACT_WARHORSE BV31 /* Can be ridden in combat without penalty */
Affect Flags
AFF_INVISIBLE 2 The mobile is invisible.
AFF_DETECT_INVIS 8 The mobile can see invisible players.
AFF_SANCTUARY 128 The mobile is affected by the spell sanctuary.
AFF_FAERIE_FIRE 256 The mobile is affected by the spell faeire fire.
AFF_UNDERSTAND 2048 The mobile can understand anyone.
AFF_SNEAK 32768 The mobile is sneaking, players to not see it move.
AFF_HIDE 65536 The mobile is hiding.
AFF_FLYING 524288 The mobile is flying always.
AFF_PASS_DOOR 1048576 The mobile can walk through locked doors.
AFF_STEALTH 2097152 The mobile can hide and sneak continually.
AFF_CLEAR 4194304 The mobile can walk through thick vegetation.
AFF_HUNT 8388608 The mobile chases fleeing characters, if possible.
AFF_TONGUES 16777216 Allows the mobiles to speak all languages.
AFF_ETHEREAL 33554432 Makes the mobile absolutely invisible to system
*** Note:
Please remember not to use any combination of values that will
select a bit outside of those shown. Although combining valid
bits are allowed.
*** Simple/Complex
The 'S' at the end of the affects field is a placeholder that is
ignored by this mud. It should always be an 'S'. Originally it was to
select Simple or Complex mobiles in Diku muds. It is here to support
future implementation.
*** BODY PARTS
You must give a flag to tell the mud that this is a valid field. This flag
is ACT_BODY, and should obviously go in the Action Flags field. If the
ACT_BODY flag is not set, then body parts will be ignored. Body parts will
also be ignored if the mobile is flagged ACT_RACE.
*** ATTACK PARTS
This field is normally ignored on the mud, but with the ACT_BODY flag
selected, the field becomes the attack parts of the mobile. Attack parts
is how the mobile attacks. The different kinds of attacks from various
body parts do not affect damage, as it only changes what is printed when
the attack takes place. This feature is required, but is there to give the
mobiles the correct forms of bare-hand attacks. Attack parts use the same
field values as that of the body parts. Mobiles with weapons will always
override the different kinds of body attacks. Any mobile that is not flagged
ACT_RACE MUST have attack parts set, else it will have no parts to attack
with.
Below are the flags and spams for attack parts listed.
BODY_HEAD head butt
BODY_MOUTH bite
BODY_EYE evil-eye
BODY_NONE shoulder slam
BODY_NONE hip slam
BODY_FOOT_2 knee
BODY_HAND_2 elbow slam
BODY_WING flap
BODY_TAIL tail slap
BODY_TENTICLE tenticle whip
BODY_HORN horn jab
BODY_CLAW_1 claw
BODY_HAND_1 punch
BODY_FOOT_1 kick
*** HITPOINTS and DAMAGE
The functions of hitpoints and damage are arrayed randomly by the
mud, as a function of imaginary dice and bonuses. These always
follow the form xdy+z, where x is the imaginary amount of dice, y is
how many sides these dice have, and z is a constant being added to the
final total.
For example, our example mob had hitpoints of 1d6+2: a random
number between 1 and 6, then add 2, for a range of 3-8. Another mob
might have 10d10+150 for a range of 160-250. Damage is calculated the
same way.
These fields must follow the form xdy+z, even if z equals 0!
For instance, our example mob does 1d4+0 damage with its bare hands...
Leaving any of these fields blank will cause errors for the load
procedure.
One more important thing to know about damage: this is the mob's damage
with its fists/claws/what-have-you. If the mobile is wielding a weapon,
the damage of the weapon overrides the barehand damage.
Standards and Measures
The best way to determine the strength of mobiles for hit points, level
and damage, is to refer to the monster listings in the D20 SRD.
*** GOLD
This is simply the amount of gold that the mobile is carrying when it
is loaded. All mobiles can carry some amount of gold.
maximum gold : level*1500
*** RACE
The creator must define the ACT_RACE bit in the action flags, and then use
one of the RACE_ types in this field. This will fix the mobile as to what
language it speaks and understands. It determines many characteristics such
as racial type, abilities, bonuses and etc. It will also allow mobprogs to
be used based on race.
*** POSITION
A mob will be loaded into its loading position initially, and after
fighting, will return to its default position.
The valid positions are:
POS_SLEEPING 4
POS_RESTING 5
POS_STANDING 7
There are a few more positions than these, but are not used
except during fighting, which the mud takes care of automatically.
*** GENDER
This is the sex of the mobile, and has only three possible values:
SEX_NEUTRAL 0
SEX_MALE 1
SEX_FEMALE 2
*** TIPS and OBSERVATIONS
Mobs wander around by default. Remember to include the 'Sentinel'
Action flag for stationary mobs!
Freak mobs can be simulated by loading them sitting and agressive,
with a default position of standing. After being attacked, they will
wander around instead of sitting back down! Other interesting things
can be done with the position values as well...
Don't forget to add the 'smart' Action flag if you want your mob to
talk. Neither add 'smart' to all mobs, unless you want a boar to
shout for revenge when it tries to get back at an attacker.
6. The #OBJECTS section
An object is any item in the game, be it unmovable rock, the fountain in
market square, or that nice sword Everyman the Ranger has. Everything
the mud needs to know about objects can be found in the #OBJECTS section,
except for where they actually are.
This section in the .are file will always start first with this line:
#OBJECTS
This section in the .are file will always end with with this line:
#0
*** OBJECT ARCHETYPE
<#vnum>
<name list>~
<short description>~
<long description>~
<description>~
<item type>
<item flags>
<wear locations>
<value0> <value1> <value2> <value3>
<weight> <cost> <level>
[obj program]
E
<extra name list>~
<extra description>~
A <apply type> <apply amount>
The night has begun.
C
<attack message>~
<classes that may use weapon>
Here is an example object, followed by a line-by-line breakdown:
---example follows this line---
#QQ00
sword example~
an example sword~
An example sword lies on the ground, examping.~
It looks very shiny and polished, as if someone
is taking care to try to make a good example.
~
ITEM_TYPE_WEAPON
FLAG_MAGIC|FLAG_ANTI_EVIL
CAN_WEAR_WIELD|CAN_WEAR_WIELD
0 MATERIAL_STEEL 10 SIZE_MEDIUM
WEAPON_TYPE_SWORD_LONG WFLAG_BANE RTYPE_REPTILIAN 10 0 0 0 0
5 1000 10
E
example~
This is a rather boring example.
~
A APPLY_STR 1
C
slash~
FLAG_CLASS_FIGHTER
---example precedes this line---
Note:
In the file, and amount of spaces or returns can separate different
fields, so the extra return and spacing in the above example is valid.
*** Field by Field Breakdown
The following is a list of each of the fields of the Object format.
*** Vnum
#QQ00
This is identical to the method of the mobile vnum.
This number may be the same as a room or mobile, but no other
object may have this number.
See the section on virtual numbers in Part 3 of this Handbook.
*** Name list
sword example~
The words can be used to manipulate the object.
In this case, either of the words 'sword' or 'example'
can be used in conjunction with a wield, drop, take, etc.
This field requires a '~' or tilde at the end of the line.
For use with mob_progs and obj_progs all names are appended
with a special name starting with 'I' and followed by the
vnum of the object. This is used to specifically point to
a particular key, if the player has several keys.
ex: item vnum is 9775, added keyword is 'I9775'
*** Short description
an example sword~
This is seen when the object is the target of a command:
'You wield an example sword.' 'You give an example sword to...'.
*** Long description
An example sword lies on the ground, examping.
~
This is what a player sees if the object is lying in a room by itself.
*** Description
It looks very shiny and polished, as if someone
is taking care to try to make a good example.
~
In Mud20, this field is used as the default "look" at the item,
for example, if you did "look sword" while holding this item.
Diku used this field for an action, and Merc ignored it.
*** Object Type
ITEM_TYPE_WEAPON
This number is what type of object this is...a weapon. See
'OBJECT TYPES' below.
*** OBJECT TYPES
ITEM_TYPE_LIGHT 1
ITEM_TYPE_SCROLL 2
ITEM_TYPE_WAND 3
ITEM_TYPE_STAFF 4
ITEM_TYPE_WEAPON 5
ITEM_TYPE_SYMBOL 6
ITEM_TYPE_SPELLBOOK 7
ITEM_TYPE_TREASURE 8
ITEM_TYPE_ARMOR 9
ITEM_TYPE_POTION 10
ITEM_TYPE_SPELLPOUCH 11
ITEM_TYPE_FURNITURE 12
ITEM_TYPE_TRASH 13
ITEM_TYPE_SHEATH 14
ITEM_TYPE_CONTAINER 15
ITEM_TYPE_QUIVER 16
ITEM_TYPE_DRINK_CON 17
ITEM_TYPE_KEY 18
ITEM_TYPE_FOOD 19
ITEM_TYPE_MONEY 20
ITEM_TYPE_COMPONENT 21
ITEM_TYPE_BOAT 22
ITEM_TYPE_CORPSE_NPC 23
ITEM_TYPE_CORPSE_PC 24
ITEM_TYPE_FOUNTAIN 25
ITEM_TYPE_PILL 26
ITEM_TYPE_PORTAL 27
ITEM_TYPE_ARTIFACT 28
ITEM_TYPE_TOOLS 29
ITEM_TYPE_AMMO 30
ITEM_TYPE_TOTEM 31
*** Object Flags
FLAG_MAGIC|FLAG_ANTI_EVIL
This determines what is affecting the object. In this case, the item is
magical, and it zaps any evil person who tries to wield it.
*** OBJECT FLAGS
FLAG_GLOW BV01 /* Item glows */
FLAG_DARK BV02 /* Absorbs light - MUST CODE */
FLAG_LOYAL BV03 /* Item does not fall when disarmed */
FLAG_EVIL BV04 /* Evil aura */
FLAG_INVIS BV05 /* Item is invisible */
FLAG_MAGIC BV06 /* Item is magic, has magial aura */
FLAG_NODROP BV07 /* Cannot be dropped, cursed */
FLAG_BLESS BV08 /* Good aura */
FLAG_ANTI_GOOD BV09 /* Zaps good chars */
FLAG_ANTI_EVIL BV10 /* Zaps evil chars */
FLAG_ANTI_NEUTRAL BV11 /* Zaps neutral chars */
FLAG_ANTI_LAWFUL BV12 /* Zaps lawful chars */
FLAG_ANTI_CHAOTIC BV13 /* zaps chaotic chars */
FLAG_ANTI_UNCONCERNED BV14 /* zaps unconcerned chars */
FLAG_NOREMOVE BV15 /* Can't be removed, cursed */
FLAG_INVENTORY BV16 /* Can't be put in containers */
FLAG_BURNING BV17 /* Sheds light, adds fire damage to hit */
FLAG_NOT_VALID BV18 /* internal use only */
FLAG_AUTO_ENGRAVE BV19 /* item auto tags itself to first wearer */
FLAG_FORGERY BV20 /* internal use for forged items */
FLAG_ETHEREAL BV21 /* cannot be seen by mortals */
FLAG_MODIFIED BV22 /* internal use for spells and renames */
FLAG_HIDDEN BV23 /* Item in hidden in room */
FLAG_MASTERWORK BV24 /* masterwork item */
FLAG_NOSCRY BV25 /* cannot be scried with spells */
FLAG_CONCEALED BV26 /* concealed on a PCs person */
FLAG_DEATHROT BV27 /* disappears on PCs death - MUST CODE*/
FLAG_PROTOTYPE BV28 /* for OLC with oset - MUST CODE */
FLAG_BURIED BV29 /* buried underground - MUST CODE */
FLAG_TRANSPARENT BV30 /* items layered under this one can be seen - MUST CODE */
FLAG_UNIQUE BV31 /* only one of this VNUM can be worn by PC - MUST CODE */
*** Wear Flags
CAN_WEAR_WIELD|CAN_WEAR_WIELD
This flag tells the mud where the item can be worn on a player
or mob. An object may be flagged to be worn is several places,
such as a band that can go around the wrist and the waist.
*** WEAR FLAGS
CAN_WEAR_TAKE BV01 /* 1 */
CAN_WEAR_FLOAT BV02 /* 2 */
CAN_WEAR_HEAD BV03 /* 4 */
CAN_WEAR_FACE BV04 /* 8 */
CAN_WEAR_EARS BV05 /* 16 */
CAN_WEAR_NECK BV06 /* 32 */
CAN_WEAR_ARMS BV07 /* 64 */
CAN_WEAR_WRIST BV08 /* 128 */
CAN_WEAR_HANDS BV09 /* 256 */
CAN_WEAR_FINGER BV10 /* 512 */
CAN_WEAR_BODY BV11 /* 1024 */
CAN_WEAR_ABOUT BV12 /* 2048 */
CAN_WEAR_BACK BV13 /* 4096 */
CAN_WEAR_WAIST BV14 /* 8192 */
CAN_WEAR_BELT BV15 /* 16384 */
CAN_WEAR_LEGS BV16 /* 32768 */
CAN_WEAR_ANKLE BV17 /* 65536 */
CAN_WEAR_FEET BV18 /* 131072 */
CAN_WEAR_SHIELD BV19 /* 262144 */
CAN_WEAR_WIELD BV20 /* 524288 */
CAN_WEAR_BOTH BV21 /* 1048576 */
CAN_WEAR_HOLD BV22 /* 2097152 */
*** Material and size types
0 MATERIAL_STEEL 0 SIZE_MEDIUM
The first value is unused, and is left for future implementation.
The second field is the material type of the item. This affects things
like the item's hardness (damage resistance) and the total max hit points
of the item.
The third value is also unused, and is left for future implementation.
The fourth value is the object's size, the size of objects determines
various things: The size of armor determines what size character can wear
it. The size of a weapon is based on the weapon type, and is set when the
weapon type is chosen in OLC, it also determines what size PC can use it.
The size of a container determines the max size of an object to be put in
it (no, you can't put a spear in a backpack), the size of a sheath
determines the size weapon that will fit in it. The other item types use
size as a relative comparison, a ring, for example, is diminutive, a
necklace is tiny, while a bronze statue, while also treasure, could be
medium, or even large in size. Again, size helps to determine whether a
character could pick it up, put it in a container, etc. A human isn't
going to be picking up a gargantuan anything, even if it's made up of
feathers, simply because it's too big.
*** Object Values
WEAPON_TYPE_SWORD_LONG WFLAG_BANE RTYPE_REPTILIAN 10 0 0 0 0
These are the object's values. What each number means is completely
dependant on what Type of object it is.
*** OBJECT VALUES
The eight numbers consisting of the 'item values' are different
for each type of item. This is no longer relevant to the original diku
values at all, and most items have totally different uses for each
value.
The last value, value[7], is used as a modifier for a skill affecting the
item. For example, if someone conceals a dagger on their person, the Sleight
of Hand roll for the act is stored in value[7]. Any attempt to search for
the item will have to beat the value stored there.
Below is listed the used values for each item type. If a value isn't listed,
it isn't used for that item type:
ITEM_LIGHT (1)
Value[0]: Not Used
Value[1]: Not Used
Value[2]: Number of hours the light can be used for. Zero hours means that
the light has gone out. A negative number will create an eternal
light source. Eternal lights should not be easily obtained.
Value[3]: Not Used
ITEM_SCROLL (2)
Value[0]: Level of the spell on the scroll.
Value[1]: Which spell (see list in spells.txt)
Value[2]: FLAG_ARCANE or FLAG_DIVINE, whether the spell is divine or arcane.
ITEM_WAND (3)
Value[0]: Level of spell in wand.
Value[1]: Max Charges
Value[2]: Charges Left
Value[3]: Which spell in wand (see list in spells.txt)
ITEM_STAFF (4)
Value[0]: Level of spell in staff.
Value[1]: Max Charges (1..X)
Value[2]: Charges Left
Value[3]: Which spell in staff (see list in spells.txt)
Value[4]: Which spell in staff (see list in spells.txt)
Value[5]: Which spell in staff (see list in spells.txt)
Value[6]: Which spell in staff (see list in spells.txt)
ITEM_WEAPON (5)
Value[0]: The type of weapon
(inset weapon types here)
Value[1]: Weapon Flags (see weapon flags)
(insert weapon flags here)
Value[2]: First modifier for weapon flags
Value[3]: Second modifier for weapon flags
ITEM_TREASURE (8)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_ARMOR (9)
Value[0]: The effective AC. >0 enhances the AC. <0 reduces AC.
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_POTION (10)
Value[0]: Level of the spell in the potion.
Value[1]: Which spell (Listed in spells.txt)
ITEM_FURNITURE (12)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_TRASH (13)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_CONTAINER (15)
Value[0]: Maximum weight the container can contain.
Value[1]: Container flags:
(insert container flags here)
Value[2]: The item-number of the object which can open the object. -1 means
no lockability.
Value[3]: -
ITEM_DRINKCON (17)
Value[0]: Maximum drink-units the drink-container can contain.
Value[1]: Number of drink-units that are left in the container.
Value[2]: The type of liquid in the drink-container, one of:
NAME NUMBER DRUNKNESS FULLNESS THIRST
--------------------------------------------------------------------
LIQ_WATER 0 0 0 10
LIQ_BEER 1 2 0 5
LIQ_WINE 2 5 0 5
LIQ_ALE 3 2 1 5
LIQ_DARKALE 4 1 1 5
LIQ_WHISKY 5 6 0 3
LIQ_LEMONADE 6 0 0 8
LIQ_FIREBRT 7 10 0 0
LIQ_LOCALSPC 8 3 0 3
LIQ_SLIME 9 0 1 -6
LIQ_MILK 10 0 2 6
LIQ_TEA 11 0 0 6
LIQ_COFFE 12 0 0 6
LIQ_BLOOD 13 0 3 -1
LIQ_SALTWATER 14 0 0 -3
LIQ_COKE 15 0 0 6
The above values for drunkness/fullness/thirst are used per
four "units" drunk. The values are expressed in HOURS!
Example:
Dragon drinks 7 times milk
His Drunkness is not changed: (7*0) hours
His Fullness increases by: (7*2) hours
His Thirst increases by: (7*6) hours
The hours above are numbers between 0 and 24. 24 hours is
maximum for drunkness/fullness/thirst. When hours are zero
for any drunkness/fullness/thirst the person will be
sober, hungry, or thirsty respectively.
Value[3]: if this value is non-zero, then the drink is poisoned.
NOT_POISONED 0
POISONED 1
ITEM_KEY (18)
Value[0]: The key-type. This value must match the lock-type the door
that the key can open (if the vnum of the key doesn't match
the lock-type that is).
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOOD (19)
Value[0]: The number of hours, that this food will fill the stomach
Value[1]: -
Value[2]: -
Value[3]: If this value is non-zero, the food is poisoned.
NOT_POISONED 0
POISONED 1
ITEM_MONEY (20)
Value[0]: The number of gold coins "in the pile of coins".
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_BOAT (22)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOUNTAIN (22)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_PILL (22)
Value[0]: Level of the spell in the potion.
Value[1]: Which spell (Listed in spells.txt)
Value[2]: Which spell
Value[3]: Which spell
ITEM_AMMO (22)
Value[0]: Ammunition type (matches Value[0] of weapon that will shoot it)
Value[1]: Damage (amount of damage caused by the ammo when it hits)
Value[2]: Speed (4/second, keep numbers high (20 for fast arrows))
Value[3]: Effective range (number between 1 and 5)
To create a ranged weapon with ammo, the weapon must also be
created. This is done by adding the vnum of the ammo to Value[0]
of the weapon.
*** Object Weight
5
The weight of the object.
*** Value
1000
The value of the object, in gold coins.
*** Level
10
This is the level of the object. It is only valid if the
FLAG_LEVEL flag is valid. Emud requires this field to be
used. Level is calculated by the game otherwise, to support
backward compatibily.
*** Extra Descriptions
E
sword example~
This is a rather boring example.
~
This is an extra description, and behaves EXACTLY like the extra
descriptions of rooms. The reader is referred to Part 4 of this
Handbook for more information.
*** APPLIES
A 1 1
These are 'applies' of the weapon...the 'A' signifying that
an apply is forthcoming. The second digit is the type of
apply, and the third how much the apply is worth.
An item apply is a particular effect the item has upon the
holder/wielder/wearer's statistics. There can be a maximum of three
applies on an item, each requiring their own 'A' flag to let the mud
know that there is more than one apply. Thus, a sword that added one
to a character's strength, and -10 to his hitpoints would be:
A APPLY_STR 1
A APPLY_HIT -10
Below is a list of the different types of applies, and their values.
APPLY_NONE 0
APPLY_STR 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_AC_ENHANCE 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
*** Combat Usages
C
whack~
FLAG_CLASS_FIGHTER
This is a system to change the default statement made when a weapon hits
an opponent. It also allows you to specifically define which classes can
use the weapon, even if that class cannot normally wield the type of
weapon defined by weapon type. The creator should use the weapon type
field (value 3) to set up weapons for backstabbing, shooting, throwing,
etc. All npc's can wield the item if any class is defined.
Class selection method will default to the normal method if no classes
are selected (Put a '0' in the field).
The weapon defined in the example will 'whack' the opponent, and can be
wielded by fighters.
List of flags of classes
FLAG_CLASS_BARBARIAN BV01
FLAG_CLASS_BARD BV02
FLAG_CLASS_CLERIC BV03
FLAG_CLASS_DRUID BV04
FLAG_CLASS_FIGHTER BV05
FLAG_CLASS_MONK BV06
FLAG_CLASS_PALADIN BV07
FLAG_CLASS_RANGER BV08
FLAG_CLASS_ROGUE BV09
FLAG_CLASS_SORCERER BV10
FLAG_CLASS_WIZARD BV11
FLAG_CLASS_ADEPT BV12
FLAG_CLASS_NOBLE BV13
FLAG_CLASS_COMMONER BV14
FLAG_CLASS_EXPERT BV15
FLAG_CLASS_WARRIOR BV16
FLAG_CLASS_ARCANE_ARCHER BV17
FLAG_CLASS_ARCANE_BLADE BV18
FLAG_CLASS_ASSASSIN BV19
FLAG_CLASS_BLACKGUARD BV20
FLAG_CLASS_DUELIST BV21
FLAG_CLASS_DWARVEN_DEFENDER BV22
FLAG_CLASS_ELDRITCH_KNIGHT BV23
FLAG_CLASS_LOREMASTER BV24
FLAG_CLASS_MYSTIC_THEURGE BV25
FLAG_CLASS_SHADOWDANCER BV26
Please note that FLAG_CLASS_ values are not the same as CLASS_ values
*** Object Programs
Object programs are based on intercepting user commands, and substituting
new ones with actions outside of normal game operation. Several programs
may be included on each object. These programs, used in combination with
mob_progs can lead to very complex systems of commands. Object programs
can also trigger off of basic time increments, damaging others, getting
damaged, wearing or removing the object with the program. They cannot
trigger off of things that the player sees, or text on the screen.
Trigger off things seen on the screen is limited to mob_progs, and will
not be included in object programs, due to operational speed problems.
Object programs start with a 'P' similar to object extra descriptions.
Following the 'P' is a number describing the index value of the program,
for branching operations to reference.
An object will usually have a group of small 'programs' or execution units
that do individual commands. There is always a 'Trigger' that will start
the program, and a 'response' that does some form of action. The trigger
need not be related to the response. This also means that the response
does not know why it was triggered, and responses cannot be based on them.
Ex: An object may not give back the same amount of hit points to the player
if a damaged trigger was used, but it may give back some fixed amount,
because it knows that the player was hit.
In programs with the same index, execution of a command will start with
the first one that gets triggered regardless of the index number. But
the system will then flow through to any subsequent program with the same
index number. This will allow the programs to do several routines on one
trigger.
*** IMPORTANT: Each program set must have a unique index number.
Object programs basically follow the format of trigger followed by
response. Each type of obj_prog trigger has a special format:
Normal command intercept:
P <reference number>
TRIGGER <percentage> <game command>
{responses}
Percentage is the chance that the command will be intercepted.
Game command is the command you wish to intercept.
TRIG_UNKNOWN
P <reference number>
TRIG_UNKNOWN <percentage> <unknown command>
{responses}
Unknown command is either a social command, or something new that would
not be a normal command, such as "polish" or "brush".
TRIG_VOID
P <reference number>
TRIG_VOID
{responses}
This is generally used as the end effect of a branching response.
TRIG_TICK
P <reference number>
TRIG_TICK <percentage>
{responses}
This is triggered once every 4 seconds of real time. It can be used to make
the player do things they did not intend to do. Or occasionally modify
stats, or any other time based reaction.
TRIG_HIT
P <reference number>
TRIG_HIT <percentage>
{responses}
This trigger is called every time the player with the object is hit in a
non magical way. This can be used to make objects that heal the player
every time they are hit, or objects that scream whenever they are damaged.
TRIG_DAMAGE
P <reference number>
TRIG_DAMAGE <percentage>
{responses}
This is called every time a player damages another character, either a
mobile, or player in a non magical way. It can be used to create objects
that say something or any other response to the damage given.
TRIG_WEAR
This is called everytime the object with the program is worn. It can be
used to make a magical weapon greet its new owner.
TRIG_REMOVE
This is called everytime the object with the program is removed. It can
be used to remove a disguise that was set upon wearing.
TRIG_ROOM_COMMAND
This is called everytime a player uses defined command in the room in
which the object lies. You can use ethereal objects if needed, it's
the result that counts.
TRIG_ROOM_UNKNOWN
This is called everytime a player uses defined keyword in the room in
which the object lies.
TRIG_SACRIFICE
This is called when a player sacrifises the object with the program.
*** RESPONSES
Each type of obj_prog response has a special format. The only time a
tilde is required is after a string is used. Commands such as OPROG_APPLY
should not have a tilde after them.
OPROG_ECHO
P 1
TRIG_UNKNOWN 100 EXAMPLE
OPROG_ECHO
bla bla bla bla~
These lines are given to the user only. Be sure to include the tilde.
OPROG_GOD_COMMAND
P 1
TRIG_UNKNOWN 100 EXAMPLE
OPROG_GOD_COMMAND
say Greetings&
smile self&
say the name is $I, Sir $I~
These commands are given at the trust level of 98. This means that the
user is able to perform god commands for the duration of the object
program. Several commands may be used, and separated by the '&' symbol.
The '$' allows you to print player related information:
$i name of the player
$I name and title of the player
$m him her it (based on player sex)
$s his her its
$e he she it
$o short description of the object
Always use 'self' to refer to the player when the name doesn't need to
be printed.
All mobile program commands can be used.
It should be noticed that objects can use quest bits to their fullest by
allowing objects to read and write both the object's and the player's
quest bits.
Example:
OPROG_GOD_COMMAND
mpmset self long A small turtle named $ stands here.~
This would set the description that others see when entering the
room the player is in, very similar to the skill disguise. To
reset the string to normal game operation, use:
OPROG_GOD_COMMAND
mpmset self long null
OPROG_GOD_ARGUMENT
P 1
TRIG_COMMAND 100 flee
OPROG_GOD_ARGUMENT
say beam me up scotty!&
mpecho {170}$I starts to fade and waves goodbye at $s friends.&
mpgoto ~
This command allows the use of one command, but the inclusion of an
argument. This allows special commands like GOTO to let the user pick
a destination. It makes sure that the user cannot put any multi-line
commands so they will be limited to the one command given. This is used
to give the player the full advantage of the god command. Use this
only under permission of the game administrators. $I will print the
player's name and honorific, the $s prints his/her/its based on gender.
Example of the above program executed by a player named Neophyte.
Sword Master Neophyte says 'beam me up scotty!'
Sword Master Neophyte starts to fade and waves goodbye at his friends.
OPROG_APPLY <APPLY_TYPE> <AMOUNT>
P 1
TRIG_TICK 100
OPROG_APPLY OAPPLY_HIT 25
This command is executed to change one of several stats of the player that
has the current object. These will only affect the current stats, and
never the maximum, as most other object affects to. It is allowed to
make the amount either positive or negative.
Apply types:
OAPPLY_HIT - Applies to current hit points.
OAPPLY_MOVE - Applies to current movement points.
OAPPLY_MANA - Applies to current mana points.
OAPPLY_ALIGNMENT - Applies to current alignment.
OPROG_JUNK
P 1
TRIG_HIT 100
OPROG_ECHO
Your shield shatters into a million pieces!~
P 1
TRIG_VOID
OPROG_JUNK
This command will destoy the item that is executing the program. This is
the only bug free method unlike sacrifice, eat, or mpjunk
OPROG_IF_HAS_OBJECT <VNUM> <TRUE DESTINATION> <FALSE DESTINATION>
P 1
TRIG_UNKNOWN 100 EXAMPLE
OPROG_IF_HAS_OBJECT 21 2 3
P 2
TRIG_VOID
OPROG_ECHO
I have the object with vnum: 21~
P 3
TRIG_VOID
OPROG_ECHO
I do not have the object with vnum: 21~
This command will branch successfully if the player has the object in
either inventory or equipment, but not in a container.
In this case the P 2 will be jumped to if the if check is true.
If the if check is false P 3 will be called.
Do aknowledge you can only jump to a higher reference number.
if a lower number is given than the if check itself the program will
be aborted.
OPROG_IF
OPROG_IF <IF CHECK> <OPERATOR> <VALUE> <TRUE DEST.> <FALSE DEST.>
Available IF CHECKS:
OIF_WEAR_LOC - wear location (-1 if not worn)
OIF_USER_CLASS - user class
OIF_USER_POSITION - user position
OIF_USER_GOLD - user gold
OIF_USER_ROOM_NUM - user room number
OIF_RANDOM_PERCENT - random percent
OIF_USER_WHICH_GOD - user follows which god
OIF_USER_ALIGNMENT - user alignment
OIF_USER_LEVEL - user level
OIF_USER_RACE - user race
OIF_USER_PERCENT_MOVE - user move percent
OIF_USER_PERCENT_HITPT - user hitpoints percent
OIF_USER_PERCENT_MANA - user mana percent
OIF_USER_SEX - user gender
OIF_USER_AREA - The first room number of user's area
OIF_USER_SECTOR - The sector type the user is in
OIF_TIME_OF_DAY - The hour of day in game time
OIF_MCLASS_FIGHTER - The amount of war levels
OIF_MCLASS_RANGER - The amount of Gla levels
OIF_MCLASS_ROGUE - The amount of Mar levels
OIF_MCLASS_MONK - The amount of nin levels
OIF_MCLASS_DRUID - The amount of dru levels
OIF_MCLASS_BARD - The amount of sor levels
OIF_MCLASS_CLERIC - The amount of sha levels
OIF_MCLASS_WIZARD - The amount of wlc levels
OIF_WEATHER - ( 0 = Clear, 1 = Cloudy, 2 = Raining, 3 = Storm )
OPERATOR
< - Less than
> - Greater than
= - Equal to
! - Not equal to
VALUE
The value is a number that the check variable is compared against.
True destination is the obj_prog index (the one listed after the 'P')
that the branch will continue when the if check is true.
False destination is the obj_prog index that is executed when the if
check is false.
If the destination number is not found, then the branch will not be
successful, and the program will stop. This can be used for branches
that are not necessary to the operation of the program.
When using 0 as the destination number the program will always abord.
It's suggested to use 0 so an area admin won't waste time looking for
a non existant destination number.
OPROG_QUEST_SET <OFFSET> <NUMBITS> <VALUE>
P 1
TRIG_UNKNOWN 100 EXAMPLE
OPROG_QUEST_SET 0 4 15
This is a method of setting the value of the quest bits on an object.
The offset is the starting bit number of the grouped quest numbers.
The numbits are the amount of bits involved with the defined value.
The value is the desired value of the set.
OPROG_QUEST_ADD <OFFSET> <NUMBITS> <VALUE>
P 1
TRIG_WEAR 100
OPROG_QUEST_ADD 4 4 1
This is a method of adding a value to the quest bits of an object.
The offset is the starting bit number of the grouped quest numbers.
The numbits are the amount of bits involved with the defined value.
The value is the desired increment being added to the quest bits.
The number inside the defined bit range will never overflow to higher
bits, or go below zero. The value may be negative to subtract.
This can be used to make items that have limited lifespan.
In this example the value will go when wearing several times to :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 and so on.
OPROG_PLAYER_QUEST_IF <OFFSET> <NUMBITS> <OPERATOR> <VALUE> <TRUE> <FALSE>
OPROG_OBJECT_QUEST_IF <OFFSET> <NUMBITS> <OPERATOR> <VALUE> <TRUE> <FALSE>
P 1
TRIG_UNKNOWN 100 TEST
OPROG_PLAYER_QUEST_IF 0 1 = 1
OPROG_ECHO
Your first bit has value 1~
The quest if check allows branching to other obj_progs.
The offset is the starting bit number of the grouped quest numbers.
The numbits are the amount of bits involved with the defined value.
The quest bits checked will be those of the area the object belongs to.
Operator:
< - Less than
> - Greater than
= - Equal to
! - Not equal to
The value is a number that the check variable is compared against.
True destination is the program index (the one listed after the 'P') that
the branch will continue when the if check is true.
False destination is the obj_prog index that is executed when the if
check is false.
If the destination number is not found or goes backwards, then the branch
will not be successful, and the program will stop. This can be used for
branches that are not necessary to the operation of the program. It's
good practise to branch to 0 in this case, which will always abord the
program.
** Example Programs:
P 1
TRIG_COMMAND 45 say
OPROG_GOD_COMMAND
mpechoat self {160}You are occasionally tongue tied.&
mpechoaround self $n tries to speak but $e seems tongue tied.~
P 2
TRIG_UNKNOWN 100 HOME
OPROG_IF OIF_WEAR_LOC = WEAR_NONE 3 4
P 3
TRIG_VOID
OPROG_ECHO
You must wear the example object (with program) to go home.~
P 4
TRIG_VOID
OPROG_GOD_COMMAND
mpechoaround self {030}$I says 'I'm going home!'&
mpgoto 9755&
say I'm home!~
Explanation:
The first section of the program is a simple command trigger. 45% of the time
that the user tries to use the 'say' command, it will not be functional, and
the user will see the response that he is tongue tied. The mpechoaround will
send the same message to everyone but the user standing in the same room.
The rest of the program checks when the user types the unknown command
'HOME'. If that is typed, then the If Check checks for the wear location of
the object. If the wear location equals WEAR_NONE (item is not worn),
then the command continues with program 3. If the item is worn, then the
program will continue with program 4.
The next program has a void trigger, and can only be reached by the previous
branch statement. The user is messaged to wear the object.
The final program has a void trigger too.
Faking that the player says he is going home,
then to 'mpgoto', a mob command, the location of 9755, which is the square
in the city of Roterodamum.
Then the user is forced to say: I'm home!
Notes on obj_progs:
It can easily be seen that there is a very large amount of room for
improvement on object_programs of this type. This system has been set
up because obj_programs are searched MANY more times than mob_progs,
and require a significantly longer amount of CPU time to process than
mob_progs. Therefore a tokenized method was developed instead of the
interpreted system of the mob_progs. Essentially the format in the .are
file is the same that the database system saves all the information.
Using this tokenized system is at least 4 times faster for the CPU than
an interpreted based system.
More complex object programs can be realized by asking the Emud implementors
to add new types of triggers and responses. This system is relatively new,
and has not been fully tested for CPU usage, but early tests show that the
response time is such that 50 people having 20 items with complex programs
each, should not noticeably degrade system performance. For the sake of
safety, both the commands of 'save' and 'quit' are removed from those allowed
in obj_prog responses. Be very careful with using the god commands, as they
can permanently change the statistics of players, rooms, and just about
anything in the game.
*** Important:
It is allowable to delete the item as a final command.
The JUNK command will always automatically terminate object programs,
regardless if the object program continues.
QUEST BITS:
This is generally a very complex system to initially understand, therefore
The following is a detailed description of how quest bits work.
Quest bits are used in 3 places.
-Each player has a set of quest bits for each area, so that a player may
be on several quests, and each area has it's own set, without worrying
about other areas.
-Each mobile has one set of quest bits. (not saved during crashes)
-Each item has one set of quest bits.
It should generally be considered that you should not allow modifications
of quest bits by an something from one area to another. As each set of
quest bits are defined completely by the area creator.
Quest bits are used to allow the area creator the ability to define their
own set of variables that are constant for that individual, object, or
mobile.
This means that once the value is set, it is saved throughout the game,
and allows various states, or steps in a quest to be marked. The
definition of a quest is the ability of the game to know how far a player
has gotten in an area regardless if they come back to the game several
days later.
Each set of quest bits is really a set of user definable 128 bits.
Some knowledge of binary numbers helps in decifering this system
completely, but is not necessary.
The offset is always the starting point of where the defined value is.
The amount of bits defines the totaly range of the values used.
With basic binary system, the amount of bits define an exponential range:
1 bit - 2 values
2 - 4
3 - 8
4 - 16
5 - 32
6 - 64
7 - 128
8 - 256
Ex. Say a creator wants to have 4 states on an object. The first being the
initial state, the second when a player hits a mobile, the third when
the player goes to sleep, and the fourth when he wakes up.
The area creator wants an object that poisons the player when he attacks
a mobile, and damages them when the player wakes up. The player is
even informed that when he wakes up next, he will be hurting very bad.
Since there are only 4 states, only 2 bits are required.
Be aware that's only 2 out of 128 bits, this means you can pick the
first available bits, but also the last available bits.
Below we'll see some asci art showing the first 32 bits, be aware that
the first bit has the location: 0, and bit 32 has location: 31
In this example we'll only use the 5th and 6th bit, they're at
locations: 4 and 5
30 28 26 24 22 20 18 16 14 12 10 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X| | |X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
("X" indicates an unused bit)
A bit has either value 0 or 1 which allows you to make 4 values:
00 = 0 (initial state)
01 = 1 (player has hit mobile)
10 = 2 (players has gone to sleep)
11 = 3 (player has woken up)
If this is clear to you we'll once again concentrate on how to read
and how to write these bits.
Reading the bits:
OPROG_OBJECT_QUEST_IF 4 2 = 3 6 8
Freely translated:
start reading at bit 4 + read 2 bits
if equals : 3 --> true: branch to program 6
false: branch to program 8
Writing goes almost the same way :
To set the bits to have the value 2 -->
OPROG_QUEST_SET 4 2 2
Now what if you don't understand a single bit of the above? This is
possible if you're not familiar with computer science. In that case
you can use a set amount of values that always work. In that case we
suggest you always use the format to remember 16 steps of a player's
or object's quest bits:
OPROG_QUEST_SET 0 4 <value ranging from 0 to 15)
OPROG_OBJECT_QUEST_IF 0 4 = <value ranging from 0 to 15)
The object starts with a value of 0
use OPROG_QUEST_SET 0 4 2 to set quest to 2
use OPROG_OBJECT_QUEST_IF 0 4 = 5 to see if the quest equals 5
This will work for any value ranging from 0 to 15, thus there is
no huge need to know how stuff exactly works, as long as you can
use it.
*** TIPS and OBSERVATIONS
Items with applies to stats over +3 should be very rare on most muds,
and hard to get.
A lot of small items make an area more interesting than a few incredibly
powerful items, for the most part. This is very subjective, however.
Items that are too powerful may be changed by the game administrators,
which usually annoys the administrator more. The better the area, and
the quest you've written, the better the objects.
Remember to put take wear-flags on almost everything. It's easier to
put a take wear-flag on everything, and take off the ones you don't
need (like fountains and such).
don't feel limited to items players consider 'useful', such as weapons
and armor. A giant (untakeable) monolith, and other strange and odd
items can add a lot of atmosphere to an area.
The FLAG_INVENTORY has very special purposes and should not be used
for normal items. An object that is flagged as inventory will follow the
player, even in death.
A mobile that is killed with an object that has an inventory type item will
automatically delete the item. This is useful for creating objects that
the player desires, but cannot get. An object with this flag can be given
to the player by a mobile with mob_progs, or picked up off the ground.
7. The #SHOPS section
The #SHOPS section tells the mud each shop the kind of items it deals
in. It also tells the profit margins, and the hours open. Usually all
the numbers are on one line.
*** Shop Archetype
<Mob vnum> <type1> <type2> <type3> <type4> <type5> <%sell> <%buy> <open> <close>
*** Mob Vnum
This is the mobile that works in the shop.
*** Type
These five values are the ITEM_TYPE numbers that the shop deals in.
The shop will only buy or sell these types of items. Leaving a '0' in
any of the slots will allow the shop to deal in less than five types of
items, but a shop may never deal in more than five.
*** %Sell
This is the percent of the normal value of an object when the shopkeeper
sells it to a player. Usually around 100. This number is limited by
the system and can only be 100 or higher.
*** %Buy
This is the percent of the normal value of an object when the shopkeeper
buys it from a player. Usually around 50. This number is also limited
by the system and can only be 100 or less.
*** Hour Open
This field is a number from 0 to 23 that is the hour that the shop opens.
*** Hour Close
This field is a number from 0 to 23 that is the hour that the shop opens.
*** Note:
Comments may be added after the Hour Closed following a ';'.
The comments can only be as long as the screen length.
*** Note:
Shops on Emud can be browsed through during off hours, but nothing
can be bought there. All shops are considered safe rooms at all
times, even in off hours.
8. The #RESETS section
The #RESETS section tells the mud where everything goes, from the
goblin in the pit to what the knight is wielding and putting the
fountain in the square. This section is simple a list of commands.
The zone commands tell the mud exactly how to reset a zone,
from mobs to objects, to closing doors. Each command is given its own
line, one after the other, until the end of the file. Comments can be
added for clarity's sake example: ; big guy with sword
Areas reset based on the average of all the levels of the mobiles in
the area. Low level areas take about 5 minutes to reset, and high
level areas take about 15 minutes. This number is fixed and continuous
regardless of how many players are in the area.
*** Standard Fields
<if-flag> An if flag tells the mud to look at the previous command.
If the if-flag is 0, the mud will try to execute the command
regardless of the previous command. If the if-flag is any
other than a zero (one is most commonly used), then that
particular command will only execute if the command immediately
preceding it did as well.
This is useful for objects loaded onto mobs; you don't want
to load a shield on a guard that didn't get loaded, for example.
All in all it doesn't matter much.
<max #> This is the maximum number of whatever this is can exist in the
mud. If on a mob command, this will do nothing.
On an object command, this limits how many of this object are
available in the game. For items not limited, it is common to
put a very high number in this slot, 100 should do in most cases.
For something like recall scrolls you can settle for 999
*** List of all Commands
M <if-flag> <mob vnum> <maximum> <room vnum>
G <if-flag> <obj vnum> <maximum>
E <if-flag> <obj vnum> <maximum> <wear location>
O <if-flag> <obj vnum> <maximum> <room vnum>
P <if-flag> <obj vnum> <maximum> <container vnum>
D <if-flag> <room vnum> <exit direction> <door flag>
R <if-flag> <room vnum> <last exit to randomize>
*** M <if-flag> <mob vnum> <maximum> <room vnum>
The M reset loads a mobiles to a certain place in the mud.
*** G <if-flag> <obj vnum> <maximum>
The G reset loads an object and gives it to a mobile loaded in the
reset immediately previous. Note that this is different from
the E reset below, in that the E reset loads an object and makes
the mob equip it. A G reset object stays in the mob's inventory.
To make a unique item the <maximum> should be 1. Generally this means
that the object will not load if any others exist in the game. There
is a basic 20% chance that the object will load anyways when the mobile
resets. A mobile will reset after it is killed on the next area reset.
*** E <if-flag> <obj vnum> <maximum> <wear location>
The E reset loads an object and makes the mob loaded in the reset
immediately previous to this one equip it.
Where equipment position is _one_ of the following:
WEAR_LIGHT 0 WEAR_HANDS 9
WEAR_FINGER_L 1 WEAR_ARMS 10
WEAR_FINGER_R 2 WEAR_SHIELD 11
WEAR_NECK_A 3 WEAR_ABOUT 12
WEAR_NECK_B 4 WEAR_WAIST 13
WEAR_BODY 5 WEAR_WRIST_L 14
WEAR_HEAD 6 WEAR_WRIST_R 15
WEAR_LEGS 7 WEAR_WIELD 16
WEAR_FEET 8 WEAR_HOLD 17
*** O <if-flag> <obj vnum> <maximum> <room vnum>
The O reset loads an object into a room. This is mostly used for
unowned or immovable objects.
To make a unique item the <maximum> should be 1. Generally this means
that the object will not load if any others exist in the game. There
is a basic 20% chance that the object will load anyways when the area
resets.
*** P <if-flag> <obj vnum> <maximum> <container vnum>
The P reset loads an object, and places it into another object
(container-type) that was previously loaded.
*** D <if-flag> <room vnum> <exit direction> <door flag>
The D reset can open, close, or close and lock a door every repop,
Where door flag is _one_ of the following:
DOOR_OPEN 0
DOOR_CLOSED 1
DOOR_CLOSED_LOCKED 2
Where exit direction is one of the following:
DIR_NORTH 0 DIR_WEST 3
DIR_EAST 1 DIR_UP 4
DIR_SOUTH 2 DIR_DOWN 5
*** R <if-flag> <room vnum> <last exit to randomize>
The R reset randomizes the specified exits in a room.
Where <last exit to randomize> is the number equivalent of the first
exit in the room to not randomize. For example:
R 0 6495 3
would randomize the north(0), east(1), and south(2) doors of the room with
the vnum 6495. Swapping only those three exits.
*** TIPS and OBSERVATIONS
Remember, a functioning door is a door from both sides, and needs to
be closed from both sides. Thus, 2 door resets for each door.
The P reset gets confused if you try to load multiple objects
into multiple containers IF the containers are all the same
object.
The solution is to copy the container over into the #OBJECTS section
with a different vnum however many different containers you need.
9. Putting it all together.
This section is simply composed of building tips for novice
builders. This is very subjective, and based on the experiences of
the builders at the Curious Area Workshop. Not all these techniques
may be of use to your average builder.
Absolutely, positively use the AREACHECK utility.
The areacheck utility comes with the utilites section of
documents that goes along with this document. The
areacheck will normally allow the area to start right up
unless you have doors specified wrong, or have problems
with obj_progs or mob_progs. Areacheck does a VERY good
job of checking syntax, such as numbers that are off or
spacing that is wrong. It also checks the syntax or
spelling of all the text versions of flags.
Learn to build without an area editor first.
Its a lot easier to troubleshoot when you understand what
exactly goes on with all those numbers in those files...
This is very important because most area editors are designed
for Merc or Diku areas. They are actually fine for making
a framework for the area, but realize that MANY differences
crop up in creating Emud areas. And the creator must then
use a text editor to finish out the area. Also the editors
tend to make little errors, crashing the area editor and
leaving one without advanced knowledge helpless.
Do it on paper first. Do it big.
Having a map to work from helps a LOT when doing exits, and
provides a visual impetus to getting all those tedious bits done.
Do the #ROOMS section first.
The #ROOMS section almost always takes the longest. Once past that
long fight, the #MOBILES and the rest will come easier.
Save Mobile programs and Object programs till the very end.
It is simpler to create obj_progs and mob_progs when all the
mobiles and objects are in place, and the rooms are finished.
BE aware that you might end up redoing alot of rooms, mobiles
and objects because you want certain things in your quest which
you make up while working on it. Therefor it is suggested to
think very well about the quest you want to make. Write it down
in steps. Then build your area such way that you can implement
all the mobile and object programs without having to make heavy
changes.
Your #RESETS file will always be wrong on the first try.
-Get used to it.
Your mobile and object programs will suck and work badly on the
first try.
-Keep working on them till they work as you desire.
For random mob distribution, use this method:
(this was contributed by Locke of CthulhuMUD)
Make a room, with exits to all the places that you would like mobs
to come out of, in all 6 directions. Load all mobs to be randomly
distributed in this room, and they'll choose and walk out themselves!
(if they're not sentinel).
For a big area, several of these 'mob chutes' can be connected
for a bubble-sort effect.
An area will take twice as long as you think it will to build.
a certain boredom sets in sometimes. just set it aside for
awhile if this happens; its better to build when you want to
then turn out something uninspired. If you plan on using
obj_progs or mob_progs then the area will take four times
as long as you expect. If you plan on using quest bits, then
count of it taking much longer than you expect, with several
errors.
Mobile and object programs are a MUST however, once you learn
how to use them properly you'll be able to create an area
unparalised by areas without progs.
Be fair with the items:
Good items should be hard to get. Lousy items should require
much less effort. Give the ordinary stuff to the mobs to wear,
and reserve the good stuff as a reward for the cool quest you'll
hopefully write.
Always remember that items and objects can easily get out of
scale, and all areas can and probably will be modified by the
implementors of a Emud system. This is to be expected, so
don't get too put out.
Contributions to this section are welcome, and will be added with
proper credits.
10. Credits
Special Thanks to Tarkin of NaVieMUD and MJPrime of AlbertMUD for
invaluble help in writing this Handbook.
Extra Special Thanks to all the Players of NaVie (128.213.5.14 4001),
for all the help during the Buggies & Bounties competitions.
Builder_5
11/11/93
ftp.cs.odu.edu \pub\caw
Modifications for MrMud v1.2 written on (incredibly) 11/11/94
David Bills (Chaos on Mortal Realms - hydrogen.ee.utulsa.edu 4321)
Doug Michael (Order on Mortal Realms - hydrogen.ee.utulsa.edu 4321)
Modifications for Emud v2.2 written on 12/12/01
Scandum (Demise on Storms of Time - minas-2.demon.nl 4321)
===============================================================================
FILE: "mob_prog.txt"
=== MOBprograms
MOBprograms are a way to make your mobiles more interesting. This
basic version has enough to get things going, and should be quite
readable and understandable and more to the point, extendable. The
remainder of this document describes MOBprograms and gives a couple
trivial examples.
Table of Contents:
The Basic Idea
MOBprogram Syntax
Associating MOBprograms With A Mobile
Trigger Types
Variables
Control Flow Syntax
Operators
If_Checks In Control Flow
MOBcommands Of Interest
Regarding CPU Slowdown
Miscellaneous Information
Credits
-------------------------------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 Mob Prog-
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.
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.
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. And not to be demeaning toward implementors, area creators who
never wrote a c program have constructed mobile programs being far more
complex and entertaining than 99% of the spec_procs.
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.
------------------------------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.
">" {trigger_type} " " {argument_list} "~" NL
{program_command_1} NL
{program_command_2} NL
{program_command_3} NL
. . .
{program_command_N} NL
"~" NL
=== Explainations
A TRIGGER_TYPE is one of the available triggers.
A PROGRAM_COMMAND can be any legal mud command, or a control flow command.
The ARGUMENT_LIST depends upon the trigger, but it is always parsed into
the system as a character string.
This is an example of ONE MOBProgram block for a mob.
--------------------Associating MOBprograms With A Mobile----------------------
There is only one way for the mud to associate the program with the
mobile. The result is a link list of mob_programs which are
attached to the mobile_prototype. This is done at boot time, and so only
one copy is kept, regardless of how many instances of the mobile are
running about.
In the #MOBILES 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 blocks
(using the syntax above) followed by a line starting with one '|' (pipe).
Example provided: holygrove.are
-----------------------------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:
*** act_prog [p] <ARGUMENT>
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. If the first word is the character 'k' by itself then the
prog checks to see that all of the words in the word list are present in
the checked text. The trigger is activated whenver a keyword (or the
phrase) is contained in the act() message. Both the phrase and keywords are
case insensitive.
This is the most general trigger. It 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). Do aknowledge only players can trigger an
act_prog, mobs will be ignored.
Example
>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.
*** buy_prog <ARGUMENT>
The argument is an object number, like a give_prog, use the 'I' format
for the object number. This only works on a shopkeeper and is triggered
when an object of this obj number is purchased by a player.
Example
>buy_prog i432~
This trigger will only be activated you purchase item i432 from the mobile
with the prog. This is handy for having the mobile explain the item, or
modify the item based upon the purchaser. This prog does not interrupt the
actual transaction, though it may eventually be modified to do so, to allow
a purchase to pass through if checks.
*** cast_prog <ARGUMENT>
The argument is the name of a spell. The prog does a skill_lookup on the
entered phrase to see if the spell being cast by a player matches. The
prog triggers if so.
Example
>cast_prog detect magic~
This trigger will be activated if the player casts detect magic in the same
room as the mobile, obj, or room with the prog. The potential for this
trigger is myriad, allowing a mobile to react to the caster with speech,
counter spells of its own, hostile reactions, etc. This prog does not
actually interrupt the spell, only triggers in reaction to it.
*** damage_prog <NUMBER>
The argument is a percentage chance. This prog is only set upon an object,
and only an object equipped by a player. It can trigger when the player
wearing or holding the object damages another player.
Example
>damage_prog 20~
This trigger will be activated if the player injures another player, if the
percent check is 20 or lower. This program can do things like applying
additional affects to the player or his victim, or other effects, like an
evil sword that makes eerie sounds when it harms a victim.
*** hit_prog <NUMBER>
The argument is a percentage chance. When set upon an object, it triggers
when the object wearer is damaged by a physical attack. When set upon a
mobile, the program triggers whenever the mobile is damaged.
*** intercept_prog <ARGUMENT>
The argument is a command word or words. This powerful trigger allows
almost any word to become a command. It can also do as its name implies,
and intercept any actual command and replace the command's actions with
the mobile or object's own.
Example
>intercept_prog north~
This would intercept the command 'north', even if only the letter 'n' is
issued. This could allow a mobile to check conditions before allowing a
player to actually go north.
Note that this trigger does actually interrupt the actions of an existing
command, and in order to allow the command to pass as typed at some point
during the program, there must be an 'mpunintercept' command. For example,
after checking conditions for northward travel, as above, mpunintercept
at the end of the program would allow those meeting the conditions to do so.
*** speech_prog <ARGUMENT>
The argument is the same as for an act_prog. A word or phrase (when the
character 'p' by itself is the first word in the word list) triggers the
event.
Example
>speech_prog dog~
This is only triggered when the keyword is contained in a message which
has been said by a PC in the same room as the mob.
>speech_prog p brown dog~
This prog is only triggered when the words 'brown dog' are used together
in the statement.
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.
*** sayto_prog <ARGUMENT>
This works like a speech_prog, except that it only triggers if the saying
is targeted to the mobile using sayto. If the first word is the character
'p' by itself then the rest of the word list is considered to be a phrase.
If the first word is the character 'k' by itself then the prog checks to
see that all of the words in the word list are present in the checked text.
This is a vast improvement on the old speech_prog, which will trigger on
the correct word or phrase, regardless of who it's said to, or in what
context. With this prog, there's the intent to speak to the mobile that is
required.
*** trigger_prog <ARGUMENT>
This works like a speech_prog, except that it only triggers from a mobile
using the MPTRIGGER command. If the words in the mptrigger argument match
the word or phrase in the trigger, then the program activates.
This is the way that mobiles can communicate and conspire together. You
can use mptrigger to summon reinforcements, to order another mobile to
follow a mobile's orders, or even to just make two mobiles talk to each
other in flavor dialog.
*** social_prog <ARGUMENT>
The argument is an existing social. The prog triggers if the player targets
the mobile with that social. This can give the mobile a little life by
setting up reactions to players' behavior.
*** rand_prog <NUMBER>
The argument is a percentage chance.
This trigger is checked at each PULSE_MOBILE. It will only trigger if
there are players in the same area as the mob, to cut down on lag.
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.
If the $r Variable is used in the body of the trigger the trigger will only
execute if there is a player in the room. To allow a mobile to work with
both $r and without players in the room use 1 rand_prog having the $r part,
and one rand_prog or a time_prog taking care of other stuff. Only 1
rand_prog can trigger at each time.
*** repop_prog <NUMBER>
The argument is a percentage chance. This trigger is checked any time a
mobile resets.
One possible use is to give mobiles an echo using a repop prog, to give a
more rational reason for its reappearance than simply reappearing where
the original mob was killed upon repop. It could also be used to give a
nasty surprize to a player who was hanging around waiting for another go
at a mobile by making the mobile do something unexpected.
*** time_prog <NUMBER>
day_prog <NUMBER>
month_prog <NUMBER>
The argument is a number betweeen 0 and 24 for time_prog, between 0 and 30
for day_prog, and between 0 and 12 for month_prog.
This trigger is checked at the turn of each hour, day, and month,
respectively and if the argument equals the turn, the program activates.
It is useful for events that happen on a regular interval, such as seasons
changing, or the changing of the guard at a certain time every day. Using
the highest number of the range, 24 for time, 30 for day, or 24 for month,
will activate the program on every hour, day, or month.
Time progs trigger whether or not any players are in the room or area with
the mobile, so it is handy for using mobiles to control the environment.
*** fight_prog <NUMBER>
The argument is a percentage.
Useful for giving mobiles combat attitude. It is checked at the beginning
of every mobile's turn. 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
turn. Mobiles with a fight prog do NOT act according to their coded AI on
any turn that a fight_prog is triggered either, to again avoid stacking
attacks.
*** hitprcnt_prog <NUMBER>
The argument is a percentage.
Is activated at the beginning of the mobile's turn only 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.
*** desc_prog <NUMBER>
The argument is a percentage.
Whenever someone looks at the mobile or object with the prog, it triggers.
This can be used to give a random desc to something or someone, or to
trigger a reaction, or other possibilities.
Note that a desc prog, when triggered, interrupts the normal desc for the
target being looked at. So plan accordingly with echoes and what have you
to mimic a worded description.
*** get_prog <NUMBER>
drop_prog <NUMBER>
Again a percentage argument.
Only settable on objects, these progs trigger when an object is either
picked up, or dropped.
*** wear_prog <NUMBER>
Again a percentage argument.
Triggers when the object with the prog is worn, held or wielded.
*** use_prog <NUMBER>
Again a percentage argument.
Triggers on an object when activated with the USE command. This basically
allows you to create a plethora of trigger-use items beyond the typical
wand, staff or whatever. Note a use_prog overrides any other result of the
USE command, so it's best to use it on objects that don't already have a
function triggered by the command.
*** trap_prog <NUMBER>
Again a percentage argument.
This can be set upon a mobile or object that's summoned by a trap using
the TRAP_TYPE_MLOAD or TRAP_TYPE_OLOAD flags. The combination of this flag
and the mob prog trigger can make for very elaborate and complex traps and
trap effects.
*** greet_prog <NUMBER>
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.
*** do_greet_prog <NUMBER>
Again a percentage argument.
Like greet_prog, but it triggers when the player uses the GREET command
upon a mobile. This effectively restricts the trigger to someone actively
trying to interact with the mobile. This is quite shamelessly borrowed
from the cues of online games with NPCs that trigger when interacted with.
Good for shop merchants, quest givers and the like.
*** group_greet_prog <NUMBER>
Again a percentage argument.
Like greet_prog, but it only triggers once for an entire group when they
enter the room at the same time. Much better for quest mobiles during
group adventures, as the mobile doesn't spam the same statement to every
player in the group.
*** entry_prog <NUMBER>
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.
*** exit_prog [dir]
Argument is an optional direction.
The reverse of greet_prog. Triggers when a player leaves the mobile or
room with the prog. Adding an optional direction will trigger the prog
only when the player leaves by that direction.
*** arrival_prog <NUMBER>
Argument is a room vnum.
Triggered when a mobile enters the final room after doing MPWALKTO, and
also when arriving back at it's reset room. If the check matches the vnum
of the room presently in, the program activates.
*** give_prog <ARGUMENT>
On a mobile, the argument is the number of an object in 'I' format.
Example:
>give_prog I9720~
This is triggered whenever something is given to the mobile. Note the code
as of Mud20 has been revised so that any mobile that doesn't trigger with
a give prog gives any item back to the giver. This avoids accidental loss
of items from giving the wrong item to a mobile.
On an object, the argument is a percentage.
This is triggered whenever the object with the prog is given to someone
else.
*** sac_prog <NUMBER>
Argument is a percentage.
Triggered when the object with the prog is sacrificed.
*** bribe_prog <NUMBER>
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. Values are in
copper, so don't forget to multiply higher coin amounts.
You can run multiple bribe progs on a single mobile, but only the first
successful prog runs when triggered. Because of this, you should list your
bribe progs from largest amount to smallest, so that it keeps passing the
amount down the line until it triggers a prog.
*** death_prog <NUMBER>
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 load a fresh version of itself, give all items to the new mob and force
it to wear them, then have the new mob attack and mppurge self to disappear
without leaving a corpse. (Note that a kitten could turn into a dragon
this way too).
*** range_prog <number>
The argument is a number between 1 and 100, but does nothing atm, might be
a percentage in the future.
The range_prog is triggered if the mobile is shot by a range weapon. The
program can then check the shotfrom ($i) ifcheck to see which direction the
shot came from.
Note that the first successful bribe_prog, give_prog, hitprcnt_prog,
death_prog, fight_prog, rand_prog and entry_prog is the only one which
is executed. All the successful greet_progs, speech_progs, and act_progs
will be done. This is the best arrangement we found for handling
situations where you imported several MOBprogram files for a mobile.
If you are going to write lots of little files and piece them together
to create the effect you want, it is advisible to not mix things together
all that much, otherwise you have to pay close attention to the order in
which the programs are added to the link list.
You should avoid using triggers of the same type at all times, except
for the $r situation, and hitprcnt_prog. When using hitprcnt_prog do
not use a fight_prog unless you want both the fight and hitprcnt_prog
to trigger in the same combat round.
Also, no MOBprograms will be successful when the mobile is charmed or
possessed to protect mobiles which are given special powers from being
pimped by players.
----------------------------------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 word of the name of the mobile
$I the short description of $i
$n the name of the one who caused the trigger to happen
$N the short description of $n
$t the name of a secondary player target (example: $n smiles at $t)
$T the short description of $t
$r the name of a random player in the room
$R the short description of $r
$e he,she,it based on sex of $n
$m him,her,it based on sex of $n
$s his,hers,its based on sex of $n
$j he,she,it based on sex of $i
$k him,her,it based on sex of $i
$l his,hers,its based on sex of $i
$E he,she,it based on sex of $t
$M him,her,it based on sex of $t
$S his,hers,its based on sex of $t
$J he,she,it based on sex of $r
$K him,her,it based on sex of $r
$L his,hers,its based on sex of $r
$o the name of the primary object (selected in give_progs)
$O the short description of $o
$p the name of the secondary object (example $n puts $o in $p)
$P the short description of $p
$c the name of a carried object (select with hasobjnum check)
$C the short description of $c
$a a,an based on name of $o
$A a,an based on name of $p
$1..$9 Corresponding word in the trigger phrase
Also, in if_checks, the accepted variables are the basic ones
(i,n,t,r). If a variable is referenced that doesnt exist, then the value
is simply left blank. (i.e referring to $o when the trigger is: A kisses B)
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 wierd log file spam, espescially if $t is
used in an if_check (if isnpc ($t) or something)
The basic fix is to write the act_program such way that it can hardly
go wrong for a very specific situation.
Example: >act_prog p gives a stone of power to~
$n is the one giving the stone.
$t is the one receiving the stone.
$O is the short description of the stone.
You'll hardly need $o and $p though.
$c and $C are very useful to store the name of a player so the mobile
can refer to it later on.
------------------------------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:
--- Explainations
An IF_CHECK is a string which describes how to compare things.
The ARGUMENT is the target of the check.
The OPERATOR indicates how the target and value are going to be compared.
The VALUE is compared depending on the given operator.
The BREAK command bails out of the entire MOBprogram regardless of the
level if nesting.
If that looks confusing, skip to the end of the document and review the
Example. Hopefully that should clear things, otherwise you'll probably
have to give us a mail since examples are the best way we know to
explain syntax.
--------------------------------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.
------------------------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 or $r)
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. name($n)== orc large brown)
if actorhasobjnum (vNum) sets $c and $C variable
if actorwearsobjnum (vNum) sets $c and $C variable
if age ($*) == integer checks the age of the char
if areaquest (B,N,$*) == integer B = Offset, N = Numbits for area quest bits
if cansee ($*) can the mobile see $* (object or character)
if cancarry ($*) can $* carry more items
if cha_check ($*) == integer/$* cha check against a DC, or cha roll of $*
if class ($*) == bitvector checks active class of $*
if con_check ($*) == integer/$* cha check against a DC, or con roll of $*
if curr_str ($*) == integer the current STR of the charater
if curr_dex ($*) == integer the current DEX of the charater
if curr_con ($*) == integer the current CON of the charater
if curr_int ($*) == integer the current INT of the charater
if curr_wis ($*) == integer the current WIS of the charater
if curr_cha ($*) == integer the current CHA of the charater
if existsarea (name)
if existsroom (name) searches for matching object or mob
if existsworld (name)
if goldamt ($*) == integer
if hasobj (name) sets $c and $C variable
if hasobjnum (vNum) sets $c and $C variable
if hitprcnt ($*) == percent Checks percentage of hitpoints left
if inroom ($*) == vnum
if isaffected ($*) == bitvector
if isevil ($*)
if isfight ($*) Is $* fighting
if isfollow ($*) Is $* a follower with master in same room
if isgood ($*)
if iskiller ($*)
if isneutral ($*)
if isnpc ($*) Hardly used since most triggers only work on players
if ispc ($*)
if isthief ($*)
if level ($*) == integer
if name ($*) == string
if number ($*) == integer Is the vnum of $* equal to integer
if number ($*) == integer Is the vnum of $* equal to integer
if objquest (B,N,$*) == integer
if objtype ($*) == bitvector
if objtype ($*) == bitvector
if objval0 ($*) == integer
if objval0 ($*) == integer
if objval1 ($*) == integer
if objval1 ($*) == integer
if objval2 ($*) == integer
if objval2 ($*) == integer
if objval3 ($*) == integer
if objval3 ($*) == integer
if pcsinarea ([vnum]) == integer
if pcsinroom () == integer
if position ($*) == bitvector
if quest (B,N,$*) == integer B = Offset, N = Numbits, R = Room vnum
if questr (R,B,N,$*) == integer
if race ($*) == bitvector
if rand (number) Is rand percentage less or equal to number
if sex ($*) == bitvector
if shotfrom ($i) == string Used for range_prog
if skilllevel ('skill name',$*) == integer checks the ranks in the given skill
if time () == integer
if whichgod ($*) == bitvector
Skill if checks
These are worthy enough to have a basic explanation of their own. These
if checks use the OGS d20 mechanic to make skill checks for each of the
applicable skills. In some cases, this check MUST me done against a
DC, and this is specified by <integer> after the operator. Some checks
will allow an opposing character, indicated by <integer/$*>. When this
is the case, you may use a target argument instead, and the skill check
will use the opposing roll of the opponent character. In rare instances,
a certain skill check may require ONLY an opponent, thus indicated by
<$*> alone.
Note these checks only work with the operators == or >= (meaning the
check succeeded) or < or != (meaning the check failed)
if balance_check ($*) == integer
if bluff_check ($*) == integer/$* vs. sense motive of $*
if climb_check ($*) == integer
if concentration_check ($*) == integer
------------------------MOBCommands Of Interest-----------------------------
These are fairly basic things, most of them are wiz commands which have
been changed to allow for mobiles to perform the commands. If you have
the problem of immortals abusing these powers on your mud either ditch
the immortals, or add a check in all of them to only let NPC's with null
descriptors do the commands. (However, you lose a little debugging help
that way). Emud has provided a little security feature against this but
it is by no means comprehensive. Please check yourself if you are
concerned.
*** Important:
Since many items have the same name for keywords, it is required
for area creators to use the I#### system for such things as give_prog.
This uses the object number with an 'I'.
This method allows exact procedures of handling objects in mob_progs.
This system is added to all item keywords, so it is not necessary to
add them to each item keyword list.
Here are the basic MOBcommands that we found to be enticing:
*** PEACE
This command comes in handy to stop a fight. It also clears the
hunting, hating, and fearing flags that might be upon a mobile.
*** SLAY <victim>
This command simply kills the victim, this cannot be 'self'. When
a player is slayed they will not lose exp or have a death added.
*** QUIT
When this command is executed by a mobile it will instantly die,
leaving a corpse.
*** RESETAREA
resetarea will result in an instant repop of the area the mobile is in.
*** MPROG <mobile>
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.
*** MPECHO <text_string>
MPECHOAT <victim> <text_string>
MPECHOAROUND <victim> <text_string>
MPAREAECHO <text_string>
Prints the text message to the room of the mobile. Colors can be used.
When executed by a player:
$n will print the name of the executer. $e $s $m will show sex related
stuff of the executer.
When executed by a mobile program:
See list with variables, they will work as described.
*** MPJUNK <object>
Destroys the object refered to in the mobiles inven. It prints no
message to the world and you can do mpjunk all to junk every item
carried AND worn by the mobile in one time.
*** MPJUNKPERSON <victim> <object>
Works like MPJUNK, but is targeted to another mobile or player. Can be a
very nasty thing to do.
*** MPMLOAD <mobile vnum>
MPOLOAD <object vnum>
Loads the obj/mobile into the inven/room of the mobile. If the item is
non-takable it will drop to the ground unseen.
This lets a mobile distribute a quest item or load a key or something.
Being an area quest orientated mud we don't make a problem out of
loading, where other muds might.
*** MPKILL <victim>
Lets a mobile kill a player. Lots of MOBprograms end up with mpkill $n
commands floating around. It works on both mobiles and players.
*** MPDO <argument>
Allows a mobile to do the specified command, regardless of trust or level.
Note this is a very powerful command, and it only work for a mobile, not
even an immortal can use it.
*** MPUNINTERCEPT
Use this command within an intercept prog to pass the player's command
after processing the trigger. Without this command, the player's command
will not happen.
*** MPPURGE <all|area|argument>
Destroys the argument from the room of the mobile. With the 'all' argument
the result is the cleansing of all NPC's and items from the room with
the exception of the mobile itself. However, mppurge self 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 crash will happen. There are situations where this comes
unwanted. Simply add a 'break' after the mppurge self , it will stop
the program and the break itself won't cause any errors.
mppurge area, will purges everything in the area, except the mob purging
it.
*** MPQUIET < 'ON', 'OFF'>
This command stops ALL forms of out output data from reaching anyone.
This command can be only used inside of mob_progs, and should not be
used in obj_progs at any time (it will not work regardless).
Simply issue 'mpquiet on' to make all commands quiet. The mob_prog
will always reset it to 'off' regardless is the programmer calls the
'off'. This command could be used to simulate a snake biting, when
it is actually casting 'poison'. Simply mpecho the bite, then turn
MPQUIET ON and do the casting.
*** MPGOTO <dest>
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 <dest> <command>
Perfoms the command at the designated location. The destination can
be an object, room or player/mob. It mainly saves some coding work
since you won't need the mob to mpgoto <destination> + command +
mpgoto <where mob came from> to get stuff done.
*** MPPRACTICE <victim> <skill> <max>
This trains the victim up 1 point in the given skill. MAX is the maximum
rank the command will train up to. As coded, this command only works for
knowledge and trade skills, and the player is still subject to his max
ranks for the given skill. This does not cost the player a skill point.
Only a mobile can issue this command.
*** MPSETFEAT <victim> <feat> [ignore]
MPCLEARFEAT <victim> <feat>
MPSETFEAT sets a victim to have the named feat. MPCLEARFEAT removes it.
The target must still spend a feat point to have a feat set, and must
have the prerequisites for the feat unless the IGNORE argument is added.
MPCLEARFEAT will reimburse the feat points for the feat reset.
*** MPFOLLOW <victim>
Makes the mobile both follow the victim, and join his group.
*** MPTRANSFER [<victim>, 'all', 'pcs'] [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. The mobile MUST be in the
same room as the character being transfered before the transfer will
take place.
Please note that the use of "all" includes mobiles except one issuing
the command. Use "pcs" to transfer all players and pets. Try to use
"pcs" as much as possible, unless you want to transfer mobs.
*** MPFORCE <victim, all> <command>
Forces the victim to do the designated command. The victim is not told
that they are forced, they just do the command, mpquiet is oftenly used
here so the player isn't aware when you force them to remove all there
gear and sac it in a very naughty program. Again, if the victim is "all"
then everyone in the mobiles room does the command.
*** MPWALKTO <room vnum>
Sets the mobile walking to the point specified. Note that if it is a mobile
flagged ACT_SENTINEL and is loaded in a reset, it will end up walking back
to its reset location, so long as it is awake and standing. So make sure
the program does whatever else is needed to WAKE it or make it STAND. The
mobile will take the most direct route, not opening doors or other
obstacles. So if it cannot actually arrive at the location, it will
ultimately time out.
*** MPLOG <text_string>
Works like MPECHO, but prints the string to the log file, and echoes it
on the log channel. Handy for events you want logged, like a certain mobile
getting attacked, or a player completing a certain quest, etc.
*** MPDELAY <$target|self> <time> [$actor]
Sets a delay on the mobile for triggering a delay_prog. This can be used
to simulate a lag in an action. The first program sets the delay using
mpdelay, and then a delay_prog continues the action once the delay time
expires. If the mobile sets qbits upon itself, it can even make longer
multiple paused actions, simply mpdelaying itself at the end of each
stage, and the delay_prog processing the qbit as conditions to know what
to do next.
*** MPTRIGGER <$target> <word list>
This command allows one mobile to communicate with another, and trigger
the second mobiles actions if it has a trigger_prog set on it. Use it to
command other mobiles, set up a conversation between two mobiles, or other
possibiliies.
*** MPMSET <victim> <field> <value>
*** MPMSET <victim> <string> <argument>
Allows the mobile to set any field of a player or mobile, just like an
immortal can do using MSET.
quest, questr, randquest, randquestr have additional parameters:
mpmset <victim> quest <firstBit> <numBits> <newValue>
mpmset <victim> questr <areaVnum> <firstBit> <numBits> <newValue>
mpmset <victim> randquest <firstBit> <numBits>
mpmset <victim> randquestr <areaVnum> <firstBit> <numBits>
To reset a mobile's desc string to the original, simply use null as the
argument.
Example:
mpmset $n long There is a small boy here.
(disguise the mobile as a small boy)
mpmset $n long null
(returns the mobile to normal)
*** MPMADD <victim> <field> <value>
Allows the mobile to set any field of a player or mobile, just like an
immortal can do using MADD. The main difference between MPMSET and MPMADD
is that MPMADD adds the value to the current one, rather than overwriting
it for a new value.
quest and questr have additional parameters:
mpmadd <victim> quest <firstBit> <numBits> <value>
mpmadd <victim> questr <areaVnum> <firstBit> <numBits> <value>
*** MPOSET <object> <field> <argument>
*** MPOSET <object> <string> <argument>
Allows the mobile to set any field of an object, just like an immortal can
do using OSET.
quest and randquest have additional parameters:
mposet <object> quest <firstBit> <numBits> <newValue>
mposet <object> randquest <firstBit> <numBits>
*** MPOADD <object> <field> <argument>
Allows the mobile to set any field of an object, just like an immortal can
do using OADD. The main difference between MPOSET and MPOADD is that MPMODD
adds the value to the current one, rather than overwriting it for a new
value.
quest has additional parameters:
mpoadd <object> quest <firstBit> <numBits> <value>
*** MPASET <object> <location> <value>
Location can be any of the multitude of effect apply locations.
This command allows you to permanently add affects to objects.
*** MPZSET <field> <argument>
Field being one of:
resetmsg, quest
quest has additional parameters:
mpzset quest <firstBit> <numBits> <newValue>
This allows you to make semi-persistent changes in an area. You can change
the reset message for the area, and you can also set quest bits on the area.
Programs in the area's objects, mobiles, etc, can then read the area quest
bits to alter their behavior. Changes made of course, only persist until
the next reboot, unless you save the area first. MPSAVEAREA may be an
upcoming command to make such changes permanent.
*** MPDAMAGE <$target|all|pcs|foe> <numdice> <sizedice> <damtype> <argument>
Damtype being one of the following:
pierce slash bash acid cold electric fire sonic divine force
Damages the specified target(s) with the specified damage type. Victims
get no save, no defense, though resistances to damage types do apply.
Targeting ALL affects both mobiles and players. PCs affects only players.
FOE targets someone the mobile is fighting.
*** MPGORAND <firstroom> <lastroom> <offset> <skipsize>
say, you have a 4x4 area from room #6400 to #6415 arranged like:
6400 6401 6402 6403
6404 6405 6406 6407
6408 6409 6410 6411
6412 6413 6414 6415
mpgorand 6400 6415 0 4
would put the mobile in 1 of the the following rooms: 6400 6404 6408 6412
mpgorand 6400 6415 3 4
would put the mobile in 1 of the the following rooms: 6403 6407 6411 6415
*** MAZE <X size> <Y size> <Z size> <Character Name>
This command takes an area that already exists, and redefines the exits
into a random pattern. This can be used to create mazes that change
during game play. This command is very slow, so use with caution.
The maze that is created has absolutely no connections to the rest of the
world, so the use of "connect", "doorset" and "key" may be required to
link the area to the rest of the game.
<? size> defines the dimensions of the maze.
<Character Name> defines what the seed number will be.
Seed number is a value that determines how the maze will be generated.
The use of the same seed on a maze with the same dimensions will always
generate the same maze. Therefore individuals will always see the same
maze, but it will be different between individuals.
Example:
maze 3 2 4 $n
Creates a maze that has 24 rooms, with a seed based on $n's vnum.
NOTE: The name is a good place for '$n' of the mob_progs.
*** CONNECT <direction> <roomVnum> [both]
This command creates a hallway in one direction from the current room
to the room described in the destination.
<direction> defines which door the exit is generated at.
Use: north, east, south, west, up, down
<roomVnum> defines the number of the room connecting to.
Use a destination number of "-1" to create a wall, and disconnect a room.
[both] is an optional parameter that creates a bi-directional hallway.
Without this option, the hallway created it totaly one-way.
Example:
connect north 9755 up
Creates a connection between the current room and roterodamum square.
Usage:
An interesting use for this command is to temporarily create a door that
did not previously exist, and force a party through it, then use the
connect command again to remove the newly created eixt.
*** DOORSET <direction> <doorflag> <doorname>
The doorflag must have a value between 0 and 47 (needs an update we know)
The doorname will automatically become the exit description
Every key with value0 being 0 will unlock the created door
Current plans will result in the following change in the future:
doorset <direction> <field> <argument>
Field being one of:
name desc flag key
This command places a door between two connected rooms. These rooms need
not be connected through the "connect" command. If you are using the
"connect" command, be sure to connect both sides, since the "connect"
command only works in one direction. The door command only works if both
exits on the two rooms are going in opposite directions, to the other room,
which is a standard hallway.
<direction> defines which door the exit is generated at.
Use: north, east, south, west, up, down
<flag> is the door flag:
0 - no door
1 - door
2 - closed
4 - locked
8 - hidden
32 - pickproof
64 - bashproof
128 - magicproof
Example: These are for the future version of doorset:
doorset north name gate
(sets the keyword of the door to: gate)
doorset north desc You see heavy iron gates blocking your path.
(sets the exit description)
doorset north flag 167
(sets exit flags to: magicproof, pickproof, locked, closed, door)
doorset north key 3714
(the door can be unlocked by the item with vnum 3714, the key from
the tower of training in this case)
*** RESCALE <mobVnum> <target> <percentage>
The level, damage, and hitpoints of the mobile will be rescaled
Formula: newLevel = mobLevel * targetLevel/100 * percentage/100
*** PURGE AREA
This command is a modified form of MPPURGE, called by "purge area".
When used it scans every room in an entire area, and purges it of items
and mobiles.
*** MPSWAP <direction1> <direction2>
This command will swap the given directions. It works easier than
disconnecting and reconnecting exits, and should be useful if you
want to create your own mazes.
--------------------------Regarding CPU Slowdown-------------------------------
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 rand_progs shouldn't be used when a time_prog will
do just as well. (A time prog is checked once a mud day, which is about
once every 1 minuts, instead of every second)
Include proper if checks to avoid too much code needing execution.
Include a $r if the program only needs execution with a player being in
the same room.
Try to keep the percentage low when the rand prog is just for fun and
isn't required for good functioning of the quest.
Emud systems can track the average speed for various functions. Mobile
programs rank as one of the top 3 functions, and eat up about 25% of the
total cpu usage for the entire game. Although this is a general game-wide
value, it gives an idea of the complexity of the mob_prog system. Even
though computer hardware gets better and better it's still a good habbit
to make your programs as cpu friendly as possible.
-------------------------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 22k, so that is
probably about 500 lines. The indentation spaces shown in the example
make it easier to read (and debug), and since your programs will be
checked by an admin it would be wise to use them.
The MOBprogram stuff runs totally without anything in the mob_commands.c
file, but letting mobiles be a bit more godlike has allowed us to do what
we consider to be wonderful things. The replicant and polymorphing mobiles
described above as well as some nifty mob helping mob interactions are an
example.
It IS possible to accidentally make mobiles which can trigger in
loops. As mentioned in the example at the end of this document, the
result is usually a mud crash or major CPU dent. We dont know any way
to prevent this from happening, other than careful coding and a
restriction of mobile travel from zones of one creator to another
(another good reason to not have charmed mobiles do anything).
Tracking down the culprit mobile is not always easy. The only thing we
have found which always works, is to add a log statement into the
MOBprogram driver and fill some disk space until it becomes apparent
what commands are repetitively issued. Also, most infinite loops are
flukes where the situation just happens to be right and usually it never
happens again.
Another common problem is mobiles that load other mobiles for various
reasons. This may seem innoculous, until the loaded mobile decides to
load another mobile. It has been seen that some areas, over the course
of time can develope thousands of mobiles, which slow down the cpu
drastically, not to mention the drain on system resources, such as RAM.
Be very careful that you know the exact situation before mpmloading
another mobile.
The list of variables and triggers and if_checks will grow continuously
as our creators demand the ability to do certain things. If you have a
request or if you have a new one, we don't mind hearing about them,
and if you find bugs, we 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.
*** Note about testing:
All area creators are required to test their area thoroughly before
it is included in the working game. This is usually done on a test game,
where the implementors of the working game run the test game on a
part-time basis.
Special note should be taken on all mob_progs, and obj_progs. It is
absolutely required that all cases of a program must be tested, even if
it is a simple failure to break. It is much better to find program bugs
in the test game then in the working game.
----------------------------------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
murph@ri.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 Marble Mud 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
{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}+{+}
Just a tasteless gloating statement by Chaos:
A major advancement to the operation of mob_progs was introduced October
of 1995. This major advancement is the tokenizing of mob_progs. The
original code was a simple system that parsed the code for the $n stuff
and shoved the result into the interp routine. This is the same interp
routine that players use to decipher commands. The interp routine is
relatively slow, and the mob_prog parser is quite slow itself. The basis
of the tokenizer is that a mob_prog will not change, once the mud itself
has started up, so why parse and interperet it with every execution of a
mob_prog?
The basic system parses and interperets the mob_progs at boot time.
During the execution of a mob_prog, the entire program is made up of
pointers to tokens, or blocks of binary (not ascii) data. Execution time
is improved significantly.
Additional, the wiz command mprog displays the mob_prog's input,
displaying the mob_prog's output. This means that the command shows
what the mud understands from the mob_prog given to it. Which is
excellent for debugging. Also the TIMEMODE command in active mode will
give a trace output of the mob_progs while they execute, including the
mob_prog line numbers. Future efforts may give these commands to the
players on the testing game.
===================CUT HERE FOR QUICK REFERENCE SHEET========================
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
TRIGGERS ARGUMENT Explanation
act_prog WORDLIST or P WORD_PHRASE to match from act() to mobile
bribe_prog INTEGER amount of miminum gold amount given to mobile
entry_prog PERCENT chance to check when mobile moves to a new room
give_prog OBJ NAME to match when obj given to mobile
greet_prog PERCENT chance to check if visable char enters mobile's room
all_greet_prog PERCENT chance to check when any char enters mobile's room
fight_prog PERCENT chance to check at fight_pulse if mobile is fighting
hitprcnt_prog PERCENT lower than mobiles hit/max_hit if mobile is fighting
death_prog PERCENT chance to check after mobile has been slain
rand_prog PERCENT chance to check every game_pulse
speech_prog WORDLIST or P WORD_PHRASE to match in dialogue to mobile
range_prog PERCENT triggered when mobile shot
time_prog HOUR triggered on given hour. (0-23) *24 is every hour
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VARIABLES MOB ACTOR VICTIM RANDOM OBJ1 OBJ2 OBJ3
name $i $n $t $r $o $p $c
short_desc $I $N $T $R $O $P $C
he/she/it $j $e $E $J -- -- --
his/hers/its $k $s $S $K -- -- --
him/her/it $l $m $M $L -- -- --
a/an -- -- -- -- $a $A --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
IFCHECKS
isnpc ($*) Is $* a mob
ispc ($*) Is $* a player
isgood ($*) Is $* of good alignment
isevil ($*) Is $* of evil alignment
isneutral ($*) Is $* of neut alignment
iskiller ($*) Is $* a killer
isthief ($*) Is $* a thief
rand (number) Is random percentage less or equal to number
hasobj (name) Is the mob carrying the object: sets $c
hasobjnum (vNum) Is the mob carrying the object: sets $c
actorhasobjnum (vNum) Is actor carrying the object: sets $c
isaffected ($*) == integer Is $* affected by spell
hitprcnt ($*) == percent Is the hit/max_hit of $* equal to percent
inroom ($*) == vnum Is the room of $* equal to vnumber
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
race ($*) == integer Is the race of $* equal to integer
whichgod ($*) == integer Is the god of $* equal to integer
goldamt ($*) == integer Is the money of $* equal to integer
age ($*) == integer Is the age of the player equal to integer
objtype ($*) == integer Is the item type of $* equal to integer
objval0 ($*) == integer Is the value equal to integer
objval1 ($*) == integer Is the value equal to integer
objval2 ($*) == integer Is the value equal to integer
objval3 ($*) == integer Is the value equal to integer
number ($*) == vNum Is the vnum of $* equal to integer
name ($*) == string Is the name of $* equal to string
time () == integer Is the mud time equal to integer
shotfrom ($i) == integer Is the mob shot from exit equal to integer
pcsinarea () == integer Is amount of PC's in area equal to integer
pcsinarea (vNum) == integer Is amount of PC's in area equal to integer
pcsinroom (vNum) == integer Is amount of PC's in room equal to integer
quest (B,N,$*) == integer Is (startBit,range,$*) equal to integer
questr(A,B,N,$*) == integer Is (area,startBit,range,$*) equal to integer
objquest(B,N,$*) == integer Is (startBit,range,$*) equal to integer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
MP-COMMANDS ARGUMENTS MP-COMMANDS ARGUMENTS
MPROG <mobile> MPASOUND <text_string>
MPJUNK <object> MPECHO <text_string>
MPMLOAD <mobile> MPECHOAT <victim> <text_string>
MPOLOAD <object> <level> MPECHOAROUND <victim> <text_string>
MPKILL <victim> MPPURGE [argument]
MPGOTO <dest> MPAT <dest> <command>
MPTRANSFER <dest> [location] MPFORCE <victim> <command>
MPMSET <mobile> <flag/string> MPOSET <object> <flag/string>
MPMADD <victim> <flag> <val> MPOADD <object> <flag> <val>
MPGORAND <frm> <lrm> <ofs> <skp>
======================END OF QUICK REFERENCE SHEET===========================
++++++++++++++++++++++++++++++++EXAMPLE++++++++++++++++++++++++++++++++++++++
Referenced from above in the Control Flow section
>act_prog p pokes you in the~
if isnpc ($n)
chuckle
poke $n
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!!!
kill $n
else
slap $n
shout MOMMY!!! $n is poking me.
endif
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.
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)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following are extra examples of mob_progs. These are the running code
for the area Gateway to Avernus. Use these as references for creating
mob_progs.
==============================================================================
#QQ19
iron golem chair~
The Iron Golem~
There is a chair here with the distinct outline of a large man.~
The Iron Golem, formerly a chair, is large and menacing. His steps echo in
the room. He has a complete look of indifference in his eyes.
~
ACT_SENTINEL|ACT_SMART
AFF_DETECT_INVIS|AFF_DETECT_HIDDEN
0 S
65 0 0 2d800+6000 2d5+50
0 0
POS_STANDING POS_STANDING SEX_MALE
>speech_prog margoyle~
mpat QQ54 mpecho $n arrives from the infinite plains.
mptransfer $n QQ54
mpecho $n is taken from the infinite plains.
~
>rand_prog 10~
if rand (50)
say Hello mortal. I know how to leave the plains.
else
say Ask me to tell you about the stones.
endif
~
>speech_prog stones~
say The stones can move, when they have life.
say But the question is how do they get life?
~
>speech_prog life~
say Life can be endowed by the simplest of powers.
say Even the homonculous can tell you that.
mpecho The homonculous grins widely.
~
>speech_prog plains~
say The plains are infinite.
~
>speech_prog homonculous~
say The homonculous was also created by my master,
say along with the other creatures, that exist behind
say a set of gates. If you know who my fellow stone
say creatures are, I will take you out of the plains.
~
|
#QQ20
efreeti~
The Efreeti~
There is a large Efreeti here laughing deeply at you.~
The efreeti stands over twelve feet tall. Although man-like in appearance, he
has two small horns sprouting out of his head. He has flames licking his body.
~
ACT_SENTINEL|ACT_SCAVENGER|ACT_AGGRESSIVE|ACT_SMART
AFF_DETECT_INVIS|AFF_DETECT_HIDDEN
-100 S
62 0 0 2d400+2000 2d25+25
80000 0
POS_STANDING POS_STANDING SEX_MALE
>fight_prog 50~
if rand (33)
cast 'energy drain' $n
else
if rand(50)
cast 'lightening bolt' $n
else
cast fireball $n
endif
endif
~
>death_prog 100~
if questr (30900,0,3,$n) == 1
if quest (30,1,$n) == 0
mpmset $n quest 30 1 1
mpforce $n HELP GUILDTOKEN
mpquiet on
mpoload 30914
give i30914 $n
mpquiet off
endif
endif
~
|
#QQ12
belial devil arch~
Belial the Arch Devil~
Belial is twiddling with the ring on his finger and grinning evilly.~
With an angry glare, Belial judges you. He looks like an ebony man with small
horns poking out from the top of his head. He says something to you that you
don't understand.
~
ACT_SENTINEL|ACT_SCAVENGER|ACT_AGGRESSIVE|ACT_SMART
AFF_DETECT_INVIS|AFF_DETECT_HIDDEN|AFF_STEALTH|AFF_TONGUES
-1000 S
150 0 0 1d1+19000 4d30+90
60000 0
POS_STANDING POS_STANDING SEX_MALE
>fight_prog 66~
if rand (25)
mpecho {100}A black hole opens in space to admit a small devil.
mpmload 4201
else
if rand (33)
mpecho {100}A black hole opens in space to admit a devil.
mpmload 4202
else
if rand (50)
mpecho {100}A black hole opens in space to admit a large devil.
mpmload 4211
else
mpecho {100}A black hole opens in space to admit a huge devil.
mpmload 4213
endif
endif
endif
if rand (25)
say You WILL die mortal!
else
if rand (33)
cast "call lightning" $r
else
if rand(50)
cast heal
cast heal
cast heal
cast heal
cast heal
endif
endif
endif
~
>rand_prog 10~
mpquiet on
get all
remove all
wear all
drop all
sacrifice all
mpquiet off
~
|
#QQ13
barbed devil~
The Barbed Devil~
There is a rather large Barbed Devil here.~
The Barbed Devil is toying with the small flame that is erupting from his hands.
~
ACT_SCAVENGER|ACT_AGGRESSIVE|ACT_SMART
AFF_DETECT_INVIS|AFF_DETECT_HIDDEN
-1000 S
70 0 0 2d200+2600 2d25+35
30000 0
POS_STANDING POS_STANDING SEX_NEUTRAL
>fight_prog 50~
if rand (10)
cast "fire breath" $n
else
if rand (20)
mpecho The Barbed Devil cries out for help from Belial.
mpecho A large opening in space appears, and a devil steps out.
mpmload 4211
else
kick
endif
endif
~
>time_prog 1~
cast 'stone skin'
~
|
==============================================================================
FILE: "Mud20.txt"
These are extractions from Emud, the program. So they are accurate
for the time they were extracted from the program.
MAX_CLASS 8
MAX_RACE 29
MAX_LEVEL 99
PULSE_PER_SECOND 4
PULSE_VIOLENCE ( 4 * PULSE_PER_SECOND)
PULSE_MOBILE ( 4 * PULSE_PER_SECOND)
===============================================================================
Area Flags
AFLAG_NODEBUG AFLAG_NORECALL
AFLAG_NOTELEPORT AFLAG_NOCASTLE
AFLAG_NOGOHOME AFLAG_NORIP
===============================================================================
Mobile Actions
ACT_SENTINEL ACT_TRAIN ACT_NO_ORDER
ACT_SCAVENGER ACT_PRACTICE ACT_BODY
ACT_DRUNK ACT_WEAK ACT_RACE
ACT_AGGRESSIVE ACT_SMART ACT_UNDEAD
ACT_WIMPY ACT_NOCORPSE
===============================================================================
Mobile Affects
AFF_DETECT_HIDDEN AFF_ETHEREAL AFF_UNDERSTAND
AFF_DETECT_INVIS AFF_INVISIBLE AFF_TONGUES
AFF_NONE AFF_STEALTH AFF_SLEEP
AFF_PROTECT_GOOD AFF_SNEAK AFF_CHARM
AFF_PASS_DOOR AFF_HIDE AFF_FAERIE_FIRE
AFF_FLYING AFF_HUNT AFF_POISON
AFF_SANCTUARY
===============================================================================
Mobile Genders
SEX_NEUTRAL SEX_MALE SEX_FEMALE
===============================================================================
Body Parts
BODY_HEAD BODY_FOOT_2 BODY_HORN
BODY_MOUTH BODY_HAND_2 BODY_CLAW_1
BODY_EYE BODY_WING BODY_HAND_1
BODY_NONE BODY_TAIL BODY_FOOT_1
BODY_NONE BODY_TENTICLE
===============================================================================
Mobile Races
RACE_HUMAN RACE_SPRITE RACE_PHOENIX
RACE_ELF RACE_SHADE RACE_MYRDDRAAL
RACE_DARKELF RACE_ROC RACE_DRAGON
RACE_DWARF RACE_THREEKREEN RACE_TITAN
RACE_GNOME RACE_WEREWOLF RACE_EAGLE
RACE_ORC RACE_DEMON RACE_OCTOPUS
RACE_GRIFFON RACE_GARGOYLE RACE_FIREDRAGON
RACE_HALFELF RACE_WRAITH RACE_MINDSTALKER
RACE_OGRE RACE_TROLL
RACE_MULL RACE_VAMPIRE
===============================================================================
Mobile Positions
POS_DEAD POS_STUNNED POS_FIGHTING
POS_MORTAL POS_SLEEPING POS_STANDING
POS_INCAP POS_RESTING
===============================================================================
Object Types
ITEM_TYPE_NOTHING ITEM_TYPE_ARMOR ITEM_TYPE_FOOD
ITEM_TYPE_LIGHT ITEM_TYPE_POTION ITEM_TYPE_MONEY
ITEM_TYPE_SCROLL ITEM_TYPE_FURNITURE ITEM_TYPE_BOAT
ITEM_TYPE_WAND ITEM_TYPE_TRASH ITEM_TYPE_FOUNTAIN
ITEM_TYPE_STAFF ITEM_TYPE_CONTAINER ITEM_TYPE_PILL
ITEM_TYPE_WEAPON ITEM_TYPE_DRINK_CON ITEM_TYPE_AMMO
ITEM_TYPE_TREASURE ITEM_TYPE_KEY
===============================================================================
Object Flags
FLAG_HUM FLAG_BLESS FLAG_INVENTORY
FLAG_EVIL FLAG_ANTI_NEUTRAL FLAG_LEVEL
FLAG_INVIS FLAG_ANTI_GOOD FLAG_AUTO_ENGRAVE
FLAG_MAGIC FLAG_ANTI_EVIL FLAG_GLOW
FLAG_NODROP FLAG_NOREMOVE
===============================================================================
Wear Locations
CAN_WEAR_TAKE CAN_WEAR_LEGS CAN_WEAR_ABOUT
CAN_WEAR_FINGER CAN_WEAR_FEET CAN_WEAR_WAIST
CAN_WEAR_NECK CAN_WEAR_HANDS CAN_WEAR_WRIST
CAN_WEAR_BODY CAN_WEAR_ARMS CAN_WEAR_WIELD
CAN_WEAR_HEAD CAN_WEAR_SHIELD CAN_WEAR_HOLD
===============================================================================
Object Applies
APPLY_STR APPLY_MANA APPLY_SAVING_PARA
APPLY_DEX APPLY_HIT APPLY_SAVING_ROD
APPLY_INT APPLY_MOVE APPLY_SAVING_PETRI
APPLY_WIS APPLY_AC_ENHANCE APPLY_SAVING_BREATH
APPLY_CON APPLY_HITROLL APPLY_SAVING_SPELL
APPLY_SEX APPLY_DAMROLL
===============================================================================
Object Classes
FLAG_CLASS_FIGHTER FLAG_CLASS_MONK FLAG_CLASS_CLERIC
FLAG_CLASS_RANGER FLAG_CLASS_DRUID FLAG_CLASS_WIZARD
FLAG_CLASS_ROGUE FLAG_CLASS_BARD
===============================================================================
Containers
CONT_CLOSEABLE
CONT_PICKPROOF
CONT_CLOSED
CONT_LOCKED
===============================================================================
Drink Containers
LIQ_WATER LIQ_LEMONADE LIQ_COFFE
LIQ_BEER LIQ_FIREBRT LIQ_BLOOD
LIQ_WINE LIQ_LOCALSPC LIQ_SALTWATER
LIQ_ALE LIQ_SLIME LIQ_COKE
LIQ_DARKALE LIQ_MILK
LIQ_WHISKY LIQ_TEA
===============================================================================
Weapons
WEAPON_SLICE WEAPON_CLAW WEAPON_GREP
WEAPON_STAB WEAPON_BLAST WEAPON_BITE
WEAPON_SLASH WEAPON_POUND WEAPON_PIERCE
WEAPON_WHIP WEAPON_CRUSH
===============================================================================
Room Flags
ROOM_DARK ROOM_PRIVATE ROOM_NO_MOB
ROOM_FOG ROOM_SOLITARY ROOM_NO_ASTRAL
ROOM_INDOORS ROOM_ALLOW_FTR ROOM_NO_RECALL
ROOM_SAFE ROOM_ALLOW_BAR ROOM_NO_SAVE
ROOM_BANK ROOM_ALLOW_ROG ROOM_NO_CASTLE
ROOM_PET_SHOP ROOM_ALLOW_MNK ROOM_NO_RIP
ROOM_MORGUE ROOM_ALLOW_DRU
ROOM_ALTAR_N ROOM_ALLOW_SOR
ROOM_NOTE_BOARD ROOM_ALLOW_CLE
ROOM_BLOCK ROOM_ALLOW_WIZ
===============================================================================
Room Sectors
SECT_INSIDE SECT_WATER_NOSWIM SECT_ASTRAL
SECT_CITY SECT_UNUSED SECT_UNDER_WATER
SECT_FIELD SECT_AIR SECT_UNDER_GROUND
SECT_FOREST SECT_DESERT SECT_DEEP_EARTH
SECT_HILLS SECT_LAVA
SECT_MOUNTAIN SECT_INN
SECT_WATER_SWIM SECT_ETHEREAL
===============================================================================
Exit Directions
DIR_NORTH DIR_EAST DIR_SOUTH
DIR_WEST DIR_UP DIR_DOWN
===============================================================================
Door Flags
EX_ISDOOR EX_HIDDEN EX_MAGIC_PROOF
EX_CLOSED EX_PICKPROOF
EX_LOCKED EX_BASHPROOF
===============================================================================
Door Reset Flags
DOOR_OPEN
DOOR_CLOSED
DOOR_CLOSED_LOCKED
===============================================================================
Reset Wear Locations
WEAR_NONE WEAR_HEAD WEAR_WAIST
WEAR_LIGHT WEAR_LEGS WEAR_WRIST_L
WEAR_FINGER_L WEAR_FEET WEAR_WRIST_R
WEAR_FINGER_R WEAR_HANDS WEAR_WIELD
WEAR_NECK_A WEAR_ARMS WEAR_HOLD
WEAR_NECK_B WEAR_SHIELD
WEAR_BODY WEAR_ABOUT
===============================================================================
Conditions
COND_DRUNK COND_FULL COND_THIRST
===============================================================================
God Flags
GOD_NEUTRAL GOD_MANWE GOD_AQUARIUS
GOD_DEMISE GOD_HYPNOS GOD_GAIA
===============================================================================
Class Flags
CLASS_FIGHTER CLASS_MONK CLASS_WIZARD
CLASS_RANGER CLASS_DRUID
CLASS_ROGUE CLASS_BARD
===============================================================================
Values for items value0, value1, value2, value3
ITEM_LIGHT
Value[0]: -
Value[1]: -
Value[2]: Number of hours the light can be used for.
Value[3]: -
ITEM_SCROLL
Value[0]: Level of the spell on the scroll.
Value[1]: Which spell
Value[2]: Which spell
Value[3]: Which spell
ITEM_WAND
Value[0]: Level of spell in wand.
Value[1]: Max Charges
Value[2]: Charges Left
Value[3]: Which spell in wand
ITEM_STAFF
Value[0]: Level of spell in staff.
Value[1]: Max Charges
Value[2]: Charges Left
Value[3]: Which spell in staff
ITEM_WEAPON
Value[0]: Type of ammo shot by the weapon
Value[1]: Number of dice to roll for damage
Value[2]: Size of dice to roll for damage
Value[3]: The weapon type.
ITEM_TREASURE
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_ARMOR
Value[0]: The effective AC
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_POTION
Value[0]: Level of the spell in the potion.
Value[1]: Which spell
Value[2]: Which spell
Value[3]: Which spell
ITEM_FURNITURE
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_TRASH
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_CONTAINER
Value[0]: Maximum weight the container can contain.
Value[1]: Container flags
Value[2]: key vnum. -1 means no lockability.
Value[3]: 0
ITEM_DRINKCON
Value[0]: Maximum drink-units the drink-container can contain.
Value[1]: Number of drink-units that are left in the container.
Value[2]: The type of liquid in the drink-container
Value[3]: if this value is non-zero, then the drink is poisoned.
ITEM_KEY
Value[0]: The key-type. Must match lock type.
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOOD
Value[0]: The number of hours, that this food will fill the stomach
Value[1]: -
Value[2]: -
Value[3]: If this value is non-zero, the food is poisoned.
ITEM_MONEY
Value[0]: The number of gold coins "in the pile of coins".
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_BOAT
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOUNTAIN
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_PILL
Value[0]: Level of the spell in the potion.
Value[1]: Which spell
Value[2]: Which spell
Value[3]: Which spell
ITEM_AMMO
Value[0]: Ammunition type
Value[1]: Damage
Value[2]: Speed
Value[3]: Effective range
==============================================================================
FILE: "holygrove.are" Using the 'QQ' system
==============================================================================
#AREA Holy Grove~
#AUTHORS Daith Superdave~
#RANGES 5 20 1 95
#FLAGS AFLAG_NODEBUG
#RESETMSG You hear the sound of druids wandering the grove.~
#TEMPERATURE 20 80 15 5
#HELPS
0 HOLYGROVE 'HOLY GROVE'~
{120}
Holy Grove
{300}
The Holy Grove is a place of happiness, a calm peaceful place where the
citizens of the realm come to celebrate the spring, where farmers give
thanks for bountiful harvests in the fall, and where lovers stroll in
the summer.
{140}
Modified by Daith and Superdave
~
0 $~
#MOBILES
#QQ00
hierophant~
The Hierophant~
The old Hierophant of the holy grove is here, gathering holly.~
He is a very old man, dressed in an old robe; but from the glint in his
clear blue eyes you can see that He is aware of the world, and wise to its
traps and pitfalls.
~
ACT_SMART|ACT_TRAIN|ACT_BODY|ACT_RACE|ACT_WIMPY
AFF_TONGUES|AFF_UNDERSTAND|AFF_SANCTUARY|AFF_DETECT_INVIS
1000 S
20 BODY_HAND_1|BODY_HAND_2 BODY_HAND_1|BODY_HAND_2 20d20+180 1d8+15
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
>greet_prog 100~
if quest(0,2,$n) == 0
say Greetings stranger, would you care to help me?
break
endif
if actorhasobjnum(QQ23)
say I see you have found some holly!
say May I have it please?
break
endif
if quest(0,2,$n) == 1
say I'm still waiting for you to bring me some holly.
say Perhaps you can find some in the DRAGON's garden.
endif
~
>speech_prog dragon~
say The Great Dragon Archibald lives in the home to the south
say of the croquet lawn. Perhaps you can find some holly there
say in his garden.
~
>speech_prog yes~
if quest(0,2,$n) == 0
say I need some holly leaves for my magic potion.
say Gather me some holly and I will reward you.
mpmset $n quest 0 2 1
else
say Yes what?
endif
~
>speech_prog no~
say well thanks anyway.
grumble
~
>give_prog iQQ23~
if quest(0,2,$n) == 1
mpmset $n quest 0 2 2
say Thank you for your help.
say Please take this as a reward.
mpecho $I weaves some of the holly together.
mpjunk iQQ23
mpoload QQ24
mpquiet on
cast 'giant strength' $n
mpquiet off
give iQQ24 $n
else
say Thank you for bringing me more holly!
smile $n
endif
~
|
#QQ01
hierophant~
The Hierophant~
The old Hierophant of the holy grove is here, gathering ivy.~
She is a very old woman, dressed in an old gown; but from the glint in her
clear blue eyes you can see that She is aware of the world, and wise to its
traps and pitfalls.
~
ACT_WIMPY|ACT_BODY|ACT_SMART|ACT_PRACTICE|ACT_RACE
AFF_SANCTUARY|AFF_UNDERSTAND|AFF_TONGUES|AFF_DETECT_INVIS
1000 S
20 BODY_HAND_1|BODY_FOOT_1|BODY_HAND_2 BODY_HAND_1|BODY_FOOT_1|BODY_HAND_2 20d20+180 1d8+15
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_FEMALE
>greet_prog 100~
if quest(2,2,$n) == 0
say Greetings friend, would you care to help me?
break
endif
if actorhasobjnum(QQ22)
say I see you found some ivy!
say May I have it please?
break
endif
if quest(2,2,$n) == 1
say I'm still waiting for you to bring me some ivy.
say Perhaps you can find some in the DRAGON's garden.
endif
~
>speech_prog dragon~
say The Great Dragon Archibald lives in the house to the south
say of the croquet lawn. Perhaps you can find ivy there in his
say wonderful garden.
~
>speech_prog yes~
if quest(2,2,$n) == 0
say I need some ivy to make one of my potions.
say Bring me some ivy, and I'll reward you.
mpmset $n quest 2 2 1
else
say Yes what?
endif
~
>speech_prog no~
say well thanks anyway.
sigh
~
>give_prog iQQ22~
if quest(2,2,$n) == 1
mpmset $n quest 2 2 2
say Thank you for your help.
say Please take this as a reward.
mpecho $I ties some of the ivy together.
mpjunk iQQ22
mpoload QQ25
mpquiet on
cast 'giant strength' $n
mpquiet off
give iQQ25 $n
else
say Thanks for more ivy!
hug $n
endif
~
|
#QQ02
elder druid~
an elder druid~
An elder druid stands here, watching the local flora and wildlife.~
He looks ageless, as do all druids. His grey beard contrasts strongly with
his lack of wrinkles.
~
ACT_WIMPY
AFF_UNDERSTAND|AFF_TONGUES|AFF_TONGUES
1000 S
13 0 0 13d13+130 1d4+10
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
#QQ03
elder druidess~
an elder druidess~
An elder druidess stands here, watching the local fauna and feeding rabbits.~
She looks ageless, as do all druids. She smiles a beautiful smile at you.
~
ACT_WIMPY|ACT_BODY
AFF_TONGUES|AFF_UNDERSTAND
1000 S
13 BODY_HAND_2|BODY_HAND_1|BODY_FOOT_1 BODY_HAND_2|BODY_HAND_1|BODY_FOOT_1 13d13+130 1d4+10
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_FEMALE
>death_prog 100~
if questr (41000,0,4,$n) == 1
if questr (41000,8,8,$n) < 75
if quest (30,1,$n) == 0
mpmset $n quest 30 1 1
mpmadd $n questr 41000 8 8 1
mpoload 30914
mpforce $n HELP GUILDTOKEN
mpquiet on
give i30914 $n
mpquiet off
endif
endif
endif
~
|
#QQ04
doe~
a doe~
A doe is here, munching on grass.~
This peaceful creature looks at you with big dark eyes. Her nose twitches as
she sniffs at you, but she goes back to chewing some grass.
~
ACT_BODY
0
0 S
6 BODY_HORN BODY_HORN 5d5+35 1d7+2
2 RACE_HUMAN
POS_STANDING POS_STANDING SEX_FEMALE
#QQ05
deer~
a deer~
A deer is here, staring back at you.~
The deer looks angered at your intrusion. He butts his head against you,
albeit ineffectively.
~
ACT_BODY
0
0 S
7 BODY_HORN BODY_HORN 6d6+40 1d4+4
2 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
#QQ06
stag deer large~
a stag~
A large deer stag is here, protecting his territory.~
He eyes you with contained anger. You'd better leave him alone!
~
ACT_AGGRESSIVE|ACT_BODY
0
0 S
9 BODY_HORN|BODY_FOOT_2 BODY_HORN|BODY_FOOT_2 7d8+40 1d4+6
2 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
#QQ07
bunny rabbit~
a small bunny~
A small bunny is here, poking from bush to bush.~
This bunny looks so adorable, you wished you had one just like this!
~
ACT_BODY
0
0 S
2 BODY_FOOT_1 BODY_FOOT_1 2d2+10 1d1+5
2 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
#QQ08
snake~
a harmless snake~
A small snake slithers between the grass.~
Upon careful inspection, you are sure it is NOT a cobra!
~
ACT_BODY|ACT_AGGRESSIVE
AFF_SNEAK
0 S
4 BODY_MOUTH BODY_MOUTH 4d4+10 1d1+6
2 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
#QQ09
druid~
a druid~
A druid is here in meditation.~
He doesn't like you bothering him, but is too polite to ask you to leave.
~
ACT_WIMPY
AFF_DETECT_INVIS
1000 S
10 0 0 10d10+100 1d4+11
50 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
#QQ10
druidess~
a druidess~
A druidess is here, peering at you.~
She wonders why you are staring at her, and how you got in here.
~
ACT_WIMPY
AFF_DETECT_INVIS
1000 S
10 0 0 10d10+100 1d4+11
50 RACE_HUMAN
POS_STANDING POS_STANDING SEX_FEMALE
#QQ11
archibald dragon majestic~
Archibald~
The great dragon Archibald is here.~
The dragon before you appears to be three times your size. He is curled up
relaxing on floor. His green scales reflect light and blind you for a moment.
~
ACT_SENTINEL|ACT_SMART|ACT_BODY
AFF_DETECT_HIDDEN|AFF_SANCTUARY|AFF_UNDERSTAND|AFF_FLYING|AFF_TONGUES|AFF_DETECT_INVIS
1000 S
15 BODY_WING|BODY_TAIL|BODY_CLAW_1 BODY_WING|BODY_TAIL|BODY_CLAW_1 10d10+200 10d2+4
9142 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE
>greet_prog 100~
if quest(12,2,$n) == 0
mpechoat $n $I sniffs sadly.
tell $n can you perhaps help me with something?
else
if quest(8,4,$n) == 15
mpmset $n quest 8 4 0
if quest(12,2,$n) == 1
mpoload QQ26
say Thank you $n! You have helped clean my garden!
mpecho $I gets a shining scale from a small box.
give iQQ26 $n
drop iQQ26
say Take this as a token of my gratitude.
mpmset $n quest 12 2 2
else
say Thanks again for cleaning out those weeds.
say Here, have some money. It's the least I can do.
mpoload QQ28
drop iQQ28
endif
endif
endif
~
>speech_prog yes~
if quest(12,2,$n) == 0
mpmset $n quest 12 2 1
tell $n My lovely garden has been overgrown by weeds lately.
tell $n If you could go and destroy some of those weeds for me,
tell $n I will reward you handsomely.
else
say Yes what?
endif
~
|
#QQ12
ethmobgrove~
ethereal grove mob~
~
~
ACT_SENTINEL
AFF_ETHEREAL
0 S
1 0 0 1d1+20 1d1+3
0 0
POS_STANDING POS_STANDING SEX_NEUTRAL
#QQ13
black bloodroot sapling~
a bloodroot sapling~
A small black sapling grows here.~
This small sapling has been infected by the bloodroot disease. It must be
destroyed before it infects any other trees in the grove!
~
ACT_SENTINEL
AFF_BLIND|AFF_CURSE
0 S
13 0 0 1d1+75 1d13+1
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
#QQ14
bloodroot tree~
a bloodroot tree~
A large bloodroot tree grows here.~
This large tree has been infected by bloodroot disease. You can see drops
of red sap along the base of its roots. You had better chop down this tree
before it spreads and infects the other trees of the grove.
~
ACT_SENTINEL
AFF_CURSE|AFF_BLIND
0 S
19 0 0 1d1+130 1d19+1
5000 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
#QQ15
overgrown weed~
an overgrown weed~
A gigantic overgrown weed grows here.~
This giant weed grows in the lovely garden. Archibald doesn't like weeds
however, for they rob his flowers of their precious nutrients. The toothed
leaves look at little dangerous, but its merely a plant and shouldn't be
too much of a problem for you to destroy it.
~
ACT_SENTINEL
AFF_BLIND|AFF_CURSE
0 S
9 0 0 1d1+50 4d2+1
500 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
>death_prog 100~
if quest (12,2,$n) != 0
if quest (8,4,$n) < 15
mpmadd $n quest 8 4 1
else
mpechoat $n {160}You have killed enough weeds for today, go see Archibald for your reward.
endif
endif
~
|
#QQ16
bee~
a honey bee~
A giant honey bee flies around here.~
This giant bee quickly flies from flower to flower, pollenating them as it
drinks the nectar from the blooms.
~
ACT_BODY|ACT_SENTINEL
AFF_CURSE|AFF_FLYING|AFF_FAERIE_FIRE|AFF_BLIND
0 S
9 BODY_WING BODY_WING|BODY_TAIL 1d1+50 4d2+1
100 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
>rand_prog 5~
mpecho Bzzzzzzzzzzzzzzz
~
|
#QQ17
ethereal fountain~
ethereal fountain~
The ethereal fountain is standing here~
~
ACT_SENTINEL|ACT_SMART
AFF_UNDERSTAND|AFF_TONGUES|AFF_ETHEREAL
0 S
50 0 0 1d1+2500 1d1+100
0 RACE_HUMAN
POS_STANDING POS_STANDING SEX_FEMALE
>rand_prog 100~
mpquiet on
if isaffected ($r) == spell_sanctuary
if isaffected ($r) == spell_enhanced_heal
if isaffected ($r) == spell_shield
if isaffected ($r) == spell_giant_strength
if isaffected ($r) == spell_armor
cast feast
break
endif
cast armor $r
break
endif
cast 'giant strength' $r
break
endif
cast shield $r
break
endif
cast 'enhanced heal' $r
break
endif
cast sanctuary $r
mpquiet off
~
>act_prog p drinks from a garden fountain~
if isaffected ($n) == spell_bless
break
endif
mpquiet on
cast bless $n
mpquiet off
mpechoat $n {160}A powerful blessing is laid upon you.
~
|
#QQ30
etherealobelisk~
The Ethereal Obelisk~
The Ethereal Obelisk stands here.~
~
ACT_SENTINEL
AFF_DETECT_HIDDEN|AFF_ETHEREAL|AFF_DETECT_INVIS
0 S
1 0 0 0d0+10 0d0+3
0 RACE_HUMAN
POS_STANDING POS_STANDING SEX_NEUTRAL
>speech_prog roterodamum rot~
if hasobjnum (QQ31)
if level ($n) > 25
if level ($n) < 99
mpecho {170}Laughter echoes through the grove.
break
endif
endif
if quest (0,5,$i) == 0
mpmset self quest 0 5 10
mposet kladblok short $n
mpecho {170}White strings of magic start to spin around the obelisk.
else
mpechoat $n The obelisk seems to be about to transport $C.
endif
endif
~
>rand_prog 100~
if quest (0,5,$i) > 0
mpmadd self quest 5 5 1
if quest (5,5,$i) > 9
mpmset self quest 0 10 0
mpecho {170}The white strings of magic vanish.
break
endif
if hasobjnum (QQ31)
mpmset $C quest 100 1 1
if quest (100,1,$r) == 1
mpmset $r quest 100 1 0
mpechoat $r {160}Arms from white magic pull you through the obelisk to your destination.
mpechoaround $r {170}Arms from white magic pull $r into the black obelisk.
if quest (0,5,$i) == 10
mptransfer $r 9702
mpat $r mpforce $r look
mpmset self quest 0 10 0
break
endif
endif
mpmset $C quest 100 1 0
if rand (50)
mpechoaround $C {170}Energy sizzles through the air slowly surrounding $C.
else
mpechoaround $C {170}Energy sizzles through the air.
endif
mpechoat $C {160}Energy sizzles through the air slowly surrounding you.
endif
endif
~
|
#0
#OBJECTS
#QQ01
closet~
a closet~
There is a wooden closet tucked into a corner.~
It is large, yet gracefully made, obviously of Scandinavian design.~
ITEM_TYPE_CONTAINER
FLAG_LEVEL
0
100 1 -1 0
500 0 7
#QQ02
jar~
a spice jar~
A small unlabeled spice jar is standing here.~
~
ITEM_TYPE_CONTAINER
FLAG_LEVEL
CAN_WEAR_TAKE
5 5 -1 0
1 10 1
#QQ03
powder black~
some black powder~
Some strong-smelling black powder has been carelessly scattered here.~
* * *
* * *
**** AAAHHHH-TSHOU! ****
* * *
* * *
~
ITEM_TYPE_FOOD
FLAG_LEVEL
CAN_WEAR_TAKE
-2 0 0 NOT_POISONED
1 300 1
P 1
TRIG_TICK 5
OPROG_IF OIF_USER_POSITION > POS_SLEEPING 2 0
P 2
TRIG_VOID
OPROG_GOD_COMMAND
look IQQ03&mpechoaround self $n sneezes loudly. AAAHHHH-TSHOU!~
#QQ04
kernel kernels~
some small yellow kernels~
Some small yellow kernels have been accidentally left here.~
They look fairly dull...~
ITEM_TYPE_FOOD
FLAG_LEVEL
CAN_WEAR_HOLD|CAN_WEAR_TAKE
1 0 0 NOT_POISONED
1 10 1
#QQ05
paper wad~
a crumpled wad of paper~
There is a crumpled wad of paper here, left behind by some messy bypasser.~
~
ITEM_TYPE_TRASH
FLAG_LEVEL
CAN_WEAR_HOLD|CAN_WEAR_TAKE
0 0 0 0
1 0 1
#QQ10
staff wooden~
a wooden staff~
You see a wooden staff on the floor.~
This oaken staff is very hefty but balanced.
~
ITEM_TYPE_WEAPON
FLAG_ANTI_EVIL|FLAG_LEVEL
CAN_WEAR_WIELD|CAN_WEAR_TAKE
0 3 3 WEAPON_POUND
5 50 6
#QQ11
robe brown cloth~
a brown robe~
Some brown cloth is on the floor.~
This robe is rough, but appears quite durable.~
ITEM_TYPE_ARMOR
FLAG_ANTI_EVIL|FLAG_LEVEL|FLAG_MAGIC
CAN_WEAR_TAKE|CAN_WEAR_BODY
6 0 0 0
5 60 10
A
APPLY_MANA 10
#QQ13
bluish herbs~
some bluish herbs~
Some bluish herbs are scattered here.~
You remember from your nature classes that these herbs provide protection.
~
ITEM_TYPE_PILL
FLAG_LEVEL|FLAG_MAGIC
CAN_WEAR_TAKE
15 SPELL_SHIELD SPELL_ARMOR SPELL_STONE_SKIN
1 1 15
#QQ14
purplish herbs~
some purplish herbs~
Some purplish herbs are scattered here.~
You remember from your nature classes that these herbs can make you
stronger for a bit.
~
ITEM_TYPE_PILL
FLAG_LEVEL|FLAG_MAGIC
CAN_WEAR_TAKE
15 SPELL_BLESS SPELL_CURE_POISON SPELL_GIANT_STRENGTH
1 1 15
#QQ15
blackish herbs~
some blackish herbs~
Some blackish herbs are scattered here.~
You remember from your nature classes that these herbs can transport you
back to your room of recall.
~
ITEM_TYPE_PILL
FLAG_LEVEL
CAN_WEAR_TAKE
1 SPELL_NONE SPELL_NONE SPELL_WORD_OF_RECALL
0 100 1
#QQ16
grayish herbs~
some grayish herbs~
Some grayish herbs are scattered here.~
You remember from your nature classes that these herbs can help you
understand and speak many languages.
~
ITEM_TYPE_PILL
FLAG_MAGIC|FLAG_LEVEL
CAN_WEAR_TAKE
10 SPELL_COMPREHEND_LANGUAGES SPELL_TONGUES SPELL_NONE
0 100 10
#QQ17
reddish herbs~
some reddish herbs~
Some reddish herbs are scattered here.~
You remember from your nature classes that these herbs will allow you to
see things more clearly.
~
ITEM_TYPE_PILL
FLAG_MAGIC|FLAG_LEVEL
CAN_WEAR_TAKE
15 SPELL_DETECT_INVIS SPELL_DETECT_SECRET SPELL_INFRAVISION
0 100 15
#QQ18
orangish herbs~
some orangish herbs~
Some orangish herbs are scattered here.~
You remember from your nature classes that these herbs can miraculously
heal your wounds.
~
ITEM_TYPE_PILL
FLAG_LEVEL
CAN_WEAR_TAKE
10 SPELL_CURE_CRITICAL SPELL_CURE_CRITICAL SPELL_CURE_CRITICAL
0 100 10
#QQ19
pinkish herbs~
some pinkish herbs~
Some pinkish herbs are scattered here.~
You remember from your nature classes that these herbs can help reduce
damage taken in battle.
~
ITEM_TYPE_PILL
FLAG_MAGIC|FLAG_LEVEL
CAN_WEAR_TAKE
10 SPELL_PROTECTION_EVIL SPELL_SANCTUARY SPELL_PROTECTION_GOOD
0 100 10
#QQ20
holly bush~
a holly bush~
A small bush of holly grows here.~
The bush is quite small and green, and it looks to have some holy inside
of it.
~
ITEM_TYPE_CONTAINER
FLAG_LEVEL
0
24 0 0 0
0 10 1
#QQ21
patch ivy~
a patch of ivy~
A patch of ivy grows here.~
There is a small patch of ivy here. Glancing inside, you can see some
nice fresh ivy just ready to be taken.
~
ITEM_TYPE_CONTAINER
FLAG_LEVEL
0
24 0 0 0
0 10 1
#QQ22
ivy~
some ivy~
Some ivy is here.~
~
ITEM_TYPE_PILL
FLAG_LEVEL
CAN_WEAR_TAKE
5 SPELL_CURE_LIGHT SPELL_CURE_LIGHT SPELL_CURE_LIGHT
0 10 5
#QQ23
holly~
a small piece of holly~
A small piece of holly is here.~
~
ITEM_TYPE_PILL
FLAG_LEVEL
CAN_WEAR_TAKE
5 SPELL_CURE_LIGHT SPELL_CURE_LIGHT SPELL_CURE_LIGHT
1 1 5
#QQ24
holly belt~
a small belt made of holly~
A small ring of holly is laying here.~
~
ITEM_TYPE_ARMOR
FLAG_LEVEL
CAN_WEAR_WAIST|CAN_WEAR_TAKE
5 0 0 0
5 60 10
A
APPLY_DEX 2
A
APPLY_DAMROLL 2
#QQ25
ivy necklace~
a small necklace made of ivy~
A small ring of ivy is here.~
~
ITEM_TYPE_ARMOR
FLAG_LEVEL
CAN_WEAR_NECK|CAN_WEAR_TAKE
5 0 0 0
5 60 10
A
APPLY_INT 2
A
APPLY_CON 2
A
APPLY_WIS 2
#QQ26
scale dragon~
a scale of the great dragon archibald~
A small greenish scale is here.~
~
ITEM_TYPE_ARMOR
FLAG_ANTI_EVIL|FLAG_MAGIC|FLAG_LEVEL
CAN_WEAR_ARMS|CAN_WEAR_TAKE|CAN_WEAR_SHIELD
5 0 0 0
5 60 10
A
APPLY_DAMROLL 2
A
APPLY_HITROLL 2
#QQ27
fountain~
a garden fountain~
A beatiful fountain sprays water into the air.~
This fountain is in the shape of a beautiful naked woman carrying a large
urn. You stare at it for a while longer, then proceed with your duties.
~
ITEM_TYPE_FOUNTAIN
FLAG_GLOW|FLAG_LEVEL
0
0 0 0 0
1000 10 1
#QQ28
pile coins~
a huge pile of coins~
A huge pile of coins has been dropped here!~
~
ITEM_TYPE_MONEY
FLAG_GLOW|FLAG_LEVEL
CAN_WEAR_TAKE
200000 0 0 0
10 200000 1
#QQ30
black obelisk~
a black obelisk~
A black obelisk rises from the ground here.~
{070}
{070} _____________________________________________________________
{070} / \
{070} | Simply say the name of the location to which you would like |
{070} | to travel and the obelisk will magically transport you. |
{070} | |
{070} | Available locations include: Recommended levels: |
{070} | |
{070} | Roterodamum Levels 1 - 95 |
{070} \______________________________________________________________/
~
ITEM_TYPE_TREASURE
FLAG_LEVEL
0
0 0 0 0
100 100 1
#QQ31
notepad~
notepad~
a notepad with all kind of names written on it lies here.~
You see a storage object for temporary names used by the obelisk ethereal,
the messy handwritings on it make you wonder about ethereal education.~
ITEM_TYPE_FURNITURE
FLAG_LEVEL
CAN_WEAR_TAKE
0 0 0 0
0 0 1
#0
#ROOMS
#QQ00
The entrance to a large lovely garden~
You stand upon a well kept path which leads southward into an enormous garden.
The smooth ground upon which you stand is free of any dirty or weeds.
~
QQ 0 SECT_INSIDE
DDIR_NORTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ19
DDIR_SOUTH
~
~
0 -1 QQ20
S
#QQ01
The holy grove~
You are standing amidst the ancient oaks and poplars in the holy grove. You
can feel a strange sensation of contentedness and relief seeping through You,
as if great burdens have been lifted from Your shoulders. From here,
friendly-looking paths lead east and south.
~
QQ 0 SECT_FOREST
DDIR_EAST
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ02
DDIR_SOUTH
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ04
S
#QQ02
The holy grove~
You are standing amidst the ancient oaks and poplars in the holy grove. You
feel unusually happy here, as if great burdens have been lifted from Your
shoulders. From here, pleasant-looking paths lead east, west and south.
~
QQ 0 SECT_FOREST
DDIR_EAST
The path wind its way through the tall trees, towards a clearing faintly seen.
~
~
0 -1 QQ03
DDIR_SOUTH
The path wind its way through the tall trees, towards an open area barely
visible in the distance.
~
~
0 -1 QQ05
DDIR_WEST
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ01
S
#QQ03
A clearing in the woods~
You are standing in a clearing in the light woods. Somehow, this place
seems powerfully DIFFERENT from the rest of the forest, as if something is
severely strained in the fabric of reality here. There is a small tablet
on one of the trees.
~
QQ ROOM_NO_MOB SECT_FOREST
DDIR_NORTH
A small, narrow path winds north, and is quickly lost in the bushes. It
looks quite a wilderness there!
~
~
0 -1 5378
DDIR_SOUTH
There is a path winding its way south through the tall poplars, disappearing
out of sight some 100 yds. away.
~
~
0 -1 QQ06
DDIR_WEST
There is a friendly-looking path leading west through the tall trees.
~
~
0 -1 QQ02
E
tablet~
This zone has been populated by Merc. 1993
~
S
#QQ04
The holy grove~
You are standing amidst the ancient oaks and poplars in the holy grove. You
feel calm and relaxed here, as if great burdens have been lifted from Your
shoulders. From here, pleasant-looking paths lead east, north and south. To
the west, through the trees, you can see the gate of Midgaard.
~
QQ ROOM_NO_MOB SECT_FOREST
DDIR_NORTH
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ01
DDIR_EAST
The path wind its way through the tall trees, towards a clearing faintly seen.
~
~
0 -1 QQ05
DDIR_SOUTH
The path wind its way through the tall trees, into the grove.
~
~
0 -1 QQ07
DDIR_WEST
~
~
0 -1 3053
S
#QQ05
The sacred glade~
You are standing in the middle of the sacred glades, where the citizens of
Chakkor come to celebrate the spring, where farmers give thanks for bountiful
harvest in the fall, and where lovers stroll in summer. You feel seasons of
remembered happiness and joy taking Your sorrows and worries away from You,
leaving You calm and invigorated, ready for the world. Paths lead into the
holy grove to the east, north and west, while to the south a wide, sunny
field slopes down to a sparkling lake.
~
QQ 0 SECT_FOREST
DDIR_NORTH
The path wind its way north, disappearing through the tall trees.
~
~
0 -1 QQ02
DDIR_EAST
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ06
DDIR_SOUTH
To the south, a wide, sunny field stretch out, sloping down towards a brightly
glittering lake.
~
~
0 -1 QQ08
DDIR_WEST
The path wind its way west between stately poplars and oaks.
~
~
0 -1 QQ04
S
#QQ06
The holy grove~
You are standing amidst the ancient oaks and poplars in the holy grove. You
can feel a strange sensation of joy and calm seeping through You, as if great
burdens have been lifted from Your shoulders. To the south, You glimpse an
open area through the trees, while paths lead away north and west.
~
QQ 0 SECT_FOREST
DDIR_NORTH
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ03
DDIR_EAST
~
~
0 -1 17498
DDIR_SOUTH
To the south, just beyond the trees, you can see a wide green lawn, and past
the lawn, a softly shimmering, rainbow-colored mansion.
~
~
0 -1 QQ09
DDIR_WEST
The path wind its way through the tall trees, disappearing out of sight.
~
~
0 -1 QQ05
E
mansion~
The mansion is a sprawling, two-story affair with three wings, where the top
of one wing serves as balcony. The walls look as marble would do, if marble
changed color slowly, continuously, through the entire spectrum. There are
large windows all over the house.
~
S
#QQ07
The holy grove~
You are standing amidst the tall, majestic trees in the southern end of the
holy grove. Paths lead north and east. To the east, You can see a wide, open
field, sloping gently down towards a bright, glittering lake. Somehow, here
you feel an inexplicable happiness, as if the world's troubles no longer
really matter to you.
~
QQ 0 SECT_FOREST
DDIR_NORTH
The path leading north is soon lost out of sight amongst the ancient oaks and
poplars.
~
~
0 -1 QQ04
DDIR_EAST
To the east, the path leads out into a wide, sunny summer's field, sloping
south towards a beautiful lake. Past the field You can see a stately mansion,
shimmering gently in all the rainbow's colours.
~
~
0 -1 QQ08
E
mansion~
The mansion is a sprawling, two-story affair with three wings, where the top
of one wing serves as balcony. The walls look as marble would do, if marble
changed color slowly, continuously, through the entire spectrum. There are
large windows all over the house.
~
S
#QQ08
The sunny field~
You are standing in the middle of a wide, summery, sunlit field. There is a
fragrance of spring in the air, a sound of summer and a feeling of eternal
Saturday afternoon. To the south is a clear, sparkling lake, and to the north
and west is the holy grove. In the wood's edge, to the east, is a stately
mansion, shimmering softly through the colors of the rainbow. You feel as if
You could spend the rest of your life here, lying on your back and looking at
the patterns of the clouds as they gently drift across the sky.
~
QQ ROOM_INDOORS SECT_FIELD
DDIR_NORTH
There is a path leading north towards the sacred glade.
~
~
0 -1 QQ05
DDIR_EAST
To the east, You can see the rainbow-colored mansion, shimmering like some-
thing out of this world.
~
~
0 -1 QQ19
DDIR_WEST
There is a small path leading into the woods to the west.
~
~
0 -1 QQ07
E
mansion~
The mansion is a sprawling, two-story affair with three wings, where the top
of one wing serves as balcony. The walls look as marble would do, if marble
changed color slowly, continuously, through the entire spectrum. There are
large windows all over the house. There is a terrace in front of the house,
next to the low wing, which is almost completely windows.
~
S
#QQ09
The croquet lawn~
You are standing on a immaculately manicured green lawn, the kind you only
get after 200 years of meticulous work. There is a winding stone path leading from the wood's edge to the north, to the softly shimmering, rainbow-colored mansion to the south. This place enjoys a perpetual cool, sunny summers afternoon.
~
QQ ROOM_NO_MOB SECT_FIELD
DDIR_NORTH
To the north, the winding stone path leads into the holy grove.
~
~
0 -1 QQ06
DDIR_SOUTH
To the south, the path leads straight up to the front door of the mansion.
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ10
E
mansion~
The mansion is a sprawling, two-story affair with three wings, where the top
of one wing serves as balcony. The walls look as marble would do, if marble
changed color slowly, continuously, through the entire spectrum. There are
large windows all over the house.
~
S
#QQ10
The foyer~
You are standing in the foyer of Archibald's mansion. The wide double doors
to the croquet lawn is to the north, flanked by large windows. The walls are
panelled in oak and hung with strange paintings. There is door in the south
wall.
~
QQ ROOM_NO_MOB|ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
Through the windows next to the door you can see the croquet lawn, bathed in
afternoon sunlight.
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ09
DDIR_SOUTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ11
E
painting paintings~
They are strange indeed, works of breathtaking precision depicting obviously
impossible motifs, like a sky filled with headless men, all dressed in some
black costume (including hats), or a lady standing, blue from the waist up, or
some pieces of plankwood that seems to be melting away like snow, or a night
sky with a dove-shaped hole of bright day sky in the middle.
~
S
#QQ11
The hallway~
You are in the north end of a connecting hallway, tastefully decorated with
oak paneling and the coat-of-arms of various famous nobles hung on the walls.
The hallway leads south, and there is a door in the eastern wall.
~
QQ ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ10
DDIR_EAST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ12
DDIR_SOUTH
~
~
0 -1 QQ13
S
#QQ12
The blue room~
You are in the blue room, one of the guest rooms in Archibald's mansion. The
walls are (surprise!) blue, and the rest of the room is decorated in similar
shades, producing a very nice, cool effect. There is a large bed and a
matching set of sofas, easy-chairs and a coffee table. Through the venetian
blinds in front of the large east window you can see the edge of the grove.
~
QQ ROOM_PRIVATE|ROOM_INDOORS SECT_INSIDE
DDIR_WEST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ11
S
#QQ13
The hallway~
You are standing in the south end of the hallway. There are doors in the
elegant oak-panelled walls to the south, east and west. Many different
coat-of-arms adorn the walls here.
~
QQ ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
~
~
0 -1 QQ11
DDIR_EAST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ14
DDIR_SOUTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ15
DDIR_WEST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ16
S
#QQ14
The red room~
You are in the red room, one of the guest rooms in Archibald's mansion. The
walls are wallpapered a deep warm red, and dark mahogany panelling nicely
complements them. There is a large, warm waterbed and a sofa group in dark
wood with leather upholstery, including a coffee table. Heavy brown
curtains are pulled away from the wide windows, to reveal a nice view
towards the grove.
~
QQ ROOM_PRIVATE|ROOM_INDOORS SECT_INSIDE
DDIR_WEST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ13
S
#QQ15
The kitchen~
You are standing in the middle of Archibald's kitchen. Contrary to popular
belief, He *doesn't* eat virgins, which is amply demonstrated by the large
variety of foodstuffs found here on the shelves. There are numerous cans of
tomatoes, peas, corn etc., vines of garlic, a *Huge* array of small spice
jars along several shelves and a large combo refrigerator/freezer. A big
oven and stove is lurking in a corner. There is some proof here that
Archibald is a less than meticulous housekeeper... There are doors to the
north and west.
~
QQ ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ13
DDIR_WEST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ18
S
#QQ16
The ballroom~
You are standing in the middle of a vast palisander floor. This is where
Archibald entertains large number of guests, but the cloth-covered chairs
standing forlornly in a corner suggests that this does not happen often.
There are doors in the south and west walls, while to the east there is a
short corridor to the greenhouse.
~
QQ ROOM_INDOORS SECT_INSIDE
DDIR_EAST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ13
DDIR_SOUTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ18
DDIR_WEST
~
~
0 -1 QQ17
S
#QQ17
The greenhouse~
This is Archibalds' greenhouse. Green light filters in slantwise through
the plants, giving the room a subtropical ambience. It is not really hot
in here, though, rather a pleasantly warm temperature. The walls are all
windows, except the eastern one joining the greenhouse to the main
building, but it is hard to see out for all the greenery here. There is a
set of easy-chairs and a glass coffee table. To the south, there is a wide
double door out to a sunlit terrace.
~
QQ ROOM_PRIVATE|ROOM_INDOORS SECT_INSIDE
DDIR_EAST
~
~
0 -1 QQ16
DDIR_SOUTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ19
S
#QQ18
The dining hall~
This is Archibalds' dining hall. There is a large long solid oak table,
seating at least 24, with heavy, wooden chairs to match. The oak panel walls
are filled with paintings. There are doors to the north and east, and to the
west there is a wide double door opening out onto the sunlit terrace.
~
QQ ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ16
DDIR_EAST
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ15
DDIR_WEST
~
wide door~
EX_ISDOOR|EX_CLOSED -1 QQ19
E
painting paintings~
There are many, many beautiful paintings of famous dragons of history and
literature. There is a big one of Smaug, a group picture of Cuspidorian Toxic
Dragons, a rather fearsome picture of Norse Chaos incarnate, a grainy black-
and-white photograph of Vorgulremik the Steel Dragon, a romantic picture of
Dalvenjah the Mindijaran and Allan the man become dragon. There are three
empty frames labeled 'The Chimerical', 'The Mythical' and 'The Hypothetical',
A panoramic picture of Strabo flying between the worlds dominate one wall,
while a dragons-eye view of Pern (with dragons in the foreground, of course)
fills another. There even are a few rare medieval renditions of the great
beast of the Revelation. Over the head of the table hangs a rather modest
portrait of a silver Dragon, sparkling with blue lightening, looking amused.
~
S
#QQ19
The terrace~
You are standing on a sunlit terrace in front of Archibald's mansion. To
the west, there is a splendid view over the field down over the lake. To
the north is the greenhouse, its large windowpanes shimmering with weird
and wonderful colors, while a double door leads into the house proper to
the east. It is warm and calm here. There is a white-painted table with a
parasol here, together with a matched set of chairs. You can see a
lovely garden to the south
~
QQ ROOM_NO_MOB|ROOM_INDOORS SECT_INSIDE
DDIR_NORTH
~
door~
EX_ISDOOR|EX_CLOSED -1 QQ17
DDIR_EAST
~
double door~
EX_ISDOOR|EX_CLOSED -1 QQ18
DDIR_SOUTH
Garden door
~
garden door~
EX_ISDOOR|EX_CLOSED -1 QQ00
DDIR_WEST
~
~
0 -1 QQ08
S
#QQ20
A smoothly paved pathway~
You stand long a well kept pathway. You can see many strange plants and
flowers to your east and west. Archibalds house is back to the north,
while the garden path continues southward.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ00
DDIR_EAST
~
~
0 -1 QQ22
DDIR_SOUTH
~
~
0 -1 QQ23
DDIR_WEST
~
~
0 -1 QQ21
S
#QQ21
A dark grove of trees~
Many small saplings grow in this portion of the garden. They seem quite
sickly however, as if infected by some arboric disease. You notice some
larger trees nearby, which seem to be suffering as well.
~
QQ 0 SECT_FOREST
DDIR_EAST
~
~
0 -1 QQ20
DDIR_SOUTH
~
~
0 -1 QQ24
DDIR_WEST
~
~
0 -1 QQ29
S
#QQ22
A room in the garden~
Many small saplings grow in this portion of the garden. They seem quite
sickly however, as if infected by some arboric disease. You notice some
larger trees nearby, which seem to be suffering as well.
~
QQ 0 SECT_FOREST
DDIR_EAST
~
~
0 -1 QQ39
DDIR_SOUTH
~
~
0 -1 QQ25
DDIR_WEST
~
~
0 -1 QQ20
S
#QQ23
North of the center of the garden~
You stand just north of a large fountain. Even from here you can feel the
refreshing spray of misty water as it gently touches your face. It is nice
and quiet and relaxing in this quiet garden.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ20
DDIR_EAST
~
~
0 -1 QQ25
DDIR_SOUTH
~
~
0 -1 QQ27
DDIR_WEST
~
~
0 -1 QQ24
S
#QQ24
Inside the garden~
This part of the garden is filled with many fragrant flowers of all types,
sizes, and colors. You can hear the buzzing of bees as they fly and
pollenate the blooms. The birds chirp and all is happy in this quiet
garden.
~
QQ 0 SECT_FIELD
DDIR_NORTH
~
~
0 -1 QQ21
DDIR_EAST
~
~
0 -1 QQ23
DDIR_SOUTH
~
~
0 -1 QQ26
DDIR_WEST
~
~
0 -1 QQ30
S
#QQ25
Inside the garden~
Many fresh and fragrant flowers grow in this section of the garden. A wide
variety of colors fill the entire area, as do a swarm of pollenating bees.
You hope you do not aggravate them enough that they attack.
~
QQ 0 SECT_FIELD
DDIR_NORTH
~
~
0 -1 QQ22
DDIR_EAST
~
~
0 -1 QQ38
DDIR_SOUTH
~
~
0 -1 QQ28
DDIR_WEST
~
~
0 -1 QQ23
S
#QQ26
West of the garden center~
You stand west of the garden fountain. Many weeds cover the floor here, as
if no one tends this section of the garden. You really feel like pulling
them out, as they are quite unsightly.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ24
DDIR_EAST
~
~
0 -1 QQ27
DDIR_SOUTH
~
~
0 -1 QQ33
DDIR_WEST
~
~
0 -1 QQ31
S
#QQ27
At the Center of the garden~
You stand within the center of this big garden. There is a lovely fountain
here which spews out crystal clear water.
~
QQ ROOM_SAFE|ROOM_NO_MOB SECT_INN
DDIR_NORTH
~
~
0 -1 QQ23
DDIR_EAST
~
~
0 -1 QQ28
DDIR_SOUTH
~
~
0 -1 QQ34
DDIR_WEST
~
~
0 -1 QQ26
S
#QQ28
One room east of the center of the garden~
You are now east of the center of this colorful garden. Unfortunately,
many weeds have sprouted up and ruin the beauty of this path. Perhaps you
could kill some.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ25
DDIR_EAST
~
~
0 -1 QQ37
DDIR_SOUTH
~
~
0 -1 QQ35
DDIR_WEST
~
~
0 -1 QQ27
S
#QQ29
A corner of the garden~
In this dark area of the garden, a few dark evil looking trees grow. They
seem to shake and move, as if they are trying to get you. Perhaps it is
just your imagination, or perhaps the trees really are alive.
~
QQ 0 SECT_FOREST
DDIR_EAST
~
~
0 -1 QQ21
DDIR_SOUTH
~
~
0 -1 QQ30
S
#QQ30
A dark grove of trees~
The trees here look very strange compared to other normal trees. These
look dark and evil, unlike the normal trees of the holy grove. They aren't
fully grown however, merely saplings.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ29
DDIR_EAST
~
~
0 -1 QQ24
DDIR_SOUTH
~
~
0 -1 QQ31
S
#QQ31
West end of the garden~
You come to the end of the garden. Many tall trees block any further
passage to the west. Looking around, all you see are weeds growing
everywhere.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ30
DDIR_EAST
~
~
0 -1 QQ26
DDIR_SOUTH
~
~
0 -1 QQ32
S
#QQ32
A dark grove of tress~
Many sickly baby trees grow here. They are void of leaves, which have long
since dropped off of them and onto the ground. The leafless branches look
quite eerie, and you can imagine them moving as they sway in the wind.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ31
DDIR_EAST
~
~
0 -1 QQ33
DDIR_SOUTH
~
~
0 -1 QQ40
S
#QQ33
Inside the garden~
Many flowers bloom here, but the weeds which grow here as well ruin the
natural beauty of the flower garden. You do notice a few bees flying
around drinking nectar from the blossoms.
~
QQ 0 SECT_FIELD
DDIR_NORTH
~
~
0 -1 QQ26
DDIR_EAST
~
~
0 -1 QQ34
DDIR_SOUTH
~
~
0 -1 QQ41
DDIR_WEST
~
~
0 -1 QQ32
S
#QQ34
Just south of the garden center~
You are now wandering south of the center of the garden. Many giant weeds
grow along the sides of the smooth walkway. You wonder if anyone even
tends this garden at all.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ27
DDIR_EAST
~
~
0 -1 QQ35
DDIR_SOUTH
~
~
0 -1 QQ42
DDIR_WEST
~
~
0 -1 QQ33
S
#QQ35
Inside the garden~
Many bright and colorful, as well as fragrant flowers grow in this spot of
the garden. However, many wild weeds grow here as well, ruining the other-
wise beatiful landscape.
~
QQ 0 SECT_FIELD
DDIR_NORTH
~
~
0 -1 QQ28
DDIR_EAST
~
~
0 -1 QQ36
DDIR_SOUTH
~
~
0 -1 QQ43
DDIR_WEST
~
~
0 -1 QQ34
S
#QQ36
A dark grove of trees~
The trees here look very strange compared to other normal trees. These
look dark and evil, unlike the normal trees of the holy grove. They aren't
fully grown however, merely saplings.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ37
DDIR_SOUTH
~
~
0 -1 QQ44
DDIR_WEST
~
~
0 -1 QQ35
S
#QQ37
Eastern end of the garden~
You have come to the eastern end of the garden. Many tall trees block any
further passage east. Many prickly weeds seem to have over grown this
area, as you doubt there is any gardener employed here.
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ38
DDIR_SOUTH
~
~
0 -1 QQ36
DDIR_WEST
~
~
0 -1 QQ28
S
#QQ38
A dark grove of trees~
Many sickly baby trees grow here. They are void of leaves, which have long
since dropped off of them and onto the ground. The leafless branches look
quite eerie, and you can imagine them moving as they sway in the wind.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ39
DDIR_SOUTH
~
~
0 -1 QQ37
DDIR_WEST
~
~
0 -1 QQ25
S
#QQ39
A corner of the garden~
In this dark area of the garden, a few dark evil looking trees grow. They
seem to shake and move, as if they are trying to get you. Perhaps it is
just your imagination, or perhaps the trees really are alive.
~
QQ 0 SECT_FOREST
DDIR_SOUTH
~
~
0 -1 QQ38
DDIR_WEST
~
~
0 -1 QQ22
S
#QQ40
A corner of the garden~
In this dark area of the garden, a few dark evil looking trees grow. They
seem to shake and move, as if they are trying to get you. Perhaps it is
just your imagination, or perhaps the trees really are alive.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ32
DDIR_EAST
~
~
0 -1 QQ41
S
#QQ41
A dark grove of trees~
The trees here look very strange compared to other normal trees. These
look dark and evil, unlike the normal trees of the holy grove. They aren't
fully grown however, merely saplings.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ33
DDIR_EAST
~
~
0 -1 QQ42
DDIR_WEST
~
~
0 -1 QQ40
S
#QQ42
Southern end of the Garden~
You stand at the southern most room of the garden. Here many weeds have
overgrown the walkwalk. You wonder where the gardener is, for who could
have grown such beatiful garden yet let weeds grow rampant like this?
~
QQ 0 SECT_CITY
DDIR_NORTH
~
~
0 -1 QQ34
DDIR_EAST
~
~
0 -1 QQ43
DDIR_WEST
~
~
0 -1 QQ41
S
#QQ43
A dark grove of trees~
The trees here look very strange compared to other normal trees. These
look dark and evil, unlike the normal trees of the holy grove. They aren't
fully grown however, merely saplings.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ35
DDIR_EAST
~
~
0 -1 QQ44
DDIR_WEST
~
~
0 -1 QQ42
S
#QQ44
A corner of the garden~
In this dark area of the garden, a few dark evil looking trees grow. They
seem to shake and move, as if they are trying to get you. Perhaps it is
just your imagination, or perhaps the trees really are alive.
~
QQ 0 SECT_FOREST
DDIR_NORTH
~
~
0 -1 QQ36
DDIR_WEST
~
~
0 -1 QQ43
S
#0
#SHOPS
0
#RESETS
O 0 QQ30 1 QQ00 ; Obelisk
M 0 QQ30 1 QQ00 ; Obelisk ethereal
G 1 QQ31 1 ; Kladblok
M 0 QQ00 1 QQ05 ; The Hierophant in The sacred glade
E 1 QQ10 99 WEAR_WIELD ; wooden staff
E 1 QQ11 99 WEAR_ABOUT ; brown robe
G 1 QQ19 99 ; pinkish herbs
G 1 QQ18 99 ; orangish herbs
M 0 QQ01 1 QQ01 ; The Hierophant in The holy grove
E 1 QQ10 99 WEAR_WIELD ; wooden staff
E 1 QQ11 99 WEAR_ABOUT ; brown robe
G 1 QQ13 99 ; bluish herbs
G 1 QQ15 99 ; blackish herbs
M 0 QQ02 1 QQ02 ; an elder druid in The holy grove
E 1 QQ10 99 WEAR_WIELD ; wooden staff
G 1 QQ14 99 ; purplish herbs
G 1 QQ16 99 ; grayish herbs
M 0 QQ03 1 QQ04 ; an elder druidess in The holy grove
E 1 QQ10 99 WEAR_WIELD ; wooden staff
G 1 QQ19 99 ; pinkish herbs
G 1 QQ17 99 ; reddish herbs
M 0 QQ04 2 QQ05 ; a doe in The sacred glade
M 0 QQ05 2 QQ06 ; a deer in The holy grove
M 0 QQ07 4 QQ03 ; a small bunny in A clearing in the woods
M 0 QQ09 1 QQ11 ; a druid in The hallway
G 1 QQ13 99 ; bluish herbs
M 0 QQ09 2 QQ18 ; a druid in The dining hall
M 0 QQ11 1 QQ16 ; Archibald in The ballroom
G 1 QQ16 99 ; grayish herbs
M 0 QQ10 1 QQ14 ; a druidess in The red room
G 1 QQ14 99 ; purplish herbs
M 0 QQ10 2 QQ17 ; a druidess in The greenhouse
M 0 QQ14 1 QQ44 ; a bloodroot tree in A corner of the garden
G 1 QQ19 100 ; pinkish herbs
M 0 QQ14 1 QQ44 ; a bloodroot tree in A corner of the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ14 1 QQ44 ; a bloodroot tree in A corner of the garden
G 1 QQ16 100 ; grayish herbs
M 0 QQ14 1 QQ44 ; a bloodroot tree in A corner of the garden
G 1 QQ17 100 ; reddish herbs
M 0 QQ13 1 QQ43 ; a bloodroot sapling in A dark grove of trees
G 1 QQ14 100 ; purplish herbs
M 0 QQ13 1 QQ43 ; a bloodroot sapling in A dark grove of trees
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ43 ; a bloodroot sapling in A dark grove of trees
G 1 QQ16 100 ; grayish herbs
M 0 QQ15 1 QQ42 ; an overgrown weed in Southern end of the Garde
M 0 QQ15 1 QQ42 ; an overgrown weed in Southern end of the Garde
M 0 QQ15 1 QQ42 ; an overgrown weed in Southern end of the Garde
M 0 QQ13 1 QQ41 ; a bloodroot sapling in A dark grove of trees
G 1 QQ17 100 ; reddish herbs
M 0 QQ13 1 QQ41 ; a bloodroot sapling in A dark grove of trees
G 1 QQ14 100 ; purplish herbs
M 0 QQ13 1 QQ41 ; a bloodroot sapling in A dark grove of trees
G 1 QQ13 100 ; bluish herbs
M 0 QQ14 1 QQ40 ; a bloodroot tree in A corner of the garden
G 1 QQ13 100 ; bluish herbs
M 0 QQ14 1 QQ40 ; a bloodroot tree in A corner of the garden
G 1 QQ14 100 ; purplish herbs
M 0 QQ14 1 QQ40 ; a bloodroot tree in A corner of the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ14 1 QQ40 ; a bloodroot tree in A corner of the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ14 1 QQ39 ; a bloodroot tree in A corner of the garden
G 1 QQ19 100 ; pinkish herbs
M 0 QQ14 1 QQ39 ; a bloodroot tree in A corner of the garden
G 1 QQ17 100 ; reddish herbs
M 0 QQ14 1 QQ39 ; a bloodroot tree in A corner of the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ14 1 QQ39 ; a bloodroot tree in A corner of the garden
G 1 QQ13 100 ; bluish herbs
M 0 QQ13 1 QQ38 ; a bloodroot sapling in A dark grove of trees
G 1 QQ15 100 ; blackish herbs
M 0 QQ13 1 QQ38 ; a bloodroot sapling in A dark grove of trees
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ38 ; a bloodroot sapling in A dark grove of trees
G 1 QQ17 100 ; reddish herbs
M 0 QQ15 1 QQ37 ; an overgrown weed in Eastern end of the garden
M 0 QQ15 1 QQ37 ; an overgrown weed in Eastern end of the garden
M 0 QQ15 1 QQ37 ; an overgrown weed in Eastern end of the garden
M 0 QQ13 1 QQ36 ; a bloodroot sapling in A dark grove of trees
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ36 ; a bloodroot sapling in A dark grove of trees
G 1 QQ16 100 ; grayish herbs
M 0 QQ13 1 QQ36 ; a bloodroot sapling in A dark grove of trees
G 1 QQ13 100 ; bluish herbs
M 0 QQ15 1 QQ35 ; an overgrown weed in Inside the garden
M 0 QQ15 1 QQ35 ; an overgrown weed in Inside the garden
M 0 QQ16 1 QQ35 ; a honey bee in Inside the garden
M 0 QQ15 1 QQ34 ; an overgrown weed in Just south of the garden
M 0 QQ15 1 QQ34 ; an overgrown weed in Just south of the garden
M 0 QQ15 1 QQ34 ; an overgrown weed in Just south of the garden
M 0 QQ15 1 QQ33 ; an overgrown weed in Inside the garden
M 0 QQ15 1 QQ33 ; an overgrown weed in Inside the garden
M 0 QQ16 1 QQ33 ; a honey bee in Inside the garden
M 0 QQ13 1 QQ32 ; a bloodroot sapling in A dark grove of tress
G 1 QQ13 100 ; bluish herbs
M 0 QQ13 1 QQ32 ; a bloodroot sapling in A dark grove of tress
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ32 ; a bloodroot sapling in A dark grove of tress
G 1 QQ14 100 ; purplish herbs
M 0 QQ15 1 QQ31 ; an overgrown weed in West end of the garden
M 0 QQ15 1 QQ31 ; an overgrown weed in West end of the garden
M 0 QQ15 1 QQ31 ; an overgrown weed in West end of the garden
M 0 QQ13 1 QQ30 ; a bloodroot sapling in A dark grove of trees
G 1 QQ14 100 ; purplish herbs
M 0 QQ13 1 QQ30 ; a bloodroot sapling in A dark grove of trees
G 1 QQ19 100 ; pinkish herbs
M 0 QQ13 1 QQ30 ; a bloodroot sapling in A dark grove of trees
G 1 QQ15 100 ; blackish herbs
M 0 QQ14 1 QQ29 ; a bloodroot tree in A corner of the garden
G 1 QQ19 100 ; pinkish herbs
M 0 QQ14 1 QQ29 ; a bloodroot tree in A corner of the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ14 1 QQ29 ; a bloodroot tree in A corner of the garden
G 1 QQ14 100 ; purplish herbs
M 0 QQ14 1 QQ29 ; a bloodroot tree in A corner of the garden
G 1 QQ13 100 ; bluish herbs
M 0 QQ15 1 QQ28 ; an overgrown weed in One room east of the cent
M 0 QQ15 1 QQ28 ; an overgrown weed in One room east of the cent
M 0 QQ15 1 QQ28 ; an overgrown weed in One room east of the cent
M 0 QQ17 1 QQ27 ; fountain in At the Center of the gard
M 0 QQ15 1 QQ26 ; an overgrown weed in West of the garden center
M 0 QQ15 1 QQ26 ; an overgrown weed in West of the garden center
M 0 QQ15 1 QQ26 ; an overgrown weed in West of the garden center
M 0 QQ16 1 QQ25 ; a honey bee in Inside the garden
M 0 QQ15 1 QQ25 ; an overgrown weed in Inside the garden
M 0 QQ15 1 QQ25 ; an overgrown weed in Inside the garden
M 0 QQ15 1 QQ24 ; an overgrown weed in Inside the garden
M 0 QQ15 1 QQ24 ; an overgrown weed in Inside the garden
M 0 QQ16 1 QQ24 ; a honey bee in Inside the garden
M 0 QQ13 1 QQ22 ; a bloodroot sapling in A room in the garden
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ22 ; a bloodroot sapling in A room in the garden
G 1 QQ16 100 ; grayish herbs
M 0 QQ13 1 QQ22 ; a bloodroot sapling in A room in the garden
G 1 QQ14 100 ; purplish herbs
M 0 QQ13 1 QQ21 ; a bloodroot sapling in A dark grove of trees
G 1 QQ18 100 ; orangish herbs
M 0 QQ13 1 QQ21 ; a bloodroot sapling in A dark grove of trees
G 1 QQ15 100 ; blackish herbs
M 0 QQ13 1 QQ21 ; a bloodroot sapling in A dark grove of trees
G 1 QQ19 100 ; pinkish herbs
O 0 QQ01 2 QQ12 ; a closet in The blue room
O 0 QQ01 2 QQ14 ; a closet in The red room
O 0 QQ02 2 QQ15 ; a spice jar in The kitchen
P 1 QQ03 1 QQ02 ; black powder in a spice jar
P 1 QQ04 1 QQ02 ; small yellow kernels in a spice jar
O 0 QQ02 2 QQ15 ; a spice jar in The kitchen
O 0 QQ05 1 QQ15 ; a crumpled wad of paper in The kitchen
O 0 QQ27 1 QQ27 ; a garden fountain in At the Center of the gard
O 0 QQ20 1 QQ42 ; a holly bush in Southern end of the Garde
P 1 QQ23 5 QQ20 ; a small piece of holly in a holly bush
O 0 QQ21 1 QQ37 ; a patch of ivy in Eastern end of the garden
P 1 QQ22 5 QQ21 ; some ivy in a patch of ivy
D 0 QQ14 DIR_WEST DOOR_CLOSED ; door in The red room
D 0 QQ13 DIR_EAST DOOR_CLOSED ; door in The hallway
D 0 QQ12 DIR_WEST DOOR_CLOSED ; door in The blue room
D 0 QQ11 DIR_EAST DOOR_CLOSED ; door in The hallway
D 0 QQ11 DIR_NORTH DOOR_CLOSED ; door in The hallway
D 0 QQ10 DIR_SOUTH DOOR_CLOSED ; door in The foyer
D 0 QQ10 DIR_NORTH DOOR_CLOSED ; door in The foyer
D 0 QQ09 DIR_SOUTH DOOR_CLOSED ; door in The croquet lawn
D 0 QQ13 DIR_SOUTH DOOR_CLOSED ; door in The hallway
D 0 QQ15 DIR_NORTH DOOR_CLOSED ; door in The kitchen
D 0 QQ13 DIR_WEST DOOR_CLOSED ; door in The hallway
D 0 QQ16 DIR_EAST DOOR_CLOSED ; door in The ballroom
D 0 QQ18 DIR_NORTH DOOR_CLOSED ; door in The dining hall
D 0 QQ16 DIR_SOUTH DOOR_CLOSED ; door in The ballroom
D 0 QQ18 DIR_EAST DOOR_CLOSED ; door in The dining hall
D 0 QQ15 DIR_WEST DOOR_CLOSED ; door in The kitchen
D 0 QQ18 DIR_WEST DOOR_CLOSED ; door in The dining hall
D 0 QQ19 DIR_EAST DOOR_CLOSED ; door in The terrace
D 0 QQ17 DIR_SOUTH DOOR_CLOSED ; door in The greenhouse
D 0 QQ19 DIR_NORTH DOOR_CLOSED ; door in The terrace
D 0 QQ19 DIR_SOUTH DOOR_CLOSED ; door in The terrace
D 0 QQ00 DIR_NORTH DOOR_CLOSED ; door in The entrance to a large l
S
#$