CoffeeMud 5.10 Game Builders Guide |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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:
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:
Crafting 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:
Gathering Skills Gathering Skills are skills that players use to generate items, usually raw resources. These are skills like Foraging, Mining, Drilling, etc. Although CoffeeMud includes a wide variety gathering skills, it is not beyond the realm of possibility that you may want to add onto them. Therefore, CoffeeMud also allows you to define gathering 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 gathering skill called Worm Gathering, for instance, you might enter: CREATE GATHERSKILL Common_WormGathering And it would be done. The "Common_WormGathering" is the abilities Ability ID. The fact that it starts with "Common_" is merely for descriptive purposes, and is not required. Most existing gathering 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:
Wrighting Skills Wrighting Skills are a type of Crafting Skills that players use to principally craft large transports, such as sailing ships and caravans. These are skills like Shipwright, etc. Although CoffeeMud includes a wide variety of configurable wrighting skills, it is not beyond the realm of possibility that you may want to add onto them. Therefore, CoffeeMud also allows you to define wrighting 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 wright skill called Mixologist, for instance, you might enter: CREATE WRIGHTSKILL Common_Bigwright And it would be done. The "Common_Bigwright" 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:
Generic Traps Traps are abilities applied by Thieves to items, exits, chests, etc that trigger terrible effects when disturbed. They are applied by the Lay Traps and Make Bombs skills. Although CoffeeMud includes a wide variety of traps, it is not beyond the realm of possibility that you may want to add onto them. Therefore, CoffeeMud also allows you to define traps outside of the java-realm. This can be done from the command line using the CREATE command. If you want to create a new trap called Boom Trap, for instance, you might enter: CREATE TRAP Trap_Boom And it would be done. The "Trap_Boom" is the abilities Ability ID. The fact that it starts with "Trap_" is merely for descriptive purposes, to keep your traps organized together.. 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:
Components (for Skills, Spells, etc..) A Component in this context refers to an item/items or process that a player must have or do in order to use a particular skill, cast a particular spell, prayer, song, etc. Material 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. Process/Ritual components are a series of tasks that must be performed in order to invoke a skill or spell. An example would be saying some magic words, then waving your hands, then pointing at a target. Material and Process components can be separate, or combined into a single and very complex set of spell casting requirements. Components can then have a ZapperMask to define which players/mobs the requirements apply to. From the command line, all kinds of 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:
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 Now, because Trigger rituals can incorporate Socials into them, and because it may be common for very specific spell-casting socials to be unique only to components, the Components system also allows you to define a series of Socials which are available ONLY if the player/mob has access to a Component which is a Trigger Ritual which uses one of those special socials. These are created, etc by using CREATE COMPONENT SOCIAL Handwave, MODIFY COMPONENT SOCIAL Fingertwiddle, DESTROY COMPONENT SOCIAL Invoke, etc. Of course, all this can also be done from the MUDGrinder Components editor.
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 :
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:
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:
Introduction: AutoReaction
Factions: With this system, killing the mobs will cause faction values to go down, making the mobs more likely to mistreat the player. On the other hand, 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. Faction
Engine: 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. Faction Ranges: 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. For example, if a faction ranges from absolute evil (-10000) to pure good (10000), then a range might be neutral (-1000 to 1000) and somewhat evil might be (-5000 to -1000). Such are ranges. 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. Change Triggers: 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. A change triggers is triggered according to a specific action, and then is 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 includes:
The valid Triggers, and their parameters, if any, include:
Valid Change Directions include:
Valid Change Flags include:
Change triggers also include a target Mask, which is a zapper mask that the target of an event must pass to allow the event. If the target of an event (such as the target killed, or the bribed) does not match this mask, the change is not processed. 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.
Introduction: A plane of existence is a particular mirror universe to your own world. Each plane has a special character and flavor that alters the mirror of your existing area to reflect its special flaire. The area that is mirrored is the same as the one where the spell is cast to travel from the normal Prime Material plane to the new plane. Planes require powerful magic both to enter, and to leave. Each plane definition describes the ways in which the normal area being teleported from is changed to reflect the new plane of existence. Now, lets discuss how to list existing planes: LIST PLANES The list that is shown with this command reflects the list of existing planes. CREATE PLANE My New Plane This command will create a new plane of existence, and allow you to edit its fields as per MODIFY PLANE below. Once chosen, the plane name can not be edited later, so choose carefully. If you made a mistake on the name of a new Plane, use DESTROY and then create it again. DESTROY PLANE My Old Plane This command will destroy an existing plane. MODIFY PLANE My Old Plane The modify command will take you into the editor for an existing plane. The Plane editor contains numerous other complex and interesting fields to change. All fields are optional, and any field left empty will not be applied to the area being transformed. For example, if no alignment is given, the existing alignments of the area mobs will be unchanged. Here are all the fields:
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:
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. Recommended, but optional. SET CATEGORY [CATEGORY WORD(S)] - a space-delimited list of arbitrary category words. Completely optional. SET INSTRUCTIONS [QUEST INSTRUCTIONS] - player instructions for this quest. Recommended, but 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! See also SET EXPIRATION. SET
EXPIRATION [#TICKS/TIME]-
Either a number of ticks (4 second periods) the quest will exist once
started, or a formula, or a number followed by the word minutes,
seconds, hours, days, mudhours, or muddays. Once the quest has been
running for the expiration time, it will be removed from the list of
available quests permanently. Use a simple
value of 0, which is default, will make your quest persistant. 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/ONCE/ALLONCE/ANY/ANYONCE]
- 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. The ONCE and ALLONCE arguments are the
same as TRUE and ALL except that only one spawned instance is allowed at
any given time. The ANY and ANYONCE arguments will spawn a random step.
Spawned steps should immediately change their names for the ONCE limits to be
properly applied.
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. QUIET [ON/OFF] - Turns on or off quiet mode, in which error messages are not logged. However, errors will still cancel the quest script running. OPTIONAL [ON/OFF] - Turns on or off optional mode, in which errors no longer cancel quest script running. 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.  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 PCMOBGROUP (RESELECT) ([MOB NAME]) - serves the same purpose as the above command of the similar name, but the argument is an object specifier which is allowed to be applied to players. 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. Players 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 (see the QuestBound property) 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. This can not be applied to players. SET PCMOB [OBJECT] - serves the same purpose as the above command of the similar name, but the argument is an object specifier which is allowed to be applied to players. 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.  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.  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.  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. STAT IDs can be seen in game by doing "LIST STAT [CLASSNAME]", for example "LIST STAT GenMob". Another way is HELP STATS. One special stat for areas is "SUPPRESSLAW", which can be set to the name of a crime, or the word "ALL", in case your quest is inhibited by law enforcement, until the Quest is no longer running. A more 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. GIVE SCRIPT (SAVABLE/GLOBAL/INDIVIDUAL/PLAYEROK) [SCRIPT] - This command will give the currently designated mob, item, room, area, or mobgroup (designated using the set or load commands), itemgroup, or roomgroup the mobprog script. The script can be a semi-colon delimited script or a LOAD= command, as per the Scriptable command. The arguments before the script can be used to set the variable scope (GLOBAL/INDIVIDUAL), or whether the script persists when the object is saved (SAVABLE), or whether players should be treated normally (PLAYEROK). Without PLAYEROK, this command will attempt to call CAN_ACCEPT and DO_ACCEPT mobprog functions on the script instead. 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", "LOADEDABILITIES", "AREA", "ROOM", "ABILITY", "MOBGROUP", "ITEMGROUP", "ROOMGROUP", "ABILITYGROUP", "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 MOTIVEGROUP [OBJECT] - Sets the MOTIVEGROUP variable to the [OBJECT]. Will also designate one random string from the group as the MOTIVE. See Object Specifiers above this command listing. SET MOTIVEGROUP [STRING] .. [STRING] - Sets the MOTIVEGROUP to the set of strings specified. Will also designate one random string from the group as the MOTIVE. The strings are space delimited, and words grouped with double-quotes. SET MOTIVEGROUP [#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 ACTIONGROUP [OBJECT] - Sets the ACTIONGROUP variable to the [OBJECT]. Will also designate one random string from the group as the ACTION. See Object Specifiers above this command listing. SET ACTIONGROUP [STRING] .. [STRING] - Sets the ACTIONGROUP to the set of strings specified. Will also designate one random string from the group as the ACTION. The strings are space delimited, and words grouped with double-quotes. SET ACTIONGROUP [#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. Quest scripts:The MOBPROG scripts GIVEn to mobs or whatever by the above quest script should handle things like allowing a player to accept a quest, providing a way to track the players progress in a quest, and providing a way to complete a quest. There are several commands and conventions in MOBPROG language to assist with this. The most common way to accept a quest is to have an NPC that acts as a quest giver. He can announce the quest to players entering his room, and allow the quest to be accepted using a SPEECH_PROG, or some other way. If you wish your quest to be compatible with StdQuestBoard or other quest items, however, you also need to include both the SET INSTRUCTIONS command in your quest script, as well as include two special FUNCTION_PROGs: FUNCTION_PROG
CAN_ACCEPT The above shows examples of the two special functions for item or board-based quest accepting. The first function CAN_ACCEPT should return nothing if the player $n is permitted to do your quest, and should return a non-empty string (in this case, "CANCEL") if the player is not permitted. The CAN_ACCEPT function also demonstrates a check to see if the player has previously completed the quest (QUESTWINNER) and whether the player is currently running a script assigned by this quest (QUESTSCRIPTED). The DO_ACCEPT function should perform any actions required to allow the player $n to proceed with your quest. In this case, the quest statistics are updated to denote that a player has accepted the quest using MPQSET, and then the player is given their own tracking script using MPSCRIPT. The example SPEECH_PROG is just a simple example of using the spoken phrase 'i accept' to accept a quest. Tracking quest progress can be done using a personal script on each player doing the quest, as mentioned above. For compatibility with the player QUESTS command in-game, you should set the MOBPROG script Vars <playername> PROGRESS and/or <playername> TIME_REMAINING to update the players progress in the game. Completing quests can be accomplished by the MOBPROG script on the announcer mob, the quest target mob(s), or even a script on the player themselves. Here is an example of a script snippet on the announcer mob: ALL_GREET_PROG
100 In the above example, an ALL_GREET_PROG checks to see if the greeted player ($n) was QUESTSCRIPTED previously, as a way of determining whether they are actually on this quest. It then checks their NUM_KILLED variable to see if it is high enough to complete the quest. If both conditions are true, some goodies are given out: 100 xp, a quest point, and 10 gold. Then the special command MPQUESTWIN is used to signal that the player has won the quest. MPENDQUEST $n is then used to clear off any residual quest scripts or data from the player. Lastly, as in the accept example above, the quest statistics are updated using MPQSET * STATISTICS SUCCESS. 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. AlthoughJavascript 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 loadedMobsand loadedItemsare available with any items or mobs gained from the IMPORT command, regardless of whether they were LOADed. There is also the mysteryDataobject 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, or use the Quest Maker to generate a quest to study. Lastly, check out the Random Areas Guide for information on Random Quest generation. And lastly, remember that quest script errors are always sent out to your mud.log, so check there often when starting up a new quest! 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:
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: CREATING THE TWIGGLE SOCIAL From the command line, enter the command: 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, TWIGGLE with a custom target, TWIGGLE (to a target), and TWIGGLE to a target with an argument. We'll start with the first type:. After changing the You-see string, enter option 2 to define the action type: 2. Your action type: MOVEMENT 3. Others-see string: '<S-NAME>
twiggles.'. Option 3 from the menu above is what the people
in the
room see when you perform a social. And that concludes the
creation of our type 1 TWIGGLE social. Change 1 to change what you see when you
perform the
social TWIGGLE SELF. Now select option 2: 2. Your action type=MAKING NOISE And that concludes the creation of our type 2 TWIGGLE social.  Now select option 2: 2. Your action type=MAKING NOISE 5. You-see when no target: 'Twiggle who?'. And that concludes the creation of our type 3 TWIGGLE social. CREATING TWIGGLE
ELABORATELY SOCIAL Yay! Type 4! We are going to invent our very own custom
target
for this one, called ELABORATELY. Others Effect type=HANDS And that's all for a targeted twiggle. One more type. CREATING TWIGGLE
<T-NAME>
ELABORATELY SOCIAL 1. You-see string: 'You twiggle
<T-NAME> in the
elaborately.'. 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, etc), When you get tired of a social variant, you can use the MODIFY SOCIAL command to delete targets. To eliminate a social entirely, use DESTROY SOCIAL [NAME]. =======
AND NOW
FOR
THE LIST OF TAGS ======= 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:
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 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:
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:
Positions constitute the ranks, roles, or positions within this clan. These also have their own fields, enumerated below:
An Auto-Award skill is a behavior or property or spell effect
that is automatically assigned based on player characteristics as
filtered by a ZapperMask, AND can differ efficiencly based on the
aspects of the date. From the command line, auto-award entries can be created using the CREATE command: CREATE AWARD -RACE +ELF :: -MONTH +5 :: Prop_Adjuster(str+2) The bit before the first ::
is the normal player zapper mask describing which players are elligible
for the award. This section may include race, class, or even
birthday checks, but should never include current mud date checks. The
bit between the two :: markers
is the date-based zapper mask. This mask will be compared against
the current date in the starting room area of the player in
question. This second mask should only contain date/time based
checks. The bit after the last ::
marker are the awards for players matching the mask: a list of behavior
or ability ids, with parameters/arguments in parenthesis.
Multiple behaviors/abilties are separated by spaces. When editing from the MUDGrinder, the arguments are a bit easier :
If you no longer want an award to exist, you can always list the existing awards with LIST AWARD, and then obliterate it with the DESTROY command: DESTROY AWARD 4 Of course, all this can also be done from the MUDGrinder Achievements/Awards editor. An Auto-Title is the awarding of a new character Title option (see
TITLE command) due to matching a particular zappermask during one of
the periodic system checks. From the command line, auto-award entries can be created using the CREATE command: CREATE TITLE *, the Elf=-RACE +ELF When creating titles, the * character is a substitute for the
ordinary character name. The bit after the equal sign is the
zapper mask to select which players can have this title.
Optionally, a maximum number of players who can get this title can be
specified before the mask, with a colon separating them. When editing from the MUDGrinder, the arguments are a bit easier :
If you no longer want an award to exist, you can always list the existing awards with LIST TITLES, and then obliterate it with the DESTROY command: DESTROY TITLE *, the Elf Of course, all this can also be done from the MUDGrinder Achievements/Awards editor. 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:
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:
|