Storms of Times
_________
__ __,----' `-----.__
__ \\/====-____ ___,-' `
\\ _/_/_/ /||\\ `---.____/
______---\ _- / \/ ||| \\ _,'`
__,--' ,--'||\-_ /,--_/--.|- |`\. \\ ,'
_,' ,-' | \\`. ` */ /==/- / || `\. /
.' ,' | \\ \_** /==/- / || \ /
/ _____ / __ | \\**-_/==/|- _/ ,// \ /
,-' `-|--' `--_ \ ***-/===| \-_-===-' _ _/`
`-| **** *|====| \_ __,-- '
.. '* *** *|====| \_ _, /\
... *** * \=====\__ \/ \__ _
... ***-' _/'\=,-' ____-'`-_ `== \
() *. ()| ** //--\ ///--\`._ `- _\ \
#_/ /#_| () / \=======\ `----.________,--- __/
# / # /#_/ __--======`) \-._______________,---
### / \ / # | //,--' `==--___ |-------'
##### / / / \ O##<_ //,-- -\
/ / \
Emud ver 2.3 (Updated by Scandum - December 2002)
==============================================================================
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 the Emud configuration.
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.
emud.txt
the latest set of values used by Emud. 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.
holygrove.are
An example area, with mobile programs.
Don't be afraid to create, Scandum, the Dude of Fire
==============================================================================
Emud now uses OLC which I believe to be 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 list 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 imp 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. 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~
*** 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.
#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.
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>
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>
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
DDIR_NORTH
You spot the Second Room to the north, behind a large steel grate.~
grate steel~
1 QQ00 QQ01
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
The first number is the zone number of this room; what zone should
the mud consider this room to be in for game purposes. Please see
'zone numbers' in section 3 of this handbook.
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, emud 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.
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
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.
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.
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_DARK 1
ROOM_SMOKE 2
ROOM_NO_MOB 4 wandering mobiles can't enter the room
ROOM_INDOORS 8
ROOM_NO_GOHOME 32
ROOM_BANK 256
ROOM_PRIVATE 512 only two players at a time
ROOM_SAFE 1024
ROOM_SOLITARY 2048 only one player at a time
ROOM_PET_SHOP 4096 place to buy pets
ROOM_NO_RECALL 8192
ROOM_BLOCK 32768 room blocked from entrance
ROOM_NO_SAVE 65536
ROOM_MORGUE 131072 in this room are PC corpses sold
ROOM_ALTAR_N 1572864 able to set death room
ROOM_ALLOW_WAR 2097152
ROOM_ALLOW_GLA 4194304
ROOM_ALLOW_MAR 6291456
ROOM_ALLOW_NIN 8388608
ROOM_ALLOW_DRU 10485760
ROOM_ALLOW_SOR 12582912
ROOM_ALLOW_SHA 14680064
ROOM_NOTE_BOARD 134217728
ROOM_NO_CASTLE 268435456
ROOM_NO_RIP 536870912
ROOM_ALLOW_WLC 1073741824
These are complete for Emud v2.2.
*** SECTOR TYPES
The 'sector type' of a room controls how many movement points it costs to
enter that room. This is not a flag type item: choose one, and use the
value...
SECT_INSIDE 0
SECT_CITY 1
SECT_FIELD 2 (allows castles to be build)
SECT_FOREST 3 (allows castles to be build)
SECT_HILLS 4 (allows castles to be build)
SECT_MOUNTAIN 5 (allows castles to be build)
SECT_WATER_SWIM 6
SECT_WATER_NOSWIM 7 (Requires a boat)
SECT_UNUSED 8
SECT_AIR 9 (Requires fly spell)
SECT_DESERT 10
SECT_LAVA 11 (Requires Fire breath spell)
SECT_INN 12 (Heals the player while not on the game)
SECT_ETHEREAL 13 (Requires Ethereal Travel spell)
SECT_ASTRAL 14 (Requires Astral Projection spell)
SECT_UNDERWATER 15 (Requires Breath water spell)
SECT_LEY_LINES 16 (Something undefined...)
*** 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
emud. 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 vague description of what the next room
might be, 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.
The door type can be the following values:
0 Standard hallway without door
EX_ISDOOR 1
EX_CLOSED 2
EX_LOCKED 4 Does not necessarily require a key */
EX_HIDDEN 8 cannot be seen without detect hidden
EX_PICKPROOF 32 only greater pick will open door
EX_BASHPROOF 64 cannot be bashed open
EX_MAGIC_PROOF 128 cannot be dissolved with unbarring ways
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.
Please note that adding a description for the door itself is usually done
under the 'extra descriptions' part of the room db.
*** 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. Flying does not affect any aspect of the
non-air types of sectors, with the assumption that.. dunno..
it's a weird world we mud in :)
The Marauder class has the climb ability that greatly increases the chance
of safety for players in a cliff modified room. The only other modifier is
dexterity. The longer a player stays on a cliff, the higher the likelyhood
that they will fall. The slope of a cliff is defined as 0 for a slight
incline, to 10 for a vertical cliff face. This number is ignored for
SECT_AIR. 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 emud 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>~
<actions>
<affects>
<alignment> S
<level> <body part> <attack part> <hitpoints ?d?+?> <damage ?d?+?>
<gold> <race>
<loaded position> <default position> <sex>
[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.
~
131072|194|65536 8 100 S
1 4 16|8 1d6+2 1d4+0
10 2
7 7 0
---example precedes this line---
The following is the same example with the ascii version of the flags.
---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.
~
ACT_RACE|ACT_WIMPY|ACT_SCAVENGER|ACT_BODY
AFF_DETECT_INVIS 100 S
1 BODY_EYE BODY_TORSO|BODY_HIP 1d6+2 1d4+0
10 RACE_ELF
POS_STANDING POS_STANDING SEX_NEUTRAL
---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.
194 8 100 S
The first number is the ACTION flag of the mob, which tell the mud how the
mob should act.
The second number is the AFFECTION 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 & AFFECTION FLAGS' below for more on both of these.
The third number is the alignment of the mob, ranging from 1000 (good) to
-1000 (evil).
The 'S' stands for simple mob. This feature is not used in Emud,
and is left there as a placeholder. Always use an 'S' here.
This feature is used for backward compatibility.
1 20 10 1d6+2 1d4+0
Field one is the mob's level.
The second field is the body parts that can fall off when the mob dies.
The third field is the body parts that attack.
Field four is the mobs hit points. There is more on Hitpoints and damage
below in the aptly named 'HITPOINTS and DAMAGE'.
The fifth field is how much damage a mob does with its bare hands.
10 2
The first number is how much gold pieces this mob is carrying.
The second field was used for exp on DIKU and Merc games, we ignore
exp in files, and allow this field to define the race of the mobile
if the action flags include ACT_RACE.
7 7 0
The first and second number are the mob's loading and default position,
respectively. There is a section below: 'POSITIONS' that will explain
more.
The final number is the mob's gender; 0 is neuter, 1 is male, 2 is female.
*** 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_SENTINEL 2 Stays in one room
ACT_SCAVENGER 4 Picks up objects
ACT_DRUNK 8 Talks drunk
ACT_AGGRESSIVE 32 Attacks PC's
ACT_WIMPY 128 Flees when hurt
ACT_TRAIN 512 Can train PC's
ACT_PRACTICE 1024 Can practice PC's
ACT_WEAK 2048 Cannot carry anything
ACT_SMART 4096 Can say, normal can't
ACT_ONE_FIGHT 8192 Disapears after fight.
ACT_NO_ORDER 16384 Cannot be ordered.
ACT_BODY 65536 Allows body parts to function.
ACT_RACE 131072 Allows race to be defined.
ACT_UNDEAD 262144 Does not create corpse on death.
Affection 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 Emud. It should always be an 'S'. Originally it was to
select Simple or Complex mobiles in Diku muds. It is here to support
backward compatibility.
*** BODY PARTS
This field was used by Thac0 on Merc and Diku muds, but is ignored
on Emud. Therefore it can be used by a different value. But you must
give a flag to tell Emud 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.
We advise selecting one or two body parts on all mobiles.
Body parts are the parts that can be chopped off when the mobile dies.
They will not show up elsewhere except in attack parts. Body parts
might give a slightly different version than attack parts, as in
BODY_MOUTH, which is a jaw bone in body parts, and a bite in attack
parts. Any combination of body parts may be used, and it does not
necessarily have to match the attack parts. Only one is selected when
the body part is chopped off with a 25% chance that the body part will
even fall off. It is not suggested to select two arms, as this will
cause an error, only one is required.
Below are the flags and spams for body parts listed.
BODY_HEAD $n's head slowly falls off.
BODY_MOUTH $n's jaw drops to the floor.
BODY_EYE $n's eyeball pops out.
BODY_TORSO $n is broken into pieces.
BODY_HIP $n falls to pieces.
BODY_LEG $n kicks $s leg off.
BODY_ARM $n's arm seems to have been unattached.
BODY_WING $n is flying nowhere.
BODY_TAIL $n can no longer wag $s tail.
BODY_TENTICLE $n's tenticle gushes bloody.
BODY_HORN $n's horn bumps you as it falls to the floor.
BODY_CLAW The claw of $n gets clipped.
BODY_HAND $n gives you the finger, right before losing $s hand.
BODY_FOOT $n stumbles, as $s foot falls off.
*** ATTACK PARTS
This field was originally AC on Diku and Merc muds. This field is
normally ignored on Emud, 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.
Note: AC, or Armor Class is computed by the game itself, and is
dependant on the level of the mobile. If the mobile is should
normally be wearing armor, the armor will add 2/3 of it's normal
AC bonus. If the mobile is not weaing armor, and is normally
supposed to be wearing armor, then the AC of the mobile is
1/3 of the value of the armor less than the normal AC for a
mobile of the same level.
Below are the flags and spams for attack parts listed.
BODY_HEAD head butt
BODY_MOUTH bite
BODY_EYE evil-eye
BODY_TORSO shoulder slam
BODY_HIP hip slam
BODY_LEG knee
BODY_ARM elbow slam
BODY_WING flap
BODY_TAIL tail slap
BODY_TENTICLE tenticle whip
BODY_HORN horn jab
BODY_CLAW claw
BODY_HAND punch
BODY_FOOT 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 mobile will do it's basic damage plus one-half
of the damage of the weapon wielded.
Standards and Measures
These are the suggested strengths of mobs.
level 60 mobs or lower :
minimum hitpoints : 10 + level * level * 0.5
maximum hitpoints : 20 + level * level * 1.5
minimum damage : 2 + level * 0.5
maximum damage : 5 + level * 3.0
level 61 mobs and higher :
minimum hitpoints : level * level * 0.7
maximum hitpoints : level * level * 1.5
minimum damage : level * 0.7
maximum damage : level * 3.00
These values are checked with the areacheck tool by the emud admins.
*** 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
This field was previously used for exp for the mobile, but Emud calculates
exp based on the level of the mobile. This leaves the field open for more
important things: 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 will also
allow mobprogs to be used based on race. You must pick a race which is one
of the basic 29, even if the mobile should be something outside of those
defined. Just pick the closest one.
*** POSITION
A mob always has two position numbers: its loading position,
and its default position. A mob will be loaded into its loading
position initially, and after fighting, will return to its default
position. Note that these do not have to be the same, but usually
are.
The valid positions are:
POS_SLEEPING 4
POS_RESTING 5
POS_FIGHTING 6
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 Barbarian 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.
~
5
64|16384 8193
0 3 1 10
5 1000 10
E
example~
This is a rather boring example.
~
A 1 1
C
slash~
1
---example precedes this line---
The following is the same object using the ascii flags system:
---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
ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL
ITEM_WEAR_WIELD|ITEM_WEAR_WIELD
0 3 1 10
5 1000 10
E
example~
This is a rather boring example.
~
A APPLY_STR 1
C
slash~
FLAG_CLASS_WARRIOR
---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 Emud, 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
5
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_TREASURE 8
ITEM_TYPE_ARMOR 9
ITEM_TYPE_POTION 10
ITEM_TYPE_FURNITURE 12
ITEM_TYPE_TRASH 13
ITEM_TYPE_CONTAINER 15
ITEM_TYPE_DRINK_CON 17
ITEM_TYPE_KEY 18
ITEM_TYPE_FOOD 19
ITEM_TYPE_MONEY 20
ITEM_TYPE_BOAT 22
ITEM_TYPE_FOUNTAIN 25
ITEM_TYPE_PILL 26
ITEM_TYPE_AMMO 30
*** Object Flags
64|16384
This determines what is affecting the object. Also note the
ITEM_FLAG_LEVEL is required on Emud. This is a flag that lets
the field of the level work. If this flag is not set, the level
field is ignored, and item level might be calculated incorrect.
*** OBJECT FLAGS
ITEM_FLAG_GLOW 1
ITEM_FLAG_HUM 2
ITEM_FLAG_DARK 4
ITEM_FLAG_LOCK 8
ITEM_FLAG_EVIL 16
ITEM_FLAG_INVIS 32
ITEM_FLAG_MAGIC 64 /* Auto set if any affects exist */
ITEM_FLAG_NODROP 128
ITEM_FLAG_ANTI_GOOD 512
ITEM_FLAG_ANTI_EVIL 1024
ITEM_FLAG_ANTI_NEUTRAL 2048
ITEM_FLAG_NOREMOVE 4096
ITEM_FLAG_INVENTORY 8192
ITEM_FLAG_LEVEL 16384 /* Absolutely required on Emud */
ITEM_FLAG_AUTO_ENGRAVE 65536 /* This item is engraved to first to get */
*** Wear Flags
8193
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
ITEM_WEAR_TAKE 1 /* Required for the player to get object */
ITEM_WEAR_FINGER 2
ITEM_WEAR_NECK 4
ITEM_WEAR_BODY 8
ITEM_WEAR_HEAD 16
ITEM_WEAR_LEGS 32
ITEM_WEAR_FEET 64
ITEM_WEAR_HANDS 128
ITEM_WEAR_ARMS 256
ITEM_WEAR_SHIELD 512
ITEM_WEAR_ABOUT 1024
ITEM_WEAR_WAIST 2048
ITEM_WEAR_WRIST 4096
ITEM_WEAR_WIELD 8192
ITEM_WEAR_HOLD 16384
*** Object Values
0 3 1 10
These are the object's values. What each number means is completely
dependant on what Type of object it is.
*** OBJECT VALUES
The four numbers consisting of the 'item values' are different
for each type of item. Below the meanings of these numbers are broken
down by each type. Zeroes refer to fields not used, while letters are
explained for each section...
please note this is basically lifted verbatim from the dikudocs.
Credits to the original authors, and no disrespect intended.
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]: Which spell
Value[3]: Which spell
The values(1-3) are three (or less) different spells, mixed 'on'
the scroll. Unused spells should be set to -1.
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)
ITEM_WEAPON (5)
Value[0]: Type of ammo shot by the weapon (0 if not a range weapon)
Value[1]: Number of dice to roll for damage (keep this number low)
Value[2]: Size of dice to roll for damage
Value[3]: The weapon type. Type is one of:
NAME NUMBER CATEGORY Message type
--------------------------------------------------------------------
WEAPON_SLICE 1 : Slice Slice
WEAPON_STAB 2 : Stab Stab (throw, backstab)
WEAPON_SLASH 3 : Slash Slash
WEAPON_WHIP 4 : Whip Whip
WEAPON_CLAW 5 : Claw Claw
WEAPON_BLAST 6 : Blast Blast
WEAPON_POUND 7 : Pound Pound (throw)
WEAPON_CRUSH 8 : Crush Crush (throw)
WEAPON_GREP 9 : Grep Grep
WEAPON_BITE 10 : Bite Bite
WEAPON_PIERCE 11 : Pierce Pierce (throw, backstab)
To make a ranged weapon, you must also create ammo for it.
A ranged weapon is defined by including the vnum of the ammo
in Value[0] of the weapon. If a '0' is used here, it is not
a shooting weapon.
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)
Value[2]: Which spell
Value[3]: Which spell
Unused spells should be set to -1.
Eg.
Value 0 : 30 (Level)
Value 1 : 27 (Harm)
Value 2 : 17 (Curse)
Value 3 : -1 (no-spell)
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:
CONT_CLOSEABLE 1
CONT_PICKPROOF 2
CONT_CLOSED 4
CONT_LOCKED 8
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
ITEM_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 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_WARRIOR
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 warriors.
List of flags of classes
FLAG_CLASS_WARRIOR 1
FLAG_CLASS_GLADIATOR 2
FLAG_CLASS_MARAUDER 4
FLAG_CLASS_NINJA 8
FLAG_CLASS_DRUID 16
FLAG_CLASS_SORCERER 32
FLAG_CLASS_SHAMAN 64
FLAG_CLASS_WARLOCK 128
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_WARRIOR - The amount of war levels
OIF_MCLASS_GLADIATOR - The amount of Gla levels
OIF_MCLASS_MARAUDER - The amount of Mar levels
OIF_MCLASS_NINJA - The amount of nin levels
OIF_MCLASS_DRUID - The amount of dru levels
OIF_MCLASS_SORCERER - The amount of sor levels
OIF_MCLASS_SHAMAN - The amount of sha levels
OIF_MCLASS_WARLOCK - 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 ITEM_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. 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.
*** speech_prog <ARGUMENT>
The argument is the same as for an act_prog. This works best when only
one word is used as the argument, as several can cause the mob_prog to
trigger several times in a row.
Example
>speech_prog the dog~
The previous example is faulty, because it would trigger twice if the
player said the words 'the' and 'dog' in the same sentence.
Correct 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.
The PC restriction is not necessary, but makes infinite loops between
two talking mobiles impossible. It also makes it impossible for two
NPC's to stand and discuss the weather however.
*** rand_prog <NUMBER>
The argument is a number betweeen 1 and 100 inclusive.
This trigger is checked at each PULSE_MOBILE and if the argument is
greater than a percentage roll the trigger is activated. This
will happen even if there is no PC in the room with the mob.
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.
*** fight_prog <NUMBER>
The argument is a percentage like in rand_prog.
Useful for giving mobiles combat attitude. It is checked every
PULSE_VIOLENCE when the mobile is fighting. Can be used to cast
spells, curse at the opponent, or whatever. Only the first successful
one will be processed to save time. Also, this means that the
mobile wont get lucky and 1. curse, cast a fireball and 2. spit on the
player, cast another fireball in the same pulse.
*** hitprcnt_prog <NUMBER>
The argument is a percentage.
Is activated at each PULSE_VIOLENCE when the mobile is fighting. It
checks to see if the hitpoints of the mobile are below the given
percentage. Multiple hitprcnt_progs should be listed in increasing
order of percent since a 40% will always be activated before a 20%
and, only the first successful hitprcnt trigger is performed.
*** greet_prog <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.
*** all_greet_prog <NUMBER>
Again a percentage argument.
Like greet_prog, but it can be triggered even if the mobile didnt
see the arrival (stealth, invis). Most useful for faking teleport
rooms (if your mobiles can transfer) or for impassable guardians.
Neither greet_prog is activated if the mobile is fighting.
Do aknowledge that a mobile with detect_invis and detect_hidden
will always trigger with a normal greet_prog. Unless it has been
blinded. It is advised to use greet_prog to simulate more natural
behavior, and use the all_greet_prog for mobiles without detection
who still need to trigger. Or for ethereal mobs who don't need
detects for the kind of greet program you have in mind.
*** 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.
*** give_prog <ARGUMENT>
This command should always be used with the 'I' format for item vnums.
Example
A scroll of recall is vnum 9720, so use 'I9720' for the argument.
>give_prog I9720~
This is triggered whenever something is given to the mobile. Best used
for quests.
*** 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.
If money is given to a mobile with this trigger type, instead of the
cash being added to mob->gold, the mobile is instead given a pile of
coins in the proper amount. In this way, the mobile can drop the coins
or refer to the pile of gold by I3 (item vnum is 3). And use $O to print
the short description: "%d gold coins".
*** 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 your 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 rand (number) Is rand percentage less or equal to number
if isnpc ($*) Hardly used since most triggers only work
if ispc ($*) on players
if isgood ($*)
if isevil ($*)
if isneutral ($*)
if iskiller ($*)
if isthief ($*)
if isfight ($*) Is $* fighting
if isfollow ($*) Is $* a follower with master in same room
if hitprcnt ($*) == percent Checks percentage of hitpoints left
if inroom ($*) == vnum
if isaffected ($*) == bitvector
if sex ($*) == bitvector
if position ($*) == bitvector
if class ($*) == bitvector
if race ($*) == bitvector
if whichgod ($*) == bitvector
if level ($*) == integer
if goldamt ($*) == integer
if objtype ($*) == bitvector
if objval0 ($*) == integer
if objval1 ($*) == integer
if objval2 ($*) == integer
if objval3 ($*) == integer
if number ($*) == integer Is the vnum of $* equal to integer
if name ($*) == string
if time () == integer
if shotfrom ($i) == string Used for range_prog
if objtype ($*) == bitvector
if objval0 ($*) == integer
if objval1 ($*) == integer
if objval2 ($*) == integer
if objval3 ($*) == integer
if number ($*) == integer Is the vnum of $* equal to integer
if hasobj (name) sets $c and $C variable
if hasobjnum (vNum) sets $c and $C variable
if actorhasobjnum (vNum) sets $c and $C variable
if actorwearsobjnum (vNum) sets $c and $C variable
if quest (B,N,$*) == integer B = Offset, N = Numbits, R = Room vnum
if questr (R,B,N,$*) == integer
if objquest (B,N,$*) == integer
if pcsinarea ([vnum]) == integer
if pcsinroom () == integer
if existsroom (name) searches for matching object or mob
if existsarea (name)
if existsworld (name)
------------------------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:
*** 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.
*** 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.
*** 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.
*** 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.
*** 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.
*** MPMSET <victim> <field> <argument>
*** MPMSET <victim> <string> <argument>
Field being one of:
level gold align thirst drunk full exp quest questr randquest randquestr
String being one of:
name short long title
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 make a diguise for a player, change the string of LONG to what you want
to disguise the player as. To return the player to it's normal state, use
the value of NULL.
Example:
mpmset $n long There is a small boy here.
(disguise the player as a small boy)
mpmset $n long null
(returns the player to normal)
*** MPMADD <victim> <field> <argument>
Field being one of:
level gold align thirst drunk full exp currhp currmana currmove
hp mana move quest questr
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>
Field being one of:
value0 value1 value2 value3 extra setextra clrextra wear level weight
cost timer quest randquest
String being one of:
name short long ed
quest and randquest have additional parameters:
mposet <object> quest <firstBit> <numBits> <newValue>
mposet <object> randquest <firstBit> <numBits>
*** MPOADD <object> <field> <argument>
Field being one of:
value0 value1 value2 value3 level weight cost timer quest
quest has additional parameters:
mpoadd <object> quest <firstBit> <numBits> <value>
*** MPASET <object> <field> <argument>
Field being one of:
str dex int wis con mana hp move ac damroll hitroll
para rod petri breath spell
This command allows you to permanently add affects to objects.
*** 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 -- -- --
him/her/it $l $m $M $L -- -- --
his/hers/its $k $s $S $K -- -- --
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: "emud.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_ONE_FIGHT
===============================================================================
Mobile Affects
AFF_DETECT_HIDDEN AFF_ETHEREAL AFF_UNDERSTAND
AFF_DETECT_INVIS AFF_INVISIBLE AFF_TONGUES
AFF_PROTECT_EVIL 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 AFF_CLEAR
===============================================================================
Mobile Genders
SEX_NEUTRAL SEX_MALE SEX_FEMALE
===============================================================================
Body Parts
BODY_HEAD BODY_LEG BODY_HORN
BODY_MOUTH BODY_ARM BODY_CLAW
BODY_EYE BODY_WING BODY_HAND
BODY_TORSO BODY_TAIL BODY_FOOT
BODY_HIP 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
ITEM_FLAG_HUM ITEM_FLAG_BLESS ITEM_FLAG_INVENTORY
ITEM_FLAG_EVIL ITEM_FLAG_ANTI_NEUTRAL ITEM_FLAG_LEVEL
ITEM_FLAG_INVIS ITEM_FLAG_ANTI_GOOD ITEM_FLAG_AUTO_ENGRAVE
ITEM_FLAG_MAGIC ITEM_FLAG_ANTI_EVIL ITEM_FLAG_GLOW
ITEM_FLAG_NODROP ITEM_FLAG_NOREMOVE
===============================================================================
Wear Locations
ITEM_WEAR_TAKE ITEM_WEAR_LEGS ITEM_WEAR_ABOUT
ITEM_WEAR_FINGER ITEM_WEAR_FEET ITEM_WEAR_WAIST
ITEM_WEAR_NECK ITEM_WEAR_HANDS ITEM_WEAR_WRIST
ITEM_WEAR_BODY ITEM_WEAR_ARMS ITEM_WEAR_WIELD
ITEM_WEAR_HEAD ITEM_WEAR_SHIELD ITEM_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 APPLY_SAVING_BREATH
APPLY_CON APPLY_HITROLL APPLY_SAVING_SPELL
APPLY_SEX APPLY_DAMROLL
===============================================================================
Object Classes
FLAG_CLASS_WARRIOR FLAG_CLASS_NINJA FLAG_CLASS_SHAMAN
FLAG_CLASS_GLADIATOR FLAG_CLASS_DRUID FLAG_CLASS_WARLOCK
FLAG_CLASS_MARAUDER FLAG_CLASS_SORCERER
===============================================================================
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_SMOKE ROOM_SOLITARY ROOM_NO_GOHOME
ROOM_INDOORS ROOM_ALLOW_WAR ROOM_NO_RECALL
ROOM_SAFE ROOM_ALLOW_GLA ROOM_NO_SAVE
ROOM_BANK ROOM_ALLOW_MAR ROOM_NO_CASTLE
ROOM_PET_SHOP ROOM_ALLOW_NIN ROOM_NO_RIP
ROOM_MORGUE ROOM_ALLOW_DRU
ROOM_ALTAR_N ROOM_ALLOW_SOR
ROOM_NOTE_BOARD ROOM_ALLOW_SHA
ROOM_BLOCK ROOM_ALLOW_WLC
===============================================================================
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_WARRIOR CLASS_NINJA CLASS_WARLOCK
CLASS_GLADIATOR CLASS_DRUID
CLASS_MARAUDER CLASS_SORCERER
===============================================================================
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: "spells.txt"
SPELL_NONE
SPELL_ACID_BLAST
SPELL_ACID_BREATH
SPELL_ANIMATE_DEAD
SPELL_ANTI_MAGIC_SHELL
SPELL_ARMOR
SPELL_ASTRAL_PROJECTION
SPELL_BANISH
SPELL_BENEDICTION
SPELL_BLESS
SPELL_BLINDNESS
SPELL_BLOCK_AREA
SPELL_BREATH_WATER
SPELL_BREW_POTION
SPELL_BURNING_HANDS
SPELL_CALL_LIGHTNING
SPELL_CAUSE_CRITICAL
SPELL_CAUSE_LIGHT
SPELL_CAUSE_SERIOUS
SPELL_CHANGE_SEX
SPELL_CHARM_PERSON
SPELL_CHILL_TOUCH
SPELL_COLOUR_SPRAY
SPELL_CONFUSION
SPELL_CONTINUAL_LIGHT
SPELL_CONTROL_WEATHER
SPELL_CREATE_FOOD
SPELL_CREATE_SPRING
SPELL_CREATE_WATER
SPELL_CURE_BLINDNESS
SPELL_CURE_CRITICAL
SPELL_CURE_LIGHT
SPELL_CURE_POISON
SPELL_CURE_SERIOUS
SPELL_CURSE
SPELL_DEMON
SPELL_DETECT_EVIL
SPELL_DETECT_HIDDEN
SPELL_DETECT_INVIS
SPELL_DETECT_MAGIC
SPELL_DETECT_POISON
SPELL_DISPEL_EVIL
SPELL_DISPEL_GOOD
SPELL_DISPEL_MAGIC
SPELL_DISPEL_UNDEAD
SPELL_EARTHQUAKE
SPELL_ELEMENTAL
SPELL_ENCHANT_WEAPON
SPELL_ENERGY_DRAIN
SPELL_ENERGY_SHIFT
SPELL_ENHANCED_HEAL
SPELL_ENHANCED_REST
SPELL_ENHANCED_REVIVE
SPELL_ENHANCE_OBJECT
SPELL_ETHEREAL_TRAVEL
SPELL_FAERIE_FIRE
SPELL_FAERIE_FOG
SPELL_FARHEAL
SPELL_FEAST
SPELL_FIREBALL
SPELL_FIRESHIELD
SPELL_FIRE_BREATH
SPELL_FLAMESTRIKE
SPELL_FLY
SPELL_FROST_BREATH
SPELL_GATE
SPELL_GAS_BREATH
SPELL_GENERAL_PURPOSE
SPELL_GIANT_STRENGTH
SPELL_HALLUCINATE
SPELL_HALLUCINATORY_TERRAIN
SPELL_HARM
SPELL_HASTE
SPELL_HEAL
SPELL_HIGH_EXPLOSIVE
SPELL_HOLY_WORD
SPELL_HOMONCULOUS
SPELL_IDENTIFY
SPELL_ILLUSION
SPELL_IMPROVED_INVIS
SPELL_INDUCTION
SPELL_INFRAVISION
SPELL_INVIGORATE
SPELL_INVIS
SPELL_KNOW_ALIGNMENT
SPELL_LIGHTNING_BOLT
SPELL_LIGHTNING_BREATH
SPELL_LOCATE_OBJECT
SPELL_MAGE_BLAST
SPELL_MAGE_SHIELD
SPELL_MAGIC_MISSILE
SPELL_MASS_INVIS
SPELL_MIRROR_IMAGE
SPELL_NIGHTMARE
SPELL_OBJECT_INVIS
SPELL_PASS_DOOR
SPELL_PHANTASM
SPELL_POISON
SPELL_POSSESS
SPELL_PROTECTION_EVIL
SPELL_PROTECTION_GOOD
SPELL_HALLUCINATE
SPELL_HALLUCINATORY_TERRAIN
SPELL_HARM
SPELL_HASTE
SPELL_HEAL
SPELL_HIGH_EXPLOSIVE
SPELL_HOLY_WORD
SPELL_HOMONCULOUS
SPELL_IDENTIFY
SPELL_ILLUSION
SPELL_IMPROVED_INVIS
SPELL_INDUCTION
SPELL_INFRAVISION
SPELL_INVIGORATE
SPELL_INVIS
SPELL_KNOW_ALIGNMENT
SPELL_LIGHTNING_BOLT
SPELL_LIGHTNING_BREATH
SPELL_LOCATE_OBJECT
SPELL_MAGE_BLAST
SPELL_MAGE_SHIELD
SPELL_MAGIC_MISSILE
SPELL_MASS_INVIS
SPELL_MIRROR_IMAGE
SPELL_NIGHTMARE
SPELL_OBJECT_INVIS
SPELL_PASS_DOOR
SPELL_PHANTASM
SPELL_POISON
SPELL_POSSESS
SPELL_PROTECTION_EVIL
SPELL_PROTECTION_GOOD
SPELL_RECHARGE
SPELL_REFRESH
SPELL_REMOVE_CURSE
SPELL_REMOVE_FEAR
SPELL_RESTORE
SPELL_RIFT
SPELL_RIGHTEOUS_FURY
SPELL_RIP
SPELL_SANCTIFY
SPELL_SANCTUARY
SPELL_SHADOW
SPELL_SHADE
SPELL_SHIELD
SPELL_SHOCKING_GRASP
SPELL_SLEEP
SPELL_SLOW
SPELL_SMOKE
SPELL_SOUTHING_TOUCH
SPELL_STABILITY
SPELL_STONE_SKIN
SPELL_SUMMON
SPELL_TELEPORT
SPELL_TONGUES
SPELL_TRANSPORT
SPELL_TREMOR
SPELL_TRUESIGHT
SPELL_TELEPORT
SPELL_TONGUES
SPELL_TRANSPORT
SPELL_TREMOR
SPELL_TRUESIGHT
SPELL_UNBARRING_WAYS
SPELL_UNDERSTAND
SPELL_UNHOLY_WORD
SPELL_VENTRILOQUATE
SPELL_VAMPIRIC_TOUCH
SPELL_WEAKEN
SPELL_WORD_OF_RECALL
SPELL_WRITE_SPELL
==============================================================================
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|BODY_ARM BODY_HAND|BODY_ARM 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|BODY_FOOT|BODY_ARM BODY_HAND|BODY_FOOT|BODY_ARM 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_ARM|BODY_HAND|BODY_FOOT BODY_ARM|BODY_HAND|BODY_FOOT 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_LEG BODY_HORN|BODY_LEG 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 BODY_FOOT 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 BODY_WING|BODY_TAIL|BODY_CLAW 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
ITEM_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
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_LEVEL
ITEM_WEAR_HOLD|ITEM_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
ITEM_FLAG_LEVEL
ITEM_WEAR_HOLD|ITEM_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
ITEM_FLAG_ANTI_EVIL|ITEM_FLAG_LEVEL
ITEM_WEAR_WIELD|ITEM_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
ITEM_FLAG_ANTI_EVIL|ITEM_FLAG_LEVEL|ITEM_FLAG_MAGIC
ITEM_WEAR_TAKE|ITEM_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
ITEM_FLAG_LEVEL|ITEM_FLAG_MAGIC
ITEM_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
ITEM_FLAG_LEVEL|ITEM_FLAG_MAGIC
ITEM_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
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL
ITEM_WEAR_TAKE
10 SPELL_UNDERSTAND 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
ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL
ITEM_WEAR_TAKE
15 SPELL_DETECT_INVIS SPELL_DETECT_HIDDEN 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
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL
ITEM_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
ITEM_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
ITEM_FLAG_LEVEL
0
24 0 0 0
0 10 1
#QQ22
ivy~
some ivy~
Some ivy is here.~
~
ITEM_TYPE_PILL
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_LEVEL
ITEM_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
ITEM_FLAG_LEVEL
ITEM_WEAR_WAIST|ITEM_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
ITEM_FLAG_LEVEL
ITEM_WEAR_NECK|ITEM_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
ITEM_FLAG_ANTI_EVIL|ITEM_FLAG_MAGIC|ITEM_FLAG_LEVEL
ITEM_WEAR_ARMS|ITEM_WEAR_TAKE|ITEM_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
ITEM_FLAG_GLOW|ITEM_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
ITEM_FLAG_GLOW|ITEM_FLAG_LEVEL
ITEM_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
ITEM_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
ITEM_FLAG_LEVEL
ITEM_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
#$