The Archon's Tome
for CoffeeMud 5.2

As recorded by Pheedus Konia of the Holy City of Paran

In the lexicon of the Archons, the word "Ability" encompasses a great many powers and skills, both natural and man-made.  An ability may behave as an Affect, as a Skill, or as Both.  

An ability behaving as an Affect means that it is acting as a discrete aspect of some existing thing, whether that thing is a room, an exit, an item, or a mob.  Such aspects may include the property of great strength, great damaging ability, immunity to certain affects, or simply the garbling of normal speech.   An ability taking on this role is both passive and reactionary; passive when it is embueing its host with great strength or damage, and reactionary when it is providing immunity or garbling speech.  

An ability that is behaving as a Skill means that it allows its host (which is always a MOB in this case) to interact with the world around it, to change it, derive information from it, or beslow Affects upon it.  Such interactions can include kicking, making sick, poisoning, identifying, catching on fire, and many other things.  An ability taking on this role is entirely active, though once the active interaction ends, that same Ability may either end (as a kick), leave itself behind on its target to remain as an Affect as described above (as catching on fire would).

CoffeeMud contains over a thousand different java-coded Abilities which fall into numerous other categories and genera of various descriptions.  The most important of those categories, however, are their Ability Type.  CoffeeMud has numerous different ability types, which include Properties (which always act only as Affects), or Skills, Spells, Prayers, Chants, Diseases, Poisons, etc. (all of which can act purely as Skills, act purely as an Affects, or act as Both depending on the context in which it is used).  Whenever you place the name of an ability in the Affects list of a mob, item, room, or exit, you are telling CoffeeMud to use only the Affect/property aspect of that skill.  When you place the same ability name in the same mob's Abilities list, you are telling CoffeeMud to reserve the ability for use as a Skill.  For example, when you add Spell_GiantStrength to a GenMob's affects list, you are saying that this mob is permanently stronger than normal, but when you place it on the GenMob's abilities list, you are saying that you want the mob to be able to invoke the skill at a later date (by casting the spell).

CoffeeMud also allows you to define abilities outside of the java-realm.  This can be done from the command line using the CREATE command.  If you want to create a new skill called Poke, for instance, you might enter:

CREATE ABILITY Skill_Poke

And it would be done.   The "Skill_Poke" is the abilities Ability ID.  The fact that it starts with "Skill_" is merely for descriptive purposes, and is not required.  Generally speaking, it is a good idea to give your abilities Ability ID's that start with the general kind of ability it is, for instance "Spell_", "Chant_", "Prayer_", etc.

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

As you can tell if you read through the above, most of the meat of the work done by Generic Abilities is

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 with a number assigned.  Normal Tattoos are simply flags which a mob or player can have: either you do or do not have the tattoo.  A Faction is a kind of flag a mob or player can have the tattoo that has a special a numeric value assigned to it.  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.

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