# CoffeeMud 5.9 Game Builders Guide
Introduction CoffeeMud File System Abilities Languages CraftSkills Components All-Qualifys Recipes Classes Factions Quests Holidays Socials Polls Clans Governments Achievements | Introduction The purpose of this document is to cover aspects of CoffeeMud game creation that are not directly related to Area/Map and Mob/Item creation, which is already covered in detail in the Archons Guide. 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 xml (*.cmare) files for the RandomMonsters 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 UNIX 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. If you peruse the CMFS directories using either the shell command, or the File Manager in the MUDGrinder, you will find that all of your local files, and any VFS files you created are accessible side-by-side. Poke around long enough, however, and you'll find one special VFS directory (/resources/catalog/...). This directory is created by the system to house read-only versions of the items and mobs in your Catalog system as xml (*.cmare) files. These files and directories may not be modified or deleted, as they are only a mirror of the catalog. See the Archon's Guide for more information on the Catalog system. 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). Abilities (Skills/Spells/Chants/etc..) 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 bestow 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 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:
Property | Description
Skill Name | the name of the ability. Make this anything you like, but uniqueness is important for making help file entries.
Type, Domain | the skill type and domain (if any). Enter the type, a comma, and a domain (or nothing). Enter ? to get a list of skill and domain types.
Command Words | the command invocation word. This need not be unique to your skill! For instance, use CAST for spells, and the command word will automatically require the skills name to be included for invocation. Use commas to seperate different invocation words. This can be blank for Properties.
Minimum Range | for combat/targeted skills, how far away the invoker must be to use the skill. Use ? to get a list of possible values.
Maximum Range | for combat/targeted skills, how close the invoker must be to use the skill. Use ? to get a list of possible values.
Ticks Between Casts | number of ticks that must ellapse before the skill can be used again.
Duration Override (0=NO) | if your skill affects the target over time, then the duration will be standard. If you wish to override the standard effect duration, set this to a number of ticks greater than 0.
Affect String | what is displayed in the Affects list when players and mobs are affected by this ability. Enter nothing, or NULL to show nothing at all. This is only used when Can Affect is set properly.
Is Auto-invoking | whether this skill is automatically applied to a player as an affect when they learn the skill. If true, the ability will show no casting message, and proceed directly to affecthood.
Skill Flags | 0 or more comma-delimeted flags that describe the affects of your skill to the rest of the mud engine. Use ? to get a list.
Override cost | designate the cost of using this skill in mana/movement/etc. A value of -1 means to use the default system as defined in your coffeemud.ini file. A value of 0 means its free. A value from 0-99999 means to always use that amount. A value of 2147483647 means to always use all of the mobs mana/move points. A value of 2147483647-100 to 2147483647 means to use that percentage of the mobs mana/move points.
Cost Type | one or more flags designating the type of mob resource used to invoke the skills, whether it be move, mana, hit points, or some combination. Enter ? for a list.
Can Affect | the types of objects which, when invoked, this skill will remain on as an affect. The list is comma-delimited. Make sure this is a subset of the Can Target list! Enter ? for a list.
Can Target | the types of object which, when invoked, this skill will target. If the value is 0, it will target only the invoker. Enter ? for a list.
Tick/Periodic Affects | the standard damage/healing and Extra Castings will apply at skill invocation time. However, if your skill is set to affect the target over time, AND this is set to true, then those things will happen every tick until the effect expires.
Quality Code | whether this skill is malicious (hurts the target), beneficial to self or others (always gives a combat benefit), ok to self or others (sometimes gives a combat benefit under certain circumstances), or indifferent (usually for role-playing skils). Enter ? for a list.
Affect Adjustments | For skills that affect their targets (see Can Affect), this is the list of affects and their values. It is modelled on the same syntax and format of the property Prop_HereAdjuster, so enter HELP Prop_HereAdjuster for information on the syntax for this field. Entering ? will show you that help.
Caster Mask | a mask to determine if the invoker is allowed, under the circumstances, to use this skill. Enter ? or help on ZAPPERMASKS for more information on the syntax for CoffeeMud "Zapper" masks.
Scriptable Parm | a Scriptable-behavior parameter denoting the script that is active during invocation of this skill and during its tenure as an affect. See the Scriptable Guide for detailed information on how to use mobprog scripts. Enter ? for some short help on acceptable parameters here. *special note: during successful invocation of this ability, a special trigger event will occur that can be handled by an IMASK_PROG p <ability id>. Such a script trigger would, for example, be the appropriate place to put damage commands for skills that do damage. Periodic actions can be placed in RAND_PROG triggers.
Target Mask | a mask to determine if the target is allowed, under the circumstances, to be targeted by this skill. Enter ? or help on ZAPPERMASKS for more information on the syntax for CoffeeMud "Zapper" masks.
Fizzle Message | the message shown when the mob or player fails their proficiency check for this skill. Use <S-NAME> as a substitute for the invoker, and <T-NAME> as a substitute for the name of the target.
Auto-Cast Message | the message shown when the skill is invoked from a wand, scroll or other automatic means. Use <S-NAME> as a substitute for the invoker, and <T-NAME> as a substitute for the name of the target.
Normal-Cast Message | the message shown when the skill successfully invoked. Use <S-NAME> as a substitute for the invoker, and <T-NAME> as a substitute for the name of the target.
Post-Cast Message | the message shown after the skill is invoked, if the target did not make a saving throw against it. Use <S-NAME> as a substitute for the invoker, and <T-NAME> as a substitute for the name of the target.
Attack Type | an optional field for malicious skills. this is the secondary type of attack being made, where the primary attack type is determined by the skill type (magic for spells, chants, prayers, etc). for instance, for a flame-shooting spell, FIRE would be an appropriate value. Use ? for a list.
Silent Affects | an optional semicolon delimited list of miscellaneous skills/spells/properties which the target of this skill will be placed under for the duration of the affect. Enter ? or help on Prop_SpellAdder for more information on the syntax for this field.
Extra Castings | an optional simicolon delimited list of mischellanous skills or spells which will be invoked upon the target of this skill after all of the other above things have occurred. Enter ? or help on Prop_SpellAdder for more information on the syntax for this field.
Damage/Healing Formula | an optional formula describing either a range of damage or a range of healing which will be inflicted upon the target of this skill at invocation time. The syntax of this field is a formula. Use +-*/()?. @x1=caster level, @x2=target level. Formula evaluates >0 for damage, <0 for healing. Requires Can Target above! See help on MATH_FORMULA for more information on how to use this formula field.
Help Text | always starting with the string <ABILITY>, this is the entry players will see when they enter HELP ABILITYNAME.
Languages Although below the consideration of the mighty archons, a language is a series of noises or scribblings that mortals use to communicate their ideas with each other. Like Skills and Spells above, Languages can be created by the Archons, and then assigned to races, or allow them to be trained by players. By default, CoffeeMud comes with several interesting languages that players can speak using the SPEAK command. However, CoffeeMud also allows you to define languages outside of the java-realm. This can be done from the command line using the CREATE command. If you want to create a new language called Boopsia, for instance, you might enter: CREATE LANGUAGE Lang_Boopsia And it would be done. The "Lang_Boopsia" is the abilities Ability ID. The fact that it starts with "Lang_" is merely for descriptive purposes, and is not required. Most languages do not, for some unknown reason. Whenever creating or modifying a new language, the Archon is presented with a menu of selections and options available to customize the class. Here is a description of those options:
Property | Description
Name | the name of the language. Make this anything you like, but uniqueness is important for making help file entries.
X Letter Words | languages work by replacing the players native language words with words from these lists which are similar in length. Since most english words are under 10 letters, you would normally not need more than 10 word lists. These lists are a comma delimited set of words in the New language that are used to replace english words of similar length.
Hashed / Replacement Words | If you would actually like to have some direct word translations, here is where you would put them. For example, to have the word "CAT" always translated to "DIABLO" in your new language, you would define that fact here
Help Text | always starting with the string <ABILITY>, this is the entry players will see when they enter HELP ABILITYNAME.
Craft Skills Crafting Skills are skills that players use to take raw resources and turn them into useful things, like swords, armor, bags, bowls, and so forth. These are skills like Cobbling, Carpentry, Weaponsmithing, etc. Although CoffeeMud includes a wide variety of configurable crafting skills, it is not beyond the realm of possibility that you may want to add onto them. Therefore, CoffeeMud also allows you to define crafting skills outside of the java-realm. This can be done from the command line using the CREATE command. If you want to create a new craft skill called Mixologist, for instance, you might enter: CREATE CRAFTSKILL Common_Mixologist And it would be done. The "Common_Mixologist" is the abilities Ability ID. The fact that it starts with "Common_" is merely for descriptive purposes, and is not required. Most existing crafting skills do not, for some unknown reason. Whenever creating or modifying a new skill, the Archon is presented with a menu of selections and options available to customize the class. Here is a description of those options:
Property | Description
Name | the name of the skill. Make this anything you like, but uniqueness is important for making help file entries.
Command Words | the command invocation word. This need not be unique to your skill! Use commas to seperate different invocation words.
Skill Verb | a descriptive verb shown when the player is doing this skill, such as mixing, crafting, carving, hitting...
Recipe Filename | the name of the recipe file, which will be found in /resources/skills/
Raw Materials | if this skill supports making items out of a raw material (as opposed to making items out of other items), then here is where you would specify which raw material or resource types are used to make them. If nothing is specified here, then the skill can only be used to make items from other items.
Can Mend | does this skill support mending the things it makes?
Can Refit | does this skill support refitting the wearables it makes?
Can Bundle | does this skill support bundling the raw materials you make things from with this skill?
Can Sit | can this skill be performed while sitting down?
MSP file | the name of the sound file from /web/pub/sounds that should be played when the player does this skill.
Help Text | always starting with the string <ABILITY>, this is the entry players will see when they enter HELP ABILITYNAME.
Components (for Skills, Spells, etc..) A Component in this context refers to an item or items that a player must have or have access to in order to use a particular skill, cast a particular spell, prayer, song, etc. Components are required only at the time the skill or spell in invoked, and may be consumed or not by the invocation. An example of this would be cloth for the bandaging skills, a forge for the blacksmithing skill, or sand for the sleep spell. From the command line, skill components can be created using the CREATE command: CREATE COMPONENT Skill_Sleep You can also modify the skill component requirements by using the MODIFY command: MODIFY COMPONENT Skill_Sleep Where Skill_Sleep would be the full ABILITY ID of the skill you want to add or modify component requirements for. Use can use LIST ABILITIES to see all the ability ids in your mud. Either way, you are then presented with a wizard menu for each required component in the invocation. An invocation can include several components, and they can be all required, or just some or one of them required. You can also have some required by certain kinds of casters that are not required by other kinds. The first menu is a list of each component, whether it is one of many requred, or just an optional component. To edit one, enter its number. To add a new one, enter the highest number shown. This will give you a menu of information about that component, as follows:
Property | Description
Conjunction | this is how this entire component relates to the ones before it. If it is ALSO required in addition to the ones before it, set this to say AND. If it is an OPTION along with the ones before it, set it to say OR. On the command line, enter X to delete the entire component.
Component Position | this is where the item must be in order to be used as a component. This value can be 'inventory' for the players inventory, 'onground' to be on the ground in the same room as the player, 'held' to require it be in the players held position, 'worn' to require it be worn, or nearby for an item in a nearby container.
Component Fate (Consumed) | whether or not a this component is consumed when the skill is used. This value will be consumed if if is, or kept if it is not.
Amount | the number of units of the component required for each skill invocation. If the component is consumed, all units will be consumed.
Type of Component | there are 3 types of valid components, material types, specific material resources, or arbitrary item names. Use ? for a list of resources.
Component Mask | a zapper mask (see help on zapper masks) to filter in what kind of player this component applies to.
If you no longer want a skill to require a component, you can always just obliterate it with the DESTROY command: DESTROY COMPONENT Skill_Sleep Of course, all this can also be done from the MUDGrinder Components editor. All-Qualify Skills/Spells/etc.. An All-Qualify skill is one that is accessible to all of your character classes. They are divided into two catagories: skills that are qualified by All classes, and skills that are qualified by Each and Every class. The distinction is an subtle one; skills qualified for by All classes are not considered to belong to any particular class, and will be listed and processed different in the muds user interface in various ways. A skill qualified for by each and every class belongs to each class, and is processed exactly like any other class skill. From the command line, all-qualify entries can be created using the CREATE command: CREATE ALLQUALIFY EACH Skill_Sleep You can also modify the all-qualify entries by using the MODIFY command: MODIFY ALLQUALIFY ALL Skill_Sleep Where ALL would be either EACH or ALL; where Skill_Sleep would be the full ABILITY ID of the skill you want to add or modify all-qualify entries for. Use can use LIST ABILITIES to see all the ability ids in your mud, or LIST ALLQUALIFYS to view the existing entries. Either way, you are then presented with a wizard menu :
Property | Description
Qualifying Level | which class level is the skill gained or qualified for
Auto-Gained | true if the skills is automatically gained, and false if it is merely qualified for (and must be gained at cost)
Default Proficiency | the proficiency that a player automatically has in this skill when they gain it, either automatically, or after training
Qualifying Mask | a zapper mask filtering what sorts of players can gain this skill. See HELP ZAPPERMASK for more info.
Required Skills | a list of other skills that must be known before this one can be gained. You can also specify a minimum proficiency to gain the skill. In the command line, this is a space-delimited list.
If you no longer want a skill to be all qualified, you can always just obliterate it with the DESTROY command: DESTROY ALLQUALIFY EACH Skill_Sleep Of course, all this can also be done from the MUDGrinder All-Qualifys list editor. Recipes (for Common Skills) Recipes are the wonderful things that players can create from their Common Skills, specifically those dealing with crafting. To create, modify, or delete recipes, the MODIFY command is used: MODIFY RECIPE Armorsmithing Where Armorsmithing is the name of the skill to define recipes for. Use LIST RECIPES to get a list. You will now be presented with an ENORMOUS grid showing all the recipes currently defined for that skill. The columns will differ from skill to skill, and are probably hard to read in 80 columns. Entering a number next to one of the columns will give you a menu for each of those confusing columns. Here is a list of all the possible columns you may see and what they mean:
Field Name | Table Column | Description
Spell ID | The Spell ID | the ability id of the spell cast by this item
Resource Name | Resource |
Item Name | Item Final Name | the final name of the item. If a % character
Item Level | Lvl | the level of the item, and the required level of the player to make the item
Build Time Ticks | Time | the number of ticks (4 seconds) to make the item
Amount Material Required | Amt | the amount of material required to make the item. The material type depends on the common skill.
Optional Amount Required | Amt | an optional amount of material required to make the item. The material type depends on the common skill.
Materials Required | Amount/Cmp | one of 3 things: 1. the amount of material required to make the item. The material type depends on the common skill. 2. an ability id representing the name of a pre-defined skill component definition (see skill components in this document) 3. a coded string defining a custom skill component definition, containing one or more components, each of which contains: disposition (inventory, held, worn, nearby, onground), fate (consumed or kept) , amount of items, component id (name of a raw resource, name of a material type, or an item name), mask (zapper mask for players that this component applies to)
Item Base Value | Value | base value, in base currency (usually gold) of this item
Item Class ID | Class ID | the class of the item (GenItem, GenFood, GenWeapon, GenArmor, GenContainer, etc)
Coded Wear Location | Wear Locs | where the item can worn (hands, etc..)
Container Capacity | Cap. | capacity of the container created, in pounds
Base Armor Amount | Arm. | number of armor points the item provides, or takes away
Container Type | Con. | container type: (liquid, coins, swod, daggers, scrolls, keys, etc, etc..).
Container Type or LidLock | Con. | container type: (liquid, coins, swod, daggers, scrolls, keys, etc, etc..). or Lid for items with lids, or Lock for items with lids and locks.
Coded Spell List | Spell Affects / Abilities | list of ability ids that affect the user of the item, or an ability followed by a semicolon and its parameters
Base Damage | Dmg. | the base amount of damage the item does
Lid Lock | Lid. | lid if the item has a Lid, Lock if it has a lid and a lock
Statue | Statue | whether or not the item is a statue of something or someone
Ride Basis | Ride | if a rideable item, what kind of rideable: chair, table, ladder, etc..
Liquid Capacity | Liq. | amount of liquid capacity
Weapon Class | WClas | the weapon classification of the weapon
Smoke Flag | Smoke | whether the item is smokeable
Weapon Hands Required | Hand | number of hands required to use the weapon
Light Duration | Dur. | duration, in ticks, of the light source
Clan Item Codenumber | Typ. | clan item type (flag, banner, gavel, etc...)
Clan Experience Cost Amount | Exp | clan item amount of experience required to create
Clan Area Flag | Area | clan item area the law book belongs to
Readable Text | Read | readable text (optional)
Required Common Skill ID | Common Skill | clan items: the ability id of the common skill this item causes mobs to do
Food Drink | ETyp | edible type -- whether the item created is food or drink
Smell List | Smells | smell emote produced by this perfume
Resource or Keyword | Resc/Key | either the name of a raw resource, or an arbitrary item name
Resource Name or Herb Name | Resrc/Herb | either the name of a raw resource, or the name of an herb type
Ammo Type | Ammo | type of ammo (arrows, bullets, etc)
Ammo Capacity | Ammo# | amount of ammo the item holds
Maximum Range | Max | maximum range of the weapon
Resource or Material | Rsc/Mat | either a raw resource, or a material type
Optional Resource or Material | Rsc/Mat | either an optional raw resource or an optional material type
Herb Name | Herb Final Name | the final name of the herb
Ride Capacity | Ridrs | the number of players/mobs who can ride the item
Metal or Wood | Metal | whether metal or wood is used as a secondary material type
Optional Race ID | Race | optional required races that can make this item
Character Classes A character class is a designation chosen by players that limits the scope of skills and abilities they will have available to them as they advance in level. CoffeeMud supports several different class-systems through its coffeemud.ini file (the CLASSSYSTEM entry). One such option is the Single-class system, whereby the player can select a single class to play throughout their characters gaming career. Another is the Sub-classing system, whereby the player selects a parent-class to play, but may add/change to any of that parent classes sub-classes to gain a different selection of skills as they go forward in levels. A third is the multi-classing system, whereby the player can select an initial class, but may add/change to any other class to gain a different selection of skills as they go forward in levels. The last option is to disable the class system altogether, which essentially only means that the player is not allowed to choose which class they play, but are secretly forced into a single class that determines their skill selection. See your coffeemud.ini file for more information on this feature. CoffeeMud includes numerous character classes by default that give players access to the hundreds of skills in the CoffeeMud codebase. However, they doesn't mean there isn't room for change, improvement, or addition. Customized player or mob 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. The name Boxer is just an example. You can enter any non-space string to serve as an official ID for your character class. You can even specify the name of an existing code-base class, such as Fighter or Mage. If you specify your own name, you are creating a new class from scratch. If you specify an existing class name, you are essentially "over-riding" that standard class. This can be a quick and easy way to disable existing standard classes, since you can create a generic character class called Fighter, for instance, then set it so that players can not select it, which effectively disables that character class. After a character class is created using the CREATE CLASS command, it can be deleted or modified later using the DESTROY CLASS or MODIFY CLASS commands. 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:
Property | Description
Number of Names | the number of displayable names this class has. Normally just 1.
Name #x | a displayable name of the class. Each displayable name applies based on a class level.
Name #x Class Level | a class level at which this displayable name begins to apply.
Level Cap | maximum level that can be gained in this class, or -1 for unlimited
Base Class | the base class category into which the class fits. Usually this is the same as the ID you specified when doing CREATE CLASS. However, if you are using a subclass system and you want this class to belong to a set of subclasses under a base class, and this particular class is NOT the base class, then this field should be set to the class ID of the base class it falls under.
Availability | whether or not players may access this class at creation, in spells, or never.
HP/Level Formula | formula for determining number of hit points gained at each level. See help on math formula. Variables are: @x1: Players current class level, @x2: Players adjusted Strength, @x3: Players Max adjusted Strength, @x4: Players adjusted Dexterity, @x5: Players Max adjusted Dexterity, @x6: Players adjusted Constitution, @x7: Players Max adjusted Constitution, @x8: Players adjusted Wisdom, @x9: Players adjusted Intelligence
Mana/Level Formula | formula for determining number of mana points gained at each level. See help on math formula. Variables are: @x1: Players current class level, @x2: Players adjusted Wisdom, @x3: Players Max adjusted Wisdom, @x4: Players adjusted Intelligence, @x5: Players Max adjusted Intelligence, @x6: Players adjusted Attack Attr, @x7: Players Max adjusted Attack Attr, @x8: Players adjusted Charisma, @x9: Players adjusted Constitution
Practices/Level | the number of practice points gained by this class per level.
Attack/Level | the number of attack points, modified by a formula based on the mobs attack attribute, gained per level.
Attack Attribute | the primary attribute used with the above to determine the number of attack points gained per level.
Practices/1st Level | the number of practice points received by this class at first level.
Trains/1st Level | the number of training sessions received by this class at first level.
Level/Dmg Pt | the number of levels between gains of 1 point of base damage.
Movement/Level Formula | formula for determining number of movement points gained at each level. See help on math formula. Variables are: @x1: Players current class level, @x2: Players adjusted Strength, @x3: Players Max adjusted Strength, @x4: Players adjusted Dexterity, @x5: Players Max adjusted Dexterity, @x6: Players adjusted Constitution, @x7: Players Max adjusted Constitution, @x8: Players adjusted Wisdom, @x9: Players adjusted Intelligence
Armor Restr. | the type of armor restrictions for using skills in this class, if any.
Armor Restr Spells | normally, armor restrictions apply when any class skill is used. If this field is true, however, armor restrictions apply only when a class spell/chant/prayer is cast.
Limitations | This is an open text field. Mention any special limitations of the class.
Bonuses | This is an open text field. Mention any special bonuses to being this class.
Qualifications | This is a mask to determine which players qualify for it. Use ? for more information on the mask.
Minimum Stats | minimum base character stat values required to become this class.
Required Races | list of races or racial categories one must be to become this class, or all.
PhysStat 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. Hunger or Thirst > +2000000000 (two billion) to disable those. Fatigue < -2000000000 ( neg.two billion) disables that.
Starting CharState Adjustments | adjustments, positive or negative, to the default hit points, mana, and other stats for starting players of this class.
Extra Class Flags | Whether race, level, or the gaining/losing of experience applies to this class. By default, they do.
Weapon Restr. | This is a list of the weapon classes which players of this class will fumble using.
Weapon Mat. Req. | A list of the raw materials out of which a players weapon must be made in order to avoid fumbling.
Outfit | This is a list of any equipment outfitted to players who join this class.
Starting Money | String denoting how much money new players of this class get. Values can be numbers like 10, or strings like "10 gold".
Stat-Modifying Class | the name of a standard character class which will be used for special stat adjustments from java code, such as a thiefs level-based defence bonus, or druids mana bonus at their monument. If you are creating a generic char. class on top of an existing standard one, you will need to use the fully qualified class name of the form: com.planet_ink.coffee_mud.CharClasses.<charclassname> in order to access the standard version.
Special-Event Class | the name of a standard character class which will be used for special event processing from java code, such as a clerics alignement restrictions when praying, or an Artisan's expertience gains while crafting.. If you are creating a generic char. class on top of an existing standard one, you will need to use the fully qualified class name of the form: com.planet_ink.coffee_mud.CharClasses.<charclassname> in order to access the standard version.
Sub-Class switch rule | a flag that determines how this class behaves under subclassing rules. BASE means that the class can only switch to another of the same base class (default), ANY means they can switch to any base class, and NONE means a dead-end class.
Max Non-Crafting | Maximum number of non-crafting common skills learnable by players of this class, excepting class skills.
Max Crafting | Maximum number of crafting common skills learnable by players of this class, excepting class skills.
Max Common | Maximum number of all types of common skills learnable by players of this class, excepting class skills.
Max Languages | Maximum number of languages learnable by players of this class, excepting racial.
Class Abilities | a list of abilities available to those who become this class. the proficiency given is the default proficiency which players/mobs of this class start out with. Also listed here is the class level at which the skill becomes available, whether it is automatically gained (true), or merely qualified for (false), whether it is a secret skill or not, and any miscellaneous parameters for this skill. You can also modify the maximum proficiency that players of this class can train this skill up to.
Number of Security Code Sets | If this class is intended to administrators or builders, you may specify one or more sets of security codes or security groups (see above section on CoffeeMud Security). Each set begins to apply at a given class level for that set. All previous sets at lower levels continue to apply as well.
Security Codes in Set#x | The space-delimited list of security codes or groups which applies to this set.
Class Level for Set#x | The class level at which this set of security codes or groups begins to apply, in addition to any previous sets.
Factions A faction can be viewed very simply as a glorified tattoo with a number value. 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 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. Before discussing the nuts of bolts of the faction system, it should be mentioned that CoffeeMud includes some automatic and built-in factioning systems for you to use. In addition to the default alignment system, there is also a mob reaction system controlled in the coffeemud.ini file under the AUTOREACTION entry. This will cause mobs to react to players based on how their area, race, or other mobs of the same name have been treated in the past. While killing the mobs will cause faction values to go down, making the mobs more likely to mistreat the player, doing things like chatting with the mobs, just hanging around their area, or even bribing them will make them happier. The default settings for the three reaction systems is found int the resources/examples directory as areareaction.ini, racereaction.ini, and namereaction.ini. You can also customize the systems for particular areas, races, or mobs (depending on your system) by creating a directory /resources/factions and adding to it a file called race_<racename>.ini, area_<areaname>.ini, or name_<mobname>.ini with your designed faction definition. You must replace any spaces with underscore _ characters. If these files do not exist, the default configuration mentioned previously will be used for all areas, races, or mobs. The general 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 unique 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 (and Murder2, ... Murder5) which is triggered when the holder of this faction dies, Kill (and Kill2, ... Kill5) which is triggered when the holder of this faction kills another, 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. Change triggers also include a mask, which refers to the target of an event, and can prevent the event. 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 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.
Effects / Behaviors | a list of Ability Effects and Behaviors which are bestowed to non-player mobs who match the mob masking criteria for each item. Parameters for the specified Ability/Behavior may also be entered. This is terribly useful to allow mobs with a particular faction to turn nasty when they meet someone else. For example, if you have a faction named "Baddies and Goodies" and it has a Division/Range with code name BADDY, you may add the Behavior Aggressive with parameters: -FACTION +BADDY. This will make all the mobs who have the faction to attack the baddies.
Reaction Effects | a list of host faction ranges which will trigger certain game Commands, Ability Effects and/or Behaviors to appear on certain mobs in the same room as the host, so long as those mobs meet the zapper mask for the given reaction. Parameters for the Command/ Ability/ Behavior may also be entered. This is a companion to Effects/Behaviors above, except that the effects happens even to non-factioned mobs surrounding a factioned player/mob, while the above happens to the factioned mob/player. This system includes two versions: The normal system which uses more resources, but players with different faction values will conflict when in the same room, making mob reactions go to the winner. However, all properties and behaviors will work as expected. The 'Light' system uses less resources, and allows players with different faction values to get some functionality when in the same room with each other. However, some properties and behaviors may not work as expected.
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 cmare xml 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) The easiest way to create a quest is to use the Quest Maker Wizard, either from the Quest Manager in the MUDGrinder, or by entering the command: CREATE QUEST from the command line. The wizard will first allow you to select a template basis for your quest. Templates will differ in several ways, but the most important ones to watch out for are: what the player needs to do to complete the quest, and which components of the quest are created by you versus which make use of existing components of your world. After selecting a template, you will be taken through a series of pages and asked to enter lots of little details about the new quest. Hopefully the prompts are self-explanatory. Take special note when a prompt designates special syntax for the expression of data -- not following the rules can make the difference between a Quest working and falling flat, leaving a nasty trail of error messages in your log. In data dealing with the things mobs will announce or say, remember that you can use any of the special codes described in the Scriptable guide to insert data into the mobs speech, such as $i $r $a and others. When you are done filling in all the fields, your new quest will be ready for playing according to the timing you laid out. You can also manually start your quests from the Quest Manager screen in the MUDGrinder, or by using the MODIFY QUEST <quest name> command from the command line. If you have stretched the Quest Wizard as far as it will go and are ready to try your hand at poking around the innards of a Quest, continue reading. Otherwise, you're done learning about Quests. A quest weaves its way into your world through a long set of definitions and pseudo-commands called a QUEST-SCRIPT. The quest scripts are manually 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 DISPLAY [DISPLAY QUEST NAME] - a friendly displayable name for your quest. Completely optional. SET DURATION [#TICKS/TIME] - Either a number of ticks (4 second periods) the quest will last once started, or a formula, or a number followed by the word minutes, seconds, hours, days, mudhours, or muddays. Use a simple value of 0 to make your quest run continually. This is a required command! SET WAIT [#TICKS/TIME] - Either a number of ticks, or a formula, or a number followed by the word minutes, seconds, hours, days, mudhours, or muddays to minimally wait between auto-starts of the quest. This works in conjucton with SET INTERVAL. The full wait time between quest starts is WAIT + (random number between 1 and INTERVAL). Required for scheduled quests. SET INTERVAL [#TICKS/TIME] - Either a number of ticks (1-#TICKS), or a formula, or a number followed by the word minutes, seconds, hours, days, mudhours, or muddays to additionally wait up to, after the official WAIT period above has ellapsed, before starting the scheduled quest. This works in conjucton with SET WAIT. The full wait time between quest starts is WAIT + (random number between 1 and INTERVAL). Required for scheduled quests. SET SPAWNABLE [TRUE/ALL] - whether this quest will, when started, spawn a copy of itself and run the copy instead. This allows the same quest to run more than once at the same time, though it will share its name as well as its list of winners. If the ALL flag is given, the quest manager will attempt to spawn off every single STEP of the quest all at once. This can create chaos unless STEP BREAK is used instead of STEP. See information on the STEP and SET PRESERVE commands below. SET PERSISTANCE [TRUE/FALSE]- a quest with a scheduled WAIT/INTERVAL time will attempt to start after the interval completes. If the quest then fails to start, it will then go back into a wait state before attempting to start again. Setting PERSISTANCE to TRUE will cause that failed start waiting period to be trivially start, in essence making the quest repeat its start attempt over and over until successful. If PERSISTANCE is FALSE (the Default), the wait time will be the normal one determined by the WAIT/INTERVAL variables. 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 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 ZAPPERMASKS 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. This does not affect spawned quest copies, which will always run even when another of the same name (and runlevel) is active. SET PRESERVE [#STEPS]- If a number greater than 0 is issued, then when a STEP command is encountered and the commands following it are executed due to a MPSTEPQUEST Scriptable command, then any objects, behaviors, abilities, or affects which are specified after the SET PRESERVE, but BEFORE the STEP command will not be cleaned up by the quest manager until the specified number of STEPS have been encountered and executed. This allows, for instance, a mob, once appropriated and specified by a quest, to continue being used in subsequent steps without being restored by the quest manager to a natural state. An MPSTOPQUEST command, or an expired duration, will always cause the entire quest to cease executing and all objects to be cleaned up. STEP - The purpose of this command is to allow your quest to run in several different steps or stages. Placing this command in your quest script will cause the script to end execution when it is encountered. The quest will run normally until it is ordered to proceed with the next step using the Scriptable command MPSTEPQUEST. When the MPSTEPQUEST command is issued, the quest script will clean up any objects or data defined by statements prior to this STEP command, and begin processing new quest script commands which follow it. A SET DURATION command must follow a STEP command in order to ensure that the quest will continue to run following execution of the post-STEP commands, otherwise any duration settings from previous steps will be re-used. Numerous STEP commands may be places in your quest scripts. An MPSTOPQUEST command, or an expired duration, however, will always cause the entire quest to cease executing and all objects to be cleaned up. See also SET PRESERVE. STEP AUTO-This command is the same as the normal STEP command, except that when the normal duration runs out, the next step is automatically executed. The duration can still be short-cutted with MPSTEPQUEST or MPSTOPQUEST as usual. STEP BACK-This command is the same as the normal STEP command, except that it will reset the script line pointer so that the next time the quest is ordered to step again, it will repeat the given step. This can obviously cause an endless loop, but if you are using this command, it is obviously your last command and endless repeating is your goal. The use of this command is for two-step personal quests, where the first step sets up the environment, and the next step simply applies new scripts to a given player. Since any number of players may accept a quest, you would want this step repeated for each player that accept, which explains the endless nature. STEP BREAK- This command will cause the quest script to stop evaluating any further settings. Statements after a STEP BREAK, including any SETS, LOADS, or any other statements, will not be executed. This is used in conjunction with SET SPAWNABLE ANY to allow quest scripts which have been broken into several descrete steps to run independently. A SET SPAWNABLE ANY quest is considered successfully run when this command is encountered. 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 AREAGROUP ([AREA NAME OR NAMES]) - essentially the same as set ROOMGROUP below, this will set the current designated roomgroup to the rooms in the area(s) 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, separated by spaces and word-grouped with double-quotes. The area name ALL may be given to select all world areas. If no area name is given, this will CLEAR the ROOMGROUP designation. This can have a profound impact on how subsequent mob or item loading, or room setting commands work. This command will automatically clear the AREA setting. 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.The room name ALL may be given to select all designated rooms. 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. Rooms designated this way are available in Scripts using the QUESTROOM function. 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. Rooms designated this way are available in Scripts using the QUESTROOM function. 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. Rooms designated this way are available in Scripts using the QUESTROOM function. 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. Rooms designated this way are available in Scripts using the QUESTROOM function. 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. Rooms designated this way are available in Scripts using the QUESTROOM function. 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 as described by the help entry for ZAPPERMASKS will apply in addition to the name mask entered before the MASK= string. Use a name of ALL to select all appropriate mobs. 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. Mobs designated this way are available in Scripts using the QUESTMOB function. 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. Mobs designated this way are available in Scripts using the QUESTMOB function. 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 as described by the help entry for ZAPPERMASKS 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. Note: mobs, items, rooms, etc that are Cloaked (as per Prop_WizInvis) are never ever selected with any SET 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 as described by the help entry for ZAPPERMASKS will apply in addition to the item name entered before the MASK= string. Use an item name of ALL to select all appropriate items. 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. Items designated this way are available in Scripts using the QUESTITEM function. 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. Items designated this way are available in Scripts using the QUESTITEM function. 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. Use a name of ANY or ALL to load them all. If the mob name ends with MASK=..., then a mask as described by the help entry for ZAPPERMASKS 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.Use a name of ANY to load a random one. If the name ends with MASK=..., then a mask as described by the help entry for ZAPPERMASKS 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. Use a name of ANY or ALL to load them all. 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. Use a name of ANY to load a random one. GIVE ITEM - will give a currently designated item (designated using the SET ITEM, SET ITEMGROUP, LOAD ITEM, or LOAD ITEMGROUP command) to the last designated mob or mobs (designated using the SET MOB, SET MOBGROUP, LOAD MOBGROUP, or LOAD MOB commands). GIVE ITEMS - will give all currently designated items (designated using the SET ITEM, SET ITEMGROUP, LOAD ITEM, or LOAD ITEMGROUP command) to the last designated mob or mobs (designated using the SET MOB, SET MOBGROUP, LOAD MOBGROUP, or LOAD MOB commands). GIVE STAT [STAT ID] [VALUE]- will give the currently designated object (designated using the SET ITEM/MOB/ROOM/AREA, or LOAD ITEM/MOB command) a new value for their internal stat designated by the STAT ID. An important stat to be aware of is the special "KEYPLAYER" stat. When given the value of true, it will make it so that the death of the mob or mobs it is assigned to instantly ends the quest. This is an advanced coding feature; use it wisely.. 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: + - * \ () ?. The ? may be used to generate random numbers in a math expression. For example, 1?4 would generate a random number from 1 to 4, and 3+1?4 would generate a random number from 4 to 7. * 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 script 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 MOTIVE GROUP [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 MOTIVE GROUP [#NUMBER] [OBJECT] - Sets the MOTIVEGROUP variable to [NUMBER] of the items represented by [OBJECT]. Will also designate one random string from the group as the MOTIVE. See Object Specifiers above this command listing. [#NUMBER] may be a math expression. SET MOTIVEGROUP [#NUMBER] [STRING] .. [STRING] - Sets the MOTIVEGROUP to [NUMBER] of 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. [#NUMBER] may be a math expression. 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 ACTION GROUP [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. SET ACTION GROUP [#NUMBER] [OBJECT] - Sets the ACTIONGROUP variable to [NUMBER] of the items represented by [OBJECT]. Will also designate one random string from the group as the ACTION. See Object Specifiers above this command listing. [#NUMBER] may be a math expression. SET ACTIONGROUP [#NUMBER] [STRING] .. [STRING] - Sets the ACTIONGROUP to [NUMBER] of 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. [#NUMBER] may be a math expression. 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 (isDesignatedObject, getQuestStuff, getQuestMob, getQuestItem, etc). 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! Holidays Holidays are a special/reserved quest defined by file /resources/quests/holidays/holidays.quest. They are very simple Scriptless quests that can be started at random intervals, or on certain mud dates, or real-life dates. The holidays will only impact the areas specified by the holiday settings, and only the mobs in those areas specified in the settings, and only with the features you specify. Use LIST HOLIDAYS to see a list of all defined holidays and the areas hey are defined for. By default, 3 special-case weather related holidays are included which impact any area that meets their special criteria. You can use MODIFY HOLIDAY <name> to change the settings for a holiday, DESTROY HOLIDAY <name> to delete one, or CREATE HOLIDAY name to create a new one that will automatically apply to the area the creator is standing in when it is created. Here are the standard settings for holidays:
Property | Description
Holiday Name | A unique name for your holiday. It should be unique not only among holidays, but also among quests.
Schedule Type | The type of time-trigger for the holiday, whether a random interval, a mud-date, or a real-life date.
Interval Ticks | If the time trigger is a random interval, this is the math expression to derive that interval. You may use normal math operators like +-/*(), as well as the special ? operator to generate a random number. 1?5 would mean a random number between 1-5.
Mud-Day | If the time trigger is a mud-date, this is that date in month-day numeric format (like 1-30).
Real Life Date | If the time trigger is a real-life date, this is that date in month-day numeric format (like 12-31).
Duration Ticks | The number of ticks (4 second periods) that the changes specified below will be in effect once the holiday triggers.
Areas List | The list of areas to apply the holiday to. Area names are space separated, with multiple words grouped in double quotes. The word ALL is a recognized value for this list.
Mask for mobs that apply | A zapper-mask that determines which mobs inside the designated area will benefit from the changes specified below. See ZAPPERMASKS for an example of a zapper mask, or just hit ? at the prompt here.
Mood setting | If this entry is blank, it has no effect. Otherwise, it is the name of the MOOD to force all the mobs to be in during your holiday. Use ? for a list.
Aggressive Setting | If this entry is blank, it has no effect. Otherwise, it makes all the mobs aggressive during your holiday. Use ? to get a list of valid parameters. Remember that this field must not be blank if you want it to work!
Price Factor | This change will only apply to mob shopkeepers. It is a list of price-changes to make to specified items during the holiday. See help on GenShopKeeper for more information on Price Factors. You can specify as many different price-factors for as many different types of items as you need to.
MudChat for words... | This is a list of trigger words that mobs will respond to when spoken to, and what they will respond. You can have as many trigger words groupings as you like, with as many responses to those trigger words as you need. Each response begins with a single digit weight, to show how often that selection should be chosen among the others.
MOB Behavior | A list of Behaviors to apply to mobs during your holiday. See the Archon's Guide under GenMOB for more information on this, as it works the exact same way. Use ? for a list, and ? will also work in the parameters for help.
MOB Property | A list of Affects/Effects to apply to mobs during your holiday. Again, see the Archon's Guide for more information on how this works. Use ? for a list, and ? will also work in the parameters for help.
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' 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. Enter HELP ZAPPERMASKS 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/Account | whether a single ip address or account 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.
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. Players may belong, by default, to a single clan from each clan category (which are inherited from their government by default). Since (again, by default) there is only one category, players can only belong to one clan. All of this can be changed of course, starting with the numeric requirements defined by the MAXCLANCATS setting. 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:
Property | Description
Name | the name of the clan can never be changed. It can only be destroyed. Name your clans carefully!
Government Type | how the players rule the clan -- as a tyranny (Clan), a oligarchy (Guild), a republic (Union), a family, a theocracy, or a democracy (Fellowship)
Category | places this clan in a named category, which can be used to membership. Normally derived from the government type.
Clan Premise | a description of the clan for all to read
Min Members | if set, overrides the minimum members from the government settings. Setting to 0 will make the clan immortal.
Clan Experience | the number of experience points the clan has earned, usually through taxation
Clan Tax rate | the clan experience tax rate, normally set by players
Morgue RoomID | the room ID of the room where the bodies of the members of the clan appear when they die. This room must be properly owned by the Clan using a property like Prop_RoomForSale.
Clan Home RoomID | the room ID of the room where the members of the clan appear when they cast Clan Home spell. This room must be properly owned by the Clan using a property like Prop_RoomForSale.
Clan Donation RoomID | the room ID of the room where items appear when a member of the clan casts the Clan Donate spell. This room must be properly owned by the Clan using a property like Prop_RoomForSale.
Clan Qualifications | this is a mask describing what sort of people are allowed to apply and join the clan using the CLANAPPLY command. The mask is a standard CoffeeMud ZapperMask. You can use ? for a description at the prompt.
Clan Auto-Class | the name of a character class which all players who join the clan also gain for free. Normally not used, this field can be filled in when the Archon wishes to have clan based classes.
Clan Auto-Role | the role (rank/position) of the player who enters the CLANAPPLY command. Normally this is set to Applicant, meaning that the clan must approve all new members. Setting this value to something else can override that behavior.
Clan Status | depending upon your coffeemud.ini settings, clans can be in a state of pending (awaiting a sufficient number of players to become active), a state of Active, or a state of Fading (because an insufficient number of members has logged in lately, again settable in the coffeemud.ini file). This state is changed automatically by CoffeeMud, but can be altered here.
Rivalrous Clan | True if the clan can rival other clans, False otherwise. Normally derived from the government type.
Clan Members | the list of all current members and their position/rank/role within the clan. This list can be altered manually here.
Clan Governments You might want to read the previous section on Clans before proceeding. Clan governments provide a basic structure to clans, and serve a purpose similar to the one Character Classes do for players. However, as clans are social arrangements, most aspects of governments deal with the structuring of these arrangements. By default, all governments belong to a "blank" category, which means that all governments are available for players to create clans out of. Governments with other categories are available to players as governed by the PUBLICCLANCATS setting. By default, clan governments are defined in your resources directory in the file clangovernments.xml. The Archon commands available serve to modify this file. CREATE GOVERNMENT <clangovtname> This command will create a new government with the given name. You can then enter the following commands at any time: DESTROY GOVERNMENT <clangovtname> MODIFY GOVERNMENT <clangovtname> When a government is modified, you are presented with a list of properties to fill in. Pressing enter will leave the property unchanged. The properties include:
Property | Description
Type Name | the simple friendly name of this government
Category | places this government in a named category, which can be used to govern clan types. Can also be overridden at the clan level.
Short Desc | 6-10 word description shown during clan creation
Long Desc | longer form description shown in the help system
Is Public | true if clans of this type are listed publicly
Is Family | true if only family of existing members can join
Is Rivalrous | true if clans of this government type can rival other clans, false otherwise. Can also be manually set at the clan level.
Minimum Members | if set, overrides the minimum members in coffeemud.ini. Setting to 0 will also make the clan immortal.
XP/Level Formula | formula for xp required for clan to gain a level. Empty = (500 * @x1) + (1000 * @x1 * @x1 * @x1) where @x1 is current level
Conquest Enabled | true if clans of this type can conquer areas
Clan Item Loyalty | true if clan items are used to gain loyalty in conquered areas
Conquest by Worship | true if conquest is obtained through deity conversion
Vote Approved | list of clan functions that require a vote to occur
Auto-Promotion | automatic promotion policy, by rank, by char level, and whether an existing leader can be replaced
Apply Position | the position users receive when they apply for membership
Accept Position | the position users receive when they are CLANACCEPted. If this is the same as the Apply Position, CLANACCEPT and CLANREJECT are disabled.
Entry Script | scriptable script ran when a member is Accepted. Will execute ONCE_PROG. The CLANDATA function will respond to Government Category as the clan ID.
Exit Script | scriptable script ran when a member is Exiled or Retired. Will execute ONCE_PROG. The CLANDATA function will respond to Government Category as the clan ID.
Clan Char Abilities | abilities granted or made available to clan members who have privileges, based on the clan level. For each ability, specify the default proficiency, whether it is gained or qualified for, abiity parameters, and an optional comma-delimited list of government position role ids limiting who has access to this ability.
Clan Char Effects | auto-effects imposed on clan members who have privileges, based on the clan level. For each effect, specify effect parameters, and an optional comma-delimited list of government position role ids limiting who has access to this effect.
Positions constitute the ranks, roles, or positions within this clan. These also have their own fields, enumerated below:
Property | Description
Simple Role ID | a simple identifier for this role type, should be all uppercase without spaces
Name | the singular display name of this position
Name (Plural) | the plural display name of this position
Maximum | the maximum number of characters that can hold this role per clan
Is Shown | true if this position can be seen by the public, false for only by members
Powers | list of clan functions that this role can always perform, without a vote
Achievements Achievements are things that players can do for the bragging rights, for some small reward, or for a Title. Things like completing so many quests, training their stats up to unheard-of levels, exploring most of the world, or killing so many worms can all be considered achievements. The engine will track achievement progress as the player plays. In some cases, the engine will notice achievement immediately, while in most cases, the engine will not notice until a periodic sweep is done every hour or so to check for achievement progress and status. When a player completes an achievement, the fact of that completion is recorded as a Tattoo on the players record. For this reason, each achievement defined must have a unique Tattoo name. You can see the achievement tattoo when you modify the player, and can even add or remove them that way. Achievements come in several different Event types, which describe the general nature of the achievement and how it is attained. These types are as follows:
Event Type | Completion Description
KILLS | the player kills a certain number of mobs matched by a Zappermask
STATVALUE | player stat/numeric value goes above (or below) a specific value
FACTION | particular player faction value goes above (or below) a specific value
EXPLORE | the player explores a specific percent of a particular area (or the world) (these are checked periodically, please limit)
CRAFTING | a particular number of items are crafted with a particular set of crafting skills
MENDER | a particular number of items are mended with a particular set of crafting skills
SKILLUSE | a particular number of skills/spells of a particular name or type are used
QUESTOR | a particular number of quests whose name match a mask are completed
ACHIEVER | a specific set of OTHER achievements are completed (these are checked periodically, please limit their number)
ROOMENTER | a specific room or set of rooms is entered by the player for the first time
LEVELSGAINED | a particular number of levels gained (or regained) to complete
TIMEPLAYED | a particular number of seconds played
JUSTBE | the player being in a particular state (these are checked periodically, please limit their number)
DEATHS | the player is killed a certain number of times by Zappermaked mobs
RETIRE | triggered whenever the player uses the RETIRE command
REMORT | triggered whenever the player uses the REMORT command
GOTITEM | triggered whenever the player gets a particular item
BIRTHS | triggered when a player becomes a parent
RACEBIRTH | triggered when a player becomes a parent of a newly generated mixed-race
PLAYERBORNPARENT | triggered when a player becomes a parent of a mob that just became a new player
PLAYERBORN | triggered when a player is born from the actions of another player
Achievements are defined in your resources directory in the file achievements.ini. The Archon commands available serve to modify this file. CREATE ACHIEVEMENT <unique_tattoo_name> This command will create a new achievement tracked by the given tattoo name. You can then enter the following commands at any time: DESTROY ACHIEVEMENT <tattoo_name> MODIFY ACHIEVEMENT <tattoo_name> When a achievement is modified, you are presented with a list of properties to fill in. Pressing enter will leave the property unchanged. The properties include:
Property | Description
Event Type | the type of event to complete or make progress in the achievement
Display Desc | the friendly name/description of the achievement, which should also tell the player what they must do to complete it. Something like "Kill 100 Orcs"
Title Award | a player Title granted when the achievement is completed. This is optional. Like all titles, you can use can use a * character in the string where the players name would go.
Reward List | an optional list of other awards, separated by >spaces<. On rewards for PLAYER achievements, rewards go only to the player. For rewards on an ACCOUNT achievement, rewards go to all new players or children. Each entry is an amount followed by a space, and an award type. The following are valid reward types: * amount of XP experience. Example: 10 XP * amount of QP quest points. Example: 1 QP * amount of currency. Example: 10 \"gold coins\" * amount to add to a stat (see EVENT="STATVALUE" below). Example: 2 MAXSTRENGTH Additionally are stats like: BONUSCOMMON, BONUSCRAFT, BONUSNONCRAFT, BONUSCHARONLINE BONUSLANGS, BONUSCHARSTATS, BONUSCHARLIMIT, or you can prepend the word account for these additional stats, like: \"ACCOUNT BONUSCOMMON\", etc.. * level followed by an ability id to grant a skill. The ability ID can optionally have parameters in parenthesis in key=value value form. Keys include AUTOGAIN, MASK, PARMS, PREREQS. Example: 17 Spell_Light Example: 21 \"Spell_Light(autogain=false mask=\\\"-class \\\\\"+fighter\\\\\"\\\")\" * level followed by a full expertise id, which is an expertise id followed by the expertise level number. This can also optionally be followed by parenthesis with key=value parameters in them. Keys include AUTOGAIN only. Example: 7 VEXING1 Example: 12 VEXING1(autogain=false) Note the spaces and use of quotes!
* NUM | some achievement event types require that you specify how many of something, whether kills, or castings, or items crafted, or levels gained, or quests, or whatever, are required to complete the achievement.
* VALUE | some achievements event types require that you specify the value of something, such as a stat value or a faction value, required to complete the achievement.
* PERCENT | the Explore event type achievmenent requires a percentage (0-100) of an area or the world which must be explored to complete the achievement.
* ZAPPERMASK | the Kills and Deaths event type achievements allows a zappermask to specify what kind of creatures must be killed (or are the killer) to make progress in the achievement. See HELP ZAPPERMASK for more information.
* ABOVEBELOW | some achievement event types allow you to specify whether the player stat or faction must be above or below the Value to complete the achievement. Valid values here include ABOVE or BELOW.
* STAT | the Statvalue event type achievement requires the name of a stat to check to complete the achievement. Stats include things like: CURRENT STRENGTH, MAXSTRENGTH, WEIGHT, CURRENT ARMOR, MANA, CURRENT MANA, QUESTPOINTS, etc. As you can see, stats that have a base (unmodified) value are entered simply, where the modified score is accessed by prefixing with CURRENT. There are simply too many different kinds of stats to list here. Here's a useful list of stats: LEVEL, ARMOR, DAMAGE, ATTACK, WEIGHT, HEIGHT, STRENGTH, INTELLIGENCE, DEXTERITY, CONSTITUTION, CHARISMA, WISDOM, MAXSTRENGTH, MAXINTELLIGENCE, MAXDEXTERITY, MAXCONSTITUTION, MAXCHARISMA, MAXWISDOM, AGE, HITS, MANA, MOVE, HUNGER, THIRST, FATIGUE, LEVEL, USES, SPEED, MONEY, QUESTPOINTS, FOLLOWERS, QUESTPOINTS, FOLLOWERS, TRAINS, PRACTICES
* ID | the Faction event type achievement requires the Faction ID of the faction to check to complete the achievement. See factions for more information on faction IDs.
* AREA | the Explore event type achievement requires either the name of one of your areas or the word WORLD (case sensitive) for the entire world.
* ABILITYID | several achievement event types require the AbilityID of one or more skills, but this can also include skill types such as SPELL, PRAYER, etc, or even skill domains, such as ILLUSION, STEALTHY, etc. When more than one thing is specified, the list is COMMA delimited. A value of * may be given to specify ALL skills.
* ITEMMASK | the gotitem achievment uses this required mask to identify which item will trigger completion of the achievement. See help on ZAPPERMASK for more information.
* PLAYERMASK | several achievement event types have an optional player Zappermask that the player themselves must match before progress can be made in the achievement. This can be left blank to permit all players. It is useful for check area information, or the players class, or group size, for example. See help on ZAPPERMASK for more information.
* QUESTMASK | the Questor event type achievement also has an optional Quest Name regular expression mask that the Quest must match before progress can be made in the achievement. See help on Java Regular Expressions for such a format. This can be left blank to permit all Quests.
* ACHIEVEMENTLIST | the Achiever event type achievment has a required comma-delimited list of other achievement tattoos to specify which other achievements must be completed before This achievement is completed.
* ROOMID | the Roomenter event type achievement has a required comma-delimited list of Room IDs to specify which rooms must be entered by the player at least once before the achievement is completed.
* SECONDS | the Timeplayed event type achievement requires the number of real-life seconds which must be accumulated in order to complete this achievement.