The Novice Archon's Guide
to CoffeeMud 5.2

By Archon Grothus Gallslanger of the Free City of Maltan

World Construction and Destruction

Causing buildings and towers to appear along paved streets, mountains to rise from the dust, and then breathing life into this worlds denizens may seem like a daunting task, but you will quickly discover that it is not so.  All it takes is some careful planning, and educated execution.

Towards that end, but before we get started properly on the business of molding a universe, we must needs take a moment to reflect on the powers of the Archon, and how the universes underlying laws are navigated.  Herein, therefore, I have copied from the sacred scrolls the archaic and confusing runes of "CoffeeMud Administration" for your consideration.

CoffeeMud Administration

The administration of your CoffeeMud server is done from within the game server itself, when you are logged in as your Archon player.   Some functions can be performed from the MUDGrinder.

AHELP
This is the command that Archons will use to get help on all of the commands in this section, on various administrative topics, and on all of the various building "tools" discussed elsewhere in this document, including such things as behaviors and properties.  The atopics command can give you a comprehensive list of all the topics you can get help on with ahelp.

ANNOUNCE
If there is some message you wish to give to everyone presently on your mud, this is the surest way to make sure they receive it.

AFTER
This command lets the Archon do things after an elapsed time, or even periodically.

AS
This command lets the Archon do anything as another player.

AT
This command lets the Archon do anything anywhere, regardless of where he is!

BAN
Deadly, but necessary, this command allows you to specify player names, or partial player names, or IP addresses or IP ranges that you wish to keep OUT of your mud.

BEACON
The beacon command is used to change the unique home, start room, or recall room of either the Archon, or some targeted player.  Rarely used, it is typically invoked only as reward for a player or perhaps a lesser admin.

BOOT
If a player becomes troublesome, or you just want them to go away, you will use this power to knock them temporarily out of your mud, regardless of where they are in your world.  To make them STAY away, you will have to investigate commands such as destroy or ban.

CHARGEN
This little tool accepts a character class name and a level, and it shows you the stats of an "average" player of that class and level.  Although it's not a vital administration tool, CharGen can be a helpful aid in the construction of monsters, perhaps.

CLOAK
This command makes the player unlisted in commands like who, chanwho, and on web player lists.

COPY
Depending on the argument, this command can make copies of almost anything in your mud, from rooms to monsters and items.  The thing you want to copy must exist somewhere in the world for you to properly copy it.  You can even specify how many things you wish to copy, for those moments when one pot pie just won't do.

CREATE
Depending on the argument, this command can bring almost anything into existence, from rooms to doors, from monsters to items.  The create command is discussed at length in the sections on building rooms and areas.

DESTROY
This powerful command can be used to banish objects and mobs, rooms and areas, or even players -- permanently. A  player (user) need not be online to be destroyed. The destroy command, as it relates to rooms, exits, items, and mobs, is discussed further in the sections on building rooms and areas.

DEVIATIONS
Can show you the difference between your world as it is compared with the standards at the end of this document.

DRESS
The quick way to get clothing, weapons and armor on your mobs from the command line.

DUMPFILE
When you want to view some text file on your computer through the MUD.

EXPORT
If you need a backup to your database, you can save your areas one at a time as files, for reimportation in the event of a disaster.  This command will generate files with the extension .cmare.  They are XML formatted text files containing all the data you told the system to export.  In addition to rooms and areas, you can also specifically export players, some items or mobs from a room.  The import command could then be used later to load the data you exported back in.

GMODIFY
Quickly search for all the monsters, items, or rooms that match your search criteria.  You can also optionally modify the found fields with this command.

GOTO
Allows the Archon to zap him or herself directly to the room or mob of his or her choice.  The argument is a valid Room ID, room name, mob name, or area name.  You will find yourself using the goto command quite a bit.  Walking everywhere sucks.

I3
This module is used to manage InterMud 3 chatting channels.  I3 is a component of CoffeeMud that provides for chatting channels which span across many many muds in cyperspace, allowing players and admins to talk to folks playing on other muds.

IMC2
This module is used to manage InterMud Chat 2 information.  IMC2 is a component of CoffeeMud that provides for chatting channels which span across many many muds in cyperspace, allowing players and admins to talk to folks playing on other muds.

JRUN
This command can be used to execute Javascript scripts located on the local hard drive.  If the gods have given you this power, they have great trust in you indeed.

IMPORT
Import will suck in one or more data files and recreate rooms, areas, players, mobs, items, and lots of other stuff from the contents of those files.  The data files that import will successfully read include (of course) the CoffeeMud .cmare files discussed under the export command.  In addition, import will also take in area data files from other MUDs, such as ROM, CircleMUD, and others.  Of the non-CoffeeMud area files, the ROM format is by far the best supported.

LINK
This command will cause two places to come together, making travel between them much easier.

LIST
The Archon is able to list lots of different things, for many different reasons.  "list users" will show you all of the players, and when they logged on last.  This is useful for weeding out olde players (see DESTROY below).  "list threads" will show you how many Java threads are active.  "list ticks" will show you all the objects making use of those threads! "list reports" will show you your resource usage.  "list staff" will show you a list of your areas and any Area staff defined for them. You may also list things like locales, items, weapons, armor, mobs, and other things discussed further down in the sections on world building.

LOAD
This command will cause a text or file resource to be brought into memory.  What happens to it from there is your business.

MERGE
This powerful tool is rarely used, but is vital if you need to make small changes to identical items or mobs scattered all around your world.  It uses item or mob data gathered from the export command to merge with the items and mobs you specify in the real world, making the necessary world corrections  that you want it to.

MODIFY
If something which exists is not quite right, this command can make it right.  By telling the system exactly what you want to modify, you can change it into what it ought to be.    The modify command is discussed further in the sections on building rooms and areas.

MULTIWATCH
A little tool which allows an Archon to gather evidence against multiplaying players.

NOPURGE
Prevent a player from ever being auto-purged due to not logging in.

ORDER
Although any player may order around their followers, an Archon can order ANYONE to do ANYTHING.

POOF
This command lets you modify the messages seen when you use GOTO to move from room to room.

POSSESS
Easily the most fun part of being an Archon is to possess one of the monsters and harass the players, making them think the monsters have truely come to life!  Some enjoy this so much that they forget to return to their true bodies!

PURGE
A moderate form of the DESTROY command which allows you to clear out mobs or items without affecting whether or not they will repopulate (rejuv) later on.

RESET
Giving a parameter of "room" or "area", this command will make everything reset back to the state it was last saved at.

RESTRING
A moderate form of the MODIFY command which allows only editing a few fields on items.

SAVE
This command is used to update your CoffeeMud database. If you use "save user", the system will update the players data.  "save room" can make aspects of a room permanent by saving it to the database.  Saving rooms is discussed further below in the section on building.

SESSIONS
This command will list all of the players online, and perhaps a few who are on their way to being online.

SHELL
This command will allow you to view the files in your coffeemud folder, copy and delete files, and even put them in your database.  Saving files in the database?  See Appendix H for more info on the CoffeeMud VFS system.

SNOOP
This command can let you watch other players as they wander your world.  This command gives you a second pair of eyes to look over the shoulder of the player of your choice.  You will see everything they see, almost as if you were them yourself.

STAT
This command allows you to do everything from view the statistical happenings on your world, to the simple charicteristics of a target mob or player.

SYSMSGS
This important little trick is vital to those doing CoffeeMud development from the command line. It gives the Archon a unique vision of the world sometimes necessary for his work.  For one, it makes everything visible to the Archon regardless of its state of visibility, darkness, fog, or any/all other conditions.  It also reveals the unique identifying codes, classes, and names by which things are known or identified.  All of this is very important when trying to modify or destroy things you no longer want in your world.

SHUTDOWN
Although CoffeeMud can also be brought down by killing the Java virtual machine, the proper way to shut down CoffeeMud is by entering the shutdown command.  This will ensure that all users are saved back to disk, and that the system goes down in a polite and orderly manner. 

TAKE
Use this command if a player or monster has something that doesn't belong to them, and you need it back.

TICKTOCK
This simple little power will advance the world's time clock by one hour every time it is used.  If it's day, and you want it to be night, or vis-versa, this is the way to go.

TRAILTO
A tool to tell the Archon the twistings and turns from where he is, to where he'd like to be.

TRANSFER
Allows the Archon to zap someone directly to the room or mob of his or her choice.  The argument is either ALL or the name of the target, and a valid Room ID, room name, mob name, or area name.  Use this when you want someone to go somewhere NOW.

UNLINK
This command will separate two places from one together.

UNLOAD
If you've made any changes to your help files or other resources, and don't want to have to reboot the whole MUD, you can use this command as a short-cut.  It unloads "resources" (try "list resources") that are in memory.  By unloading resources from memory, you force CoffeeMud to reload your changes from disk.

WHERE
Allows the Archon to who all is online, and where they are on the map. An argument, such as "where orc", may be given to specify a specific mob name.  That way, you can find out where you might have misplaced that wandering zombie.  Where can also be used to locate rooms, items, or almost anything else.  The mind boggles at the possibilities.

WIZEMOTE
The omnipresence of the Archon is reflected in this command, which causes a message to appear throughout the world.

WIZINV
Sometimes an Archon wants a little privacy, and this command gives it to him or her.  It will make the Archon completely undetectable, allowing free movement without harassment from players or monsters.

Security

CoffeeMud has an extremely flexible and powerful security system.  It allows the Archons to designate who has which powers, and where they may exercise them.  Powers can be doled out to minions as they deserve and warrant.  

By default, all players who have levels in the class of Archon are all powerful system administrators, who may perform all of the powers discussed in the last section and many many more.  Of course, this does not NEED to be the definition of the all powerful, but since it is for starters, we will continue as if Archon and 'All Powerful Super Duper System Administrator' are indeed and always the same.  If you wish to change it, the SYSOPMASK setting in your coffeemud.ini file is the place to go, or to the  MUDGrinder has a wonderful tool for security in the Control Panel.

While players are just players, and are unable to wipe their own noses without an Archon to provide them a tissue, they may also be much more with the wave of an Archon's hand.  The Security setting one sees when using the command MODIFY USER playername from the command line can be used to give players a small portion of the creative powers.  By combining this with the Staff setting under Areas (see below), players can have their powers narrowed to certain spheres of influence.   A customized Character Class can also be used to expand the creative power of players by adding Security Group Levels to your players character class.  See the section on creating your own custom character classes for more information on this. 

To upgrade the powers of a player, you may use the MODIFY command as mentioned previously.  From the Security setting, players who are not SYSOPS may be granted very specific privileges by adding special security codes. Each of the privileges/flags may be limited to specific areas, or available globally.  Each entry listed under Security for a player may be either a security Group, or a specific security code. Security Groups, like the SYSOPMASK mentioned above, are also defined in the coffeemud.ini file or from the MUDGrinder Control Panel. A Security Group consists of a group name, and a set of string codes representing privileges for that group. The string codes are the security flags.  The Group names in the Control Panel start with the string "GROUP_", but only the part after that string is a valid group name.  You should never include the "GROUP_" part when entering a group name into a players Security settings. 

Now, each individual security code which makes up each of the groups is implicitly global (meaning the power may be used anywhere), but can be qualified as area-only by prefixing the code with the word AREA and a space.  For example, the security code "ANNOUNCE" by itself confers the global ability to use the ANNOUNCE command. The security code "AREA ANNOUNCE" means that the ANNOUNCE command can only be used inside areas where the player is listed as Staff.  See the section on Areas in this guide for more information on Staff.

Use HELP SECURITY, or access the Control Panel from the MUDGrinder for a list of recognized security codes.

Building Your World: Planning is the First Step

Before a single bird can flitter through the skies that you opened up, you must have planned the placement of that sky, and the song of that bird.  I am assuming you have been given some general area to construct, some wicked kingdom, joyous elven city by the sea, or some other such nonsense.  If not, get one; decide on the general theme of some area you wish to construct.

At this point I suggest you get a piece of graph paper or parchment.    Upon it you shall draw small squares next to each other.  Plot out every location you will create.  The squares need not be equal in size, but they need to all fit together somehow.  Before invoking the spells of creation, you should know where every door leads, where every path ends, and if X indeed marks the spot, where the X is.

Inside each square, you shall make small notes.  What notes?  Well, that's the next part of our story.

Understanding Rooms

At the foundation of the CoffeeMud world is the room.  Now, a room is not just some pink wallpapered play area, but simply a place.  Certainly a kitchen can be a room, as can a pink wallpapered play area, but so can the bottom of a well, a stretch of rolling hills, the top of a tall mountain, or a dragon’s lair deep underground.  Physical size does not matter with rooms; only your imagination can determine that.

Every room has a general foundational type that defines it.  That type determines the behavior of that room day to day, whether it is outside or inside, made of wood or stone, a mountain or a plain, in darkness or light, a cliffside or deep in the ocean.  The type determines whether one breathes water or air, chops wood or fishes, and how good the hunting is.  This foundational type of every room has a name: Locale. 

If you log into CoffeeMud right now, you can list the available Locales with the command "list locales".  This list should include many different types of locales, most of which are self-explanatory.  They include:

The type of room you pick can have an important impact on the residents of your world.  The type of room can determine whether there is a sky above the players, whether players in the room are affected by weather events, whether there is any light in the room by default, whether nightfall affects the lighting in the room, whether players drown or require swimming, what kinds of resources are available from the various player resource-gathering common skills, and whether certain spells, prayers, skills, or commands work properly (Dirt Kicking doesn't work in ShallowWater, for instance).

For each room you are drawing on your graph parchment, you should note in the Locale type of the room from the above list, or from the list you received when you entered "list locales" into CoffeeMud.  Keep in mind that some rooms are multi-rooms.  These Grids and Mazes represent 2-Dimensional grids of rooms of a single sort.  The dimensions are entirely up to you, and can range from a thin 1x20 trail, to a wide 15x15 block.  The mazes expand on this by creating weaving paths through the grids.

The detailed properties of rooms are discussed further in the section on creating rooms.

Understanding Exits

Now surely you did not expect everyone to conjure him or herself from place to place!  Why, the pitiful halfling thieves would starve in their holes if this were so.  No, each of the rooms you have drawn on your paper will be connected with things called Exits.

For any two rooms that one can travel between, there are always two exits.  One exit leads from the first room to the second. Another exit leads from the second room to the first.  Usually those exits are the same, but they need not be if you don't want them to be so.

All exits will take a person from one room to another, and may even take them back again if you choose.  An exit can only be located in one of six directions: North, South, East, West, Up, and Down.  The four compass directions are easy to fathom, but be careful with up and down, as they need not be unhindered flight, or a reckless fall.  If, for instance, the destination room is a Locale like "InTheAir", then Up obviously represents the open sky.  If it is another "StoneRoom", however, it probably represents a flight of stairs.  The Down direction may represent falling off a cliff, but it may also represent a ladder down to the basement.  Either way is fine.  

Exits, like rooms, can be of many different types.  If you are still in CoffeeMud, enter the command "list exits".  The list you receive describes the many connectors that can be mixed and matched between rooms.  Some include doors, and some include doors with locks.  There are walkways with pits, doors with needle traps, and many others.  By far the most common of these Exits is called "Open".  It describes a completely free and clear path between the two rooms you are creating.  Here is the official list:

ClimbableExit	a passageway one must climb through
Door	an ordinary closed door
FlyingExit	a passageway one must fly through
GapExit	an exit one must jump across or fall and DIE!
Gate	an ordinary closed gate
GenDoor	the maleable generic door
GenExit	the maleable generic exit
Grate	an ordinary closed grate in the street
HiddenClosedDoorway	the venerable secret door
HiddenWalkway	a way that can be walked through, but not seen
Impassable	no one may go that way
LockedDoor	an ordinary locked door
LockedGate	an ordinary locked gate
NeedleDoor	a door trapped with a needle
Open	a normal walkable passageway
OpenDescriptable	an open walkway thats describable
OpenNameable	an open walkway thats nameable
PitOpen	a walkable passageway with a pit!
StdClosedDoorway	base class for closed doors
StdExit	base class for all exits, do not use!
StdLockedDoorway	base class for locked doors
StdOpenDoorway	base class for open walkways
TrappedDoor	a trapped and closed door
TrappedLockedDoor	a trapped and locked and closed door

As you finish your graph parchment drawing, be sure to note those places where there are doors, locked doors, pit traps, and open walkways.  If a door is one way, or if a door leads to one place when one enters, but does not go back to there when one leaves, make a note of that too.  The doors listed above are ever vigilant in decorum-- doors that are opened by players will re-close in time, and locks are resecured.

However, it may come to pass that there is a rickety straw door to some hut you wish to have, but it was not listed among your choices.  Fear not, for there is "GenExit" and "GenDoor".  "GenExit" stands for "Generic Exit", and represents the finest in Archon power.  A completely customizable exit flowing from one room to another.  And thusly are exits divided from each other: the GenExits and GenDoors are customizable, flexible, changable, and otherwise maleable.  All the other exits, however, are "Standard", meaning they are not very customizable at all, but they do load very quickly, and take up very little memory compared to a GenExit.  GenExits, as well as the other features of exits, are discussed further in the section on creating exits.

Understanding That Which Creepeth Upon the Land

The denizens of your land are surely the greatest accomplishment you will claim.  From the lowly cooks in your kitchens to the great beasts in the darkest dungeons, it is they who will be remembered by those who visit your realm. 

Funny then that for things so important, they should have such a short, ugly sounding name: MOB.  If you are in CoffeeMud, you can list them: "list mobs".  It will show you every creature that can populate your cities, dwell in your dungeons, or hide in your pantries.  They are too numerous to list here. 

If a creature is not listed there that you require, there is always the GenMob, that nasty formless being that can be shaped by the Archon to appear and behave exactly as it should.  GenShopkeepers, GenPostman, and GenBankers are available to provide valuable services for your community.  GenDeitys give your Clerics employment. GenRideable mobs provide transport.  For more devious spirits, however, the GenUndead is also available, to strike fear in the hearts of the purest cleric.  These mobs just mentioned form the troupe of "Generic" mobs, meaning they are customizable and changeable from inside the mud.  The other mobs listed are classified as species "Standard" mob, meaning they are not nearly as customizable, though they do load quickly, and take up much less memory than the "Generic" mobs do.

GenMobs, as well as the features of MOBs, are discussed further in the section on creating MOBs.

The Things We Treasure

Our last planning topic is that of the items that will be found in your land.  Some of them will be priceless once-in-a-lifetime creations.  Others will be reoccurring trapped chests that always seem to have enough gold for those bold enough to continuously risk their guardians.

The items can be discovered using the "list items" command.  Other items include weapons, which can be discovered through "list weapons", armor from "list armor", and other miscellaneous enchanted items through "list magic". 

For those items you need by are not present, there is also the "GenItem", "GenBoat", "GenChair", "GenTable", "GenBed", "GenLimb", "GenCoins", "GenCorpse", "GenKey", "GenLantern", "GenLightSource", "GenCigar", "GenPipe", "GenMap",  "GenResource", "GenLiquidResource", "GenFoodResource", "GenRideable", "GenWallpaper", "GenJournal", "GenBook", "GenContainer", "GenFood", "GenDrink", "GenWater", and "GenReadable".  For the fighting spirit there is the "GenWeapon", "GenStaff", and "GenArmor".  Among the formless magical items are "GenPill", "GenPowder", "GenPotion", "GenScroll", "GenWand", and "GenSuperPill".    These items just mentioned form the gluttony of "Generic" items, meaning they are customizable and changeable from inside the mud.  The other items listed are classified as "Standard" items, meaning they are not nearly as customizable, though they do load quickly, and take up much less memory than the "Generic" items do.  These and the many properties of items are discussed below under the section on creating items.

The Art of Creation

Before beginning, you should log into CoffeeMud and take yourself to some place that is adjacent to the area you will be forming.  You should also cast the spell of natural enlightenment using the following command: "sysmsgs".  You should see an utterance that reads "Extended messages are now: ON". 

Now your eyes will behold new wonders when you look around the rooms:  You will see the Locale types of the room, the Room IDs that have been assigned uniquely to each room, the Area IDs of the area you are in.  They should look like this:

Area  :(MyArea)
Locale: (StoneRoom) 
(MyArea#123) Joe Bob's Room

The first line lists the area name, the second line the locale type we talked about earlier, and the third line lists the Room ID, followed by the Room Name.  Take note of them all, my friend, and learn to appreciate their beauty. 

Creating Rooms

Now that you have your plan laid out, it is quite time to being execution.  Gather your strength, and begin harnessing the power of the Archon, for you will need every ounce of it when the wood and rock chips start flying.

To create a new room most easily, you must first be standing in a room adjacent to it, one that will be connected to it through some exit.  You will then utter the invocation of room creation, summoning the Locale in the direction that the new room should be.  For instance, you wish to have a new room north of room "MyArea#123".  If room "MyArea#123” is already created, and the new room is going to be of the "StoneRoom" Locale, you would bring yourself to room "MyArea#123" and utter the words:  "create stoneroom north".

At this point, you should cover your ears, as the sound of a stone room falling to the north is often quite disturbing.  Between the two rooms; the one you are standing in, and the one you have created, will be a default exit: the Open exit.  Most times, that is ok, though changing it will be the subject of the next section.

However, once this is done, and the rooms are irrevocably linked, you can still throw a small twist on things.  If you are still standing in room "MyArea#123" and wish to create a NEW StoneRoom in the SAME direction, it can be done.  Uttering the words "create StoneRoom north" AGAIN and a new room is created.  Now, what happened with "MyArea#124" you’re wondering?  It is still there, and it still leads back to where you are standing -- a one way exit.

Modifying Rooms

For now, once you have created a new room, it is time to design the landscape of it.  To do this, you should enter the room through the default Open exit that was created for you.  You will find the room plain and boring. 

To give the room a new name and description, utter the invocation: "modify room" and follow the promptings.   The display property is the short name that appears at the top of the room description, while the description field is the long text.  Type whatever text you like into these fields, and feel the power as the place takes on a new form dictated by your creative magic.  These two fields support the CoffeeMud color codes described in the Programmer's guide, as well as line breaks using either %0D or \n.  Normally, that's all you need to know.  However, these fields may also be customized to display different text depending on the weather, season, or the time of day.  This last is done by starting the field with the string <VARIES>, and following it with text surrounded by the appropriate codes in the following format: <CODE>text</CODE>.  In all of these cases, the codes must be in uppercase.  Valid codes include: SUMMER, SPRING, WINTER, FALL, DAY, NIGHT, DUSK, DAWN, RAIN, SLEET, SNOW, CLEAR, HEATWAVE, THUNDERSTORM, BLIZZARD, WINDY, DROUGHT, DUSTSTORM, COLD, HAIL, CLOUDY.

Rooms of the Grid and Maze sort present unique challenges to the molder of universes.  In the first place, if you have SYSMSGS turned on, you will notice that the room ID displayed is a little different.  In addition to the room ID of the parent room, there is an additional set of parenthesis showing where you are in the big grid room.  It would look something like this:

Area :(Coffee Grounds)
Locale:(Plains)
(Coffee Grounds#19#(0,2)) The Demitasse Demesnes

In this case, we are in Coffee Grounds#19, child room at X=0, Y=2. 

You will notice that you are unable to modify child rooms like this one.  In the case of Grids and Mazes, you must be inside the Parent room to perform modifications.  To get to the parent room, use the GOTO command.  In the example above, we would enter "goto Coffee Grounds#19".  This will allow us to properly modify the room, and add any creatures (mobs) to it later on.

Once you are in the parent room of a Grid or Maze, you may use "modify room" to modify the properties of the entire grid or maze.  You can modify things like the dimensions in the X and Y, to make your grid anything from a long hallway to a giant hedge maze. 

Modifying the display  and description fields also has unique consequences inside a Maze or Grid.  You may enter a random selection of text strings to display into each of these fields, so long as you remember to separate each individual text selection by the <P> string.  For example:

Display: 'First Display Title<P>Second Display Title<P>Third Display Title'
Description: 'First Description<P>Second Description<P>Third Description'

The above, when placed in a grid or maze locale, will cause CoffeeMud to select randomly among three different display title/description combinations.   Since there is an equal number of display and descriptions given (3), the display and titles will always be matched up in the grid children rooms. 

After you have made your modifications to the grid parent room display and description, use the "reset room" command to have them take effect.

The "reset room" command will force CoffeeMud not only to reset a grid or maze, but to reload the creatures and items last saved in the CoffeeMud database.  This can be useful if you make a few critters or things you don't want to keep and havn't yet saved.  A corresponding "reset area" command does the same for the whole area.

And speaking of areas, rooms also may have behaviors and effects added to them, including a few more.  In this case, the behaviors and effects above will only be active for this particular room. Aside from those listed under Areas above, here are additional Behaviors you might enjoy:

"DelayedTransporter" causes all those who enter to be whisked elsewhere.
"Emoter" - yea -- this is mentioned under Areas, but it's just sooo cool.
"FasterRecovery" - makes the players recover their stats faster in this room.
"FieryRoom" - stuff catches on fire here! watch out!
"InstantDeath" - nuff said.
"Mime" causes the room to mimic players.  Wierd.. yea, I know.
"MovingRoom" the fast train to somewhere.
"ProtectedCitizens" will allow resident mobs to scream for help and receive it when attacked.
"RandomMonsters" will cause monsters from a saved file to appear here.
"RandomItems" will cause items from a saved file to appear here.
"ItemGenerator" will create treasure and items for your rooms.
"RandomTraps" will cause random traps to be set here.
"ResourceOverride" if you want fishing in the desert, or sand in your swap, this is the way to go.
"Scriptable" makes the room react to events in a scripted way.
"ScriptableEverymob" same as scriptable, but applies itself to all the mobs born here.
"Sounder" is still a good alternative to Emoter.
Lots of other properties and effects are also available for rooms.  In addition to all the ones listed above under Areas, here are a few more you might want to add:

"Prop_AbilityImmunity" protects the room from specified targeted spells.
"Prop_ClosedDayNight" turns off the lights in a lit room at nighttime.
"Prop_ClosedSeason" turns off the lights in a lit room during a season.
"Prop_CommonTwister" jumbles up the usefulness of gathering common skills.
"Prop_Crawlspace" forces players to crawl through here.
"Prop_EnlargeRoom" forces players to use more movement traveling through here.
"Prop_EnterAdjuster" affect the occupants stats permanent when entering the room.
"Prop_HereAdjuster" affecst the occupants stats when in the room.
"Prop_HereSpellCast" affect the occupants with spells when in the room.
"Prop_ItemTransporter" drop it, and its gone -- elsewhere.
"Prop_ItemReceiver" is the elsewhere.
"Prop_LotsForSale" puts this room up for sale, and ensures that you never run out of new rooms to buy.
"Prop_MagicFreedom" makes the room an unhappy place for mages.
"Prop_NarrowLedge" makes this a room you can cross.. if you are very very careful.
"Prop_NoChannel" makes the room safe from channel messages.
"Prop_NoCharm" makes the room safe from charming.
"Prop_NoOrdering" makes the room safe from player ordering.
"Prop_NoPurge" makes the room safe for dropped garbage.
"Prop_NoPKill" makes the room safe from player killing.
"Prop_NoRecall" makes the room safe from recalling.
"Prop_NoSummon" makes the room safe from summoning.
"Prop_NoTeleport" makes the room safe from teleporting in.
"Prop_NoTeleportOut" makes the room safe from teleporting out.
"Prop_NoTelling" makes the room safe from telling between players.
"Prop_Peacemaker" makes the room safe.
"Prop_ReqAlignments" lets you limit the alignment of all who enter.
"Prop_ReqCapacity" lets you limit the number of folks or items in the rooms.
"Prop_ReqClasses" lets you limit the character class of those who enter.
"Prop_ReqNoMOB" to make your area a player-only place to be. 
"Prop_RestrictSpells" lets you limit specific skills or spells from being used here.
"Prop_ReqEntry" lets you limit entry to folks by many different criteria.
"Prop_ReqHeight" keeps out tall people, or at least those unwilling to crawl.
"Prop_ReqLevels" lets you limit entry by levels.
"Prop_ReqRaces" lets you limit entry by race.
"Prop_ReqTattoo" lets you limit entry to players with certain builder-definable tags.
"Prop_ReqPKill" makes this a place that only the bloodthirsty may enter.
"Prop_RestrictSpells" shuts down a list of spells that you provide.
"Prop_RoomDark" makes the whole area a place in need of light.
"Prop_RoomForSale" puts this one little room on the market.
"Prop_RoomsForSale" designates that this room, and all others like it nearby, are for sale as a group.
"Prop_RoomUnmappable" makes the whole area unmappable by mundane means.
"Prop_RoomView" makes this room seem to be another...
"Prop_RoomWatch" allows folks in other rooms to watch what goes on here.
"Prop_Smell" gives the place a smell.
"Prop_SparringRoom" makes the consequences of death more palatable.
"Prop_SpellAdder" puts everyone who enters under its spell.
"Prop_TattooAdder" puts a little something on all who enter.
"Prop_Transporter" send those who enter to the room you designate.
"Prop_Trashcan" destroys stuff dropped on the ground.
"Prop_WeakBridge" makes cross this room very very dangerous.
"Spell_Silence" to quiet things down.
And lots and lots of traps to put in your rooms: "Thief_Caltrops", "Thief_DeathTrap", "Thief_Listen", "Thief_MinorTrap", "Thief_Trap", "Trap_AcidPit", "Trap_Avalanche", "Trap_BearTrap", "Trap_Boulders", "Trap_CaveIn", "Trap_CrushingRoom", "Trap_Darkfall", "Trap_DeepPit", "Trap_Enter", "Trap_EnterBlade", "Trap_EnterGas", "Trap_EnterNeedle", "Trap_EnterSpell", "Trap_FloodRoom", "Trap_MonsterCage", "Trap_RatPit", "Trap_RoomPit", "Trap_SnakePit", "Trap_Snare", "Trap_SpikePit", "Trap_Tripline".

Ok! Back to work!

If you are ever wandering around, and wish to go directly to a room you have created, you may utter the magic matra "goto RoomID".  For instance, entering "goto MyArea#123" would take you to the room we created above.  This will especially come in handy when we begin to create and destroy the links between rooms, and there is no other way to get to a room.

Linking Two Rooms Together

Now that you have created a room, and wish to link one of the rooms in your area with one of another, you can use a command that utilizes the Room IDs mentioned above.  If you would like to create a northerly link from room "MyArea#123" to a room whose room ID is "MyArea#124", then you need only stand in room "MyArea#123" (use the "goto" command if you must), and utter the invocation:  "link MyArea#124 north".  This will create an Open exit between the room you are standing in, and the room whose ID is born out. 

You should note that this command could be used as it was in the last section to create one-way exits to existing rooms.

Unlinking Two Rooms

If you wish to detach two rooms from each other, you need only learn the "unlink" command.  If you are standing in the room to the south of the one you wish to unlink, and the room you wish to detach from is to the north, utter the command: "unlink north".  It will do the trick!

Keep in mind that just because there is no longer a route from the room you are in to the other via a northerly path, it does not mean that there is no path from the detached room back to here again.  You may have to conjure yourself into the other place and enter a "unlink south" command to completely detach them forever.

Destroying a Room

Sometimes the pain born from a failed or evil place is too much to bear, and as an Archon, you can do something about it.  This involves the destroy command.  It does not merely unlink the room, but obliterates it altogether and forever.  To do this, first make sure you are not standing in the room you wish to destroy.  Such destructive magic would surely be your end as well.  Then you must utilize the Room ID of the doomed place.  If the room you wish to destroy has the Room ID of "MyArea#124", then enter:  "destroy MyArea#124".  It will obliterate that place from the planet forever.

Creating Exits

The difference between Exits and Rooms is a very important one.  Creating and destroying Rooms describes WHETHER two rooms are connected, and by which direction.  Creating and destroying Exits describes HOW one gets from one room to the next.  Two rooms must be connected together before exits between them can be modified.

For instance, suppose you linked "MyArea#123" and "MyArea#124" as described above.  By default, you get an StdOpenDoorway, also known as an "Open" exit.  These exits can be walked through freely.  Now suppose you wish to have a Door between the two rooms.  If the exits between the two rooms are both the same, and you are standing in the southernmost room of the two, then changing them both is simply a matter of issuing the command "create Door north".

Destroying Exits

Just as unlinking rooms disconnects them, destroying exits can SEEM to disconnect them.  When you issue a simple destroy command, and refer specifically to the exit, then you will not be destroying the link between the two rooms, but merely the exit that travels between them.  Archons can still travel through these missing links, but players will not be able to.  Also, destroying an exit only deletes the exit in one direction, not both.  For instance, if you are standing in the southerly room of two linked rooms that both have Exits between them, and you issue the command "destroy exit north", you will destroy the Open exit between the rooms.  As an Archon, you can still travel north through the destroyed exit, but players will not be able to.

Now, that an exit has been deleted, it is possible to create a DIFFERENT kind of exit for the northerly direction from MyArea#123 to MyArea#124.  Issuing a create command like "create Door north" will create a door that leads from MyArea#123 to MyArea#124, WITHOUT AFFECTING the Open path from MyArea#124 to MyArea#123.  This is only possible when the exits between two rooms are different, or one is deleted, as is our case here.

Now, suppose you wanted to have the same Door going between two rooms.  For sure this is a more common scenario than the example we just went through.  To do this, you must first delete BOTH of the exits between two rooms as described above. That means entering MyArea#123 and entering "destroy exit north", and then entering MyArea#124 and entering "destroy exit south". 

Now, with both exits deleted (and thus the same), you can create a single door between them as we did in the first part of this section using the "create Door south" command.

Creating and Modifying Areas

A town or village, country or demesnes can hardly come to be without the careful demarcation of their borders.  What separates the town from the country, or one country from another?  Like everything else, this is the decision of the Archon as he groups his rooms into Areas. 

The best way to create your areas is to do so right from the start.  The moment you create the first plot of land in your new area, or lay down the first building in your new town, you should designate it as such.  Enter the new room in your new area and utter the mystic chant "modify room area New Area Name".  Of course, where "New Area Name" can be anything you wish.  Call it "Newarea Land" or "Goldfish Villiage" or "The Fruity Phantasm" or whatever strikes your fancy.   

When you create a new area, you will be asked for the arcane "type of area" you want to create.  We will now take a second to peruse the different area types:

StdArea	This is a standard, every-day area in your every day world.  All of CoffeeMuds features work just fine with it, as it has no restrictions or limitations.  The standard area always has its own weather, and inherets its calendar.  Use this type for your most often used areas, your areas with lots of special features, and your most important areas, especially when they are less than 700 rooms.
StdGridArea	The standard Grid area is identical to a standard area, except that there is a limitation on the number of rooms that can be in a grid area.  That limitation is always based on the width and height dimensions you have defined for it.  The maximum rooms is always width X height.  You probably won't notice any differences between a standard area and a standard grid area unless you use the MUDGrinder visual area editor.  This is because grid areas always position their rooms at a single coordinate location on the visual editor screen, and it never ever moves from that position.  This can be a blessing for those creating carefully pre-planned areas that fit nicely in 2 dimensional graphs.  It can also be a blessing for big areas (> 200 rooms), since the MUDGrinder will let you edit a grid area in sections, and the rooms won't move around on you when you re-link them.  Use this area type if you do a lot of MUDGrinder visual work.  It can be a curse for more organic area designers, however.
StdPlanet	A standard planet is mostly unimplemented at this time.  It inherets the features of the StdArea and the StdTimeZone.
StdSpaceShip	The space ship is definitely unimplemented at this time.  Don't bother with it.  It lacks many of the features of the other area types.
StdThinArea	A thin area is the same as a standard area with one difference.  The rooms in a thin area are not loaded at mud boot time.  Instead they are loaded only when a player, mob, or a special built feature (such as a random monsters behavior) causes one or more rooms to be loaded.  Thin areas will also periodically unload their rooms when they havn't been accessed in 40 minutes or so.  Thin areas are fantastic for enormous (>1000) room areas that span massive ranges.  They won't gobble up your system resources.  They are bad for popular areas though, and for areas with lots of special features.  Things like the legal system and conquest system don't work well with them, since an officer may not know where to find the local judge when someone is arrested (if the judges chambers are one of the rooms not yet loaded).  If you are short on memory, or your area is one you need to have, but doesn't have to do much, the thin area is for you.
StdTimeZone	A standard time zone is the same as a standard area, except that it can have its very own calendar.  Any "child" areas of a time zone area will also inheret its calendar.
StdThinGridArea	A standard thin grid area is a mixture between the grid area and the thin area.  It combines the benefits and limitations of both.  Use them only when you need to have a largenormous area with not much going on, like a planet-girdling wilderness that surrounds your more standard areas, for instance.

Areas also contain important properties which may be modified.  Enter the secret code "modify area" to go through a list of these modifiable properties. 

The name and description of the area may be changed by following the promptings.  You may also tinker with the climate of your area, which will affect the types of weather that will blow through it, and how mild or severe the winters and summers may be.  This is also where you may add Staff.  A player whose name is listed as Staff has no additional powers unless their player Security settings grant them specific AREA privileges.  In that case, the player would be able to use their area privileges in the area where they are listed as Staff.  The section on Security above mentions all this stuff in more detail.  Typically, a player is listed as Staff, and then given several area creation privileges in order to assist in area building and modifying.  After all, sometimes creating a universe becomes a little bit too much work for one person.  

Strange settings like Technology Level and Archive File Name are available on the area promptings.   Don't worry about these.  The former is not very important at the moment, and the second is a bit too obscure for these lessons.  The Currency field is discussed in detail in the next section on What Areas are Worth.

You will also be asked to add any behaviors and effects to the area that you wish to.  These may seem strange at first, and usually you won't add any of these at all.  After all, rarely does a plot of dirt exibit any behavior, and what the heck is an effect?  Well! To the first, the wind blowing through the trees, the hoot of an owl, or a distant cackling noise are all considerable behaviors.  In fact, it is a behavior called "Emoter".  Enter "ahelp emoter" for more information about the Emoter behavior.  There are other behaviors that Areas may benefit from too. Here are some examples:

"Arrest" will add law and order to your area, with resident mobs playing the cops and the judges.
"Conquerable" has all the features of Arrest, plus it makes the area conquerable by clans!
"Emoter" is what I mentioned above -- it's for inserting those cute little blurbs in the area.
"FasterRoom" makes everything happen twice as fast here (or faster!)
"InstantDeath" makes everything that comes here DIE!!!!!
"LinkedWeather" makes the weather in this area mimic the weather from another area.
"ProtectedCitizens" will allow resident mobs to scream for help and receive it when attacked.
"PuddleMaker" will scatter some puddles around after rain or snow.
"RandomMonsters" will populate the area with lots of hideously random creatures that you choose.
"RandomItems" will cause items from a saved file to appear here.
"ItemGenerator" will create treasure and items for your rooms.
"RandomTraps" will scatter some traps around your area.
"ResetWhole" will cause the whole area to re-boot every so often, thus supplementing the natural "rejuv" process.
"Scriptable" allows you to script the behavior of the room in a limited sense.
"ScriptableEverymob" allows you to script all the mobs in the area at once.
"Sounder" is also for inserting little blurbs, plus it reacts to player actions.
"WaterCurrents" will make those on the water bob and flow in the direction you specify.
"WeatherAffects" will make the players really FEEL the weather.

As for effects, well, effects are special properties which you can attach to your new little holes in the ground.  There are lots of nice properties that one may add to an Area, which will affect every room in it, such as:

"Merchant" to establish a store front that follows the players from room to room.
"Prop_AreaForSale" to make the entire area purchasable by a shopkeeper in the area.
"Prop_CommonTwister" to mix up the resources gained from using gathering skills in the area.
"Prop_Crawlspace" to make the entire area require crawling through.
"Prop_EnlargeRoom" makes crossing the area eat up more Movement.
"Prop_MagicFreedom" to fluster any spell-using folks that happen along.
"Prop_Hidden" will make the area unlisted to normal players.
"Prop_ModExperience" modifies experience gained in this area..
"Prop_NoChannel" for a place of quiet.
"Prop_NoCharm" lets everyone remember who their REAL friends are.
"Prop_NoOrdering" keeps players from being bossy.
"Prop_NoPKill" keeps out the riffraff.
"Prop_NoRecall" keeps folks from taking the easy way out.
"Prop_NoSummon" makes sure that everyone leaves of their own free will.
"Prop_NoTeleport" keeps those silly mages from teleporting in.
"Prop_NoTelling" prevents players from using the TELL command to each other.
"Prop_NoTeleportOut" keeps those silly mages IN.
"Prop_PeaceMaker" to go with it if you want peace AND quiet. 
"Prop_ReqAlignments" lets you limit the alignment of all who enter.
"Prop_ReqCapacity" lets you limit the number of folks or items in the rooms.
"Prop_ReqClasses" lets you limit the character class of those who enter.
"Prop_ReqNoMOB" to make your area a player-only place to be. 
"Prop_RestrictSpells" lets you limit specific skills or spells from being used here.
"Prop_RoomDark" makes the whole area a place in need of light.
"Prop_RoomUnmappable" makes the whole area unmappable by mundane means.
"Prop_ReqEntry" lets you limit entry to folks by many different criteria.
"Prop_ReqHeight" keeps out tall people, or at least those unwilling to crawl.
"Prop_ReqLevels" lets you limit entry by levels.
"Prop_ReqRaces" lets you limit entry by race.
"Prop_ReqTattoo" lets you limit entry to players with certain builder-definable tags.
"Prop_ReqPKill" makes this a place that only the bloodthirsty may enter.
"Prop_Smell" gives off a unique aroma when players use their SNIFF command.
"Prop_Weather" to have the same weather in an Area all the time.

To learn more about the properties you can add to areas and rooms, enter "ahelp" while you are in CoffeeMud.  Now, isn't this fun?  Remember, if you make a mistake, fear not, for the land does not grow weary of your molding. 

What Areas are Worth

Currency is the system of money used by the inhabitants of the area. It is defined using the Currency field when creating and modifying Areas as discussed in the previous section.  All of the bankers, money changers, tax collectors, postmen, and shopkeepers will deal in the currency that you define for the area.   By default, all areas will use a system of currency that includes gold coins, and golden notes, whole notes, and Archon notes.  You can change this system by defining your own, however.  The way you do this is by entering a name for your currency, followed by an equal sign, and then a series of relative values and currency names, all separated by semicolons.  Let's look at an example:

US=0.01 penny(s);0.1 dime(s);.25 quarter(s);1.0 dollar(s)

In the currency we have defined here, we have four different currencies: the penny, the dime, the quarter, and the dollar.  Notice that each currency is separated by a semicolon in our definition string.  Each entry includes two or possibly three parts.  The first part is the base value, the second part is the name of the currency, and the optional third part is a "short name" used by shopkeepers when listing prices.

The first part of each currency entry tell us how much one unit of that currency is worth relative to the base coffeemud unit of value.  This base unit of value is used throughout the system, and can be thought of as equal to one gold coin in the default currency.  For this reason, it is wise for Archons to become familiar with the value of things in the default currency before defining their own.  Under the system we gave in our example, a penny is worth 0.01 or 1/100th of a base coffeemud unit of value.  The dollar is worth 1.0 or exactly one base unit value.   The only rule when defining the worth of your currency units is that all currency values MUST be evenly divisible by the lowest valued unit.  In this case, all of our values are evenly divisible by the penny, so we are safe. 

The second part of each currency entry is the name of the currency unit.  This can be any name you choose.   The fact that the name of the currency ends with (s) tells us that the system should include the trailing letter 's' when there are more than one of that currency unit listed.

It is completely optional, but if you wish, you may also include a short name for each currency unit entry.  If an entry contains a short name, it will tell the shopkeeper to try and display its currency using just those units.  If none of the unit entrys contain short names, then shopkeepers will tend to display their prices in multiples of the lowest valued unit, in this case, pennys.  Here is an example of that same currency redefined with short names.:

US=0.01 penny(s) (p);0.1 dime(s) (d);.25 quarter(s) (q);1.0 dollar(s) ($)

In this new example, we have defined short forms for each currency, allowing shopkeepers to choose the most appropriate one.  The prices will END with the letter p, d, s, or q depending upon which currency the shopkeeper chooses to display the currency in.

Once you have defined your currency in at least one area, you may use it throughout your mud by simply entering its name alone in the Currency field when you edit your area settings.  In our example, US would be a sufficient value for the Currency field to tell the system to re-use our US currency in that area.  You may also redefine the default coffeemud currency throughout the entire system by NOT entering a name for your currency.  For example.:

=0.01 penny(s) (p);0.1 dime(s) (d);.25 quarter(s) (q);1.0 dollar(s) ($)

This last example, since it contains a blank currency name, would make our U.S. currency system the default one used throughout coffeemud, or wherever the Currency value in the area settings is also empty.

Modifying Exits

To modify an exit that is east of your present location, simply enter "modify east".  If the exit to the east of you is a GenExit or a GenDoor, you will receive the properties mentioned above.  If the exit is anything other, than you will be prompted to enter the Miscellaneous Text field.  For a standard exit, like Open or Door, this field represents the secret code that must also be specified in the StdKey item in order for you to unlock this door without spells or thief picking.  For a readable exit, this field represents the text that is written on the door.

The "GenExit" and "GenDoor"

As mentioned briefly earlier, the GenExit is an undefined exit that one can mold to fit ones needs.  Whenever a GenExit is created or modified, you will be presented with a series of properties to change.  Hitting return will leave most of these properties without modification.  Entering new values will replace the old values.  These properties include:

Property	Description
Name	the general name of this exit. Such as "the grand portal", or "the wooden gate".
Description	what one sees when this exit is LOOKed at with the LOOK command
Display Text	what one sees when the EXITS command is issued and the way is OPEN.
Level	The Level of the door can determine how difficult it is to PICK or KNOCK.
Has A Door	I think thou canst figure these next few out.
Door Defaults Closed
Has A Lock
Door Defaults Locked
Reset Delay #	Whenever this exit is opened after previously being closed, this is the number of ticks (where a tick is currently 4 seconds) that will transpire before the exit is reset to its default state.
Closed Text	what one sees when the EXITS command is issued and the way is CLOSED.
Assigned Key Item	This is the secret code that must be present in the StdKey for you to be able to unlock it.  The StdKey must have it's Miscellaneous Text property set the same as this value in order to open this exit using the UNLOCK command.  If the level is sufficiently low, the door can still be KNOCKed or PICKed without the key.
Door Name	Is it a gate, door, grate, or portcullis. Specify that here.
Close Word	When you close it, are you really lowering it, or sliding it?  Specify the correct verb here.
Open Word	When you open it, are you really raising it, or sliding it?  Specify the correct verb here.
Is.. flags	I think thou doest grok most of these flags.  You may also require a little climbing or flying for this exit, in case it is a mere gulf the player must traverse, instead of the wide expanse that a climable room entails.
Behaviors	Like mentioned above when we talked about Rooms, there are not many behaviors that one can give to an item, but "Emoter" and "Sounder" works with exits very well.
Effects	As mentioned in the section on Rooms, there are many properties that one may attach to items. Use "list properties" to see them all, and "ahelp propertyname" for more information.

Like rooms and areas, there are special properties that are great for exits.  They include:

As for Effects, well, effects are special properties which you can attach to your new little holes in the ground.  There are lots of nice properties that one may add to an Area, which will affect every room in it, such as:

"Prop_AbilityImmunity" protects the exitfrom specified targeted spells.
"Prop_ClosedDayNight" shuts and locks any doors at night.
"Prop_ClosedSeason" shuts and locks any doors for a season.
"Prop_Crawlspace" requires crawling through this exit.
"Prop_EnterAdjuster" modifies the players stats permanently when they cross through this exit.
"Prop_Hidden" makes the exit hidden.
"Prop_Invisibility" makes the exit invisible.
"Prop_NarrowLedge" makes this an exit you can cross.. if you are very very careful.
"Prop_NoPKill" keeps out the riffraff.
"Prop_OpenPassword" requires a spoken password to open the door.
"Prop_ReqNoMOB" to make your exit a player-only place to be. 
"Prop_ReqAlignments" lets you limit the alignment of all who enter.
"Prop_ReqCapacity" lets you limit the number of folks or items here.
"Prop_ReqClasses" lets you limit the character class of those who enter.
"Prop_ReqEntry" keeps out people that fit your specific requirements.
"Prop_ReqHeight" keeps out tall people, or at least those unwilling to crawl.
"Prop_ReqLevels" lets you limit entry by levels.
"Prop_ReqPKill" lets you limit entry by bloodthirstiness.
"Prop_ReqRaces" lets you limit entry by race.
"Prop_ReqTattoo" checks out a mobs forearm before letting them in.
"Prop_RoomView" makes looking at this exit more revealing.
"Prop_Smell" gives the exit an aroma when using the SNIFF command.
"Prop_TattooAdder" puts a little something on all who enter.
"Prop_Transporter" send those who enter to the room you designate.
"Prop_WeakBridge" makes cross this room very very dangerous.
Popular traps for exits include: Trap_AcidSpray", "Trap_ElectricShock", "Trap_Enter", "Trap_EnterGas", "Trap_EnterNeedle", "Trap_EnterPit", "Trap_EnterSpell", "Trap_Launcher", "Trap_Needle", "Trap_Noise", "Trap_Open", "Trap_OpenBlade", "Trap_OpenGas", "Trap_OpenNeedle", "Trap_OpenSpell", "Trap_PoisonGas", "Trap_SleepGas", "Trap_SpellBlast", "Trap_SporeTrap", "Trap_Unlock", "Trap_UnlockBlade", "Trap_UnlockGas", "Trap_UnlockNeedle", "Trap_UnlockSpell", "Trap_WeaponSwing"

To learn more about the properties you can add to exits, enter "ahelp" while you are in CoffeeMud.

Creating Items

For our purposes, an item is any normal item, piece of armor, a weapon, a container, or any magical item, armor, or weapon.  To bring one of these things into the world, you have only to call its true name using the create command.  To create a Longsword, for instance, issue the command "create Longsword".  It will then fall from the sky onto the floor or ground before you.

To find out what items are available for you to create, you can enter "list items".  Entering "create <itemname>" will prove the true incantation for almost all of the items on this list.  An exception, however, is the GenRideable.  Since there is both an Item and a MOB version of that name, you will need to further qualify your create command by entering "create item GenRideable" or "create mob GenRideable".

The "GenItem", "GenResource", "GenMirror", and "GenReadable"

These represent some of the basic items your ordinary denizen will use every day.  A GenItem and GenMirror represent nothing-special THINGS.  GenResource is a raw material, like iron, coal, or wood, from which other things are made, especially with the common skills.  GenReadables are GenItems with something to read on them, like a book or parchment.

Whenever a GenItem is created, much like the GenExit above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include:

Property	Description
Name	the name of the item, like "a stone", or "a pencil"
Description	what one sees when one looks at the item.
Display Text	what one sees when an item is laying in a room. if you enter 'null' here, the item becomes blended, meaning that it does not show up in the listing of room contents, but may still be "looked" at, "read", or (if allowed) picked up!
Secret Identity	what one sees when the Identify spell is cast on the item.
Level	the level of the item, dictating the lowest level a character must attain to possess or hold it.
Uses Remaining	This property applies especially to GenWand, GenStaff, and GenScroll, discussed below. This tells how many times the magic in the item may be reused before requiring a recharge.
Rejuv/Pct	This field has two different meanings, depending upon whether the item is in the room, or in a mobs inventory.      If this item is located in a room, this value determines whether it rejuvinates after being removed from the room. In this case, it is the number of ticks (4 second intervals) between the removal time, and the time the item rejuvinates. For more information on making the RejuvTicks property take effect after changing it, see below under Rejuvenating Items and Mobs" or "How to Save a Room".      If this item is located in a mobs inventory, this value represents the % chance of it appearing in the mobs inventory after reset. In this case, the value should be between 1-100, or 0 to also represent 100 (always available).   See the section on "Equipping Mobs" for more information on this feature.
Is This Item Gettable	whether the item can be picked up off the ground.
Is This Item Droppable	whether the item can be dropped into a room.
Is This Item Removable	whether the item, once held or worn, can be removed.
Is This Item Locatable	whether the item can be found with the Locate Object spell.
Is This Item Readable	whether there are any readable markings on the item.  Normally, an item must be in a players inventory to be read.  However, if the item is set as not being Gettable, then it may be read even on the ground, like a sign or billboard.
Assigned Readable Text	if this item is marked, what those markings say. If this text begins with FILE=, then a text file from the resources directory will be displayed. For example: FILE=text/intro.txt
Material	this is the material that the item is made of.  This affects the classes with armor restrictions, and the effects of certain spells.  Choices include: cloth, metal, wood, leather, glass, and mithril.
Value	the items monetary value, for the purposes of buying from and selling to shopkeepers who price the item at default values.  The value is expressed in multiples of the the base value.  A value of 20 will mean that the item is worth 20 gold (or whatever the local currency is), assuming gold is valued at 1.0 of base.  If the local currency has only Latinum Bars valued at 0.5, then a money value of 20 here would mean that the item is worth 40 Latinum Bars.
Weight	the items weight.
Is Flags... (Disposition)	most these flags, my faith tells me, thou canst discern. To clarify, however, a glowing item gives off light. An invisible item can not be seen, except by magic. An unseen item cannot be seen at all.
Behaviors	Like mentioned above when we talked about Areas, there are not many behaviors that one can give to an item, but "Emoter" works with items very well.
Effects	As mentioned in the section on Areas, there are many properties that one may attach to items. Use "list properties" to see them all.
Uses Remaining	A few items, notably wands, scrolls, and ammutiion can only be used a few times. For all other items, this may be left unchanged.
Magical Ability	although meaningless for most Generic Items, and absent on others, this property does have meaning for specific items described below. In general, items which a magical ability above 0 are considered magical. The exception to this is the GenCoins object. For coins, this denotes the number of coins in the pile!

The "GenCoins"

A GenCoins item represents one or more instances of a unit of currency, such as a dollar bill, a gold coin, a stack of bills, or a pile of coins.

Whenever these GenCoins are created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, plus two more:

Property	Description
Money Data	A three part field, including the Currency type, which can be either "DEFAULT", another of the stock currency types, or a custom currency defined for your area. See the section on area currencies for more information on this.   The next part is the decimal absolute-value denomination within the given currency, followed by the number of items in the "stack" of money.  Together, these three fields define the nature, value, and size of the GenCoins stack. You will be prompted for each of the three parts, beginning with currency.
Base Value	For a GenCoins item, this field is, ironically, useless.

The "GenLightSource", "GenCigar", "GenPipe", and "GenLantern" 

A GenLightSource and GenLantern provide light for players whenever they are HELD.  GenCigars and GenPipes are WORN on the mouth for enjoyment. GenLightSources and GenCigars will burn away after a time, while GenLanterns can be refilled with oil from an oil flask, and GenPipes must be filled with an herb.

Whenever these GenLightSources are created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, plus two more:

Property	Description
Light Duration	the number of ticks (4 second intervals) which will transpire before the light source will burn out. See the next field for more information on burning out.
Is Destroyed after burnout	Whether the item is destroyed after burnout. This defaults to true for GenCigar and GenLightSource (torches), which vanish after use. GenLanterns and GenCigars default this to false, meaning the item remains after it burns out (though no longer gives off light). The GenLantern may be refilled with oil at this time, or the GenPipe may be refilled with herbs to continue.

The "GenJournal" and "GenBook"

GenJournals and GenBooks are similar ways of persistant message storage.  GenJournals represent message boards for players to commonly post on and everyone to read.  All GenJournals who have the same NAME field will display the same set of messages to readers, regardless of how many instances of the same journal/book there are.  GenBooks display a table of contents listing the "chapters" available for reading.  Players who have access to GenJournals or GenBooks, and who have the Write skill may write new messages/chapters (or post replies to old ones on GenJournals).

GenJournals may be used by individual players to carry around and magically chat with each other on (assuming all their journals have the same name).  They may also be large public posting boards.  To make one of this last sort, simply make the journal non-gettable.  That way, people can write on them even if they can't pick them up.

One special kind of journal is called "CoffeeMud News".  If a Journal is given that name (without the quotes, and yes -- watch your spelling and case), then all messages posted to it will be echoed to all players whenever they log on next.  For this reason, you will want to keep journals with than name close to your vest.

Archons can also create special "persistant" entries, whether they be in custom journals/books or in CoffeeMud News.  These entries remain "new" longer than normal ones.  These are created by starting off an entry subject with the letters MOTD (for message of the day), MOTM, or MOTY.  If a subject starts with those letters, in uppercase, the entry will persist as new for a day, month, or year respectively.

Archons can also make use of the Web Macros system inside the body or message part of an entry.  To do so, the message must start with the characters <cmvp>.  If those six characters start the message, then the message may contain web macros.  See the WebServer Guide for more information on this feature.

Whenever a GenJournal or GenBook is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, plus one that works a little bit differently than described above:

Property

Description

Assigned Readable Text

A Journal/Book is always readable, so this field is really redundant. Therefore, it is now used as a field where you may set requirements for reading from and writing to the journa/bookl. If no requirements are mentioned, anyone may read from, write to, or reply it. A reading requirement is specified by putting READ= followed by some requirements. A reply requirement is specified by putting REPLY= followed by some requirements. A writing requirement is specified by putting WRITE= followed by some requirements. An optional administrative requirement is specified by putting ADMIN= followed by some requirements. The requirements for each of these settings can be seen by checking out the help entry for Prop_HaveZapper.  The same mask criteria used for that property are also used for these options.

The "GenWeapon", "GenBow", "GenLasso", "GenNet", "GenSling", "GenSpear", "GenBoffWeapon"

These are the assorted weapons players and mobs use to attack each other.  They are typically worn in the WIELD position, though some may also go in the HOLD position, either as a requirement (for two handed weapons) or as an option (for those with two-weapon fighting).   

Weapons can be anything from swords to daggers, from bows you shoot ammunition at, to spears that you throw.  It all depends on how you design them.  The GenBow, GenSling, and GenSpear classes don't actually offer any functionality you couldn't get out of a properly molded GenWeapon, but are provided as good examples of how to make them.  The GenBoffWeapon, on the other hand, is another form of GenWeapon, but it provides some silly and random hit messages during combat. 

The GenNet and GenLasso, however, are quite different.  Each of those are capable of ensnaring someone who is hit by them when they are thrown.  They do default to thrown weapons.

Whenever any of these GenWeapons are created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, plus a few more:

Property	Description
Attack Adjustment	a number representing the quality of the weapon.  The most common value is zero, representing a normal quality item.  Typical ranges include -10 for a poor quality weapon up to 10 for an exceptional quality weapon.
Damage	the highest amount of damage this weapon does when used in a fight.  Typical range is 2 - 8 for low level weapons, up to 20 or 30 for high-level weapons.
Weapon Attack Type	this dictates how the weapon is used in combat, whether in a bashing manner, slicing, piercing, or as a natural (fingers and claws) item.
Weapon Classification	this tells how the weapon fits into the several weapon specialization categories, and also determines which classes can use the weapon without penalty.  Choices include blunt, dagger, edged, flailed, hammer, karate (fingers and claws), polearm, ranged, and sword.
Two-Handed	Whether the weapon occupies both the wielded and held position when used.
Magical Ability	This number represents an adjustment to both attack adjustment and damage, denoting whether the weapon is magical.  Typical ranges include -2 for a badly cursed item, up to 5 for an extremely high level magical item.
Condition	a number from 0 to 100 denoting the condition of the weapon.  A 100 means that the weapon is in top condition.  A 0 means that it is all but destroyed and worthless as a weapon.
Minimum range	this is the closest position required to use the weapon.  0 means the weapon may be used in melee, where 1 means that a minimum range of 1 pace is required.
Maximum range	this is the farthese position required to use this weapon.  When combat begins, it will denote how far away the wielder is from their foe.  The same values as above apply, though the maximum range must always equal or exceed the minimum range.
Requires Ammunition	whether this weapon requires ammunition in order to use.
Ammunition Type	This is the type of ammunition required by this weapon.  Ammunition is a special kind of item called GenAmmunition (see below) which must have an ammunition type field matching that of its intended weapon (such as "arrows" or "bolts" or "rocks") and has a Uses Remaining property above 0.
Ammunition Capacity	This is the amount of the ammunition which can be held by the weapon at one time.  Usually this is only 1.

The "GenContainer", "GenCorpse", "GenCage"

The GenContainer represents the standard container of other things, whether it be a piggy bank, a chest, or a holster.  Lids, capacity, and even restrictions on what can be placed in it are all settable from here.  Containers are also smart enough to re-close themselves after awhile when they are opened, and re-lock themselves after awhile when they are unlocked (assuming they have lids and locks, of course).  A GenCorpse is a special sort of container, and should not be created in your world without good reason. It is designed to stand as the corpse of fallen creatures and foes.   The GenCage is a GenContainer that one can see the contents of even when the lid is closed.. this simulates bars or other see-through doors and lids.

Whenever a GenContainer is created, much like the GenArmor above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus a few more:

Property	Description
Has A Lid	Well, does it have one?.
Has A Lock	If it has a lid, can you lock it?
Can Contain	This can help you limit what goes inside.
Capacity	this denotes the maximum amount of weight that can be placed in the container.

One more thing to keep in mind.  Always make the weight of a container less than its capacity.  A container must be able to hold its own weight in addition to anything put in it!

The "GenAmmunition"

The GenAmmunition is a very special kind of item that can not be worn or held.  It represents a package of ammunition for a GenWeapon (or GenBow, etc..) which requires ammunition.  To make the ammunition work with your weapon, the values in the ammunitionType fields in both the GenWeapon and the GenAmmunition must match.  Whenever a player runs out of ammunition for their weapon, it will be drawn from GenAmmunition objects, provided they are in the players inventory.

GenAmmunition differs from other items not only in its inability to be held, but also in its ability to transfer any Effects on itself to the weapon.  Whenever a weapon draws ammunition from a GenAmmunition type, properties, spells, and other Effects on the Ammunition will be transferred to the weapon.  This allows one to make Magical ammunition.

Whenever a GenAmmunition  is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus a few more:

Property	Description
Ammunition Type	arrows, bolts, bullets, etc.  MUST match the ammunition type field of the weapon.  Also, the Uses Remaining field for ammunition represents the AMOUNT of ammunition in this bundle.

The "GenArmor" and "GenShield"

These represent all manner of clothing, shoes, worn jewelry, armor, and of course shields.  Of these, only a shield MUST be made from GenShield.  Everything else may be made from GenArmor.  Plus, GenArmors are also containers, meaning that you can make armor that things can be sheathed in or placed in like pockets.

Whenever a GenArmor piece is created, much like the GenContainer above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem and GenContainer, plus a few more:

Property	Description
Worn Locations	this little menu allows you to describe either all the different places a piece of armor MAY be worn, or to describe ALL the places that a piece of armor MUST be worn.  Entering the specified numbers will toggle the locations.  Entering '1' will toggle whether it is a MAY or MUST situation.  Enter '0' when done.
Layer	a number designating what can be worn on top of or beneath this piece of armor.  Generally higher numbers are worn on top of lower numbers, with negative numbers generally meaning underwear.  However, a layer number must be 2 higher than the next lowest worn item on the same location to cover it.  For instance a layer 3 can cover a layer 1 or 0, but not a layer 2 or 4.  This entry also allows you to designate whether this item hides anything worn beneath it or is see-through, and whether multiple of these can be worn on the same location at the same time (such as jewelry).
Armor Protection	the base amount of protection provided when wearing this piece of armor. Unline MOBS, the higher the number here, the better for the wearer.
Magical Ability	This number represents an adjustment to the armor protection, denoting whether the armor is magical.  Typical ranges include -2 for a badly cursed item, up to 5 for an extremely high level magical item.
Capacity	if the armor piece has pockets, this denotes the maximum amount of weight that can be placed in it.  0 is a typical value, denoting that you cannot store items in this armor.  The capacity should always exceed the weight.
Can Contain	For armor with capacity, this can help you limit what goes inside.  This value must be changed to something specific, and a sufficient capacity must be set, in order for this item to be a SHEATH.
Condition	a number from 0 to 100 denoting the condition of the armor.  A 100 means that the armor is in top condition.  A 0 means that it is all but destroyed and is not longer providing any protection at all.
Size	the size of the piece of armor. 0 means that the piece has a variable size, and will fit anyone until it is worn for the first time.  Any other number means that the wearer must be near to the size in inches to wear it.

The "GenBed" "GenChair", "GenTable", "GenBoat", "GenRideable", "GenCageRideable", "GenTub"

These represent the GenRideable group -- a group of things which may be sat one, slept in, ridden on the seas, or pulled by horses.  The GenRideable, GenBed, GenChair, GenTable, and GenBoat all represent different incarnations of GenRideable, but are interchangable otherwise.  The GenTub is unique in that it provides the functionality of GenDrink as well as GenRideable.  GenCageRideable is very different, since it has the unique property of the GenCage -- able to be seen in even when lids or doors are closed. 

Whenever a GenRideable item is created, much like the GenContainer above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, and GenContainer, plus a few more:

The "GenFood", "GenDrink", "GenWater", "GenFoodResource", "GenLiquidResource", "GenFountain", "GenTub"

These items represent the edibles and drinkables on CoffeeMud.  The GenFood is a simple edible food, while a GenFoodResource is a raw edible material that can be used for cooking or other resource-requiring common skills.  GenWater, GenDrink, and GenFountain are all templates for drinkable containers, with a GenFountain differing only in a lack of need to ever fill it.  A GenLiquidResource represents a liquid resource for potion making or other skills.

Whenever a GenFood, GenDrink, GenFountain, or GenWater is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus GenContainer for the drinkables, plus a few more:

Property	Description
Nourishment/Eat	when eaten, how much nourishment does it provide.  1000 would represent a full day of eating, while 300 would represent a single meal.  100 would represent a snack.
Quenched/Drink	when drunk out of, how much of the total capacity is consumed.  A value of 500 represents a full day of drinking, while 100 would represent a full glass
Amount of Drink Held	the amount of total drink held by the container.  Each time the item is drunk, the amount represented by Quenched/Drink is subtracted from this.  When this number reaches 0, the container is empty and must be refilled.
Liquid Type	for GenWater/GenDrink only, this denotes what kind of liquid it is, whether fresh water, salt water, or even BLOOD!  This may differ from the GenItem material type, so that the archon may differentiate between the material of the container from whats inside it.

The "GenPerfume"

This item represents a liquid drinkable (which should not be drunk) which can be worn to gain its effect. Its effect is to put a temporary smelling emoter on the wearer, making it seem to all those with noses that the wearer is affected by the perfume.

Whenever a GenPerfume, much like the GenDrink above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenDrink, plus GenContainer, plus a few more:

Property

Description

Smell emotes

this represents the parameters passed on to the Emoter behavior when the perfume is worn. The parameters are identical to the emoter, except that the SMELL flag is automatically set. Unless the perfume is permanent, a expires parameter should always be used. A default of 100 will be used if it is absent. The parameters are as follows: Parameters : Max/Min ticks, pct chance, expires, emote strings, ';' separated. Example : min=10 max=20 chance=25;smells great!;smells lovely.;smells like roses! Example : smell chance=25 expires=100;smells horrible!;is really stinky! Example : broadcast chance=25;smells awesome!;smells overpowering! Description: \n\r\ All smell emote strings are separated by the semicolons shown above. The first parameter can be empty for defaults, or may contain a setting for minimum ticks (min=10), maximum ticks (max=20), the percept chance of occurrence after the random number of ticks has expired (chance=25), a total number of occurrences before expiration (expires=0), or a tag to make the emote broadcast to adjacent rooms (broadcast). In the first example every 10-20 ticks, there is a 25% chance that the object with this property will select one of the emotes randomly and perform it for all those in the same room who can see it. In the second example, a emote will be performed 25% of the time, but will only emote 100 times before the behavior is removed from the object. In the last example, a emote will be performed 25% of the time in the room of the behavior, and in any adjacent rooms.

The "GenMap"

A GenMap is a readable item that will automatically map out the rooms of the specified area(s).  Level is uniquely significant on a GenMap.  A level of 0 means the map will be built without access to any indoor rooms or areas behind secret exits.  A value of 1 means the map will be built with both indoor and outdoor rooms, but without secret rooms.  Any other value will display each and every room, regardless.  A room that is classified as "in the air" will never be placed on a map.

Whenever a GenMap is created, much like the GenArmor above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GetItem, plus one more:

Property	Description
Area List	List here the names of the areas which will be displayed on the map, separated by semicolons. If you have a "MyArea", and a "HisArea", you might enter them here as "MyArea;HisArea" (without the quotes).

The "GenKey"

Keys are things required to unlock doors and containers with locks. 

Whenever a GenKey is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under Genitem, plus one more:

Property	Description
Key Code	The text entered here must match exactly the assigned key code for the door or container lid which this key opens.

The "GenStaff"

A GenStaff is a type of GenWeapon which also behaves like a wand.  This means that it has an invocation word which must be spoken to activate the spell inside it.

Whenever a GenStaff is created, much like the GenWeapon above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenWeapon, plus one more:

Property	Description
Assigned Spell	List here the name of the spell which is cast by this staff.  If left blank, the staff becomes mundane.  Check the list of spells for ones to use.  Also, don't forget to set the "Uses Remaining" field to give the staff some charges!

The GenStaff, like the GenWand below, is activated by first wielding it, and then by speaking or saying the magical triggerword to the target. 

The "GenWand"

GenWands are items which must be worn/held and a magic word spoken in order to activate an innate spell.  To cast a wands spell on a creature or item, the word must be spoken to the creature or item directly.

Whenever a GenWand is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus one more:

Property	Description
Assigned Spell	List here the name of the spell which is cast by this wand.  If left blank, the wand is little more than a fancy stick.  Check the list of spells for ones to use.  Also, don't forget to set the "Uses Remaining" field to give the wand some charges!

The GenWand, like the GenStaff above, is activated by first holding it in ones hand, and then by speaking or saying the magical triggerword to the target. 

The "GenPill", "GenPotion", "GenPowder", and "GenMultiPotion"

GenPills are edible items which impart their spell after eating.  GenPowders can have their magic thrown on targets.   GenPotions and GenMultiPotions do the same when they are drank.  The difference between them is that GenPills and GenPotions vanish after drinking/eating. GenMultiPotions may be drank from many times to receive their magic.

Whenever a GenPill, GenPowder, or GenPotion is created, much like the GenArmor above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus a few more:

Property	Description
Assigned Spells	List here the names of the spells which are cast upon the eater of the pill or drinker of the potion.  Check the list of spells for ones to use.  Each potion and pill may only be used once, though an empty potion flask may be refilled with water if one likes.
Nourishment/Eat	when eaten, how much nourishment does the pill provide.  1000 would represent a full day of eating, while 300 would represent a single meal.  100 would represent a snack.  You could make a magical smorgasborg if you like!
Quenched/Drink	when drunk out of, how much of the total capacity is consumed.  A value of 500 represents a full day of drinking, while 100 would represent a full glass.  Keep in mind that when a potion is potent (contains its magical substance), the potion is entirely consumed.  Only when the potion container is refilled with water does this apply.
Amount of Drink Held	the amount of total drink held by the potion.  Each time the contents of the potion is drunk, the amount represented by Quenched/Drink is subtracted from this.  When this number reaches 0, the potion container is empty and must be refilled with something mundane, like water.

The "GenSuperPill"

The GenSuperPill is a special kind of GenPill which does not create a spell effect, but has other, more permanent benefits!

Whenever a GenSuperPill is created, much like the GenPill above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus two more:

Property	Description
Assigned Spell or Parameters	The GenSuperPill has all of the properties of the GenPill, but with a few more capabilities.  Spells, separated by semicolons, may be listed in this field.  Make sure the names are typed exactly, however, or the pill will fail!  In addition, certain adjustment parameters may be typed in, to give the pill an extra "punch".   These adjustment parameters are too numerous to list here.  I suggest you enter "help parameters", and look at the entry for "Prop_HaveAdjuster". The parameters for GenSuperPill will appear the same, though GenSuperPills can also boost experience using "expe+10" or "expe-20", or reset a players recall room to their current room using "beacon+1".   Another important difference from Prop_HaveAdjuster is that the effects of a pill are PERMANENT!!!
Nourishment/Eat	when eaten, how much nourishment does the pill provide.  1000 would represent a full day of eating, while 300 would represent a single meal.  100 would represent a snack.

The "GenScroll"

A GenScroll is a readable item that has spells written on it.  These spells may be discovered through the "Read Magic" spell, and written on using Scribe.  Spells can be learned from scrolls using Scroll Copy. 

Whenever a GenScroll is created, much like the GenPill above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus one more:

Property	Description
Assigned Spells	List here the names of the spells which are written upon the scroll.  Check the list of spells for ones to use.  Remember to set the uses remaining field so that the scroll can have a little clarity!

The "GenTitle"

A GenTitle is  a piece of paper which designates ownership of a piece of property.  A piece of property can only be a room or a set of rooms with Prop_RoomForSale, Prop_RoomsForSale, or Prop_LotsForSale on it.  Titles are unique in that whenever they are GIVEn to another player, the property changes ownership.  Although titles can be created by archons and given to shopkeepers to sell, the usual method for putting land up for sale is to create a shopkeeper of the type LANDSELLER (see shopkeepers below).  This will automatically populate the shopkeeper with titles to all properties for sale in his or her area.

Whenever a GenTitle is created, much like the GenPill above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus one more:

Property	Description
Assigned Spells	List here the names of the spells which are written upon the scroll.  Check the list of spells for ones to use.  Remember to set the uses remaining field so that the scroll can have a little clarity!

The "GenLawBook"

A GenLawBook is a Journal-Like document containing 10 pages of detailed information about the laws in the area for which it is "written".  An Area must have either the "Arrest" or "Conquerable" behaviors in order to have any laws for the law book to list.  If the Area has the Arrest behavior with a property of "custom", then Archons and staff may also use the GenLawBook to modify aspects of the law in that area.  If the Area has the "Conquerable" behavior, then either the Archon, staff, or duly authorized clan member may use the book to modify law.

Whenever a GenLawBook is created, much like the GenReadable above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenReadable, though one of the properties has a slightly different meaning:

Property	Description
Readable Text	This field is reserved for the Name of the area for which this law book refers.  The area named here must have the Arrest or Conquerable behaviors for the law book to work properly.

The "GenPortal" and "GenMobilePortal"

A GenPortal is Rideable type item that can act as a gateway between two rooms via the ENTER command. The item can be made gettable or not, blended or not, having all the advantages of a standard item, while still getting you from here to there like an Exit. The Rideable-specific fields Rideable Type and MOBs Held are also unchangeable due to the specific nature of the portal, although you will see them listed on the editor screens.  They also share the same re-closing and re-locking behaviors noted above with GenContainers.

GenMobilePortal is a GenPortal with a unique feature.  The GenMobilePortal expects that it's assigned destination room ALSO contains a GenPortal in it.  If so, then every time the GenMobilPortal is moved by a player carrying it from place to place, the target for the paired GenPortal will also be changed to reflect the move.

Whenever a GenPortal is created, much like the GenRideable above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged:

Property	Description
Assigned Room IDs	This field is the room ID of the room to which the portal will take you, or a list of rooms (separated by semicolons) to which the portal might take you.
Exit Direction Name	This field, when not blank, will cause the portal to be listed among the exits in the room. This field will hold the name of the direction, while the portal's "Name" will be the room description.
Exit Closed Text	If the Exit Direction Name is not empty, and the portal has a door/lid, then this field will be displayed instead of the "name" in the exits list.

The "GenClanItem", "GenClanCommonContainer", "GenClanApron", "GenClanCommonItem", "GenClanContainer", "GenClanFlag", "GenClanPamphlet", and "GenClanSpecialItem"

The above are all basis for the items created by the Clan Crafting skill.  The GenClanItem and GenClanContainer are standard holdable items assignable to clans, usually for the purpose of use with the Conquerable behavior on Areas.  They are only gettable by members of the clan to whom they are assigned, and have properties to allow them to be captured by other clans as well.  The GenClanCommonItem and GenClanCommonContainer cause their mob holders to perform tasks. The GenClanFlag holds a conquered area in place, and provides Conquerable behavior information. The GenClanApron makes the holder into a shopkeeper. The GenClanPamphlet makes the holder a dissident and multiplies in rival clan areas, and the GenClanSpecialItem performs miscellaneous tasks when found in a conquered area.

Clan items all have a Clan Item type, which must usually be matched with the proper GenClan class type from the list above in order to work effectively.  Here is a proper mapping:

Class Name	Clan Item Types
GenClanItem, GenClanContainer	"BANNER", "GAVEL"
GenClanCommonItem, GenClanCommonContainer	"GATHERITEM", "CRAFTITEM"
GenClanFlag	"FLAG"
GenClanPamphlet	"PROPAGANDA"
GenClanSpecialItem	"SPECIALSCALES", "SPECIALSCAVENGER", "SPECIALOTHER", "SPECIALTAXER"

Whenever a GenClanItem is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, plus a few more:

Property	Description
Clan ID	This field is reserved for the Name of the clan that this item belongs to.
Clan Item Type	This type of clan item, as described above.

The "GenWallpaper", and "GenFatWallpaper"

GenWallpaper is unique in that it is a non-gettable item which is never listed among the items in a room, but CAN be looked at.  It is intended to provide targets for the LOOK command based upon objects which might be mentioned in a room description.  Archons should make sure they have SYSMSGS turned on to edit wallpaper items, since they will not be noticed otherwise.   

GenFatWallpaper is the same as GenWallpaper, except that it also has a displayText field, so that it can be seen in a room.  However, like GenWallpaper, it can not be interacted with.

When GenWallpaper is created, you have only the name (which should contain key words for the LOOK command), the description that is seen, and whether or not it is also readable.

The "GenRecipe"

GenWallpaper is a complex but powerful tool for expanding the system of Common Skills in the CoffeeMud codebase.  A GenRecipe is a piece of paper upon which is written a recipe, schematic, or some other instructions for enhancing the list of things which can be crafted by players using their crafting Common Skills.  A player takes advantage of a recipe by mearly having the item in his or her inventory and using the appropriate skill for which the recipe was designed.

Designing a GenRecipe object is extremely complex.  After setting the "normal" GenItem fields for this item, such as name, readabletext, weight, value, etc, there are still the two key GenRecipe fields left to fill in: Common Skill ID, and the Recipe Data line.  The Common Skill ID identifies which of the common skills is served by the recipe.  The Data line describes in detail the item which can be created by players with this recipe on hand.  The format of the data line is a series of comma-delimited values which are defined for each common skill uniquely.  There are two ways of determining the number and nature of each value for the data line.  One is to open the appropriate common skill *.java file in the /com/planet_ink/Abilities/Common/ directory on your computer and observing the several lines near the top of the file which begin with "protected static final int RCP_".  The number, order, and nature of the values will be identical to these variable definitions.  The second way is to open the appropriate *.txt file for the common skill in the /resources/skills/ directory (such as weaponsmith.txt or pottery.txt) and noting the first line of the file.  The first line in most cases will be a guide to the number and nature of the field values. 

The "GenInstrument" and "GenPiano"

The GenInstrument represents a musical instrument for the purposes of the several Minstrel spells.  They differ only in that the GenPiano is also like a GenRideable mentioned above, in that it must be sat on to play.

Whenever a GenInstrument is created, much like the GenRideable above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include everything listed under GenItem, and GenRideable for the GenPiano, plus one more:

Property	Description
Instrument Type	This is the general classification of the instrument for the purposes of several of the Minstrel songs.

The "GenLimb"

This strange item represents both false limbs and real replaceable ones.

Whenever a GenLimb item is created, much like the GenContainer above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenItem, though some have slightly different meanings:

Modifying Items

There are properties of items, armor, weapons, and containers that can be modified by the Archon.  If one wishes to modify a dagger, one must either hold the dagger, or have the dagger present in the room.  The Archon can then issue the command "modify dagger".  If the item is a GenItem, GenContainer, GenFood, GenWater, GenDrink, GenWeapon, or any other "Gen" item, then the same properties as above will be presented. 

Like rooms and areas, there are a very rich selection of Behaviors you may choose for items.  Here are our favorites:

"Decay" for items that are only around for a limited time.
"DelayedTransporter" to make an item that moves people around.
"Emoter" to make items behave in random and cute manners.
"FasterRecovery" makes the owner or rider recover stats faster.
"Follower" will make items follow players and mobs around.
"InstantDeath" to cause an item to kill someone.
"RandomItems" will cause items from a saved file to appear in a container item.
"ItemGenerator" will create treasure and items for your container items.
"Mime" to make an item mimic the socials that players do.
"Patroller" makes the item travel a route you specify, even when ridden.
"Scriptable" allows you to script the behavior of the item based on triggers.
"Sounder" to add new color to item usage.

Items also benefit from effects, just like rooms, areas, and exits.  Here are some important effects you may consider for your items:

"Burning" sets an item on fire.
"Chant_ChargeMetal" makes an item attract electricity.
"Chant_Shillelagh" makes wooden weapons more deadly.
"Falling" sets an item as falling.
"Prop_AbilityImmunity" protects the item from specified targeted spells.
"Prop_AbsorbDamage" makes the item absorb damage from certain attacks.
"Prop_AddDamage" makes the item owner sustain extra damage.
"Prop_ClosedDayNight" makes an item disappear at night.
"Prop_ClosedSeason" makes an item disappear for a season.
"Prop_FightSpellCast" makes a weapon cast a spell when it hits.
"Prop_HaveAdjuster" modifies the owners stats.
"Prop_HaveResister" modifies the owners saving throws.
"Prop_HaveSpellCast" gives a spell effect to the owner.
"Prop_HaveZapper" restricts ownership.
"Prop_Hidden" makes an item hidden, temporarily.
"Prop_Invisibility" makes an item invisible.
"Prop_ItemTransporter" makes an item that transports things.
"Prop_ItemTransReceiver" makes an item receives transported things.
"Prop_LangTranslator" makes the item a translator of languages.
"Prop_LimitedItems" can limit the number of a particular item ever to be owned.
"Prop_LocationBound" limits where an item can be taken from.
"Prop_ModExperience" modifies experience gained when holding/wielding/wearing this.
"Prop_NoDamage" makes the item incapable of doing damage.
"Prop_NoPurge" makes the item a permanent piece of garbage.
"Prop_NoRecall" makes the item prevent recalling.
"Prop_OpenPassword" gives a container a secret opening word.
"Prop_RideAdjuster" modifies the mounted persons stats.
"Prop_RideEnabler" gives the mounted new skills.
"Prop_RideResister" modifies the mounted persons saving throws.
"Prop_RideSpellCast" gives a spell effect to the mounter.
"Prop_RideZapper" restricts mounting.
"Prop_RoomView" makes an item that gives you a view of something else.  A window maker!
"Prop_ScrapExplode" makes the item explode when the scrap common skill is used on it.
"Prop_Smell" gives the item an aroma when using the SNIFF command.
"Prop_SpellAdder" makes the item cast a spell on those who come near it.
"Prop_SpellReflecting" helps make a shield that reflects magic.
"Prop_TattooAdder" makes an item that grants one a tattoo.
"Prop_TicketTaker" makes a rideable that requires money to board.
"Prop_Trashcan" makes a container that destroys things placed inside.
"Prop_UseSpellCast" makes an item that spell-affects the owner when filled, worn, placed in, wielded, or held.
"Prop_UseSpellCast2" makes an item that spell-affects the one who gets, eats, or drinks from it.
"Prop_WeaponImmunity" makes an item grant attack immunities.
"Prop_WearAdjuster" modifies the wearers stats.
"Prop_WearEnabler" gives the wearer skills.
"Prop_WearResister" modifies the wearers saving throws.
"Prop_WearSpellCast" gives a spell effect to the wearer.
"Prop_WearZapper" restricts wearing/wielding/holding.
"Spell_Boomerang" makes an item very loyal to the owner.
"Spell_ContinualLight" makes an item shine!
"Spell_Fly" makes an item fly around.
"Spell_LightenItem" makes an item lighter.
"Spell_MagicalAura" gives an item a magical aura.
"Spell_Shrink" makes an item smaller.
"Spell_WizardLock" makes a container harder to open.
"Prayer_BlessItem" makes a weapon harder hitting.
"Prayer_CurseItem" makes a weapon worse at hitting.
"Prayer_FlameWeapon" makes a weapon flame striking.

Lots of traps are available to make items more perilous: "Bomb_AcidBurst", "Bomb_Explosive", "Bomb_FlameBurst", "Bomb_Noxious", "Bomb_Pepper", "Bomb_Poison", "Bomb_Smoke", "Bomb_Spores", "Bomb_Water", "Trap_AcidSpray", "Trap_Boomerang", "Trap_ElectricShock", "Trap_Get", "Trap_GetBlade", "Trap_GetGas", "Trap_GetNeedle", "Trap_GetSpell", "Trap_Gluey", "Trap_Greasy", "Trap_Ignition", "Trap_Infected", "Trap_Launcher", "Trap_Needle", "Trap_NeedlePrick", "Trap_Noise", "Trap_Open", "Trap_OpenBlade", "Trap_OpenGas", "Trap_OpenNeedle", "Trap_OpenSpell", "Trap_PoisonGas", "Trap_Popper", "Trap_SleepGas", "Trap_Spark", "Trap_SpellBlast", "Trap_SporeTrap", "Trap_Trap", "Trap_Unlock", "Trap_UnlockBlade", "Trap_UnlockGas", "Trap_UnlockNeedle", "Trap_UnlockSpell", "Trap_Vanishing", "Trap_WeaponSwing"

Lots of poisons are available to make weapons more deadly, or drinkables into poisons - "Poison_Alcohol", "Poison_BeeSting", "Poison_Bloodboil", "Poison_Decreptifier", "Poison_Firebreather", "Poison_Ghoultouch", "Poison_GoblinDrip", "Poison_Heartstopper", "Poison_Liquor", "Poison_Mindsap", "Poison_Peppersauce", "Poison_Rotten", "Poison_Slumberall", "Poison_Venom", "Poison_XXX"

For  "non-Generic" items, the following properties will be presented during modification (see Appendix A for more information):

Property	Description
Level	the level of the item, dictating the lowest level a character must attain to possess or hold it. See Appendix A for more information on this field.
Magical Ability	This number represents an adjustment to the items magical properties.  If the item is any sort of armor, then this value will be the same as described above under GenArmor.  If the item is a weapon, then this value will be the same as described above under GenWeapon.  For all other items, aside from making the item appears magical, it has no other use whatsoever.  See Appendix A for more information on this field.
RejuvTicks	This number represents the number of ticks (where a tick is roughly 3 seconds) before an item, which has been removed from the room, rejuvenates or resets to its proper state.  The value '2147483647' or '0' means that the item never rejuvenates, but once picked up and brought out of the room, is gone forever.  Any other value will represent a number of ticks.  This property does not take effect until the room is saved.  For more information on making the RejuvTicks property take effect after changing it, see below under Rejuvenating Items and Mobs" or "How to Save a Room".
UsesRemaining	for scrolls, lanterns, ammunition, staves, and wands, this represents the number of times the item may be used again before expiring.  For all other items, this field has no purpose whatsoever.
MiscText	the meaning of this field differs entirely from item to item.  For most weapons and armor, it means nothing.  For readable items, it represents the text written upon it.  For scrolls, it is the spells that are scribed upon it. For a StdKey, it is the key code that must match the door the key will open (see above under GenExit).   See Appendix A for more information on this field.

Destroying Items

To destroy an item that is either being held by you, or is in the same room as you, you need only issue the destroy command.  For instance, if a dagger has offended: "destroy item dagger" wll make it go away.

Once destroyed, items that have been set to rejuv will not do so.  If the item was a permanently saved item in the room, you must re-save the room in order to make the items destruction permanent.

Tools of the Trade

The Archons of your realm have lots of items that assist them in building and administering their mud.  Lets take a look at these:

The Archon Staff  (CREATE ITEM ARCHONSTAFF) - the Archon Staff is the main tool of the true Archon.  Also available from the OUTFIT command, it not only provides a deadly weapon, but a useful source of magical power.  To use the powers of the staff, it must first be wielded.  It is a two-handed item, so the Archon's held position must be given up for it as well.  Once wielded, numerous magical words invoke the power: say targetname "refresh" will rejuvinate the targets mana, hit points, and movement; sayto targetname "level up" will give the target a free level of experience; sayto targetname "level all up" will level the target up to 91; sayto targetname "burn" will blast the target with hellish fire.

The Wand of the Archons (CREATE ITEM WANDARCHON) - the Wand of the Archons is the one-handed alternative to the Archon Staff.  It is also available only to true Archons.  To use the powers of the wand, it must first be held. Once held, numerous magical words invoke the power: say targetname "refresh" will rejuvinate the targets mana, hit points, and movement; sayto targetname "level up" will give the target a free level of experience; sayto targetname "level all up" will level the target up to 91; sayto targetname "burn" will blast the target with hellish fire.

The Goody Bag (CREATE ITEM GOODYBAG) - The Goody Bag is full of fabulous prizes which Archons may dispense to players.  What's better, an item that is removed is always replaced, so that the bag never runs out.  Inside the goody bad are piles of currency, pills to gain stats or experience, and others goodies.

Ingredients Sack (CREATE ITEM INGREDIENTS) - The Ingredients bag has exactly one of every kind of natural resource the system offers.  Removing one from the bag will automatically replace it, so the bag never ever runs out.

Creating MOBs

Greater even than the mages powerful spells of summoning is the Archons ability to conjure beasts into caverns and townspeople on to streets.  To do this, the Archon need only issue the create command once again.  Summoning a goblin into an ordinary room is as simple as entering "create Goblin".  This will create a standard Goblin in the room you are standing in.  To make him stay there, even after you reboot, you must save the room as described in the section below on saving rooms.

To find out what mobs are available for you to create, you can enter "list mobs".  Entering "create <mobname>" will prove the true incantation for almost all of the creatures on this list.  An exception, however, is the GenRideable.  Since there is both an Item and a MOB version of that name, you will need to further qualify your create command by entering "create mob GenRideable" or "create item GenRideable".

If you wish to create your goblin a Grid-type locale, extra consideration is required.  Locale types like MountainsGrid, WoodsGrid, WoodsMaze, PlainsGrid, DesertMaze, etc.. can all contain nasty monsters in them.  However, two rules need to be followed for this magic to work properly.  The first is that you can only save creatures which are in the parent Grid room itself.  If you have SYSMSGS on, you can tell which room this is because it is the only one with a simple room ID ("MyArea#123") in the description. Since no one ever actually walks into the parent Grid room, the only way to get to it is using the Archon GOTO command.  The second of the two rules is that you must give the mob a Mobile behavior.  The mobile behaviors are specially coded so that they will take the monster to a random room inside the grid the first time the thing tries to move. 

The "GenMob" and "GenUndead"

Whenever a GenMob or GenUndead is created, much like the GenItem above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The only difference between the GenMob and GenUndead is that the GenUndead can be TURNed by a Cleric, while a GenMob cannot.  The properties include:

ShopKeepers are folks that buy and sell equipement that is given to them by Archons.  ShopKeepers can sell anything from items to creatures, skills as a teacher, or spells for a price. 

ShopKeepers designated as Land Sellers will sell any rooms in the same area as the shopkeeper which has the Prop_RoomForSale, Prop_RoomsForSale, or Prop_LotsForSale properties.  Use "AHELP Prop_RoomForSale" for more information on this effect you may add to rooms.  ShopKeepers designated as Clan Land Sellers will do the same, but only for Clan members.   In this way, players and clans can buy and own their own rooms where their property will be safe during reboots, and pets can become permanent fixtures.  This is also the way the Construction, Masonry, Locksmith, and other property-related skills can become useful.

ShopKeepers can also be Inn Keepers.  To make this work, you need only give the shopkeeper a number of StdInnKey items equal to the number of rooms in your inn.  For each room in your inn, make sure you have a locked door for each room, and that each of the locked doors in your inn has a key code equal to "INN1", "INN2", etc.. up to the number of locked doors for each room in the Inn.  Players will then buy the keys to rooms, and the keys will automatically return to the shopkeepers stock after a single mud "day".  The only other trick to making a successful inn is to make sure you do the "reset room" command to the room with the innkeeper in it, after the keys have all been given to him, and the room has been saved.

ShopKeepers are much more savvy about money and economy than most.  They will often draw not only from the loose gold a player has, but any high-denomination Notes the player has in his or her inventory.  The ShopKeeper will also give change in this manner.  The player will often need to check the "change bag" newly arrived in their inventory to see the change that a ShopKeeper might have given them.  These change bags will often contain the high-denomination notes mentioned before (such as a Golden Note, or a Half Note).  Each of these notes are convertable into loose gold merely by GETting them from the change bag. 

Whenever a GenShopKeeper is created, much like the GenMob above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenMob, plus a few more:

Property	Description
Type	a shopkeeper can sell Anything, General items, Armor, Miscellanous magic items not included amongst armor or weapons, Weapons, Pets, Leather items, Only buys the things he also sells (but sells whatever you give him to sell), Trains players in spells, prayers, skills, or songs, Casts prayers, spells, or songs on the buyer, Potions, Land, and more!  All shopkeepers can also buy what they sell, excluding Trainers and Casters.
Inventory	this is where you would "stock" your shopkeeper with items that match their type.  You may add to this list by entering the class names of any standard items, standard mobs, or abilities.  You may also enter the name of any stray items or mobs hanging out in the same room as the shopkeeper to put them up for sale.  This last is the best and only way to get Generic items and mobs onboard.  When an item is put up for sale, you may specify the number of items like it the shopkeeper has in stock, and a price for the item.  You may also specify a price for the item.  There are many different values you can put in the price field.  * A given price of 0 or higher will ensure that the item will have that price in local currency.  For example.  The price is expressed in multiples of the the base value.  A price value of 20 will mean that the item costs 20 gold to buy, before adjusting for charisma and other factors, assuming gold is valued at 1.0 of base.  If the local currency has only Latinum Bars valued at 0.5, then a price value of 20 here would yield a 40 Latinum Bars price to consumers. * A given price of -1 means that you are allowing CoffeeMud to price the item for you.  This should be the recommended entry unless you know what you are doing. * A given price between -2 and -100, or -1000 is invalid! * A given price between -101 and -999 will designate some number of Quest Points to charge for the item.  The number of quest points is determined by taking the absolute value of your given price and subtracting 100.  So a given price of -135 would mean that the item costs 35 quest points. * A given price of -1001 or lower will designate some number of Experience Points to charge for the item.  The number of experience points is determined by taking the absolute value of your given price and subtracting 1000.  So a given price of -1001 would mean that the item costs 1 experience point, while a price of -9876 would mean that the item costs 8876 experience points.
Prejudice Factors	This complicated field is where you can adjust the prices the ShopKeeper sells from the programmed normal.  It always works in tandem with the Devalue Rate below, as well as such factors as the Charisma of the player dealing with your shopkeeper. An unspecified value here will always return a value of 1.0 (which means NO adjustment).  However, you may enter one or more adjustments separated by semicolons (;).  Here is an example: SELL=5.5 Elf Dwarf ; BUY=0.4 Elf Dwarf ; SELL=1.0 ; BUY=1.0 Each adjustment must begin with the words "SELL=" or "BUY=" followed by a Real number designating the adjustment from normal.  "SELL=" refers to the adjustment to prices players get when selling TO the shopkeeper.  "BUY=" refers to the adjustment to prices players get when buying FROM the shopkeeper.  A value above 1.0 for either of those will raise the applicable prices.  A value below 1.0 (like 0.3 or 0.75) will lower prices.  Values of 0.0 are NOT allowed.  If you need to all but not allow buying and selling, a value of 0.000000001 should do.  Each adjustment may also contain the name of one or more Racial Categories (Elf, Dwarf, Gnome, Halfing, etc..).  If a Racial Category is specified, then the adjustment will ONLY apply to that race.  The adjustments are read from left to right, so adjustments without any racial categories should be listed LAST.  In the above example, Dwarves and Elves are given a very good deal, where everyone else gets a normal one.  In addition to Racial Categories, you may also list alignments (good, neutral, or evil), a sex (male, female, and neuter), a character class, or the name of a faction range.  Remember that this field is evaluated from left to right, so any matches made on the left that apply to a player will cancel evaluation of the rest of the field!   Just as bonus feature, if the adjustment begins with the words "LIMIT=", then you may enter a number representing the maximum number of rows of inventory the shopkeeper will display whenever a LIST is done.  If the adjustment begins with the words "RANGE=", then you may enter either a number or a percentage. This number will represent the maximum and minimum level range of the items which the shopkeeper will purchase from players. This level range is relative to the median level range of his area. For instance, if the median level of the shopkeepers area is 10, and RANGE=3 is entered, then the shopkeeper will only purchase items between levels 7 and 13. A value of 0 means no limit and no range, of course. These features have no relation with the above prejudice functionality -- they're just bonus.
Budget	This field is used to define the maximum amount of local currency, per a defined time period, which shopkeepers will spend when buying equipment from players. The format of the field is an amount of money (in base values only) followed by the name of period (HOUR, DAY, WEEK, MONTH, YEAR). All of these time periods are **MUD** time periods, where one hour is about 10 minutes of real life time. For example, a value of "200 DAY" means that the shopkeeper will not buy more than 200 gold per day of any equipment from players, assuming that gold=1.0 in currency value.
Devalue Rate	This field is used to limit the number of EACH PARTICULAR item that a shopkeeper will keep in his inventory. This provides a ceiling therefore on the number of unique items of a kind which a shopkeeper will purchase from players. The way this field works is by defining how far the price drops, in percentage, every time the player sells an item to a shopkeeper. Decimals (real numbers) are allowed in this field. This field may also be used to differentiate between the rate of devaluation of raw resources and other finished items. A single integer field would represent the devaluation percentage of all items, while a field with two integers seperated by a space would represent the devaluation of finished items and raw resources respectively. For example, a value of "20" would mean that the shopkeepers value price drops by 20% every time this shopkeeper buys a particular item. If the shopkeeper buys two, it would be 20%. Three would be 60% and so forth. This effectively limits the shopkeeper to buying to more than 5 of any item (5 * 20) == 100%. A value of "20 0.5" would mean a devaluation rate of 20% for finished items, and 0.5% (1/2%) for raw resources. By default, shopkeepers devalue at a rate of 20% and 0.2%, which is defined in the coffeemud.ini file.  If you want a particular shopkeeper to never devalue items, set the value of this field to 0 (meaning no devaluation).
Inventory Reset Rate	This is the rate, in ticks (4 second periods) at which the shopkeeper totally resets his inventory back to the last saved "stock" items. Leave this field empty to use the INI default, or not to have a reset rate depending.

A Banker is a special type of ShopKeeper that holds money and items in a special private account for players.  Bankers can pay or charge interest on money left in the account, and charge interest on items left with them.  Bakers can also loan money based on those same items as collateral, and automatically handle interest and payment plans. A Banker may also be designated as a Clan Banker, meaning that it will only deal with Clan Treasurers.

Whenever a GenBanker is created, much like the GenShopKeeper above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenMob and GenShopKeeper, plus a few more:

Property	Description
Coin Interest	This is the amount of interest paid (or CHARGED if negative) every game month (about once a real day) on gold money left in a players account.
Item Interest	This is the amount of interest paid (or CHARGED if negative) every game month (about once a real day) on items left in a users account.
Loan Interest	This is the amount of interest charged every game month (about once a real day) on gold money loaned to players or clans account.
Bank Name	This is a unique identifier for the bank chain. All GenBankers with the same Bank Name will offer the same accounts to players.

The "GenPostman"

A Postman is a special type of ShopKeeper that delivers items from one postman in the branch to another.  Each postman holds a special private box for players or clans.  Postman can charge to deliver items from one box to another, and can charge for the amount of time an item remains in a box.  Every player receives a free box with any postman in the same area as their Recall/Beacon point.  Other boxes with other postmen must be purchased.  Clans must always purchases their boxes.

Whenever a GenPostman is created, much like the GenShopKeeper above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenMob and GenShopKeeper, plus a few more:

Property	Description
Postal Chain	This is a unique identifier for the postal chain. Postmen will only deliver mail among members of the same chain.  Player/Clan boxes are opened with individual postmen, however.
Fee to open a new box	This is the amount of money charged to open a new box with a postman.  The money is expressed in terms of base value, though the currency accepted will reflect the area where the postman is.
Minimum postage cost	This is the minimum amount of money charged players to deliver an item.
Postage cost per pound after 1st pound	This is the amount of postage money charged, per pound of the item, for each pound over the first one.
Holding fee per pound per month	This is the amount of money charged every mud month that an item remains idle in a postal box.  The first month is always free.
Maximum number of months held	This is the maximum number of mud months which a postman will hold an item idle in a postal box.  After this duration expires, the postman will put the item up for sale to recoup losses.

The "GenRideable"

Whenever a GenRideable is created, much like the GenMob above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenMob, plus a few more:

Property	Description
Rideable Type	the type of rideable item this is, from a floater to a flyer, etc.
MOBs Held	th emaximum number of mobs which may ride this animal at once.

The "GenDeity"

Deities are the employers of Clerics, and the object of some players adoration and worship.  Deities are necessary for the DEITIES command to work, and add great role playing opportunities for all players, though especially Clerics, since only with deities does their Convert skill have any meaning.  Since deities of this sort being attacked and killed can have a negative effect on game-play, it is important that deities be placed in a room where they will be save from players.  Give the room where your deities are Prop_NoSummon and Prop_NoTeleport to keep mages from zapping deities in or out of their safe room. 

There are a few important points to understand about these supreme beings before continueing.   Deities may have separate requirements for who may worship them, and who may be their clerics.  You will specify these below.  Deities may also have a list of blessings they may bestow upon their clerics and their non-cleric worshippers.  When their clerics perform a special clerical ritual, the deity will give the cleric ALL of his blessings.  When a non-cleric worshipper performs the special worshipper ritual, the deity will give the worshipper one random blessing.  Leaving these rituals blank prevents the deity from bestowing the proper blessings.  You will specify all of these things below as well.  Deities may also have a list of curses that they bestow as punishment for sin.  When the clerics perform the cleric-specific sinful ritual, the deity will inflict all of his curses upon the cleric.  When a non-cleric worshipper performs the worshipper-specific sinful ritual, the deity will inflict one random curse upon the worshipper.  Whether these curses exist, how many there are, and whether there are any sinful rituals are all specified below.  The last point is about special clerical powers.  Deities may give one of their clerics a skill/spell/prayer/whatever as a special power after the cleric has performed the specified clerical power ritual.  This power is taken away should the cleric ever rebuke the deity.  Whether this power exists is specified below.

Whenever a GenDeity is created, much like the GenMob above, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include all of the fields listed above under GenMob, plus a few more:

Property	Description
Cleric Requirements	This field describes the requirements for a cleric to work for this deity. The value in this field include the same mask format as described in the help for Prop_WearZapper.  Check the help for that property, or enter AHELP PROP_WEARZAPPER from the command line for a list of the mask syntax used here.
Worship Requirements	This is where the requirements for becoming a worshiper of this deity is described. The values in this field are identical to the Cleric Requirements above. The only difference being to whom the mask applies (Clerics/everyone else).
Blessings	This field is a list of the spells, skills, prayers, blessings, or other Abilities which may be selectively granted by the deity to his or her worshipers. All of the listed blessings are typically granted to Clerics of the deity.
Cleric Ritual	For a cleric to receive the blessings of the deity, the cleric must perform a particular ritual consisting of one or more actions. This field will list the tasks in the ritual which must be performed. Each task is separated by a "|" to mean that either of the tasks on either side of the "|" is sufficient, or a "&" to mean that both of the tasks on either side of the "&" is required. The tasks themselves must be of one of the following forms: SAY [TEXT] - the text specified must be said by the player. For example: SAY "Allah is Great" TIME [HOUR] - the other tasks must be performed at the specified hour. For example: TIME 3 PUTTHING [THING NAME] [CONTAINER NAME] - an item of the type must be placed in the specified container. For example: PUTTHING dagger pit BURNTHING [THING NAME] - an item of the type given must be burnt or set afire. This is typically done with the FIREBUILDING skill. For example: BURNTHING the ceremonial log EAT [FOOD NAME] - the specified item must be eaten. For example: EAT holy pie. READ [ITEM NAME] - the specified item must be eaten.  For example: READ holy book. DRINK [DRINK NAME] - the specified drink must be consumed. For example: DRINK holy fountain INROOM - the player must be in the specified room number, or the word holy to designate a room with infused holiness. For example: INROOM NewArea#123 RIDING - the player must be on the specified mount. For example: RIDING holy altar CAST - the player must cast the specified spell. For example: CAST Prayer_Bless EMOTE - the player must emote the following thing. For example: EMOTE kneels before the throan PUTVALUE [MINIMUM VALUE] [CONTAINER NAME] - an item worth at least the specified amount must be placed in the specified container. For example: PUTVALUE coins pit PUTMATERIAL [MATERIAL TYPE] [CONTAINER NAME] - an item made of the specified material must be placed in the specified container. For instance: PUTMATERIAL cotton pit BURNMATERIAL [MATERIAL TYPE] - an item made of the specified material must be burnt, such as using the FIREBUILDING skill. For instance: BURNMATERIAL balsa BURNMATERIAL [MINIMUM VALUE] - an item worth at least the specified amount must be burnt, such as using the FIREBUILDING skill. For instance: BURNVALUE "wooden statue" RANDOM [PERCENTAGE NUMBER] - happens % of the time.  For example: RANDOM 10 CHECK [REQUIREMENT STRING] - Use this with care.  This allows masks to be entered which the player must meet.  The mask is of the same format as described in Cleric Requirements above. SITTING 0 - the player must be sitting (the 0 is required!) STANDING 0 - the player must be standing (the 0 is required!) SLEEPING 0 - the player must be sleeping (the 0 is required!) WAIT [#TICKS] - a pause of #TICKS is required -- this should be no MORE than 10, to use multiple WAITs in a row for longer pauses.  Also, never make this the first possible trigger -- you always want this between 2 things they must do (&). YOUSAY - if the previous item was completed (&), then the person doing the ritual will automatically say the text. ALLSAY - if the previous item was completed (&), then everyone in the room will automatically say the text. OTHERSAY - if the previous item was completed (&), then everyone in the room except person doing the ritual will automatically say the text.
Worshipper Ritual	For a worshipper to receive one of the blessings of the deity, the player must perform a particular ritual consisting of one or more actions. This field will list the tasks in the ritual which must be performed, and uses the exact same format as the Cleric Ritual field above.
Curses	This field is an optional list of the spells, skills, prayers, curses, or other Abilities which may be selectively inflicted by the deity upon his or her worshipers. All of the listed curses are typically inflicted on Clerics of the deity.
Clerical Sin	For a cleric to receive the above curses of the deity, the player must perform a particular ritual consisting of one or more actions. This field will list the tasks in the ritual which must be performed, and uses the exact same format as the Cleric Ritual field above.
Worshipper Sin	For a non-cleric worshipper of the deity to receive one of the above curses of the deity, the player must perform a particular ritual consisting of one or more actions. This field will list the tasks in the ritual which must be performed, and uses the exact same format as the Cleric Ritual field above.
Powers	This field is an optional list of the spells, skills, prayers, curses, or other Abilities which will be randomly chosen from to give to clerics who perform the clerical power ritual.
Clerical Power ritual	For a cleric to receive one of the above powers of the deity, the player must perform a particular ritual consisting of one or more actions. This field will list the tasks in the ritual which must be performed, and uses the exact same format as the Cleric Ritual field above.

There are properties of mobs that can be modified by the Archon.  If one wishes to modify a goblin, the goblin must be present in the room.  The Archon can then issue the command "modify goblin".  If the mob modified is a GenMob or GenUndead, then the same properties as above will be presented.  . 

Although there are exceptions, MOBs will be the primary beneficiary of Behaviors.  For Generic MOBs, you will find many useful Behaviors which will add great depth to your MUD.  It is highly recommended that any Archon wishing to create a rich and wonderous universe spend time perusing the help files to learn of the wonders of the Behaviors and Effects.  Here are some useful behaviors:

"Aggressive" makes the mob attack others.
"AlignHelper" makes the mob defend same alignments.
"AntiVagrant" makes the mob wake up stragglers on the street.
"Bardness" makes the mob fight with bard skills.
"Beggar" makes the mob beg for money.
"BribeGateGuard" makes the mob a gate guard who can be bribed.
"BrotherHelper" makes the mob defend similar mobs.
"ClanHelper" makes the mob defend clan buddies.
"Clericness" makes the mob fight with cleric skills appropriate to alignment.
"CombatAbilities" makes the mob use its abilities in combat.
"CombatAssister" makes the mob assist specific other mobs in combat.
"CommonSpeaker" makes the mob speak common, even if it doesn't want to.
"CorpseEater" makes the mob eat corpses it comes across.
"CorpseLooter" makes the mob loot corpses it kills.
"Decay" makes the mob go away after a time.
"DelayedTransporter" makes a mob that randomly zaps around the place.
"DoorwayGuardian" makes a mob that won't let anyone pass.
"Drowness" provides certain drow-like behavior to genmobs.
"Druidness" makes the mob fight with druid skills.
"Emoter" makes the mob do the silly things you think of.
"EvilExecutioner" makes the mob slaughter good folks.
"FaithHelper" makes the mob defend those of the same faith.
"FightFlee" makes an annoying mob that runs away.
"Fighterness" makes a mob that fights with fighter skills.
"Follower" makes the mob follow folks around.
"GateGuard" makes a mob that opens, closes, unlocks, and locks a door.
"GoldLooter" makes  a mob that takes the loot from the vanquished.
"GoodExecutioner" makes  a mob that kills evil and thief mobs.
"GoodGuardian" makes a mob that stops fights and defends the helpless.
"Guard" always defends the attacked.
"Healer" makes the mob a random friendly healer.
"Hireling" puts the mobs abilities up for hire.
"InstantDeath" kills everyone in the room with the mob, after a time.
"ItemIdentifier" makes the mob an identifier for hire.
"ItemGenerator" will create treasure and items for your mobs inventory.
"ItemMender" makes the mob a mender for hire.
"ItemRefitter" makes the mob a refitter for hire.
"MOBEater" makes the mob eat its enemies.
"MOBHelper" makes the mob assist other mobs.
"MOBHunter" makes the mob hunt other mobs.
"MOBReSave" a bizarre behavior that updates a mobs info in the world database.
"MOBTeacher" makes the mob a teacher of class skills.
"Mageness" makes the mob use mage skills in combat.
"Mime" makes the mob mime the socials of other mobs.
"Mobile" makes the mob mobile.
"MobileAggressive" makes the mob mobile and aggressive.
"MobileGoodGuardian" makes the mob mobile and peacemaking.
"MOBReSave" keeps the mob updated in the database at all times.
"MoneyChanger" makes the mob exchange coins for notes.
"MudChat" makes the mob chatty.
"NastyAbilities" makes the mob a random caster of mean spells.
"NiceAbilities" makes the mob a random caster of friendly spells.
"NoCombatAssist" makes the mob never assist group members in combat.
"ObjectGuardian" makes the mob forbid getting items in its room.
"Patroller" makes the mob walk a patrol.
"PlayerHelper" makes the mob assist players.
"PokerDealer" makes a dealer of player vs player poker games.
"ProtectedCitizen" makes the mob scream for help!
"ROMGangMember" makes the mob a gang member.
"ROMPatrolman" makes the mob a patrolman for gang members.
"RandomItems" will cause items from a saved file to appear on your mob.
"RandomTransporter" makes the mob zip around the map.
"RaceHelper" makes the mob assist those of the same race.
"Scavenger" makes the mob a scavenger of stuff on the ground.
"Scriptable" makes the mob run scripts that you write!
"Sounder" makes the mob emote the silly things you want it to.
"TargetPlayer" makes the mob fight the weakest player attacking him.
"TaxCollector" makes the mob a collector of money from players and or mobs.
"Thiefness" makes the mob use thief skills in combat.
"Vagrant" makes the mob sleepy.
"VeryAggressive" makes the mob willing to jump rooms to fight.
"Wimpy" makes the mob run away.
"WimpyAggressive" makes the mob only fight sleeping folks.

Mobs also benefit from effects, just like rooms, areas, items, and exits.  Here are some important effects you may consider for your mobs:

"Age" is the proper way to age a mob
"Allergies" gives the mob allergies.
"Amputation" takes away a limb from the mob
"Chant_Fertility" makes the mob fertile.
"Chant_PrayerWard" resists prayers.
"Chant_Shapelessness" makes the mob very light.
"Chant_SongWard" resists songs.
"Chant_SpellWard" resist spells.
"Chant_Thorns" makes those fighting the mob get pricked!
"Chant_Treemind" resist mind effects.
"Chant_WindShape" takes less damage.
"Chant_WindSnatcher" makes the mob resist the wind.
"Immunities" gives the mob immunities you pick.
"Injury" injures the mobs limbs.
"Inebriation" makes the mob drunk.
"Paladin_Aura" protects the mob from evil.
"Paladin_Goodness" assaults all evil!
"Prayer_AcidHealing" heals from acid attacks.
"Prayer_AiryForm" takes less damage.
"Prayer_BladeBarrier" hits back!
"Prayer_Bless" a holy aura.
"Prayer_Demonshield" flames back!
"Prayer_ElectricHealing" heals from electric hits.
"Prayer_Etherealness" allows him to walk through doors.
"Prayer_FireHealing" heals from fire attacks
"Prayer_IceHealing" heals from cold attacks.
"Prayer_ProtEvil" protects from evil.
"Prayer_ProtGood" protects from good.
"Prayer_ProtParalyzation" protects from paralysis.
"Prayer_ProtUndead" protects from the undead.
"Prayer_Sanctuary" takes less damage.
"Prop_AbilityImmunity" protects the mob from specified targeted spells.
"Prop_AbsorbDamage" absorbs damage from certain attacks.
"Prop_AddDamage" deals more damage to this mob from certain attacks.
"Prop_ClosedDayNight" makes the mob go home at night, or just disappear.
"Prop_ClosedSeason" makes the mob go home for the season, or just disappear.
"Prop_Doppleganger" makes the mob change its level and skill to match opponents.
"Prop_Hidden" makes the mob hidden.
"Prop_Invisibility" makes the mob invisible.
"Prop_ItemTransporter" makes the mob a transporter of items.
"Prop_ItemTransReceiver" makes the mob a receiver of transported items.
"Prop_ItemLangTranslator" makes the mob a translator of languages.
"Prop_LocationBound" limits the traveling ability of the  mob.
"Prop_ModExperience" modified experience gained from killing him.
"Prop_NewDeathMsg" changes the string seen when this mob dies.
"Prop_NoCharm" protects from charms.
"Prop_NoSummon" protects from summoning.
"Prop_NoOrdering" protects from player orders.
"Prop_PeaceMaker" makes into peace maker.
"Prop_PracticeDummy" makes into an unkillable unhitting dummy.
"Prop_Resistance" gives resistances which you pick.
"Prop_RestrictSpells" restricts spells from being cast.
"Prop_Retainable" changes its price to shopkeepers.
"Prop_RideAdjuster" adjusts stats when ridden.
"Prop_RideEnabler" gives new skills to riders when ridden.
"Prop_RideResister" adjusts saves when ridden.
"Prop_RideSpellCast" gives spell-affects when ridden.
"Prop_RideZapper" restricts riding.
"Prop_SafePet" makes unattackable.
"Prop_Smell" gives the mob an aroma.
"Prop_SpellReflecting" makes spell reflecting.
"Prop_StatTrainer" gives good stats.
"Prop_TattooAdder" gives a tattoo upon death.
"Prop_TicketTaker" requires a price to ride.
"Prop_Trainer" makes a mob into a full TRAIN command respondant.
"Prop_WeaponImmunity" gives immunities to certain attacks.
"Regeneration" regenerates hit points during combat.
"Skill_AllBreathing" makes them a fish.
"Skill_Resistance" gives resistances that you pick.
"Soiled" gives the mob a stink.
"Spell_Awe" makes them too awesome to attack.
"Spell_Blink" makes them blink around during combat.
"Spell_Blur" makes them hard to make out.
"Spell_ChantShield" protects from chants.
"Spell_Confusion"
"Spell_FeatherFall" makes them float when falling.
"Spell_Flameshield" flames back to attackers.
"Spell_IllusoryDisease" gives them a fake disease.
"Spell_IronGrip" makes them undisarmable.
"Spell_Levitate" makes them levitate.
"Spell_Light" makes them bright.
"Spell_MajorGlobe" protects from great spells.
"Spell_MinorGlobe" protects from ok spells.
"Spell_ObscureSelf" makes them hard to discern.
"Spell_ResistArrows" protects from arrows.
"Spell_ResistMagicMissiles" protects from magic missiles.
"Spell_ResistPetrification" protects from flesh to stone.
"Spell_SpellTurning" turns spells around.
"Spell_TeleportationWard" protects from teleporting.
"Spell_Tourettes" gives them a dirty mouth.

And don't forget how much fun it is to make your creatures permanently SICK!
"Disease_Aids", "Disease_Amnesia", "Disease_Anthrax", "Disease_Arthritis", "Disease_Asthma", "Disease_Blahs", "Disease_Cancer", "Disease_Carrier", "Disease_Chlamydia", "Disease_Cold", "Disease_Depression", "Disease_Fever", "Disease_Fleas", "Disease_Flu", "Disease_Gangrene", "Disease_Giggles", "Disease_Gonorrhea", "Disease_Infection", "Disease_Lepresy", "Disease_Lockjaw", "Disease_Lycanthropy", "Disease_Lyme", "Disease_Magepox", "Disease_Malaria", "Disease_Narcolepsy", "Disease_Migraines", "Disease_MummyRot", "Disease_Plague", "Disease_Pneumonia", "Disease_PoisonIvy", "Disease_SARS", "Disease_Smiles", "Disease_Syphilis", "Disease_Tetnus", "Disease_Tinnitus", "Disease_Vampirism"

For all non-generic MOBs, the following properties will be presented for modification (See Appendix B for more information):

Destroying MOBs

To destroy a MOB that is in the same room as you, you need only issue the destroy command.  If an orc, for instance, no longer requires his existence: "destroy mob orc" will take that existence away.

Once destroyed, MOBs that have been set to rejuv will not do so.  If the MOB was a permanently saved MOB in the room, you must re-save the room in order to make the MOBs destruction permanent.

Equipping MOBs

You may give a MOB equipment to wear or carry as treasure, if this is done properly.  First off, you can ONLY equip a Generic MOB.  This includes the GenMob, GenDeity, GenRideable, GenUndead, GenBanker, and GenShopKeeper.  No other creature may be saved with equipment.  Generic or non-Generic Items may be used as equipment. 

To equip the MOB, first create the items you wish to give to your new creature using the procedure described above under "Creating Items".  Now, you may use the give command to put the item into the mobs inventory, and the dress command to make the mob wear it.

MOBs can also be equipped with variable items. Variable items are items which may or may not appear in its inventory on any particular rejuvination of the mob.  Variable items are created by modifying the Rejuv/Pct field on the item in the mobs inventory.  If the value of this field is less than 1 or greater than 99, then the item will always appear in the inventory.  If the value of the field is between 1 and 100, then it represents the percent chance that the item will remain in the inventory.   A special case is created when more than one variable item is actually being worn in the same wear location on a mob.  In this special case, CoffeeMud will ensure that exactly one of the variable items will remain.

Dealing with variable equipment can be very tricky when not using the MUDGrinder.  It requires that the Archon remain in the room with the mob until the room is saved, in order to prevent the mob from ditching its equipment according to the variable rules.  This is because the variable equipment rules will not activate so long as an Archon is in the room.  Dealing with variable equipment on MOBs also requires that the Archon remember to use the RESET ROOM command whenever returning to the room to make modifications.  Only RESET ROOM will cause the mob to regain all of his equipment with their Rejuv/Pct fields intact.  Forgetting to do a RESET ROOM before making modifications and saving the room can cause the Archon to lose variable equipment.  Lastly, the Archon should take care not to make copies of variable equipment on mobs as room items.  This is because the Rejuv/Pct field that is used to hold the percentage chance for the equipment while it is in a mobs inventory means something entirely different when the item is saved in a room.  When an item is saved in a room, the Rejuv/Pct field refers to the rejuvination (repopulation) rate for the item when it is removed from a room.

Creating Races

Although the myriad of available races should be quite sufficient for any Archon's needs, you may find yourself at a point where a new species is required for the balance of your ecosystem.  In this situation, we must turn to the CREATE RACE command.  Supposing we needed the raveging Woogler to grace our shores, we would enter:

CREATE RACE Woogler

And it would be done.  Whenever creating or modifying a new race, the Archon is presented with a menu of selections and options available to customize the little boogers.  Here is a description of those options:

Property	Description
Name	the displayable name of the race.
Racial Category	the category into which the race fits.  Use ? to get a list of existing ones.
Base Weight	the minimum weight of a mob of this race
Weight Variance	the amount by which the weight of the mob may vary above the base.
Base Male Height	the minimum height of a male mob of this race
Base Female Height	the minimum height of a female mob of this race
Height Variance	the amount by which the height of the mob may vary above the base.
Availability	whether or not players may access this race at creation, in spells, or never
Leaving Text	the word displayed when a mob of this race leaves the room
Arriving Text	the word displayed when a mob of this race arrives into a room
Health Race	the name of a standard race which will be used as a source of health descriptions during combat.  In short, enter here the name of a race that looks the most like the one you are creating.
Body Parts	the number and type of body parts available for amputation
EStat Adjustments	adjustments, positive or negative, to attack, defence, and other stats.  Use ? for a list.
CharStat Adjustments	adjustments, positive or negative, to strength, saving throws, and other stats.  Use ? for a list.
CharStat Settings	hard settings for strength, saving throws, and other stats.  Use ? for a list.
CharState Adjustments	adjustments, positive or negative, to hit points, mana, and other stats.  Use ? for a list.
Starting CharState Adjustments	adjustments, positive or negative, to the default hit points, mana, and other stats for starting players of this race.
Extra Race Flags	Whether class, level, or the gaining/losing of experience applies to this race. By default, they do.
Resources	list of items produced from the corpse of this race when it is Butchered.
Outfit	list of items automatically equipped and word when the OUTFIT command is used, or a player of this race is created.
Natural Weapon	the weapon used by this race when it is unarmed.
Racial Abilities	a list of abilities available to members of this race.  the abilities must be of the type that have command words.  the proficiency given to the ability is hard coded and cannot be modified.  the level referred to is in player levels as opposed to class levels.
Cultural Abilities	a list of abilities granted automatically to those who are born this race.  it is assumed these abilities are learned because of the races culture.  the proficiency given is the default proficiency which players/mobs of this race start out with.

Creating Classes

Creating customized player or mob classes can be fun and exciting! These classes can be used as skill templates for mobs created using the Fighterness (or similar) behaviors, or as genuine player classes for your game.  Either way, here is how it is done:

CREATE CLASS Boxer

And it would be done.  Whenever creating or modifying a new class, the Archon is presented with a menu of selections and options available to customize the class.  Here is a description of those options:

Factions

Before learning the secrets of creating, modifying, and destroying factions, needs must we delve into the topic of what a Faction IS.  A faction can be viewed very simply as a glorified tattoo, where instead of merely having or not having the tattoo, a mob or player can have the tattoo and have a numeric value assigned to that tattoo.  Another way to view a faction is as a relationship between a mob or player and some idea, such as Goodness, Evilness, Orc Affinity, Reputation, or some other idea.  For example, in CoffeeMud, a mob or players Alignment is implemented as a Faction.  The Alignment can be thought of as having a tattoo called alignment along with a numeric value assigned to it.  Alignment can also be thought of as the relationship between the mob or player, and evilness, goodness, or neutrality.

The faction system in CoffeeMud is a powerful engine for defining what factions exist, how the factions are assigned, how the value of factions rise or fall in value, how value changes are reflected in other factions, and what impact the value of a faction has on experience gain, ability usage, and ability skill gain.  Since the values of factions are available for use in Properties such as Prop_WearZapper, Prop_ReqEntry, and all other features which respect Zapper Masks, factions can also potentially impact which items can be used, which rooms can be entered, the price of goods, the availability of Deities, and many other things as well.  As an example, the alignment faction typically impacts all of the things mentioned above and more.

Now, as was said before, factions have numeric values.  These values can be positive, like 2389473, negative, or even 0.  The range of values which are valid for a given faction are defined by the limits of the divisions or Ranges of a faction. 

A Range is a numeric division of a faction you have defined.  A Range has a displayable name, a special code name for use in Zapper Masks, and of course a low and high value.  A Range can also be tied back to CoffeeMud's built in "virtue meter", which allows you to define a Range as always granting the mob or player whose faction value falls into that range goodness, evilness, or neutrality.  The lowest value of the lowest Range, and the highest value of the highest Range define the overall limits of the values of the faction itself.  No player or mob may have a value for a faction which falls outside those highest and lowest values of the highest and lowest Ranges.  For this reason, ranges are the most important part of a faction.

Another important aspect are the range Change Triggers.  One of the ways factions differ from simple tattoos is that CoffeeMud can manage the rise and fall in the values of the faction on a given mob or player automatically.  The way these changes are triggered and managed is first through Change Triggers, which are applied when both the source and target of an action have standing or value in the faction, and when the source and target are different creatures.  Each Change Trigger defines 1) What triggers the change (the Trigger), 2) Whether value is gained or lost in the faction when the trigger occurs (the Direction), 3) What percentage of the amount of change (after all other modifiers) is applied to the value (the Amount Factor),  4) several miscellanous flags to define the circumstances under which the trigger is applied (the Flags), and 5) a Zapper mask to determine what criteria the target of the Trigger must meet for this trigger to apply.  The valid Triggers include: Murder, Time (a change occurs every 40 seconds or so), a type of skill being used, the domain of a spell being cast, a flag associated with a skill being used, or Add Outsider, which allows the faction to be added to those who do not have the faction, so long as they meet the other requirements.  Valid Directions of change include: Up, Down, Opposite (opposite direction of the value of the creature killed and proportional in value to the distance between the faction value in the source and the target), Minimum (automatically gains minimum value), Maximum (automatically gains maximum value), Add (gains the faction if they don't have it -- useful with the Add Outsider trigger), Away (gain if monsters value for this faction is lower, lose if higher), and Towards (gain if monsters value for this faction is higher, lose if lower).  Valid Flags include: OUTSIDER, which allows the trigger to apply even if the target of the trigger (not the source) does not have standing in this faction, SELFOK, which allows the trigger to apply even when the source or target are the same person, and JUST100, which overrides the normal modifications of a change (based on experience or other factors) and uses 100 points as a base amount for the change from this trigger.

Now, lets discuss how to list existing factions:

LIST FACTIONS

The list that is shown with this command reflects the list of those factions which have been loaded into CoffeeMuds memory.  Factions are loaded into memory when their identifiers/filenames are added to the FACTIONS entry in your "coffeemud.ini" file.  Factions may also be loaded if a mob or player is loaded who has a faction which has already been defined.  Creating new factions, as you can now guess, is a two part step.  One step is to add its identifier/filename to the FACTIONS entry of your "coffeemud.ini" file, after the file has been created. To create the new faction identifier/filename, you must do the following:

CREATE FACTION orc_affinity.ini

This command will create a new file in your CoffeeMud/resources directory or folder for the new faction.  This file will contain the default setting for your brand new faction, whose ID (identifier) will be ORC_AFFINITY.CMVars.  You will now be automatically taken into the Faction Editor.  If you had wanted simply to modify an existing faction, you might have entered:

MODIFY FACTION resources/reputation.ini

The modify command will take you into the editor for an existing faction, regardless of whether it appears on the LIST FACTIONS list, so long as the filename/identifier given refers to an existing faction file.  The Faction editor contains numerous other complex and interesting fields to change, which we will now describe.

Property	Description
Name	the displayable name of the faction, not to be confused with its official identifier, which you may not change.
Division/Ranges List	the defined ranges for this faction.  See the above discussion on ranges for the meaning of the fields.
Show In Score	whether this faction is listed with the players information when they use the SCORE command.  The FACTIONS command is always available for a player to list their factions and values regardless of whether this setting is true or false.
Show In MOB Editor	whether this faction gets its very own entry in the command-line mob editor, or the MUDGrinder mob editor.  The Factions field is always listed in the mob editor for changing the factions and their values on players and mobs regardless of whether this setting is true or false.
Automatic assigned values	optional field showing which mobs or players will automatically be given this faction and some value in it.  This is a semicolon-delimited list, where each entry begins with the value to assign, and is followed by a mask to determine who the value gets assigned to.  For example: "100 -race +elf ; 500 -race +dwarf" would mean that all elf players and mobs receive this faction with a value of 100, and all dwarf players and mobs receive this faction with a value of 500.  If this field is empty, noone is assigned a value automatically.  If this field only contains a number, or if any entry contains only a number (no mask), then everyone will receive this faction.
Other default values	required field defining the values that mobs or players will be assigned whenever this faction is granted to them by scripts, triggers, or by some other means.  The syntax of this field is similar to the "Automatic assigned values" field above.  At least one entry, however, must be without a mask, so as to make sure that a default value exists for every possible player or mob.
New player value choice	an optional list of values, semicolon delimited, which players will get to choose from when they create their characters for the first time.  Each value in this list should correspond to, or fall into, a different Division/Range listed above.  If this field is empty, players will not be given this faction at creation time.
Choices introduction text	if the previous field contained entries, then this field will become available.  It is the optional filename of a text file in your Coffeemud/resources directory or folder which describes the choices available to the player.
Rate Modifier	normally 100%, this field is a fudge factor for all instances where some value is gained or lost in this faction.  Typically gained values can be halfed, doubled, or changed in any other way by modifying this value.
Affect on Experience	whether and/or how values in this faction affect the amount of experience gained by players for killing monsters.   If the value is None, then this faction does not affect experience gained by players for killing monsters.  Otherwise, the amount of faction gained or lost is a function of the base number of experience points earned, and modified by the value of this field: Extreme means the amount gained or lost is always towards one extreme end of this factions Ranges, and always in a direction away from the value that the monster had.  Higher means the amount is always gained.  Lower means the amount is always lost.  Followhigher means the amount is always gained, and in proportion to how high the value of the monsters faction is.  Followlower means the amount is always lost, and in proportion to how low the value of the monsters faction is.
Faction Change Adjustments	like the Rate Modifier above, this field affects the values of gains and losses in this faction.  It allows you to change the value of Gains or Losses based on whether the player or mob with the faction matches the given Zapper Mask.  Both the Gain and Loss values should be positive, as they reflect a percentage change in the gain, and a percentage change in the loss only.
Cross-Faction Relations	defines whether and/or how the value of other factions may rise or fall when the value of this faction changes.  Each entry is the name of second faction, along with a positive or negative percentage of the value gained or lost in this faction, which will then be applied to the second faction.
Change Triggers	the events which cause the value of a faction on a player to rise and fall.  Usually triggers are applied when an action is performed on a target creature by a source creature, both of whom have standing in the faction.  See the description above for more information on the fields defined for each Change Trigger.
Ability Allowances	this defines the circumstances under which a player may always use a particular time of skill, spell, or whatever, unimpeded and with full privileges.   Each entry contains a list of flags to determine which skills, spells, chants, etc are being selected along with the range into which a players value in this faction must fall for the ability to be used unimpeded and with full privileges.  Requirements defined by Ability Allowances will typically determine whether proficiency is every gained in a skill, and whether certain class restrictions are overridden.

"Rejuvenating Items and Mobs" or "How to Save a Room"

MOBs and Items that are created in rooms, even those which have had the Rejuv Ticks property set to some reasonable number, will not actually begin to rejuvenate, and will not reappear in the room when CoffeeMud is rebooted, until the room is saved. 

To save a room, you must be standing in it.  From there, you may issue either the "save items" command to save the items in the room, "save mobs" command to save the mobs in the room, or "save room" to save them both.  You should make sure that the items, mobs, or both, are exactly the way you want them to be when the system is rebooted.  Players in the room, including yourself and your followers, will be ignored by the command to save the mobs.

Currently, the resets using the Rejuv setting method are on a mob-by-mob and item-by-item basis, though the system does give you some default reset times when mobs are created (based on level). There is an alternative reset method however.  If you were to make NONE of your mobs or items resettable under the current scheme (by making the REJUV value 0), then to add the Behavior called "ResetWhole" to each Area, you can simply reset every room in the area on a timed basis. The behavior will reset every room after noone has visited the area in a certain amount of time. This time can be set in the behaviors parameters.  Use AHELP ResetWhole for more information on this behavior.

Appendix A: Special Standard Items

Map

• level - A value of 0 means the map will be built without access to any indoor rooms or areas behind only secret exits.  A value of 1 means the map will be built with both indoor and outdoor rooms, but without secret rooms.  Any other value will display each and every room, regardless.  A room that is classified as "in the air" will never be placed on a map.
• misc text - The names of the areas, separated by semicolons, to place on the map.  For instance "Area1;Area2" would build a map from rooms in both Area 1 and Area 2.

LargeChest, SmallChest, LockableContainer, etc

• misc text - The name of the key which will open this container.

StdJournal

• misc text - The reading, writing, and replying requirements for the journal. The proper format is READ=REQUIREMENTS WRITE=REQUIREMENTS REPLY=REQUIREMENTS ADMIN=REQUIREMENTS. The REQUIREMENTS are as described above under the Assigned Readable Text field in the GenJournal entry. 

StdKey

• misc text - The name of the key.  This value must match the corresponding value on the door, chest, etc.

TrappedChest (or any other trapped item)

• ability - The type of trap encountered.  0=Needle, 1=Pit or Blade, 2=Gas

RingOrnamental, Gem

• level - The material the ring or gem is made out of, or what gem is mounted on it in the case of a ring. 

Coins

• ability - The number of coins in the pile
• misc text - the currency name followed by a / (slash), followed by the denomination value (floating point)

InnKey

• * Must be in a shopkeepers starting inventory in order to take effect.  Each key in the shopkeeper's inventory will be automatically set to open exits with lock descriptions "INN1", "INN2", etc..  In order to create an Inn, you need only have a shopkeeper with one InnKey for every room in your inn.  Then create the same number of rooms, each with a locked door.  Key each locked door to a different room number, so that they will match the keys.  For instance, "INN1", "INN2", etc.  See the section on exits for more information on keying locked doors.

(Most Generic and non-Generic Armor)

• ability - Equates to a roughly 10 point bonus in armor for every ability point above 0.  Makes the armor magical.  Negative ability points will do the opposite.

(Most Generic and non-Generic Weapons)

• ability - Equates to a 5 point attack bonus, and 1 point damage bonus for every ability point above 0.  Makes the weapon magical. Negative ability points do the opposite.

ScrollSpell

• usesRemaining - The number of times, total, that any spell on the scroll may be cast or scribed.  In other words, this number applies to ANY use of the scroll, as opposed to individually for each of the spells.
• misc text - The names of the spells, separated by semicolons, that are written on the scroll.  The names must be the same case-sensitive class names used in CoffeeMud.  For instance:  "Spell_MagicMissile;Spell_Fireball;Spell_ResistElectricity"

StdWand, Staff, Wand_Fire, Wand_Nourishment

• usesRemaining - The number of times the wand will respond to its activation word.
• misc text - For Staff and StdWand only, the name of the spell that is invoked by the magic word.  The name must be the same case-sensitive class names used in CoffeeMud.  For instance:  "Spell_MagicMissile"

StdPill, StdPotion

• misc text - the list of the spells, separated by semicolons, that are invoked by consumption.  The spell names must be the same case-sensitive class names used in CoffeeMud.  For instance:  "Spell_MagicMissile; Spell_Sleep"

StdLawBook

• misc text - the name of the Area for which this book operates.

StdPortal

• misc text - A room ID, or a a semicoloon-delimited list of roomIDs that this portal leads to. For the return trip, a portal object would need to be in both rooms.

Ring_Protection

• level - The type of protection afforded by the ring.  Levels 0-11 protect from various magical effects.
• ability - For levels 12 and higher, the amount of 10 point armor protection afforded.

StdTitle

• misc text - the room ID of the room which has the Prop_RoomForSale property.

ManualClasses, ManualAdvancement, etc.

• usesRemaining - The number of types the manual may be read before becomming ineffective.

Appendix B: Special Standard MOBs

Dragon

Goblin

• ability - The type of goblin being dealt with.  Ranges 0-1000

StdBanker

• misc text  - The name of the bank chain

StdPostman

• misc text  - The name of the postal chain

StdShopKeeper

• misc text - Prejudice factors.  See the field of the same name under GenShopKeeper above!

Appendix C: Generic Weapons and Armor Guide

Weapon Groups      

            When building weapons, you must first select the group that the weapon falls under.  The weapon group affects which classes can use the weapon, as well as what specializations enhance it’s use.  Selecting more common weapon groups, such as EDGED or SWORD can enable a weapon designer to place higher level restrictions, if desired, on the weapon.  This increase in levels is suggested to be 2 additional levels, but not necessary to keep the game balanced.  Weapons within a group may deal any TYPE of damage, as discussed later, but have general tendencies towards one or two types.

            Weapons within a given category have certain general tendencies, as describe by the table below.  Any or all of these can be overridden for the purpose of weapon design, these are just the basic type of weapons in that category.  For example, flailed weapons tend to be unwieldy (have a negative to attack), but that doesn’t mean all flails are unwieldy. 

Similarly, the allowed materials are materials used historically to make that type of weapon.  If a weapon designer deigns to make a weapon out of LAMPOIL, it is doable, just a little unorthodox.  (You would probably want to make the weapon out of GLASS, as that is the outer delivery devise of a Molotov Cocktail.)  Currently, weapon SIZE has no effect on game play, but that may change at a later date.  The BASE MATERIAL of a weapon assumes that weapons are made from that general area, and use material bonuses based on that type.  If you create a weapon out of a non-standard, ALLOWABLE MATERIAL, use the appropriate charts for determining attack and damage bonuses after the level has been set.

	Base Damage type	Base # Hands/ Base Reach	Base Attack Bonus	Size of Weapon	Base Material/ Allowable Materials
FLAILED	Blunt	1/0	-5	Weight*3	Wood/ M, W, R, L
BLUNT**	Blunt	1/0	0	Weight*2	Wood / M, W, R, L, P
SWORD	Slash	1/0	0	Weight + 12	Metal/ M, W, R, G, P
POLEARM	Pierce	2/1	0	Weight*4 + 24	Wood/ M, W, R, P
AXE	Slash	1/0	0	Weight + 6	Metal/ M, W, R, G, P
HAMMER	Blunt	1/0	0	Weight +12	Wood/ M, W, R,
EDGED*	Pierce	1/0	+10	Weight*2	Metal/ M, W, R, G, P
RANGED***	Pierce	2/1	0	SPECIAL	Wood/M, W, R, L, G, P

*A Dagger is a type of EDGED weapon.

**A Staff is a type of BLUNT weapon.

***Includes both RANGED, and THROWN weapons.

Allowed Materials: (M)etal/Mithril, (W)ooden, (R)ock, (B)one, (L)eather, (G)lass, (P)recious.  Disallowed:  Flesh, Vegetation, Liquid, Cloth, Paper

Determining Weapon Level

            Weapon creation can be done by the designer fixing the DAMAGE that a weapon does, or by fixing the LEVEL required to use the weapon.  To generate weapons that do a specific amount of damage which are balanced with the WEAPONSMITHING skills, use the following formula:

Level= ((2*D)/(H+1) + (A-W)/5 +R)*((R/W)+2)+1

where

D=base DAMAGE of the weapon before material modifiers,
H=number of hands required to wield
A=base ATTACK bonus of the weapon
R=REACH/RANGE of weapon
W=WEIGHT of weapon

            Round the final number down, to a minimum level of 1.  Some general criteria to follow for weapons to avoid creating ultra-powerful, low-level weapons include:

            Create the weapon for a HUMAN-sized character first.  If you wish to scale it up or down for different races, use the WEAPONS FOR GIANTS table after setting the base level.  A typical one-handed human weapon will weigh from 1-8 pounds, and a two handed weapon will typically weigh from 10 to 20 pounds.  Using heavier/lighter weapons will create a strange, and possibly unbalanced, result.

            Melee weapons should not have a reach greater than 1.

            Weight of weapons should include any incidental weight in using the item, such as carrying case, ammunition, and other equipment generally assumed to be in use with the item.  For most RANGED weapons, this will add another 4 pounds to the typical weight of the weapon.  For melee weapons, the weight is generally negligible.  (Except, possibly for a Katana with a very ornate scabbard.)

            Round the final number down, to a minimum level of 1.

Some sample weapons and levels:

Name	Class	DamType	Level	DAM	ATT	Hands	Range	Value	Size	WT	Material
Hand Ax	Axe	Slashing	1	4	-10	1	0	56	14	8	Wooden
Dagger	Edged	Piercing	1	2	-5	1	0	130	12	6	Metal
Short Sword	Sword	Slashing	1	2	0	1	0	220	22	10	Metal
Voulge	Polearm	Slashing	9	13	-10	2	1	803	96	18	Metal
Gladius	Sword	Piercing	7	4	+5	1	0	300	22	10	Metal
Grand Sceptre	Blunt	Bashing	12	8	+5	1	0	680	32	16	Metal
Executioner’s Axe	Axe	Slashing	13	20	-10	2	0	1233	72!	25	Wooden
Cat-o-nine tails	Flail	Bashing	17	15	-20	1	0	965	42	14	Leather
Sledgehammer	Hammer	Bashing	10	34	-50	2	0	2773	52	40	Wooden
Javelin	Thrown	Piercing	8	3	0	1	2	265	76	8	Metal
Katana	Sword	Slashing	13	7	+10	1	0	635	36!	16	Metal

Notice:  On the Executioner’s Axe, and the Katana, the size does not correspond to the size formula given above.  That’s OK, since the size isn’t currently used, and since the weapon designer ultimately has free reign over weapon design.  Also, if you compare many of these levels to that of the weaponsmithing skill, you will some discrepancies on the levels.  Weapon construction isn’t an exact science, as long as you get it in the general range the game will remain balanced.

Determining Weapon Damage

            If you wish to create a weapon based on the level of a MOB, you can use some algebra and convert the equation into a damage equation to give you the following formula:

D= ((L-1)/((R/W)+2) + (W-A)/5 -R)*(((H*2)+1)/2)

where

L=Level required to use weapon,
H=number of hands required to wield
A=base ATTACK bonus of the weapon
R=REACH/RANGE of weapon
W=WEIGHT of weapon

Round the final number down, to a minimum level of 1.

Determining Weapon Cost

            To compute the weapon’s base value use the following equation:

Cost of Item= 2*(W*V+(5*D+A+R*10)*D)/(H+1)

where

D=base DAMAGE of the weapon before material modifiers,
H=number of hands required to wield
A=base ATTACK bonus of the weapon
R=REACH/RANGE of weapon
W=WEIGHT of weapon
V=VALUE of the material the weapon is made from

Determining Weapon Damage Type

            Weapon Damage Type is entirely up to the weapon designer, but some guidelines have already been provided for the basic weapon types.  Here is a brief description of the different damage types, and level modifiers for weapons with these damage types:

            NATURAL—All Natural weapons should be UnGettable.  Natural weapons are available for a creature to use in combat, such as a Manticore’s tail spikes; but not actual weapons for adventurer’s to loot.  Any GETTABLE Natural weapon should have a level MODIFIER of at LEAST it’s DAMAGE rating.  Natural weapons would be favored by monks if they could get them.

            SLASHING—Slashing weapons are fairly common and include things like Axes and Swords.  No special care needs to be considered when making a weapon deal SLASHING damage.

            PIERCING—Piercing weapons are very common amongst the Polearm groups.  No special care needs to be considered when making a weapon deal PIERCING damage.

            BASHING—Bashing weapons are common amongst Blunt and Hammer weapon groups.  No special care needs to be considered when making a weapon deal SLASHING damage.

            BURNING—This is the damage type for all fire based attacks and spells.  Burning weapons tend to do more damage to cloth and leather armors, and overall are more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type BURNING.

            BURSTING— This is the damage type for all Magic based attacks and spells. Bursting are more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type BURSTING.

            SHOOT—This is the damage type of projectile missiles, such as Bows and Guns.  It is very similar in nature to PIERCING.  No special care needs to be considered when making a weapon deal SHOOT damage.

            FROSTING—This is the damage type for all Cold based attacks and spells.  Frosting weapons tend to be more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type FROSTING.

            GASSING—This is the damage type for all Gas based attacks and spells.  Gassing weapons tend to be more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type GASSING.

            MELTING—This is the damage type for all Acid based attacks and spells.  Melting weapons tend to do more damage to armors, and overall are more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type MELTING.

            STRIKING—This is the damage type for all Electricity based attacks and spells.  Striking weapons tend to do more damage to cloth and leather armors, and overall are more powerful than Slashing/Piercing/Bashing due to there infrequent use amongst weapons.  Add 2 levels to a weapon’s base LEVEL if it is of type STRIKING.

Creating Quick and Dirty Weapons

            If you just want to guestimate a weapon’s level or damage, use the following formulas.  They aren’t very accurate, and can create radically overbalanced weapons in the hands of players, but they are great for easy NON-GETTABLE MOB weapons.

LEVEL=DAMAGE + (ATTACK/5)

or

DAMAGE=LEVEL - (ATTACK/5)

Weapons for Giants

            If you wish to create weapons for large (or small) creatures, the weight of the item will often get an unusually high bias, creating MASSIVE low level weapons with lots of damage potential.  Instead, create the weapon for a human sized creature, and add the following modifiers.

WEAPONS FOR GIANTS

Weight Increase	Level Increase	Damage Increase	Size Increase	Range Increase	Value Increase
-90%	0	-3	-50%	-1	+50%
-50%	0	-2	-25%	-1	+20%
-25%	0	-1	-10%	0	+10%
+25%	+1	+1	+10%	0	+25%
+50%	+2	+2	+20%	0	+50%
+100%	+4	+4	+50%	+1	+75%
each additional +100%	+4	+4	+50%	0	+25%

Armor

            Armor creation is, in many ways, much simpler than weapon creation.  There are three types of armor: Cloth, Leather, and Metal.  Strange armors could exist, but are variants of one of these three types.  The armor values vary by location, and by material.  Shields are considered to be HELD METAL armor.  For a wooden shield, consider it as a HELD LEATHER armor for the purposes of further discussion (though your material would still be WOODEN).

Armor Points (Not the final Defensive value of the armor)

            Different types of armor have different level values, since the less armored classes would love to get that extra armor bonus at a lighter weight.  To keep the classes balanced, the use the following guideline for determining the BASE POINT value of an armor piece.  As you will see in the next section, different WEAR locations will have different ARMOR VALUEs for the same type of armor.  A platemail breastplate is more protective than a platemail cuff.

Points	Cloth Level	Leather Level	Metal Level	Sample Armor Type
0	0	0	0	Simple clothes
1	3	0	0	Padded clothes
2	7	1	0	Leather armor
3	12	5	0	Hard Leather Armor
4	18	10	1	Studded Leather or Ring Mail
5	25	16	3	Scale Mail
6	33	23	5	Chain Mail
7	42	31	8	Banded
8	52	40	12	Plate
9	62	50	17	Field Plate
10	72	60	23	Full Plate
11	82	70	30	Dwarven Plate
12	92	80	38	?
13*	102	90	47	??

*Higher levels of armor are conceivable.  Add 10 Levels per point above 13

Armor Value (The Almost Final Defensive Value)

Once you have determined it’s base points, then you will determine it’s actual ARMOR VALUE, based upon it’s location, and it’s WEIGHT, based upon location, point value, and material type.  For example, a Banded Shirt (7 points) would provide a total ARMOR VALUE of 21 (7*3), and weigh 63 (7*9) pounds.  

	Armor Value per Point	Cloth Weight per Point	Leather Weight per Point	Metal Weight per Point
Head	1	1	2	3
Neck	.5	.5	1	1.5
Arms	1	1.5	3	4.5
Wrist (2)	.5	.5	1	1.5
Hands	.5	.5	1	1.5
Torso	3	3	6	9
Waist	.5	.5	1	1.5
Legs	2	1.5	3	4.5
Feet	.5	1	2	3
Held	1	1.5	3	4.5
Wield	1	1.5	3	4.5

 The armor weights are recommendations.  If you wish to create a lighter version of chain mail that gives the same armor protection (like Elven Chainmail) go right ahead.  It will not increase the level, it will increase the COST of the armor.

Armor Cost

The formula for the cost of the armor is:

COST = (A*A + V) * ( W/2)

where

W = Weight of Armor
A  = Armor Points
V = material Value

            So our example of an iron Banded Shirt would cost 2173.5 (round up to 2174): (7*7+20)*(63/2).

Final Armor Adjustments

            After you have computed the Armor Value, consult the materials tables for any bonuses that the material may give.  This number is a bonus per Armor Point.  If a breast plate of full plate is made from Adamantite (armor bonus of 4), it would gain 12 (4*3) points of protection, bringing it’s total value from 30 (10*3) to 42. (30 + 12).  Material modifiers do NOT affect the level of the armor, even though it would have an effective Armor Point total of 14, it would still be available at level 23!  Consult the Material Modifiers section below for an Armor Point reference.

Magic Modifiers

            Magic should be controlled by the type of MUD that is being run.  If you run a low-fantasy MUD, you may wish to increase the Level requirement for items with magical properties.  If you are on a high-fantasy MUD, you may wish to decrease the Level requirements for items with magical properties.  Magic comes in at least seven forms:  Magic Adjustment, PropFightSpellCast, PropHaveSpellCast, PropWearSpellCast, PropHaveAdjustor, PropWearAdjuster, PropHaveResistor, PropWearResistor.

Magic Adjustment

            This field is available on any item, weapon or armor.  If the item can be worn (but not used as a weapon), then every point of magic gives 1 point of Armor Value.  If the item can be used as a weapon, then it gives +2 to Damage, and +10 to Attack per point of bonus.  In either case, the magic adjustment improves the item’s saving throws against attacks that damage it’s condition.  Having a Magic Adjustment greater than 0 makes the item magical (and detectable as such).  Every 1 point of magic adjustment is worth 5 additional levels to the base level of the item.

PropFightSpellCast

            This property will make a weapon discharge a spell-effect with each successful hit.  As such, it is very powerful, and the weapon’s level should be increased by twice the spell’s typical level.  As with all spell effects, use careful judgment when placing spells on items, and use your own discretion for determining the final level adjustment.

PropHaveSpellCast

            By simply having this item, the designated spell is cast on the owner.  If this is a positive effect, add the Spell effect’s typical level to the level of the item (at least, depending on usefulness).  If having a stone of Invisibility (level 7) is enough to make you invisible, then the stone should require at least a level 7 character (if it did nothing else).  On something as powerful as invisibility, you may wish to increase the level even more.

PropWearSpellCast

            This property makes any worn/wielded item grant the effects of a spell.  As a general rule, the item’s level should be increased by half of the spell’s typical level.  Again, use your own discretion when creating items that may be very powerful, such as stoneskin or invisibility.

PropHaveAdjustor

            This property makes an item that is in a MOBs possession gain certain abilities.  This is a very powerful effect, since a MOB could conceivably carry a lot of these items.  The level increase for items of this type should be at least twice as high as those with the PropWearAdjustor effect.

PropWearAdjustor

This property makes a worn/wielded item grant special benefits to it’s owner.

Level per Point	Effect
5	Str, Dex, Con, Int, Wis, Cha
1/5	Hit Points, Mana Points
1/10	Movement Points
3	Armor
½	Attack
3	Damage
2	Disposition=(Good, Neutral, Evil)
10	Level
?	Rejuv, Hunger, Thirst, Experience
5	Senses
Variable	Race, Height, Weight, Gender
5	Speed

PropHaveResistor

            This property will give anyone possessing the item the said resistance increase.  This is a more powerful version of PropWearResistor.  The level increase for this property should be three times that of a PropWearResistor.

PropWearResistor

            This property allows an item worn/held/wielded to grant the owner bonuses to various saving throws, or outright immunities to certain attacks.

Level per percentage of resistance	Effect
1/5	Gas, Fire, Electrical, Mind, Magic, Cold, Acid, Water, Evil (Undead), Justice (thief abilities and others)
½	Weapons, Blunt, Pierce, Slash (reduces damage)
2	Teleport Immunity (includes gate, summon, and others)
10	Holy Immunity
10	Disease Immunity
10	Poison Immunity

Other Effects

            There are many properties available in Coffeemud that enable unique item creation.  There are inhibiting properties such as the PropWearZapper and PropHaveZapper that can be used to reduce the level of the item (I would say as a general rule, for every race restricted, reduce the level requirement by 2, and for every class restricted reduce the level by 1.)  Other spell effects may be negative, reducing the value of the item.  Still others may be difficult to determine their effects, reducing the value of the item.  Use your judgment, or request the system owner’s advice for particularly complicated works of magic.

Cost of Magical and Miscelaneous Properties 

            For determining the added monetary value of an item based on its magical properties, you must first determine how prevelant magic items will be in your world. Choose a cost Index between *10 for a magic rich world, to *100 for a magic poor world. Each level above the base level is multiplied by this Index and then added to the base cost to determine its final value.

                       Final Cost = Base Cost + (Total Level Increase)*(cost Index)

Material Modifiers 

            The Material that you use to create an item affects it’s overall effectiveness without affecting it’s level.  Make these modifications to the item AFTER completing the previous formulas.  If you use a non-standard material, do not apply the actual material modifiers (other than value) to the item’s Attack, Damage, or Armor values.  A metal club is superior to a wooden club, but using a better type of metal doesn’t increase the bluntness (or even relative hardness) of the club significantly.  ROCK is an exception to this rule.

ALLOWABLE MATERIALS

Standard	Actual	Damage	Attack	Armor
Metal/Mithril	Wooden	-4	0	-3
Metal/Mithril	Precious**	-4	-10	-3
Metal/Mithril	Leather**	-6	-10	-4
Metal/Mithril	Rock	-2	-10	-1
Metal/Mithril	Glass	-4	-20	-3
Metal/Mithril	*Other**	-8	-30	-5
Wooden	Metal/Mithril**	+2	0	+3
Wooden	Precious**	+2	-10	0
Wooden	Leather**	-2	0	0
Wooden	Rock	+2	-10	+2
Wooden	Glass	-2	-10	0
Wooden	*Other**	-6	-30	-3
Cloth	Metal/Mithril	N/A	N/A	+4
Cloth	Wooden	N/A	N/A	+1
Cloth	Precious**	N/A	N/A	+1
Cloth	Leather	N/A	N/A	+1
Cloth	Rock	N/A	N/A	+3
Cloth	Glass	N/A	N/A	+1
Cloth	*Other**	N/A	N/A	-2

*Consider each on a case by case basis

**DO NOT apply MATERIAL MODIFIERS to DAMAGE, ATTACK, and ARMOR

Material Indexes

            Once an item is completed, add any values from materials to the end result to get the final values for the item.  Note that CONDITION is a relative term that determines ARMOR and WEAPON damage condition.  Different types of materials suffer differently from the various attack forms.  A blank in this area means that it resists damage normally, and wears at the standard rate for all attacks against that type of material.  A ‘+’ means that it holds up better against all forms of attacks.  A ‘-‘ means that it suffers more damage from all forms of attacks. 

            Mithril is a special type of METAL.  Therefore, any item that can be made from a metal, can also be made from a mithril.  Mithril has different resistance scores than metals, and has other special properties, so it is listed as its own classification.

            If an item is created from a non-standard material, apply those modifiers FIRST.  If they don’t allow for a MATERIAL MODIFIER, then skip this step.

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Stone	ROCK	1
Limestone	ROCK	1	-10	-2	-1	-
Flint	ROCK	1	-10	-2	-1	-
Granite	ROCK	2	+10	+2	+1	+
Obsidian	ROCK	10	+10	+2	+1	+
Marble	ROCK	20
Sand	ROCK	1	-40	-8	-4	----
Coal	ROCK	1	-40	-8	-4	----

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Iron	METAL	20
Lead	METAL	10	-10	-2	-1	-
Bronze	METAL	10	-10	-2	-1	-
Silver	METAL	30	-10	-2	-1	-
Gold	METAL	50	-10	-2	-1	-
Zinc	METAL	10	-10	-2	-1	-
Copper	METAL	10	-10	-2	-1	-
Tin	METAL	10	-20	-4	-2	--
Steel	METAL	150	+20	+4	+2	++
Brass	METAL	120
Platinum	METAL	80

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Mithril	MITHRIL	200	30	6	3
Adamantite	MITHRIL	500	40	8	4	+

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Wood	WOODEN	2
Pine	WOODEN	4
Balsa	WOODEN	1	-10	-2	-1	-
Oak	WOODEN	5
Maple	WOODEN	10
Redwood	WOODEN	20
Hickory	WOODEN	5
Ironwood	WOODEN	25	+10	+2	+1	+

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Scales	LEATHER	10			+2	++
Leather	LEATHER	10

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Fur	CLOTH	20			+1	+
Wool	CLOTH	10
Feathers	CLOTH	10
Cotton	CLOTH	5
Hemp	CLOTH	4
Silk	CLOTH	200
Hide	CLOTH	4

Material	Type	Value	ATTACK	DAMAGE	ARMOR	Condition
Glass	GLASS	10
Clay	GLASS	1	-20	-4	-2	--
China	GLASS	30
Crystal	GLASS	10
Bone	GLASS	1	+20	+4	+2	++

Material	Type	Value	Condition
Paper	PAPER	10

Material	Type	Value	Condition
Meat	FLESH	4
Beef	FLESH	6
Pork	FLESH	8
Poultry	FLESH	3
Mutton	FLESH	4
Fish	FLESH	5
Eggs	FLESH	2	-

Material	Type	Value	Condition
Wheat	Vegetation	1
Corn	Vegetation	1
Rice	Vegetation	1
Carrots	Vegetation	1
Tomatoes	Vegetation	1
Peppers	Vegetation	1
Greens	Vegetation	1
Fruit	Vegetation	2
Apples	Vegetation	2
Berries	Vegetation	2
Oranges	Vegetation	2
Lemons	Vegetation	2
Grapes	Vegetation	3
Olives	Vegetation	2
Potatoes	Vegetation	1
Cactus	Vegetation	2
Dates	Vegetation	2
Seaweed	Vegetation	1
Cocoa	Vegetation	4
Barley	Vegetation	1
Mushrooms	Vegetation	1
Herbs	Vegetation	1
Sugar	Vegetation	1
Hops	Vegetation	2
Coffeebeans	Vegetation	2

Material	Type	Value	Condition
Freshwater	LIQUID	0
Saltwater	LIQUID	0
Drinkable	LIQUID	0
Milk	LIQUID	2
Blood	LIQUID	1
Lampoil	LIQUID	1	+
Poison	LIQUID	1	+
Liquor	LIQUID	10	+
Honey	LIQUID	1	+
Coffee	LIQUID	0

Material	Type	Value	Condition
Jade	PRECIOUS	50
Diamond	PRECIOUS	5000	++++
Gem	PRECIOUS	1000	--
Pearl	PRECIOUS	1000	-
Opal	PRECIOUS	80
Amethyst	PRECIOUS	300
Garnet	PRECIOUS	70
Aquamarine	PRECIOUS	50
Topaz	PRECIOUS	200
Amber	PRECIOUS	80
Crysoberyl	PRECIOUS	50

Location Layers

        Equipement can be designated as undergarmets or overgarments by a system of layers.  The normal layer of clothing is designated the 0 layer.  Negative layers are underclothing, while positive layers are overclothing.  Coffeemud supports up to 32767 layers, but it is not recommended to allow such latitude in your games.  Your players will become walking department stores.  The methodology recommended by the Coffeemud staff (and utilized in the crafting skills) is listed below.  Clothing must be applied from the lowest layer to the highest layer, and removed in reverse order.

        To apply a Layer to a worn item in the common skills list (or GenRecipe), you add the layer number followed by a colon prior to the wearlocation (but in the same column as the wear location).  An example would be a doublet, worn on the torso would be shown as 1:TORSO.  The default location (0) is implicitly understood, so a shirt would be written as TORSO (no colon needed).

        Clothing in adjacent layer numbers can not be worn together (that is, a layer 1 clothing doesn’t fit on top of a layer 0 clothing, but will fit over a layer -1 clothing).
There are two special flags for clothing, Multiwear (M) and Seethru (S).  Multiwear allows the item to be worn in the same (or even adjacent) layers as other clothing.  A badge that is M1:TORSO could be worn after the character is already wearing a shirt that is 0:TORSO or a doublet that is 1:TORSO. Additionally, Multiple badges of that nature could be worn at the same time.  Seethru allows the clothing to not obscure lower-layered clothing.  In the case of our badge, if we made it MS1:TORSO, you would be able to see the shirt underneath it.  If it was just M1:TORSO, you would only see the badge(s) worn, not the shirt underneath.

Layer	Examples
-5	Tattoo, piercing
-4	Hose, leotards, Hairpieces
-3	Socks, Underwear, panties, bras, corsets, garder belts, jewelry
-2	Tshirts, Camise, nightshirts, collars
-1	Normal clothes
0	Normal Leather and Chain Armors, mitts, *DEFAULT*
1	Normal Plate armors, coats, jackets, boots
2	Cloaks,Robes, scarf, overcoat,trenchcoat, cowls
3	Sleeping Bags, body bags, Heaumes, Golashes

Appendix D: Quests

Quests are tasks which can be completed by players for prizes, typically quest points, experience, money, or all three.  Quest tasks, the monitoring of their completion and status, as well as their availability, can all be automated by CoffeeMud.

The built-in Quest system in CoffeeMud allows you to automatic all of the following processes: 

• scheduling of quests by a variety of means, and managing a quest "duration"
• setting special quest-start criteria based on the players currently online
• the selection of random mobs, items, rooms, and areas from the map by various criteria
• the introduction of new mobs and/or items from saved text files, and thier automatic removal when the quest is done
• adding various skills, affects, behaviors to any of the aforementioned objects and their automatic removal when the quest is done
• adding scripts to any of the aforementioned objects and having those scripts removed when the quest is done
• special variables and designation for making your own logic problem quests (mysteries)

A quest is designated by a long set of definitions and pseudo-commands called a QUEST-SCRIPT.  The quests are created by an Archon using the CREATE QUEST [SCRIPT] command from the command line. Where [SCRIPT] is a either a complete quest script, where each command line is terminated by a semicolon (;), or a load command of the form LOAD=[SCRIPT PATH]. If you enter a complete quest script, make sure that any embedded semicolons are escaped like "\;".  An example of a create script using a load command (the more common case) is as follows:

CREATE QUEST LOAD=quests/murdermystery/murdermystery.quest

All LOAD commands use the resources directory inside your coffeemud install directory as the default path.  Therefore, if you installed coffeemud in C:\CoffeeMud, the above LOAD command will look for the file in C:\CoffeeMud\resources\quests\murdermystery\murdermystery.quest.

Quests may be started automatically (autoquests) from inside the quest script by including the SET WAIT and SET INTERVAL commands, or they may be started manually by using the MODIFY QUEST [QUEST NAME] command.

Quests can be listed, to see their status, using the LIST QUESTS command.

Quests can be removed from the list using the DESTROY QUEST [QUEST NAME] command.

Quests can be saved using the SAVE QUESTS command. Quests saved this way will be restored during the next CoffeeMud reboot.  Any time the CREATE QUEST command is used, you will need to follow it with a SAVE QUESTS if you want your quest to remain.

Quest Scripts

When creating a new quest using the CREATE QUEST [SCRIPT] command, whether you use the load command to specify an external script, or include the script directly into the create command, the quest script commands are as follows:

SET NAME [QUEST NAME] - the *unique* name of your quest. This is a required command!

SET DURATION [#TICKS] - # of ticks (4 second periods) the quest will last once started. This is a required command!

SET WAIT [#TICKS] - minimum # ticks to wait between auto-starts of the quest. Required for auto-quests only!

SET DATE [#DAY]-[#MONTH] - The real-life start-date of the quest. This is a valid substitute for the SET WAIT requirement.

SET MUDDAY [#DAY]-[#MONTH] - The start mud-date of the quest, according to the default global mud calendar. This is a valid substitute for the SET WAIT requirement.

SET INTERVAL [#TICKS] - random # ticks (1-#TICKS) to wait between auto-starting the quest, AFTER the WAIT period (see above) is over. Required for auto-quests!

SET MINPLAYERS [#PLAYERS] - Minimum number of players who must be online for a timed quest to automatically start. See SET PLAYERMASK.

SET PLAYERMASK [MASKSTRING] - If this string is empty or not specified, then anyone is considered a player for the purposes of the MINPLAYERS setting above. However, you can specify a "zapper mask" to narrow down the definition of a player.  See HELP Prop_HaveZapper for the list of valid mask values to put here.

SET RUNLEVEL [#LEVEL] - Normally, a timed quest will always run when its time comes up.  Setting a value above -1 will prevent this quest from running when its time comes up if another quest is also running at the same or LOWER run level.

IMPORT MOBS [XML FILE PATH] - this will import a list of custom mobs from a .CMARE file generated using the EXPORT ROOM MOBS command. The parameter must be the path and file name of the file, using the same format as the LOAD= command mentioned above.  This list can then be accessed with the LOAD MOB, or LOAD MOBGROUP command.

IMPORT ITEMS [XML FILE PATH] - this will import a list of custom items from a .CMARE file generated using the EXPORT ROOM ITEMS command. The parameter must be the path and file name of the file, using the same format as the LOAD= command mentioned above.  This list can then be accessed with the LOAD ITEM or LOAD ITEMGROUP command.

SET AREA ([AREA NAME OR NAMES]) - will set the current designated area to the area specified. Although this does nothing in itself, it is important for the several commands which load mobs and items. The area name ANY may be given to choose a random area. Several area names may be specified as choices by setting the first area name as ANY, followed by your other area name choices, separated by spaces. If no area name is given, this will CLEAR the area designation. This can have a profound impact on how subsequent mob or item loading, or room setting commands work.

SET AREA [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.  If the object resolves to a group of objects, a random one from the group will be chosen.

SET ROOMGROUP ([ROOM NAME]) - will set the ROOMGROUP to the set specified. If an area has been previously designated, and not cleared (see SET AREA), then the rooms will be selected from the designated area according to the room name criteria. Otherwise, rooms from the whole map will be chosen. If a room name of ANY is given, then the rooms will be chosen randomly from the world, or the area if designated.  Several room names may be specified as choices by setting the first room name as ANY, followed by your other room name choices, separated by spaces.  If no room name is given, this will effectly clear the ROOMGROUP designation (but it will not clear the area designation!).  Valid room names include map room IDs such as MyArea#123, or key words from the titles or descriptions of rooms.

SET ROOMGROUP [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.

SET ROOM ([ROOM NAME]) - will set the current designated room to the set specified. If a room or area has been previously designated, and not cleared (see SET AREA), then the room will be selected from the designated area according to the room name criteria. Otherwise, a room from the whole map will be chosen. If a room name of ANY is given, then the room will be chosen randomly from the world, or the area if designated.  Several room names may be specified as choices by setting the first room name as ANY, followed by your other room name choices, separated by spaces.  If no room name is given, this will effectly clear the room designation (but it will not clear the area designation!).   Valid room names include map room IDs such as MyArea#123, or key words from the titles or descriptions of rooms.

SET ROOM [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET ROOMGROUPAROUND [#RADIUS] ([ROOM NAME])- will set the ROOMGROUP to the set of rooms up to RADIUS rooms from the previously set ROOM. The rooms will be selected from the set of rooms which are up to RADIUS rooms away from the currently set ROOM (see SET ROOM/SET LOCALE). The radius must then be greater than 0.  If the following room name of ANY is given, then all rooms in the radius are grouped.  Several room names may be specified as choices by setting the first room name as ANY, followed by your other room name choices, separated by spaces.  If no room name is given, this will effectly clear the ROOMGROUP designation (but it will not clear the area designation!).     Valid room names include map room IDs such as MyArea#123, or key words from the titles or descriptions of rooms.

SET LOCALEGROUP ([LOCALE]) - will set the ROOMGROUP to the ones with the specified class name. If an area has been previously designated, and not cleared (see SET AREA), then the rooms will be selected from the designated area according to the locale criteria. Otherwise, rooms from the whole map will be chosen. If a locale name of ANY is given, then the rooms will be chosen randomly from the world, or the area if designated.  Several locale types may be specified as choices by setting the first locale type as ANY, followed by your other locale type choices, separated by spaces.  If no locale is given, this will effectly clear the ROOMGROUP designation (but it will not clear the area designation!).  Valid locale names may be Locale class names such as MountainSurface, StdRoom, etc, or they may be locale types such as stone, wooden, underwater, mountains, etc.

SET LOCALEGROUP [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.

SET LOCALEGROUPAROUND ([#RADIUS] [LOCALE]) - will set the ROOMGROUP to the ones with the specified class name. The rooms will be selected from the set of rooms which areup to RADIUS rooms away from the currently set ROOM (see SET LOCALE/SET ROOM). The radius must then be greater than 0.  If the following locale name of ANY is given, then all rooms in the radius are grouped.  Several room names may be specified as choices by setting the first locale name as ANY, followed by your other locale name choices, separated by spaces.  If no locale name is given, this will effectly clear the ROOMGROUP designation (but it will not clear the area designation!).   Valid locale names may be Locale class names such as MountainSurface, StdRoom, etc, or they may be locale types such as stone, wooden, underwater, mountains, etc.

SET LOCALE ([LOCALE]) - will set the current designated room to the one with the specified class name. If a room or area has been previously designated, and not cleared (see SET AREA), then the room will be selected from the designated area according to the locale criteria. Otherwise, a room from the whole map will be chosen. If a locale of ANY is given, then the room will be chosen randomly from the world, or the area if designated.  Several locale types may be specified as choices by setting the first locale type as ANY, followed by your other locale type choices, separated by spaces.  If no locale is given, this will effectly clear the room designation (but it will not clear the area designation!).   Valid locale names may be Locale class names such as MountainSurface, StdRoom, etc, or they may be locale types such as stone, wooden, underwater, mountains, etc.

SET LOCALE [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET MOBGROUP (RESELECT) ([MOB NAME]) - will designate a set of mobs with the given name. If the name ends with MASK=..., then a mask similar in functionality to the one described in the Prop_HaveZapper will apply in addition to the name mask entered before the MASK= string.  The mobs chosen will be selected from those in the designated ROOMGROUP (if one is designated),  AREA (if one is designated) or the world. The mobs must exist somewhere in the map for this command to work.  Normally a mob will not be placed in the mobgroup if the mob has been previously set with SET MOB, or SET MOBTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that  mobs may be placed in the mobgroup even if previously set, so long as the RESELECT flag was also used in the previous SET MOB or SET MOBTYPE command.

SET MOBGROUP [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing

SET MOB  (RESELECT)  ([MOB NAME]) - will set the current mob to one with the given mob name. If the name ends with MASK=..., then a mask similar in functionality to the one described in the Prop_HaveZapper will apply in addition to the mob name entered before the MASK= string. Ths mob chosen will be selected from a MOBGROUP if one has been set. Otherwise, the mob chosen will be selected from those in the designated ROOMGROUP (if one is designated), or the AREA (if one is designated) or finally the world. The mob must exist somewhere one of those groups for this command to work. If a room has been previously designated, then this command will bring the chosen mob to that room. If a room or area has not been designated (or was cleared), then this command will designate a new room and area.  Normally a mob will not be chosen by this command if the mob has been previously set with SET MOB, or SET MOBTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that a mob may be chosen if previously chosen, so long as the RESELECT flag was also used in the previous SET MOB or SET MOBTYPE command.

SET MOB [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET MOBTYPE (RESELECT) ([CLASS]) - will set the current mob to one with the given class name. Ths mob chosen will be selected from a MOBGROUP if one has been set. Otherwise, the mob chosen will be selected from those in the designated ROOMGROUP (if one is designated), AREA (if one is designated) or the world. The mob must exist somewhere in the map for this command to work. If a room has been previously designated, then this command will bring the mob to that room. If a room or area has not been designated (or was cleared), then this command will designate a new room and area.  Normally a mob will not be chosen by this command if the mob has been previously set with SET MOB, or SET MOBTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that a mob may be chosen if previously chosen, so long as the RESELECT flag was also used in the previous SET MOB or SET MOBTYPE command.

SET MOBTYPE [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET ITEMGROUP (RESELECT)  ([ITEM NAME]) - will designate a set of items with the given name. If the name ends with MASK=..., then a mask similar in functionality to the one described in the Prop_HaveZapper will apply in addition to the item name entered before the MASK= string. The items chosen will be selected from those in the designated ROOMGROUP (if one is designated), the AREA (if one is designated) or the world. The items must exist somewhere in the map for this command to work.  Normally an item will not be placed in the itemgroup if the item has been previously set with SET ITEM, or SET ITEMTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that items may be placed in the itemgroup even if previously set, so long as the RESELECT flag was also used in the previous SET ITEM or SET ITEMTYPE command.

SET ITEMGROUP [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing

SET ITEM (RESELECT) ([ITEM NAME]) - will set the current item to one with the given name. The item chosen will be selected from those in the designated ROOMGROUP (if one is designated), AREA (if one is designated) or the world. The item must exist somewhere in a room on the map for this command to work. If a room has been previously designated, then this command will bring the item to that room. If a room or area has not been designated (or was cleared), then this command will designate a new room and area.  Normally an item will not be chosen by this command if the item has been previously set with SET ITEM, or SET ITEMTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that an item may be chosen if previously chosen, so long as the RESELECT flag was also used in the previous SET ITEM or SET ITEMTYPE command.

SET ITEM [OBJECT] - serves the same purpose as the above command of the same name, but the argument is an object specifier.  See Object Specifiers below this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET ITEMTYPE (RESELECT) ([CLASS]) - will set the current item to one with the given class name. The item chosen will be selected from those in the designated ROOMGROUP (if one is designated), AREA (if one is designated) or the world. The item must exist somewhere in a room on the map for this command to work. If a room has been previously designated, then this command will bring the item to that room. If a room or area has not been designated (or was cleared), then this command will designate a new room and area.  Normally an item will not be chosen by this command if the item has been previously set with SET ITEM, or SET ITEMTYPE.  The RESELECT flag is an optional first flag which, if specified, designates that an item may be chosen if previously chosen, so long as the RESELECT flag was also used in the previous SET ITEM or SET ITEMTYPE command.

LOAD MOBGROUP ([#NUMBER]) [MOB NAME] - will instantiate all (or optionally, the given number) mobs of the given name from the set of mobs imported using the IMPORT MOBS command above. If the mob name ends with MASK=..., then a mask similar in functionality to the one described in the Prop_HaveZapper will apply in addition to the mob name entered before MASK= string. This selected mobs will be set as the current MOBGROUP. If a room, roomgroup, or area has been previously designated, then this command will create each mob in that room or random room in the area. If a room or area has not been designated (or was cleared), then this command will designate a random room and area.  This command will also designate the current mob to the last one loaded.

LOAD MOB [MOB NAME] - will instantiate a mob of the given name from the list of mobs imported using the IMPORT MOBS command above. If the name ends with MASK=..., then a mask similar in functionality to the one described in the Prop_HaveZapper will apply in addition to the name mask entered. This selected mob will be set as the current mob. If a room, roomgroup, or area has been previously designated, then this command will create the mob in that room. If a room or area has not been designated (or was cleared), then this command will designate a random room and area.

LOAD ITEMGROUP ([#NUMBER]) [ITEM NAME] - will instantiate all (or optionally, the given number) items of the given name from the list of items imported using the IMPORT ITEMS command above. This items will be set as the current ITEMGROUP. If a room, roomgroup, or area has been previously designated, then this command will create the item in that room. If a room or area has not been designated (or was cleared), then this command will designate a random room and area.  This command will also designate the current item to the last one loaded.

LOAD ITEM [ITEM NAME] - will instantiate an item of the given name from the list of items imported using the IMPORT ITEMS command above. This item will be set as the current item. If a room, roomgroup, or area has been previously designated, then this command will create the item in that room. If a room or area has not been designated (or was cleared), then this command will designate a random room and area. 

GIVE ITEM - will give the currently designated item (designated using the SET ITEM, or LOAD ITEM command) to the last designated mob or mobs (designated using the SET MOB, SET MOBGROUP, LOAD MOBGROUP, or LOAD MOB commands).

GIVE BEHAVIOR [BEHAVIOR ID] ([PARAMETERS]) - The behavior ID must be a valid behavior class name. The parameters are any parameters you wish to pass to the behavior. This command will give the most recently designated mob, item, area, room or mobgroup (designated using the set or load commands), itemgroup, or roomgroup the above behavior.  The parameters above are optional, and include any text that would be valid for the behavior id specified.  The text may also optionally include embedded references to other quest objects.  See below Object Specifiers in Parameters below for more information on using this feature.

GIVE ABILITY [ABILITY ID] ([PARAMETERS]) - The ability ID must be a valid ability class name. The parameters are any parameters you wish to pass to the ability. This command will give the currently designated mob, or mobgroup (designated using the set or load commands) the above ability. The parameters above are optional, and include any text that would be valid for the ability id specified.  The text may also optionally include embedded references to other quest objects.  See below Object Specifiers in Parameters below for more information on using this feature.

GIVE AFFECT [ABILITY ID] ([PARAMETERS]) - The ability ID must be a valid ability class name. The parameters are any parameters you wish to pass to the ability. This command will give the currently designated mob, item, room, area, or mobgroup (designated using the set or load commands), itemgroup, or roomgroup the above affect. The parameters above are optional, and include any text that would be valid for the ability id specified.  The text may also optionally include embedded references to other quest objects.  See below Object Specifiers in Parameters below for more information on using this feature.

GIVE FOLLOWER [MOB NAME] - The mob name is a mob which will be selected from the list of previously designated mobs (designated using the LOAD MOB, SET MOB, or SET MOBTYPE commands). This mob will be made into a follower of the mob most recently designated using the SET MOB, SET MOBTYPE, or LOAD MOB command. This command does not change the current mob designation, nor does it change the location of either mob.

TAKE BEHAVIOR [BEHAVIOR ID]- The behavior ID must be a valid behavior class name.  This command will take from the most recently designated mob, item, area, room or mobgroup (designated using the set or load commands), itemgroup, or roomgroup the above behavior. 

TAKE ABILITY [ABILITY ID] - The ability ID must be a valid ability class name. This command will take from the currently designated mob, or mobgroup (designated using the set or load commands) the above ability.

TAKE AFFECT [ABILITY ID]  - The ability ID must be a valid ability class name. This command will take from the currently designated mob, item, room, area, or mobgroup (designated using the set or load commands), itemgroup, or roomgroup the above affect. 

RESET- If a ROOM has been designated using SET ROOM, or by any other previously described method, this command will cause that room to reset, or re-load from the database.  If a ROOM is not currently set (or has been unset), but a ROOMGROUP or an AREA has been set, this command will cause all rooms in that set (respectively) to reload from the database.  Doing either can be somewhat time consuming, and may disrupt any players in the rooms affected, as it will cause items to vanish from the floor, and make players and mobs unable to move until the process is completed.

<SCRIPT> - This designates the beginning of embedded Javascript in your quest script.  The end is designated by a corresponding </SCRIPT> tag on its own line.  See the next section for more details.

LOAD= ([QUEST FILE]) ([ARGUMENT] ... [ARGUMENT])  - This command will cause the specified external quest script file to be loaded and executed as if it were  embedded at the current point in the script.  The  quest  filename is of the same format mentioned above.  When LOAD= is used as a command inside a script, you can also specify one or more space-delimited arguments which will be accessible inside the target quest script as Object Specifiers.  The first argument given, whether it is itself an Object Specifier, or a simple string, will be accessible inside the target quest script as ARG1, the second as ARG2, and so forth.  A special case exists, however, if one of the arguments evaluates to an Object Specifier which represents a group of objects (such as MOBGROUP or ITEMGROUP).  If that case occurs, the LOAD= command will execute once for every object inside the group! See the discussion of Object Specifiers and Object Spcifiers in Parameters for more information.

<OPTION> ([QUEST SCRIPT COMMANDS]) </OPTION> - Putting quest script commands inside of <OPTION> tags means that, for every execution of the quest script, only ONE of the <OPTION> tags will be have their script commands executed.  The one chosen will be selected at random.  If only one <OPTION> tag exists, it will be chosen every time, of course.

* Note About #.  In a quest script, anywhere the # sign is used above (such as [#TICKS] or [#PLAYERS], you may enter a normal old every day number (34) or you may enter a valid arithmetic expression using real or integer numbers and any of the following operators: + - * \ () ?

* Object Specifiers.  Many of the SET ... commands, such as SET MOBGROUP, SET MOB, SET ITEMGROUP, SET ROOM, etc, have forms which allow you to designate their value using an [OBJECT] string.  An [OBJECT] string is one of the following basic quest-script values: "LOADEDMOBS", "LOADEDITEMS", "AREA", "ROOM", "MOBGROUP", "ITEMGROUP", "ROOMGROUP", "ITEM", "ENVOBJ", "STUFF", "MOB", or one of the following mystery quest-script values:  "FACTION", "FACTIONGROUP", "AGENT", "AGENTGROUP", "ACTION", "ACTIONGROUP", "TARGET", "TARGETGROUP", "MOTIVE", "MOTIVEGROUP", "WHEREHAPPENED", "WHEREHAPPENEDGROUP", "WHEREAT", "WHEREATGROUP", "WHENHAPPENED", "WHENHAPPENEDGROUP", "WHENAT", "WHENATGROUP", "TOOL", "TOOLGROUP".  Using the SET command in this way allows you to either COPY an objects value, or re-designate it for the purposes of one of the GIVE ... commands.  If the quest script was executed from inside of another using the LOAD= script command, and arguments were specified from the above objects, you may also have access to argument object specifiers, such as ARG1, ARG2, ... ARGN.  There will be one such object specifier available for each argument passed to the script.  Please note that some object specifiers return single objects (such as MOB, ITEM, ROOM) and some return collections of objects (such as ROOMGROUP, MOBGROUP, ITEMGROUP).  Object specifiers can also be combined using + and - characters.  For instance, MOBGROUP-MOB would return the group of mobs in the MOBGROUP minus the specified MOB while the specifier MOB+ITEM would refer to an object group containing both the specified MOB and the specified ITEM.

* Object Specifiers in Parameters. When specifing parameters for the GIVE BEHAVIOR, GIVE ABILITY, or GIVE AFFECT command, you may embed the names of one or more of the Object Specifiers by prefixing the Object Specifier code string with a $ character, and concluding it with a space or other non-alphanumeric character.  For instance, the command: "GIVE BEHAVIOR Scriptable GREET_PROG 100\; say I love $MOB!!!\;~\;" would embed the name string for the MOB object specifier inside the in-line script.   In addition to this capability, you may also put a special character after the $ and before the object specifier to manipulate how the name of the object is generated.  Special characters are: '_' (to make the name in uppercase), '&' to remove any prefixed english article words from the name, or '|' to replace all spaces in the name with | characters (which is very useful for QuestChat parameters).

Mystery Objects in Quest scripts:

In addition to the normal quest objects mentioned above, such as MOB, ITEM, ROOM and so forth, there are also extranous objects and groups intended for use when building logic problem mysteries.  The commands for setting these are as follows:

SET AGENT [OBJECT] - Sets the AGENT variable to the [OBJECT].  Will also set the MOB object.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET AGENTGROUP [OBJECT] - Sets the AGENTGROUP variable to the [OBJECT].  Will also set the MOBGROUP object to the same, as well as designate one random mob from the group as the AGENT and the MOB.  See Object Specifiers above this command listing.

SET AGENTGROUP [#NUMBER] - Sets the AGENTGROUP variable to the currently set MOBGROUP, selecting at most NUMBER mobs randomly from that list.  Will also set the MOBGROUP object to the same, as well as designate one random mob from the group as the AGENT and the MOB.  See Object Specifiers above this command listing.

SET WHEREHAPPENED [OBJECT] - Sets the WHEREHAPPENED variable to the [OBJECT].  Will also set the ROOM object.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHEREHAPPENEDGROUP [OBJECT] - Sets the WHEREHAPPENEDGROUP variable to the [OBJECT].  Will also set the ROOMGROUP object to the same, as well as designate one random room from the group as the WHEREHAPPENED and the ROOM.  See Object Specifiers above this command listing.

SET WHEREHAPPENEDGROUP [#NUMBER] - Sets the WHEREHAPPENEDGROUP variable to the currently set ROOMGROUP, selecting at most NUMBER rooms randomly from that list.  Will also set the ROOMGROUP object to the same, as well as designate one random room from the group as the WHEREHAPPENED and the ROOM.  See Object Specifiers above this command listing.

SET WHEREAT [OBJECT] - Sets the WHEREAT variable to the [OBJECT].  Will also set the ROOM object.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHEREATGROUP [OBJECT] - Sets the WHEREATGROUP variable to the [OBJECT].  Will also set the ROOMGROUP object to the same, as well as designate one random room from the group as the WHEREAT and the ROOM.  See Object Specifiers above this command listing.

SET WHEREATGROUP [#NUMBER] - Sets the WHEREATGROUP variable to the currently set ROOMGROUP, selecting at most NUMBER rooms randomly from that list.  Will also set the ROOMGROUP object to the same, as well as designate one random room from the group as the WHEREAT and the ROOM.  See Object Specifiers above this command listing.

SET WHENHAPPENED [OBJECT] - Sets the WHENHAPPENED variable to the timeclock [OBJECT].  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHENHAPPENED [#HOURS-DIFFERENCE] - Sets the WHENHAPPENED variable to the current time plus or minus the hours difference specified.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHENHAPPENEDGROUP [OBJECT] - Sets the WHENHAPPENEDGROUP variable to the [OBJECT].  Will also designate one random time from the group as the WHENHAPPENED.  See Object Specifiers above this command listing.

SET WHENHAPPENEDGROUP [#HOURS-DIFFERENCE] ... [#HOURS-DIFFERENCE] - Sets the WHENHAPPENEDGROUP list to the current time plus or minus the list of hours-differences given.  Will also designate one random time from the group as the WHENHAPPENED.  See Object Specifiers above this command listing.

SET WHENAT [OBJECT] - Sets the WHENHAPPENED variable to the timeclock [OBJECT].  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHENAT [#HOURS-DIFFERENCE] - Sets the WHENAT variable to the current time plus or minus the hours difference specified.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET WHENATGROUP [OBJECT] - Sets the WHENATGROUP variable to the [OBJECT].  Will also designate one random time from the group as the WHENAT.  See Object Specifiers above this command listing.

SET WHENATGROUP [#HOURS-DIFFERENCE] ... [#HOURS-DIFFERENCE] - Sets the WHENATGROUP list to the current time plus or minus the list of hours-differences given.  Will also designate one random time from the group as the WHENAT.  See Object Specifiers above this command listing.

SET FACTION [OBJECT] - Sets the FACTION variable to the faction string [OBJECT].  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET FACTION [FACTION NAME] - Sets the FACTION variable to one of the given name or ANY to choose a random one.

SET FACTIONGROUP [OBJECT] - Sets the FACTIONGROUP variable to the [OBJECT].  Will also designate one random faction from the group as the FACTION.  See Object Specifiers above this command listing.

SET FACTIONGROUP [#NUMBER] - Sets the FACTIONGROUP variable to NUMBER random factions, or ALL to set it to all of them.  Will also designate one random faction from the group as the FACTION.  See Object Specifiers above this command listing.

SET FACTIONGROUP [FACTION NAME] ... [FACTION NAME] - Sets the FACTIONGROUP variable to the set of factions designated by the faction names.  Will also designate one random faction from the group as the FACTION.  The faction names are space delimited, and names grouped with double-quotes. 

SET TARGET [OBJECT] - Sets the TARGET variable to the [OBJECT].  Will also set the MOB or ITEM object depending on what gets designated.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET TARGETGROUP [OBJECT] - Sets the TARGETGROUP variable to the [OBJECT].  Will also set the MOBGROUP or ITEMGROUP object to the same (depending on what type of group is designated), as well as designate one random object from the group as the TARGET, and either the MOB or ITEM.  See Object Specifiers above this command listing.

SET TARGETGROUP [#NUMBER] - Sets the TARGETGROUP variable to the currently set MOBGROUP (if one is currently set) or ITEMGROUP if not.  It will select at most NUMBER objects randomly from that list.  Will also re-set the MOBGROUP or ITEMGROUP object to the same, as well as designate one random mob or item from the group as the TARGET and either the MOB or ITEM.  See Object Specifiers above this command listing.

SET TOOL [OBJECT] - Sets the TOOL variable to the [OBJECT].  Will also set the MOB or ITEM object depending on what gets designated.  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET TOOLGROUP [OBJECT] - Sets the TOOLGROUP variable to the [OBJECT].  Will also set the MOBGROUP or ITEMGROUP object to the same (depending on what type of group is designated), as well as designate one random object from the group as the TOOL, and either the MOB or ITEM.  See Object Specifiers above this command listing.

SET TOOLGROUP [#NUMBER] - Sets the TOOLGROUP variable to the currently set MOBGROUP (if one is currently set) or ITEMGROUP if not.  It will select at most NUMBER objects randomly from that list.  Will also re-set the MOBGROUP or ITEMGROUP object to the same, as well as designate one random mob or item from the group as the TOOL and either the MOB or ITEM.  See Object Specifiers above this command listing.

SET MOTIVE [OBJECT] - Sets the MOTIVE variable to the string [OBJECT].  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET MOTIVE [STRING] - Sets the MOTIVE variable to the string.

SET MOTIVEGROUP [OBJECT] - Sets the MOTIVEGROUP variable to the [OBJECT].  Will also designate one random string from the group as the MOTIVE.  See Object Specifiers above this command listing.

SET MOTIVEGROUP [STRING] .. [STRING] - Sets the MOTIVEGROUP to the set of strings specified.  Will also designate one random string from the group as the MOTIVE.  The strings are space delimited, and words grouped with double-quotes.

SET ACTION [OBJECT] - Sets the ACTION variable to the string [OBJECT].  See Object Specifiers above this command listing.   If the object resolves to a group of objects, a random one from the group will be chosen.

SET ACTION [STRING] - Sets the ACTION variable to the string.

SET ACTIONGROUP [OBJECT] - Sets the ACTIONGROUP variable to the [OBJECT].  Will also designate one random string from the group as the ACTION.  See Object Specifiers above this command listing.

SET ACTIONGROUP [STRING] .. [STRING] - Sets the ACTIONGROUP to the set of strings specified.  Will also designate one random string from the group as the ACTION.  The strings are space delimited, and words grouped with double-quotes.

JavaScripting in Quest scripts:

The CoffeeMud quest manager engine will allow you embed Javascript into your quest scripts for the purpose of assisting in setting up your quests.  The Javascript must be located between the <SCRIPT> and </SCRIPT> quest script commands to be recognized. 

Javascript is a wholly different language than the standard Scriptable/MOBPROG language OR the quest script language described in this document.  You should read the JavaScripting section of the CoffeeMud Programming Guide for more information, as well as the following web sites which discuss the usage and syntax of the Javascript language itself: http://www.mozilla.org/js/  and http://www.mozilla.org/rhino/ .

Aside from the above information about JavaScripting in CoffeeMud, there are still a few more details to learn about JavaScripting in your quest scripts. Although Javascript does not require semicolon line delimeters and it will not likely cause problems, you should be aware that the quest manager engine will strip out all semicolons as part of its command parsing process.  For this reason, if you absolutely must keep a semicolon ANYWHERE in your javascript, whether as part of a displayable string, or a line delimeter, it must first be escaped: \;

The quest manager engine will also make a couple of useful methods available to your Javascript for assisting in setting up your quests.  One is the Quest quest() method, which, as you can see, returns a Quest object which represents to the current quest script.  The Quest object returned has numerous useful methods on them for doing things like determining which mobs and items were selected by the SET commands as described above (isQuestObject, getQuestObject, getQuestMob, getQuestItem).  There are also methods for properly adding other such mobs and items to your quest (runtimeRegisterObject), or for adding abilities, behaviors, or effects to existing objects ( runtimeRegisterAbility, runtimeRegisterEffect, runtimeRegisterBehavior).  You should check out the Quest interface for more information on these methods; they are located in the file Quest.java, which is in the com/planet_ink/coffee_mud/interfaces package.

Another method provided to Javascript by the quest manager is the QuestState setupState() method.  The QuestState object made available by this method contains information on the current state of your quest Script.   There are several useful properties of the object, such as area, room, mob, mobGroup, item, and envObject which will refer to the last such objects SET by your quest script before Javascript was executed.    The Vectors loadedMobs and loadedItems are available with any items or mobs gained from the IMPORT command, regardless of whether they were LOADed.  There is also the mysteryData object with all the objects and Vectors SET for building logic problem mysteries.

Final Quest Notes:

This stuff may seem complicated, but just make sure you carefully examine the sample quests found in the CoffeeMud resources directory! Also, remember that quest script errors are always sent out to your mud.log, so check their often when starting up a new quest!

Appendix E: Socials

Socials are those miscellaneous and happy little emoting blurbs that help make muds a more fun and realistic place for players to interact.  Without them, players couldn't smile, roll their eyes, or flip anyone off without considerable typing.  The command line includes a social creator and editor:

CREATE SOCIAL TWIGGLE

This starts the creation process for a social called TWIGGLE.  There are actually four different kinds of TWIGGLE we will make: TWIGGLE (no parameters), TWIGGLE SELF, TWIGGLE ALL, and TWIGGLE (to a target).  This is type 1 of 4.

You wave your arms...
Social name 'TWIGGLE' Enter new.
: 

This is here in case you want to change the social name before you create it. Doubtful, so just hit ENTER and skip it.

(No change)
Target=NONE
Change T)arget, S)elf, A)ll, or N)one: 

This is where you choose the social type. For type1 socials, this would be None.

(No change)
You see 'null'.  Enter new.
:

This is what you as a player would see when you perform the social.

You wiggle your toes.

Your action type=MOVEMENT
Change W)ords, M)ovement (small), S)ound, L)arge Movement 

This is the requirement of the social. Small movement just needs hands, fingers, toes, lips, and other small body movements, while large movements require legs, and often moving the entire body. I tend to not use the Words one, and I leave sounds for, well, yelling and such. This particular social involves toes, thus it's a M)ovement. Type "M" for that.

Others see 'null'.  Enter new.
: 

This is what the people in the room see when you perform a social.

<S-NAME> wiggles <S-HIS-HER> toes.

<S-NAME> means Source Name. Character performing the social is the source. I'll have a list of usable tags at the end of this tutorial for you.

Others Effect type=HANDS
Change W)ords, M)ovement (w/noise), S)ound, V)isual, H)ands: 

This is what others in the room need to be able to know you're performing a social. This social involves toe wiggling, so I would recommend Visual. If you're curious about Hands, that would be left for handshakes, highfives, etc. 

And that concludes the creation of our TWIGGLE social, type 1.

CREATE SOCIAL TWIGGLE SELF

Ahh. Part 2, the SELF portion.

You wave your arms...
Social name 'TWIGGLE' Enter new.
:

Like the above, you don't need to change the name.

(No change)
Target=NONE
Change T)arget, S)elf, A)ll, or N)one: 

Because this portion is the SELF portion, choose "S".

You see 'null'.  Enter new.
:

This is what you see when you perform the social TWIGGLE SELF.

You glaze over while you try to wiggle your toes at yourself.

Your action type=MOVEMENT
Change W)ords, M)ovement (small), S)ound, L)arge Movement

You need toes to wiggle them, right? M)ovement for that.

Others see 'null'.  Enter new.
:

What the others in the room see when you perform the social.

<S-NAME> wiggles <S-HIS-HER> toes at <S-HIM-HERSELF>. Very odd.

Others Effect type=HANDS
Change W)ords, M)ovement (w/noise), S)ound, V)isual, H)ands:

They need to see it happen, right? I would guess it's a V)isual requirement.

And that concludes the creation of our type 2 TWIGGLE social.

CREATE SOCIAL TWIGGLE ALL

Yay! Type 3! The ALL is the Target Name.

You wave your arms...
Social name 'TWIGGLE' Enter new.
:

I doubt you would still need to change the name. You have type one and two. Why make 3 different?

(No change)
Target=NONE
Change T)arget, S)elf, A)ll, or N)one:

It's the ALL portion of social creation, so choose "A".

You see 'null'.  Enter new.
:

What you would see when you perform TWIGGLE [Target] (ex: TWIGGLE VIRAX).

You wiggle your toes at everyone. How wierd.

The display would replace the tag with the appropriate name, and in this example it would be Virax.

Your action type=MOVEMENT
Change W)ords, M)ovement (small), S)ound, L)arge Movement

We have toes we'll need to wiggle. M)ovement.

Others see 'null'.  Enter new.
:

What those twiggled at people witness.

<S-NAME> wiggles <S-HIS-HER> toes at everyone. Very strange.

Others Effect type=HANDS
Change W)ords, M)ovement (w/noise), S)ound, V)isual, H)ands:

I'd say another thing they would have to see. Don't you? V)isual.

CREATE SOCIAL TWIGGLE <T-NAME>

Yay! Type 4! The TARGET! <T-NAME> is the Target Name.

You wave your arms...
Social name 'TWIGGLE' Enter new.
:

I doubt you would still need to change the name. You have type one, two, and three. Why make 4 different?

(No change)
Target=NONE
Change T)arget, S)elf, A)ll, or N)one:

It's the TARGET portion of social creation, so choose "T".

You see 'null'.  Enter new.
:

What you would see when you perform TWIGGLE [Target] (ex: TWIGGLE VIRAX).

You wiggle your toes at <T-NAME>. How cute.

The display would replace the tag with the appropriate name, and in this example it would be Virax.

Your action type=MOVEMENT
Change W)ords, M)ovement (small), S)ound, L)arge Movement

We have toes we'll need to wiggle. M)ovement.

Others see 'null'.  Enter new.
:

What those bystanders witness.

<S-NAME> wiggles <S-HIS-HER> toes at <T-NAME>. Very strange.

Others Effect type=HANDS
Change W)ords, M)ovement (w/noise), S)ound, V)isual, H)ands:

I'd say another thing they would have to see. Don't you? V)isual.

Target sees 'null'.  Enter new.
:

If you were the unfortunate victim, this is what you would see.

<S-NAME> wiggles <S-HIS-HER> toes at you.

Target Effect type=HEARING NOISE
Change W)ords, M)ovement (w/noise), S)ound, V)isual, H)ands:

You see them wiggling their toes, so this would also be V)isual.

You see when no target 'null'.  Enter new.
:

This is what you would see if the target you want to use the social against isn't there.

Sorry. They aren't here for that lovely toe wiggle.

This concludes the social creation process. Enjoy creating your own socials, folks! To modify an existing social, purely use MODIFY SOCIAL [NAME] (i.e. MODIFY SOCIAL BONK, MODIFY SOCIAL HIGHFIVE <T-NAME>) or even MODIFY SOCIAL PAT SELF) What this does is it goes through the command list like you are creating that particular social, but with the information that is already stored on it. What you can do is just hit ENTER until you get to the part of the social you want to change and change it accordingly.

======= AND NOW FOR THE LIST OF TAGS =======
<S-HIS-HER> Outputs 'Your' if Observer=Source, otherwise 'His'/'Her'.
<S-HIM-HER> Outputs 'You' if Observer=Source, otherwise 'Him'/'Her'.
<S-NAME> Outputs 'You' if Observer=Source, otherwise the Name.
<S-NAMESELF> Outputs 'Yourself' if Observer=Source, otherwise the Name
<S-HE-SHE> Outputs 'You' if Observer=Source, otherwise 'He'/'She'
<S-SIRMADAM> Outputs 'Sir'/'Madam'
<S-IS-ARE> Outputs 'Are' if Observer=Source, otherwise 'Is'.
<S-HAS-HAVE> Outputs 'Have' if Observer=Source, otherwise 'Has'.
<S-YOUPOSS> Outputs 'Your' if Observer=Source, otherwise the Name`s
<S-HIM-HERSELF> Outputs 'Yourself' if Observer=Source, otherwise the 'Himself'/'Herself'
<S-HIS-HERSELF> Outputs 'Yourself' if Observer=Source, otherwise the 'Hisself'/'Herself'
<T-HIS-HER> Outputs 'You' if Observer=Target, otherwise 'His'/'Her'.
<T-HIM-HER> Outputs 'You' if Observer=Target, otherwise 'Him'/'Her'.
<T-NAME> Outputs 'You' if Observer=Target, otherwise the Name.
<T-NAMESELF> Outputs 'Yourself' if Observer=Target, otherwise the Name
<T-HE-SHE> Outputs 'You' if Observer=Target, otherwise 'He'/'She'
<T-SIRMADAM> Outputs 'Sir'/'Madam'
<T-IS-ARE> Outputs 'Are' if Observer=Target, otherwise 'Is'.
<T-HAS-HAVE> Outputs 'Have' if Observer=Target, otherwise 'Has'.
<T-YOUPOSS> Outputs 'Your' if Observer=Target, otherwise the Name with an '`s'
<T-HIM-HERSELF> Outputs 'Yourself' if Observer=Source, otherwise the 'Himself'/'Herself'
<T-HIS-HERSELF> Outputs 'Yourself' if Observer=Source, otherwise the 'Hisself'/'Herself'

Appendix F: Polls

Polls can be an entertaining and sometimes amusing way to measure the thoughts of players.  CoffeeMud supports single-selection voting among options which you can designate.  Polls are created with the CREATE command, reviewed with the LIST command, modified with the MODIFY command, removed with the DELETE command, and participated during the login process and/or via the use of the POLL command.

CREATE POLL

This command will create a new blank poll.  When a poll is created or modified, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include:

Property	Description
Name	the internal name of the poll.  This is just to tell them apart when LISTing your polls.
Introduction	the text that is displayed to the user when they participate in the poll.
Results Header	a short line of text to designate the results for the poll.
Qual Mask	a mask to limit the participants in your poll.  This string is similar in functionality to the one described in the Prop_HaveZapper.  Enter HELP Prop_HaveZapper for information on masking your poll participants.
Poll Active	whether the poll is presently available for participation, or is closed to participation.  This flag is automatically set to false if an expiration date (below) is used and passes.  Normally a poll must be made inactive before results can be viewed.
Preview Results	whether the participant can see the results immediately after voting, or must wait until the poll is made inactive.
Allow Abstentions	whether participants can abstain from selecting one of your options by choosing not to vote.
Use IP Addresses	whether a single ip address can designate a vote.  Helps prevent multi-playing users from getting multiple votes.
Hide Results	whether anyone other than Archons or those with the POLLS security flag can ever view the results of this poll.
POLL CMD Only	whereas normally one can participate in a poll either at login, or via the POLL command, this flag will make it so that the POLL command must be used.
Expiration Date	optional field designating the date/time when the poll will be automatically set to inactive.  If this field is empty or NA, the poll must be made manually inactive using the MODIFY POLL command.
New Vote Options	the list of options the participants may choose between.

Appendix G: The CoffeeMud File System (CMFS) 

This is a complicated topic, but one that all builders and Archons should understand.  Sooner or later, every CoffeeMud adminstrator is going to want to modify some of the local files in the CoffeeMud folder.  This may include the quests, or skill lists, or hopefully the intro.txt file located in resources/text directory!  Builders will also want to add files, including MOBPROG script files that run in the Scriptable behavior, item and mob CMARE files for the RandomMobs behavior or for other scripts, Quest scripts, and other things. 

Pretty soon, your directories are packed with stuff customized to your mud.  This can create issues for back-ups, meaning that not only do you have to back-up your database (or your data directory)  but you have to backup all those files that have been modified and added, since they play as integral a role in your world as the rooms and areas do.  All those files can also create upgrade issues, as modified files can get accidently overwritten when a new version of CoffeeMud is overlayed in your installation directory.  Lastly, this can create security issues, as the builders might accidently delete the wrong file, or make a mistake, creating problems for the admins as they try to recover.

To help solve these problems, the CoffeeMud engine uses a kind of mirrored file system called CMFS to store some files in your local directory (your hard drive), some files in your database, and some files in both at the same time.  When the exact same file in the exact same directory is found in BOTH the local file system and in the database, the one in the database is always preferred.  That way, should the file in the database (called a VFS file) become corrupted or deleted, the one in the local file system will remain safe.  Furthermore, since files in the database (VFS files) are always accessed before the same file in the local file system, you can overwrite the files in the local file system with upgrades without worrying about losing your changed files.  And lastly, CoffeeMud provides a security system that allows you to grant access to users on a folder level, and also to specify whether the user can access the local file system, or only the database VFS files and folders.

The CMFS includes everything in your CoffeeMud installation directory/folder, and all the other folders therein.  In fact, CoffeeMud is utterly unable to access any files OUTSIDE of your CoffeeMud installation folder, giving the server administrator an added level of comfort.  The CMFS is also able to access the VFS files in the CoffeeMud database, and to give them preference over identically named files in your local file system.

CMFS employs the UN*X standard for separating directorys and folders.  This means that the forward slash / character is used when separating one folder from another when naming a file.  The CMFS path /resources/text/intro.txt would, for example, refer to the file called intro.txt inside the text directory, which is inside the resources directory, which is in your CoffeeMud installation folder.

If that file had been previously copied into the same directory in the VFS database, then the CMFS would prefer that version over the one that remains in the local file system.  You may modify the file resources/text/intro.txt, update it, and save it without needing to remember that you are really changing a file in the database.  CoffeeMud will always remember to prefer to the one in the VFS to the one on your local hard drive, if it has been copied or saved there. 

If for some reason you absolutely need to ensure that ONLY the local file system version of a file or ONLY the VFS version of a file is referenced by CoffeeMud, you may do so by prepending a special string to your file paths.  The string is double-colon :: to force access of a VFS file, and double-forward-slash // to force access of a local file system file.  For instance, if the Scriptable prog resources/progs/myprog.script is located in both your local and VFS file systems, then you can force Scriptable to use the VFS version by using  ::resources/progs/myprog.script as your path name.  If you needed to force Scriptable to load the local file system version of the file //resources/progs/myprog.script would do the trick.  Again, resources/progs/myprog.script alone, without any special prepended file, will prefer the VFS file, but will use the local file if a VFS file is unavailable.  This is the preferred behavior, so your Scriptable filenames should employ the normal path naming standard except under very extraordinary circumstances.

Files can be copied into the VFS from the local file system using the Archon SHELL command.  If you were to go into the coffeemud resources folder using this command:

shell cd /resources

if you now view the directory

shell dir

you'll see all the files in your local filesystem in the resources folder in your coffeemud installation directory.  Now, you may copy all of the files in this directory into the *same* directory in the VFS database by entering:

shell copy * ::/resources

the copy command here is followed by a wild-card character, the asterisk, to designate ALL files in the resources directory.  The next parameter is the destination folder.  In this case, we specify our destination as ::/resources, which would be the same directory, but in the VFS system.  Notice that we did not have to create a VFS folder called /resources before we did this.  The VFS always has a mirror copy of all the local file system folders.  However, it requires you to use the SHELL COPY command to create a mirror of the files themselves.  Now, look at the directory again:

shell dir /resources

We displayed the directory this time using an absolute path name, just to show you the syntax.  You are still looking at the same directory you saw when you entered shell dir. In fact, you can enter that command again to prove it.  You'll see that all of the files have little "+" marks next to them.  This means that the files exist both in your local file system *AND* in the VFS.  Now suppose we did something silly, like delete our local file system version of resources/socials.txt. This could be done with the following command:

shell delete //resources/socials.txt

Notice that we used the double-slash // to designate that we want to delete the LOCAL version.  Had we not put those two slashes in front, it would have preferred the VFS copy of socials.txt and deleted that one instead.  Now, look at the directory again:

shell dir *

This time we displayed the directory using an * wildcard, just to demonstrate that we can use mask characters when displaying directories.  The command is doing the same thing the previous two shell dir commands did, just in a different way.  Now, you'll see that most of the files still have the "+" sign in front, but now socials.txt only has a "-" character.  This means that the file exists only in the VFS database, and not on our local hard drive.  We can copy it back to our local file system by doing: 

shell copy ::socials.txt //

You'll see that I changed the syntax of the copy command around again to demonstrate some of the previous lessons.  We use the :: characters in front of the filename socials.txt to specify that we want to copy the VFS version of the file.  Since the VFS version is always preferred and accessed first, the copy command would have worked just fine without the two :: characters in front.  The last parameter is just two slash marks.  When no directory or folder is specified, the default and current directory is used.  In this case, we only specified the two slash marks to denote the local file system, and we did not specify a destination folder.  This means that the file socials.txt will be copied into the current folder, on the local file system only.

There are numerous other shell commands you can make use of, such as makedirectory to create new folders, edit to modify a text file, findfile to hunt down a file with a given name, or searchtext to find a file containing a given text string. The shell command is a useful tool for mirror your local files in your VFS database for safety, convenience, and easy back-ups.

The last topic concerning the CMFS is about security.  At the top of this Guide, the subject of security codes was discussed.  Well, CMFS provides its own security codes to limit access to files and folders in either the local file system, the VFS, or both. 

By default, a user is not allowed to access any files in either file system, unless they are an Archon or have been given a CMFS security code.  The two security codes are FS: [ABSOLUTE_PATH] and VFS: [ABSOLUTE_PATH].  In cmfs security codes, the [absolute path] is a path name starting from inside your coffeemud directory, with no path-separating slashes  except to separate directories or to designate that the last file is really a directory by using a trailing forward slash.  

For example, to give a user access ONLY to files in the VFS database folder /resources/text/, you would give the user security code VFS: RESOURCES/TEXT/ The user would then have permission to view or delete any of the VFS database versions of files that have been copied into that directory from the local file system.  The user would also have permission to create new files or create new directories in the VFS inside that folder.  Directories and files created by such a user, who only has a VFS security code, would not create ANY files in your local file system.  All files would reside only in the VFS database.  This user would not even be able to copy existing local file system files into the VFS to modify, since he does not have access. 

To give the same user access to BOTH the local file system and VFS versions of the resources/text directory, the security code would need to changed to FS: RESOURCES/TEXT/  Using FS instead of VFS gives the user access to both local and database versions of those files. 

Of course, by default, an Archon has access to both versions of the entire coffeemud installation folder.  It would be as if the Archon had the security code FS: With no directory specified, the Archon has local file system (and implied VFS)  access to the root directory and everything underneath it.  For that reason, when limiting access to the file system, it is best to use the VFS: security code, and to always designate a limited directory path in which your adminitrative user may play (upload their files, save their scripts, etc).

Appendix F: Clans

Clans serve many purposes in the CoffeeMud engine.  They provide a way for multiple players to own property, conquer areas, and exert control.  They also provide a means of expressing politics between themselves and other groups, or even with each other.  Clans can allow ranking players to order each other around, to create special magical items, to keep a collective treasury, to collect taxes from other players, and to override normal PK (playerkill) settings.  Clans can be tyrannical, run by a select few, run by elected members, or run collectively.  Clans can even be used as an alternative means of learning new Classes.

By default, clans can be created and managed entirely by players.  This ability can be removed by disabling the several clan creation and management commands from the coffeemud.ini file using the DISABLE= field.  Regardless, there is also an Archon mechanism for creating and managing clans.

CREATE CLAN <clanname>

This command will create a clan with the given name.  You can then enter the following commands at any time:

DESTROY CLAN <clanname>

MODIFY CLAN <clanname>

When a clan modified, you are presented with a list of properties to fill in.  Pressing enter will leave the property unchanged.  The properties include:

Appendix I: Index

Generic Item Types (GenItems)

Generic MOB Types (GenMOBs)

Appendices