Scripting in CoffeeMud 5.10 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Introduction to ScriptingScripting is the ability to makes something behave proactively, or respond to game stimuli, in a way specified by the game builders. A Script is the set of commands written by the builders to perform this function. In CoffeeMud, any object may be scripted. This means that rooms, areas, items, and especially MOBs can be scripted. Scripting is accomplished through the Scriptable Behavior. Giving an object this behavior makes it capable of running scripts on its behalf. The parameters of the Scriptable behavior define the source of the script itself. The most common parameter for the Scriptable behavior is the LOAD command, which specifies a text file containing the script. The syntax for this is as follows: load=path/file name The starting path for the Scriptable behavior is the /resources/ directory in your CoffeeMud package. Any further paths will branch from that directory. The file specified is a text file containing the script. You can also specify more than one script in the Scriptable parameters by separating LOAD= commands with the ~ character like so: load=progs/mrinfo.script~load=progs/strangetrader.script~ A less common way to specify a script for the Scriptable behavior is to enter the script itself into the parameter. Scripts entered in this way differ from scripts entered into text files for the LOAD parameter in one significant sense: Every line of a script entered in this way must be terminated by a semicolon. Here is an example. RAND_PROG 50;bounce;say "hi!";~; Scripts which are entered into text files for the LOAD parameter have their lines terminated by carriage returns (ENTER) instead of semicolons. The script syntax is, in all other ways, identical. If you need to put special characters (like ; ~ or LOAD=) into particular commands, you may need to escape those characters by putting a \ character before them, to tell the Scriptable behavior not to consider them line or script delimiters. When the Scriptable behavior loads a file using the LOAD= syntax, it automatically keeps a copy of it in memory for future use. This memory cache is called the CoffeeMud Resources. If you have a Scriptable prog you have entered using the LOAD= syntax, you can see its entry in the cache by using your Archon character to enter LIST RESOURCES from the CoffeeMud command line. Because the script files from disk are kept in memory for quick access, any changes or additions to your script on disk will not be immediately noticed by the CoffeeMud engine. To force the engine to notice your changes, you must first UNLOAD your script file from the Resources cache. This is done by using the Archon command UNLOAD. Check the ahelp entry for that command for more information on how to use it when developing Scriptable behavior files on disk. Those who are familiar with the mobprog scripting language in other mud codebases will have no trouble picking up on the CoffeeMud scripting language. In fact, most of your existing scripts will probably work without changes. Script StructureThe CoffeeMud scripting language is an "event-based" language. Each script may contain one or more event "triggers". Each trigger defines the conditions of its occurrence on a single line. This line is followed by commands underneath it which are executed only when the trigger event occurs. Each event trigger/command grouping is terminated by a ~ character, which should appear on a line by itself. Putting this together, we have a high level syntax that looks like this: EVENT_TRIGGER parameter1 parameter2 ... Scripting EventsBelow are a list of the valid event triggers, along with their parameters, and a description of the events or circumstances under which the events occur. * Note: Most triggers fire after a short delay, and only when the scripted mob is healthy and non-follower. See the MPSETINTERNAL command to change default global triggering behavior. These docs borrow heavily from the nicely written MOBPROG Tutorial at: http://www.pandapub.com/tutorial/MobprogTutorial.htm. all_greet_progUsage: all_greet_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every time someone enters the room that the script mob, item, exit, or room is currently in. If the random number generated between 1 and 100 is equal to or below the percentage of the all_greet_prog, or the zapper masks matches the creature being greeted, the prog is triggered. Note that all_greet_progs are triggered by both players and mobs, even sneaking ones, and a mob in a maze can actually sometimes end up triggering itself! This type of mobprog has all sorts of uses, ranging from giving in-zone quest information to people entering the room, creating aggressive progs, etc. EXAMPLES: all_greet_prog 25 This prog will be triggered 25% of the time when someone enters the room where the mob currently is. all_greet_prog 100 This prog will be triggered 100% of the time when someone enters the room where the mob currently is. This means every time. all_greet_prog -RACE +ElfThis prog will be triggered 100% of the time whenever an elf enters the room where the mob currently is. SPECIAL NOTES: You'll probably want to do a large number of if checks in all_greet_progs, specifically in the difference between mobs and player characters. Note that all_greet_progs will trigger even if a person is sneaking, though the mob must have detect invisibility to see invisible people, infravision to see people in the dark, sense sneaking to see sneakers, and will not see people if blinded. Also, be sure to check out arrive_prog, which is a nice counterpart to greet_prog. act_progmask_progUsage: act_prog [trigger message] This type of mobprog will trigger when the mob sees a certain string of text. When the 'p' is inserted into the trigger line, the string of text must be precise, while if it is not, any of the words in the list can trigger the mobprog. This type of mobprog has many uses, one of which is communication between mobs. There are a few socials which create a message only to the person performing them and to the one receiving them. You can use these and act_progs to safely have mobs trigger each other, without people seeing what is going on. Other uses include triggering off of people fleeing, moving out of the room, etc. The possibilities are endless. The act_prog will attempt to trigger off of the string exactly as third-partys see things, if possible. If third partys see nothing, the target view will be chosen. If only the source sees the event message, that will be chosen. Variables may not be used in trigger messages, so you will need to be ambiguous to get matches. For instance, if Bob hits Larry, the message that act_prog will see would be something like "Bob hits Larry hard!". To capture this for all possible sources and targets, your best hit then is to match on the word "hits" and then check $n and $t for the appropriate values. EXAMPLES: act_prog wolf dog coyote This will trigger whenever the mob sees a segment of text containing any of the words wolf, dog, or coyote. If the string contains more than one of these, the prog will be triggered multiple times. act_prog p A wolf howls at the moon. This will trigger the prog when it sees this precise message. Note that punctuation is stripped from both your message and the message matched against. MULTIPLE PROGS: You can have more than one act_prog on a mob, but you shouldn't have multiple act_progs that trigger off of the same message. SPECIAL NOTES: ANSI colors on objects don't seem to work well with act_progs, so avoid using ANSI colors in anything that may be part of your act_prog trigger. Variables and Codes are not used in act_progs, so do not try to use them; it won't work. arrive_progUsage: arrive_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every time the scripted mob or item owner enters a new room, or when they enter the game. If the random number generated between 1 and 100 is equal to or below the percentage of the arrive_prog, or the mask matches the scripted mob, the prog is triggered. This type of mobprog has all sorts of uses, ranging from giving in-zone quest information to people the mob stumbles upon, creating aggressive progs, etc. EXAMPLES: arrive_prog 25 This prog will be triggered 25% of the time when the mob enters a room. arrive_prog 100 This prog will be triggered 100% of the time when the mob enters a room. This means every time. SPECIAL NOTES: You'll probably want to make sure you understand the difference between the arrive_prog and greet_prog/all_greet_prog. Scripted Exits and Rooms will never trigger this event. bribe_progUsage: bribe_prog [money value] This type of mobprog is triggered when a value of money is given to the mob. If the amount of money is equal to or more than the money value of the bribe_prog, the prog will go off. If it is less than the value of the bribe_prog, or the money is not in the local currency, it will not go off. This type of prog is normally used for in-zone quests, perhaps bribing guards to let a prisoner free or bribing a bartender to give you some information. It can also be used for larger, special mob behavior, such as a ferryman who will move a player to another spot in the world for a fee. The money value is always expressed in absolute gold value of the default currency. See the Archon's Guide under currency if you don't know what that means. EXAMPLES: bribe_prog 1 This bribe_prog will trigger whenever the mob is given an amount of gold equal to or greater than 1 coin. Of course, this means that the prog will be triggered if any amount of money is given to the mob at all. bribe_prog 500 This bribe_prog will trigger if someone gives the mob an amount of money equal to or greater than 500 coins.) MULTIPLE PROGS: You can have multiple bribe_progs on the same mob. However, these must be listed in order from largest gold amount to smallest gold amount. So if you have a bribe_prog 250 and a bribe_prog 100, the 250 must be listed first, and then the 100. If you don't do this your larger sum bribe_progs will never be triggered. buy_progUsage: buy_prog [keyword list] This type of mobprog is triggered by buying an item from a shopkeeper. If the item being bought has any of the keywords of the buy_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the item must exactly match that of the buy_prog. If there is not, then any item with any of the keywords in the list in it will trigger it. If a buy_prog all is used, then the buy_prog will trigger for any item at all being bought. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: buy_prog orange apple banana This will trigger if the item being bought has any of the keywords orange, apple, or banana. This means that it would be triggered by buying a banana, an apple pie, or even an orange shield. buy_prog p apple pie delicious This will trigger if the item being bought has the exact keywords apple pie delicious. The prog would not be triggered by buying anything with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. buy_prog all This will trigger if any sort of item is bought. MULTIPLE PROGS: You can have more than one buy_prog on a mob. Generally it is best not to have buy_progs with the same keywords in them, unless they are a buy_prog p with different keyword lists but some of the same keywords – for example a buy_prog p apple red juicy and a buy_prog p apple red poisoned. cast_progUsage: cast_prog [ability id list] This type of mobprog is triggered by the mob having a spell or skill used on them by someone else. If the spell or skill name or id matches the keywords of the cast_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the name or id of the spell must exactly match that of the cast_prog. If a cast_prog all is used, then the cast_prog will trigger from any spell/skill at all being used on the mob. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: cast_prog fire ice This will trigger if the fireball spell or any spell with fire or ice in its name is cast at the mob. cast_prog p Spell_Fireball This will trigger only if the Fireball spell is cast at the mob. cast_prog all This will trigger if any spell or skill is used on the mob. MULTIPLE PROGS: You can have more than one cast_prog on a mob. Generally it is best not to have cast_progs with the same keywords in them, unless they are a cast_prog p with different keyword lists but some of the same keywords – for example a cast_prog p Spell_Fireball and a cast_prog p Spell_FlamingHands casting_progUsage: cast_prog [keyword list] This type of mobprog is triggered by the mob casting a spell or skill on someone. If the spell cast on the mob matches the keywords of the cast_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the name or id of the spell must exactly match that of the cast_prog. If there is not, then any spell with any of the keywords in the list in it will trigger it. If a casting_prog all is used, then the casting_prog will trigger from any spell at all being cast on anyone by the mob. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: casting_prog fire ice This will trigger if the mob casts an spell that has any of the keywords fire or ice. This means that it would be triggered by casting a Fireball spell or Ice Lance spell. casting_prog p Spell_Fireball This will trigger if the mob casts the spell that has the exact ID of Spell_Fireball. cast_prog all This will trigger if any spell or skill is cast by the mob MULTIPLE PROGS: You can have more than one casting_prog on a mob. Generally it is best not to have casting_progs with the same keywords in them, unless they are a casting_prog p with different keyword lists but some of the same keywords – for example a casting_prog p Spell_Fireball and a cast_prog p Spell_IceLance channel_progUsage: channel_prog [channel name] [trigger words] This type of mobprog will trigger when the mob sees a certain string of text over the specified channel. When the 'p' is inserted into the trigger line, the string of text must be precise, while if it is not, any of the words in the list can trigger the mobprog. This type of mobprog has many uses, one of which is communication between mobs. The possibilities are endlessly finite. EXAMPLES: channel_prog help me This will trigger whenever the mob sees a segment of text containing any of the words help or me. If the string contains more than one of these, the prog will be triggered multiple times. channel_prog p GOSSIP hello. This will trigger the prog when it sees this message channeled. Note that punctuation is important here as well. MULTIPLE PROGS: You can have more than one channel_prog on a mob, but you shouldn't have multiple channel_progs that trigger off of the same message. SPECIAL NOTES: ANSI colors on objects don't seem to work well with channel_progs, so avoid using ANSI colors in anything that may be part of your channel_prog trigger. Variables and Codes are not used in channel_progs, so do not try to use them; it won't work. close_progUsage: close_prog [keyword list] This type of mobprog is triggered by closing a container or door. If the script is on a container-type object, such as a door or container item, it will trigger only if the object being closed is the scripted one. Otherwise, if the target matches the keywords of the close_prog, the prog is triggered. If there is a 'p' placed before the keyword list, the keywords of the object must exactly match that of the close_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If the scripted item is not a container or door, and a "close_prog all" is used, then the close_prog will trigger from any object at all being opened. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. As is normal, if the scripted object is a mob, this event will not trigger if the scripted mob is the originator of the activity. EXAMPLES: close_prog door gate This will trigger if the object closed has any of the keywords door gate. This means that it would be triggered by closing a door or gate. close_prog p a large chest This will trigger if the object closed has the exact keywords a large chest.. The prog would not be triggered by closing an object with keywords large or chest or anything except the exact order and wording of the keyword list. close_prog all This will trigger if any object is closed. MULTIPLE PROGS: You can have more than one close_prog on an item, mob, or room. Generally it is best not to have close_progs with the same keywords in them, unless they are a close_progs p with different keyword lists but some of the same keywords - for example a close_progs p door gate and a close_prog p door to the gate. cnclmsg_progUsage: cnclmsg_prog [message code] [commands/keyword list] This type of mobprog is definitely for those very familiar with CoffeeMud. In fact, I'd recommend at least a cursory knowledge of the Programmer's Guide to consider using it. The purpose of this trigger is that it executes before a particular event or "message" occurs in the mud. The kind of event is called the "message code". The trigger also requires either the word "all" to always execute before the desired message does, or a list of player command line words matches those typed by the player most recently to the arrival of this message. Since mobs, unlike players, do not enter commands on a command line, you should use the ALL form liberally. The body of the trigger executes before the given message occurs, and the fact that the trigger executes is no guarantee that the event will end up occuring at all. For instance, this trigger may execute when a player tries to leave the room while under the effects of the "Hold" spell, meaning the player will not actually be allowed to leave regardless of what is done in your trigger. However, this type of trigger is most useful as a means of testing and cancelling certain types of event messages; thus the name. To cause the triggered event to be cancelled, you need only add a RETURN CANCEL command to the body of this script. See also execmsg_prog. Valid message codes include the following: AREAAFFECT, PUSH, PULL, RECALL, OPEN, CLOSE, PUT, GET, UNLOCK, LOCK, WIELD, GIVE, BUY, SELL, DROP, WEAR, FILL, DELICATE_HANDS_ACT, VALUE, HOLD, NOISYMOVEMENT, QUIETMOVEMENT, WEAPONATTACK, LOOK, READ, NOISE, SPEAK, CAST_SPELL, LIST, EAT, ENTER, FOLLOW, LEAVE, SLEEP, SIT, STAND, FLEE, NOFOLLOW, WRITE, FIRE, COLD, WATER, GAS, MIND, GENERAL, JUSTICE, ACID, ELECTRIC, POISON, UNDEAD, MOUNT, DISMOUNT, OK_ACTION, OK_VISUAL, DRINK, HANDS, PARALYZE, WAND_USE, SERVE, REBUKE, ADVANCE, DISEASE, DEATH, DEPOSIT, WITHDRAW, EMOTE, QUIT, SHUTDOWN, VIEW, RETIRE, RETREAT,PANIC, THROW, EXTINGUISH, TELL, SITMOVE, KNOCK, PRACTICE, TEACH, REMOVE, EXPCHANGE, DAMAGE, HEALING, ROOMRESET, RELOAD, SNIFF, ACTIVATE, DEACTIVATE, FACTIONCHANGE, LOGIN, LEVEL, EXAMINE, ORDER, EXPIRE, BORROW, HUH, LIFE, BID, CLANEVENT, UNLOAD, DUELCHALLENGE, LEGALWARRANT, DIG, PREINVOKE, POSSESS, DISPOSSESS, POWERCURRENT, CONTEMPLATE, POUR, LOOKEXITS, LASER, SONIC, REPAIR, ENHANCE, INSTALL, COLLISION, AROMA, DUELLOSS, COMMANDFAIL, METACOMMAND, ITEMGENERATED, ATTACKMISS, WEATHER,ITEMSGENERATED, WROTE, REWRITE, WASREAD, PREMOVE, THINK, STARTUP, RPXPCHANGE, COMMANDREJECT,RECIPELEARNED, GRAVITY, LEGALSTATE, NEWROOM,CAUSESINK, ENDQUEST,WINQUEST,HOLYEVENTAnd here are some general message code types that may also be used: TOUCH, MOVE, EYES, MOUTH, SOUND, GENERAL, MAGIC, DELICATE, MALICIOUS, CHANNEL, OPTIMIZE, CNTRLMSG, INTERMSG, UNINTENTIONALFor truly advanced users, you can also prefix a message code with some combination of the letters S, O, and T followed by an equal (=) sign to narrow matches to only those messages where your given code appears as the Source, Others, and Target codes respectively. For example, use a message code of ST=DEATH to match cases where the Source and Target message codes are DEATH and the Others code is ignored. You can also put the character < or > before the S, O, or Ts in order to narrowly check against the Major masks or the Minor type codes respectively. See the Programmer's Guide if you don't know what that stuff means. EXAMPLES: cnclmsg_prog hands p smile This will trigger if a player (not a mob) around the scripted object attempts to smile. cnclmsg_prog GET p get rock This will trigger if a player (not a mob) enters the command "get rock" at the command line, this will trigger and cancel he attempt.. cnclmsg_prog >S=MAGIC ALLThis will trigger if a player (not a mob) tries to use any spell. The CNCLMSG_PROG is especially useful for creating new command that only apply in particular rooms or with respect to particular mobs. This is because entering an incorrect command, which normally generates a "Huh?" message, can also be canceled and re-applied. For instance, suppose you wanted users to be able to enter "plastify sword" at some part in your quest and have it do something. In this case, you'd need to capture the HUH message as so: cnclmsg_prog HUH p plastify sword MULTIPLE PROGS: You can have more than one cnclmsg_prog, not only in the same script, but regarding the very same message codes if you like. NOTE: When enclosing JavaScript inside a CNCLMSG_PROG, the actual message object can be found at index 0 of the context objects array. consume_progUsage: consume_prog [keyword list] This type of mobprog is triggered eating or drinking from an object. If the object used matches the keywords of the consume_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the consume_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a consume_prog all is used, then the consume_prog will trigger from any object at all. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: consume_prog orange apple banana This will trigger if the object eaten has any of the keywords orange, apple, or banana. This means that it would be triggered by eating a banana, an apple pie, or even an orange shield. consume_prog p apple pie delicious This will trigger if the object eaten has the exact keywords apple pie delicious. The prog would not be triggered by eating an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. consume_prog all This will trigger if any object is ate or drank. MULTIPLE PROGS: You can have more than one consume_prog on a mob. Generally it is best not to have consume_progs with the same keywords in them, unless they are a consume_prog p with different keyword lists but some of the same keywords – for example a consume_prog p apple red juicy and a consume_prog p apple red poisoned. damage_progUsage: damage_prog This type of mobprog is triggered whenever the scripted mob is damaged, or the scripted item is used to deliver damage. The source and target mobs will be as you expect. The secondary item will be the weapon used to deliver the damage, if it was a physical item (spells are not items). The string returned in $g will be the amount of damage taken. EXAMPLES: damage_prog This program will trigger when damage is taken by a mob, or given by the scripted item. day_progUsage: day_prog [list of integer day of the month] This type of mobprog triggers once per mud day, on the days of the month listed. This allows you to have a script which triggers very infrequently indeed. There are 30 days per month in CoffeeMud. EXAMPLES: day_prog 20 21 22 This will trigger if day of the month is 20, 21, or 22. day_prog 10 This will trigger on the 10th day of every month. death_progUsage: death_prog This mobprog type triggers on the mob's death. The death_prog has a wide range of uses. The death_prog is queued just before the mob dies, so it is considered to be the mob's last gasp. At the end of the death-prog, however, the mob dies. Even if the mob sets its hit points to full, it will die. Other than that, the mob can mpjunk equipment it has, mpgoto a new room to die, unlock a door, load an object of some kind, etc. MULTIPLE PROGS: You can have multiple death_progs on the same mob. delay_progUsage: delay_prog [integer, minimum number of ticks] [integer, maximum number of ticks] This kind of mobprog triggers after a random number of ticks have elapsed. The number of random ticks is between the two integers provided. This trigger is used to take some of the load off of rand_prog type programs. EXAMPLES: delay_prog 10 20 This delay_prog will be triggered after 10-20 ticks have elapsed. delay_prog 1 11 This delay_prog will be triggered after 1-11 ticks have elapsed. drop_progUsage: drop_prog [keyword list] This type of mobprog is triggered by dropping an object. If the object dropped matches the keywords of the drop_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the drop_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a drop_prog all is used, then the drop_prog will trigger from any object at all being dropped. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. Unlike droppng_prog, when running on an npc or player, this triggers only when the npc or player witnesses the drop action. EXAMPLES: drop_prog orange apple banana This will trigger if the object dropped has any of the keywords orange, apple, or banana. This means that it would be triggered by dropping a banana, an apple pie, or even an orange shield. drop_prog p apple pie delicious This will trigger if the object dropped has the exact keywords apple pie delicious. The prog would not be triggered by dropping an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. drop_prog all This will trigger if any object is dropped. MULTIPLE PROGS: You can have more than one drop_prog on a mob. Generally it is best not to have drop_progs with the same keywords in them, unless they are a drop_prog p with different keyword lists but some of the same keywords – for example a drop_prog p apple red juicy and a drop_prog p apple red poisoned.. dropping_progUsage: dropping_prog [keyword list]This is the same as drop_prog except it triggers only when the scripted npc or player does the dropping. entry_progUsage: entry_prog [integer percentage or zapper mask] This type of prog checks a percentage chance, or a zapper mask, every time the scripted mob moves into a new room, or if a scripted item owner mob enters a new room, or a scripted room or exit is entered . If the random number generated is equal to or below the percentage of the entry_prog when a mob steps into a new room, or the mask matches the scripted mob, then the prog is triggered. This prog has a variety of uses, for instance, you can use it in conjunction with the inroom function to make sure a mob stays in the same room or never oversteps a boundary, or to have the mob attack players as it enters the room. There are many possibilities. EXAMPLES: entry_prog 25 This will trigger 25% of the time when the mob enters a room. entry_prog 100 This will trigger 100%, or every time, the mob enters a room. SPECIAL NOTES: This program is triggered on a normal delay unless it is multiply triggered, in which case it will occur once, but immediately. execmsg_progUsage: execmsg_prog [message code] [commands/keyword list] This type of mobprog is definitely for those very familiar with CoffeeMud. In fact, I'd recommend at least a cursory knowledge of the Programmer's Guide to consider using it. The purpose of this trigger is that it executes while a particular and valid event or "message" occurs in the mud. The kind of event is called the "message code". The trigger also requires either the word "all" to always execute whenever the desired message does, or a list of player command line words matching those typed by the player most recently to the arrival of this message. Since mobs, unlike players, do not enter commands on a command line, you should use the ALL form liberally. See also cnclmsg_prog. Valid message codes include the following: AREAAFFECT, PUSH, PULL, RECALL, OPEN, CLOSE, PUT, GET, UNLOCK, LOCK, WIELD, GIVE, BUY, SELL, DROP, WEAR, FILL, DELICATE_HANDS_ACT, VALUE, HOLD, NOISYMOVEMENT, QUIETMOVEMENT, WEAPONATTACK, LOOK, READ, NOISE, SPEAK, CAST_SPELL, LIST, EAT, ENTER, FOLLOW, LEAVE, SLEEP, SIT, STAND, FLEE, NOFOLLOW, WRITE, FIRE, COLD, WATER, GAS, MIND, GENERAL, JUSTICE, ACID, ELECTRIC, POISON, UNDEAD, MOUNT, DISMOUNT, OK_ACTION, OK_VISUAL, DRINK, HANDS, PARALYZE, WAND_USE, SERVE, REBUKE, ADVANCE, DISEASE, DEATH, DEPOSIT, WITHDRAW, EMOTE, QUIT, SHUTDOWN, VIEW, RETIRE, RETREAT,PANIC, THROW, EXTINGUISH, TELL, SITMOVE, KNOCK, PRACTICE, TEACH, REMOVE, EXPCHANGE, DAMAGE, HEALING, ROOMRESET, RELOAD, SNIFF, ACTIVATE, DEACTIVATE, FACTIONCHANGE, LOGIN, LEVEL, EXAMINE, BORROW, HUH, LIFE, BID, CLANEVENT, UNLOAD, DUELCHALLENGE, LEGALWARRANT, DIG, PREINVOKE, POSSESS, DISPOSSESS, POWERCURRENT, CONTEMPLATE, POUR, LOOKEXITS, LASER, SONIC, REPAIR, ENHANCE, INSTALL, COLLISION, AROMA, DUELLOSS, COMMANDFAIL, METACOMMANDAnd here are some general message code types that may also be used: TOUCH, MOVE, EYES, MOUTH, SOUND, GENERAL, MAGIC, DELICATE, MALICIOUS, CHANNEL, OPTIMIZE, CNTRLMSG, INTERMSG, UNINTENTIONALFor truly advanced users, you can also prefix a message code with some combination of the letters S, O, and T followed by an equal (=) sign to narrow matches to only those messages where your given code appears as the Source, Others, and Target codes respectively. For example, use a message code of ST=DEATH to match cases where the Source and Target message codes are DEATH and the Others code is ignored. You can also put the character < or > before the S, O, or Ts in order to narrowly check against the Major masks or the Minor type codes respectively. See the Programmer's Guide if you don't know what that stuff means. EXAMPLES: execmsg_prog get all This will trigger if a player or a mob attempts to get something. execmsg_prog GET p get rock This will trigger if a player (not a mob) enters the command "get rock" at the command line, this will trigger. execmsg_prog >S=MAGIC ALLThis will trigger if a player (not a mob) tries to use any spell. MULTIPLE PROGS: You can have more than one execmsg_prog, not only in the same script, but regarding the very same message codes if you like. However, only the first one that triggers will count. exit_progUsage: exit_prog [integer percentage or zapper mask] This type of prog checks a percentage chance, or a zapper mask, every time a mob moves out of a the room the scripted mob is in. If the random number generated is equal to or below the percentage of the exit_prog when the mob steps out of the room, or the zapper masks matches the creature exiting, then the prog is triggered. This prog has a variety of uses, for instance, you can use it in conjunction with the inroom function to make sure other mobs stay in the same room or never oversteps a boundary, or to have the mob attack remaining players when one leaves. There are many possibilities. EXAMPLES: exit_prog 25 This will trigger 25% of the time when a mob leaves the room. exit_prog 100 This will trigger 100%, or every time, a mob leaves the room. exit_prog -RACE +ElfThis will trigger whenever an elf leave the room. fight_progUsage: fight_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every round of combat that the mob is in. If the random number generated between 1 and 100 is equal to or less than the percentage of the fight_prog, or the zapper mask matches the mob, then it will be triggered. This type of mobprog is generally used to have the mob do certain things in combat, for instance, cast spells or use skills. Sometimes it is used to ensure a mob doesn't fight at all, or to perform special, more complicated actions in combat. EXAMPLES: fight_prog 10 This will trigger 10% of the time each round of combat the mob is in. That means that it is probable that this mobprog will go off every 10 rounds or so, although it is not guaranteed to do so. fight_prog 75 This will trigger 75% of the time each combat round. That means it's a safe bet that the trigger will go off 3 out of every 4 rounds. function_progUsage: function_prog [string name of the function] This type of prog provides a named placeholder for the series of commands that follows. This type of mobprog is never independently triggered, but instead relys on one of the commands, MPCALLFUNC, to trigger it manually. The usefulness of doing this will become apparent in the discussion of MPCALLFUNC. EXAMPLES: function_prog Destroy Everyone This will trigger only when called by MPCALLFUNC. get_progUsage: get_prog [keyword list] This type of mobprog is triggered by someone getting an object. If the object picked up matches the keywords of the get_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the get_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a get_prog all is used, then the get_prog will trigger from any object at all being picked up. When running on a container item, the get_prog matches the item being retrieved from the container, not the container itself. Unlike getting_prog, when running on an npc or player, this triggers only when the npc or player witnesses the get action. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: get_prog orange apple banana This will trigger if the object picked up has any of the keywords orange, apple, or banana. This means that it would be triggered by getting a banana, an apple pie, or even an orange shield. get_prog p apple pie delicious This will trigger if the object picked up has the exact keywords apple pie delicious. The prog would not be triggered by getting an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. get_prog all This will trigger if any object is picked up. MULTIPLE PROGS: You can have more than one get_prog on a mob. Generally it is best not to have get_progs with the same keywords in them, unless they are a get_prog p with different keyword lists but some of the same keywords – for example a get_prog p apple red juicy and a get_prog p apple red poisoned. getting_progUsage: getting_prog [keyword list]As get_prog, but only triggers when the scripted mob or player does the getting. give_progUsage: give_prog [keyword list] This type of mobprog is triggered by the mob being given an object. If the object given to the mob matches the keywords of the give_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the give_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a give_prog all is used, then the give_prog will trigger from any object at all being given to the mob. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: give_prog orange apple banana This will trigger if the object given to the mob has any of the keywords orange, apple, or banana. This means that it would be triggered by being given a banana, an apple pie, or even an orange shield.) give_prog p apple pie delicious This will trigger if the object given to the mob has the exact keywords apple pie delicious. The prog would not be triggered by being given an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. give_prog all This will trigger if any object is given to the mob. MULTIPLE PROGS: You can have more than one give_prog on a mob. Generally it is best not to have give_progs with the same keywords in them, unless they are a give_prog p with different keyword lists but some of the same keywords – for example a give_prog p apple red juicy and a give_prog p apple red poisoned. SPECIAL NOTES: More often than not, you'll want to remember to have the mob use the mpjunk command to get rid of the object given so people cannot steal the item back and use it again. It does depend on what you are doing of course, but it is something to keep in mind. It is also not a bad idea to have a give_prog all to have the mob drop items other than the ones it will accept in other give_progs. giving_progUsage: giving_prog [keyword list] This type of mobprog is triggered by the mob giving someone an object. If the object given to the mob matches the keywords of the giving_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the giving_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a giving_prog all is used, then the giving_prog will trigger from any object at all being given to anyone by the mob. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: giving_prog orange apple banana This will trigger if the mob gives an object that has any of the keywords orange, apple, or banana. This means that it would be triggered by giving a banana, an apple pie, or even an orange shield.) giving_prog p apple pie delicious This will trigger if the mob gives an object that has the exact keywords apple pie delicious. The prog would not be triggered by giving an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. giving_prog all This will trigger if any object is being given by the mob MULTIPLE PROGS: You can have more than one giving_prog on a mob. Generally it is best not to have giving_progs with the same keywords in them, unless they are a giving_prog p with different keyword lists but some of the same keywords – for example a giving_prog p apple red juicy and a giving_prog p apple red poisoned. SPECIAL NOTES: More often than not, you'll want to remember to have the mob use the mpjunk command to get rid of the object given so people cannot steal the item back and use it again. It does depend on what you are doing of course, but it is something to keep in mind. It is also not a bad idea to have a giving_prog all to have the mob drop items other than the ones it will accept in other giving_progs. greet_progUsage: greet_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every time someone enters the room that the scripted mob, item, room, or exit is currently in. If the random number generated between 1 and 100 is equal to or below the percentage of the greet_prog or the zapper masks matches the creature being greeted, the prog is triggered. Note that greet_progs are triggered by both non-sneaking players and mobs, and a mob in a maze can actually sometimes end up triggering itself! This type of mobprog has all sorts of uses, ranging from giving in-zone quest information to people entering the room, creating aggressive progs, etc. EXAMPLES: greet_prog 25 This prog will be triggered 25% of the time when someone enters the room where the mob currently is. greet_prog 100 This prog will be triggered 100% of the time when someone enters the room where the mob currently is. This means every time. greet_prog -race +elfThis prog will be triggered whenever an elf enters the room. SPECIAL NOTES: You'll probably want to do a large number of if checks in greet_progs, specifically in the difference between mobs and player characters. Note that greet_progs will trigger except if a person is sneaking. Also, the mob must have detect invisibility to see invisible people, infravision to see people in the dark, and will not see people if blinded. Lastly, make sure you check out arrive_prog, which is a useful counterpart to greet_prog group_greet_progUsage: group_greet_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, when someone enters the room that the scripted mob, item, room, or exit is currently in. If the random number generated between 1 and 100 is equal to or below the percentage of the greet_prog or the zapper masks matches the creature being greeted, the prog is triggered. However, this trigger is unique amongst the greets that its guarenteed to never trigger more than once per tick. Note that group_greet_progs are triggered by both non-sneaking players and mobs, and a mob in a maze can actually sometimes end up triggering itself! This type of mobprog has all sorts of uses, ranging from giving in-zone quest information to people entering the room, creating aggressive progs, etc. EXAMPLES: group_greet_prog 25 This prog will be triggered 25% of the time when someone enters the room where the mob currently is. group_greet_prog 100 This prog will be triggered 100% of the time when someone enters the room where the mob currently is. This means every time. group_greet_prog -race +elfThis prog will be triggered whenever an elf enters the room. SPECIAL NOTES: Group_greet_progs will trigger except if a person is sneaking. Also, the mob must have detect invisibility to see invisible people, infravision to see people in the dark, and will not see people if blinded. Lastly, make sure you check out arrive_prog, which is a useful counterpart to greet_prog hitprcnt_progUsage: hitprcnt_prog [integer percentage] This type of mobprog checks every round of combat to see if the mob's hit points are equal to or under the percentage given to the hitprcnt_prog. This type of prog is used mainly to have the mob do something at a certain percentage of hit points. Keep in mind, however, that this prog will trigger EVERY round of combat in which the mob's hit points are under the percentage. So if you want the mob to do only one thing, you will have to set up the mobprog that way with if checks. EXAMPLES: hitprcnt_prog 50 This will trigger if the mob's hit points are 50% or under every round of combat. hitprcnt_prog 100 This will trigger if the mob's hit points are 100% or under every round of combat. This means, more or less, every round of combat the mob will ever be in. imask_progUsage: imask_prog [trigger message] This type of mobprog will trigger when the mob does a thing that generates a certain string of text. When the 'p' is inserted into the trigger line, the string of text must be precise, while if it is not, any of the words in the list can trigger the mobprog. This type of mobprog has many uses, one of which is to have one action trigger another. The possibilities are almost endless, except that this trigger is meaningless unless the scripted object is a mob, since only mobs can generate events. EXAMPLES: imask_prog wolf dog coyote This will trigger whenever the mob does something that generates a segment of text containing any of the words wolf, dog, or coyote. If the string contains more than one of these, the prog will be triggered multiple times. imask_prog p A wolf howls at the moon. This will trigger the prog when mob does something that generates this precise message. Note that punctuation is important here as well. MULTIPLE PROGS: You can have more than one imask_prog on a mob, but you shouldn't have multiple imask_progs that trigger off of the same message. SPECIAL NOTES: ANSI colors on objects don't seem to work well with imask_progs, so avoid using ANSI colors in anything that may be part of your imask_prog trigger. Variables and Codes are not used in imask_progs, so do not try to use them; it won't work. kill_progUsage: kill_prog This mobprog type triggers when the mob causes death. The kill_prog has a wide range of uses. The kill_prog is queued just before the target dies, so it is considered to be the target's last gasp. At the end of the kill-prog, however, the target dies. Even if the target sets its hit points to full, it will die. Other than that, the mob can mpjunk equipment it has, mptrasnfer a new room to die, unlock a door, load an object of some kind, etc. MULTIPLE PROGS: You can have multiple kill_progs on the same mob. level_progUsage: level_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance every time a player gains a level anywhere in the game. If the random number generated between 1 and 100 is equal to or below the percentage of the level_prog, the prog is triggered. EXAMPLES: level_prog 25 This prog will be triggered 25% of the time when someone levels. level_prog 100 This prog will be triggered 100% of the time when someone levels. This means every time. SPECIAL NOTES: This program will trigger every time a player levels, regardless of whether they are in the same room, or even whether the scripted monster can see or detect the player. The exception to this is cloaked admins, which will not trigger. lock_progUsage: lock_prog [keyword list] This type of mobprog is triggered by locking a container or door. If the script is on a container-type object, such as a door or container item, it will trigger only if the object being locked is the scripted one. If the target matches the keywords of the lock_prog, the prog is triggered. If there is a 'p' placed before the keyword list, the keywords of the object must exactly match that of the lock_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If the scripted item is not a container or door, and a "lock_prog all" is used, then the lock_prog will trigger from any object at all being locked. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. As is normal, if the scripted object is a mob, this event will not trigger if the scripted mob is the originator of the activity. EXAMPLES: lock_prog door gate This will trigger if the object locked has any of the keywords door gate. This means that it would be triggered by locking a door or gate. lock_prog p a large chest This will trigger if the object locked has the exact keywords a large chest.. The prog would not be triggered by locking an object with keywords large or chest or anything except the exact order and wording of the keyword list. lock_prog all This will trigger if any object is locked.) MULTIPLE PROGS: You can have more than one lock_prog on an item, mob, or room. Generally it is best not to have lock_progs with the same keywords in them, unless they are a lock_prog p with different keyword lists but some of the same keywords - for example a lock_prog p door gate and a lock_prog p door to the gate login_progUsage: login_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every time someone enters the game. If the random number generated between 1 and 100 is equal to or below the percentage of the login_prog, or the zapper mask matches the mob logging in, the prog is triggered. EXAMPLES: login_prog 25 This prog will be triggered 25% of the time when someone enters the game. login_prog 100 This prog will be triggered 100% of the time when someone enters the game. This means every time. login_prog -race +elf This prog will be triggered whenever an elf logs in. SPECIAL NOTES: This program will trigger every time a player enters the game, regardless of whether they are in the same room, or even whether the scripted monster can see or detect the player. The exception to this is cloaked admins, which will not trigger logoff_progUsage: logoff_prog [integer percentage or zapper mask] This type of mobprog checks a percentage chance, or a zapper mask, every time someone leaves the game. If the random number generated between 1 and 100 is equal to or below the percentage of the logoff_prog, or the zapper mask matches the mob logging out, the prog is triggered. EXAMPLES: logoff_prog 25 This prog will be triggered 25% of the time when someone leaves the game. logoff_prog 100 This prog will be triggered 100% of the time when someone leaves the game. This means every time. logoff_prog -race +elf This prog will be triggered whenever an elf logs out. SPECIAL NOTES: This program will trigger every time a player leaves the game, regardless of whether they are in the same room, or even whether the scripted monster can see or detect the player. The exception to this is cloaked admins, which will not trigger. llook_proglook_progUsage: look_prog [keyword list] This type of mobprog is triggered by looking at the scripted item. The "llook" version triggers if the item is "examined". If the target matches the keywords of the lock_prog, the prog is triggered. If there is a 'p' placed before the keyword list, the keywords of the object must exactly match that of the look_prog. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. As is normal, if the scripted object is a mob, this event will not trigger if the scripted mob is the originator of the activity. EXAMPLES: llook_prog all This will trigger if any the scripted item, room, or mob is examined. look_prog all This will trigger if any the scripted item, room, or mob is looked at. MULTIPLE PROGS: It is generally useless to have more than one look_prog on an item, mob, or room. once_progUsage: once_prog This type of mobprog is triggered immediately by the script engine under all circumstances, but is never triggered again. This makes it useful for doing initialization or other tasks which only need to be done once after the mud boots. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: once_prog This will trigger once, right away MULTIPLE PROGS: You can have only one once_prog on a mob. open_progUsage: open_prog [keyword list] This type of mobprog is triggered by opening a container or door. If the script is on a container-type object, such as a door or container item, it will trigger only if the object being opened is the scripted one. Otherwise, if the target matches the keywords of the open_prog, the prog is triggered. If there is a 'p' placed before the keyword list, the keywords of the object must exactly match that of the open_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If the scripted item is not a container or door, and a "open_prog all" is used, then the open_prog will trigger from any object at all being opened. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. As is normal, if the scripted object is a mob, this event will not trigger if the scripted mob is the originator of the activity. EXAMPLES: open_prog door gate This will trigger if the object opened has any of the keywords door gate. This means that it would be triggered by opening a door or gate. open_prog p a large chest This will trigger if the object opened has the exact keywords a large chest.. The prog would not be triggered by opening an object with keywords large or chest or anything except the exact order and wording of the keyword list. open_prog all This will trigger if any object is opened. MULTIPLE PROGS: You can have more than one open_prog on an item, mob, or room. Generally it is best not to have open_progs with the same keywords in them, unless they are a open_progs p with different keyword lists but some of the same keywords - for example a open_prog p door gate and a open_prog p door to the gate. quest_time_progUsage: quest_time_prog [quest name] [number of minutes remaining] This kind of mobprog triggers only if the script is part of an official Quest, and only if the number of minutes remaining in the quest is equal to the number of minutes specified. This is used as part of a quest plot line, to allow the mobs to give warnings about a quest that is running out of time. If the Scriptable behavior was granted as part of a Quest, then * may be substituted for the questname. The quest time minutes ranges from a positive number to 0. A quest time minutes value of -1 will trigger whenever a quest Step is completed, bearing in mind that *every* quest has at least one step. A quest time minutes value of -2 will trigger whenever the script is being removed, usually denoting the end of the quest over-all. EXAMPLES: quest_time_prog 'my quest' 20 This quest_time_prog will be triggered on the final 20th minute of the quest 'my quest'. quest_time_prog 'my quest' 1 This quest_time_prog will be triggered on the final minute of the quest 'that quest'. put_progUsage: put_prog [keyword list] This type of mobprog is triggered by observing something being put in a container, or by the scripted object being a matching container that something is being put into. It does not trigger if the scripted object is the thing being put into the container. Now, if the container involved matches the keywords of the put_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the put_prog. If there is not, then any container with any of the keywords in the list in it will trigger it. If a put_prog all is used, then the put_prog will trigger from any container at all being used. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: put_prog chest bag drawer This will trigger if the container used has any of the keywords chest, bag, or drawer. This means that it would be triggered by putting something into a chest, an awful bag, or even an chester drawers. put_prog p a large wooden chest This will trigger if the container used up has the exact keywords a large wooden chest. The prog would not be triggered by putting anything into a container with keywords wooden chest or wooden sword or anything except the exact order and wording of the keyword list. put_prog all This will trigger if any container is used. MULTIPLE PROGS: You can have more than one put_prog on a mob. Generally it is best not to have put_progs with the same keywords in them, unless they are a put_prog p with different keyword lists but some of the same keywords – for example a put_prog p apple red juicy and a put_prog p apple red poisoned. putting_progUsage: putting_prog [keyword list] This type of mobprog is triggered by putting a matched thing into a container. It does not trigger if the scripted object is the container itself, however. If the object being put into the container matches the keywords of the put_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the putting_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a putting_prog all is used, then the putting_prog will trigger from any item being put in any container at all. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: putting_prog key skeleton This will trigger if an object with the keywords key or skeleton is being put into a container. putting_prog p the skeleton key This will trigger if the item with exact keywords the skeleton key is being put into a container. The prog would not be triggered by items with keywords skeleton or the key or anything except the exact order and wording of the keyword list. putting_prog all This will trigger if any item is being put somewhere. MULTIPLE PROGS: You can have more than one putting_prog on a mob. Generally it is best not to have putting_progs with the same keywords in them, unless they are a put_prog p with different keyword lists but some of the same keywords – for example a putting_prog p apple red juicy and a putting_prog p apple red poisoned. rand_progUsage: rand_prog [integer percentage] This kind of mobprog checks a percentage chance every tick. If the random number generated between 1 and 100 is equal to or below the percentage of the rand_prog, then it will be triggered. This type of mobprog can be triggered at any time, so long as the mob is alive, including while it is sleeping or fighting. They are very useful for setting up certain elements of your zone, or for giving personality to your mobs, such as having a blacksmith who pounds out a sword. This kind of mobprog ONLY goes off when a player is in the same zone that your mob is in. EXAMPLES: rand_prog 20 This rand_prog will be triggered 20% of each tick. rand_prog 75 This rand_prog will be triggered 75% of each tick. SPECIAL NOTES: While using rand_progs seems really easy, having a lot of them can slow down your zone. Having extremely long rand_progs on many, many mobs is generally not a good idea. If possible, consider other options, and only use rand_progs that go off at a high rate on mobs that will perform the rand_prog once and then never again, either because they have some sort of internal check, or because they go and mppurge themselves afterwards. regmask_progUsage: regmask_prog [java regular expression] This type of mobprog will trigger when the mob sees a certain string of text. When the 'p' is inserted into the trigger line, the string of text must be precisely the same, case included, as the string generated. If 'p' is not the first character, then the trigger will attempt to find the first match of the given java regular expression string. This type of mobprog has many uses, one of which is communication between mobs. There are a few socials which create a message only to the person performing them and to the one receiving them. You can use these and act_progs to safely have mobs trigger each other, without people seeing what is going on. Other uses include triggering off of people fleeing, moving out of the room, etc. The possibilities are endless. EXAMPLES: regmask_prog a*be This will trigger whenever the mob sees a segment of text starting with the lowercase letter a, then containing 0 or more other letter as followed by the string "be". This would match aaaaabe regmask_prog p A wolf howls at the moon. This will trigger the prog when it sees this precise message. Note that punctuation and case is important here as well. MULTIPLE PROGS: You can have more than one regmask_prog on a mob, but you shouldn't have multiple regmask_progs that trigger off of the same message. SPECIAL NOTES: ANSI colors on objects don't seem to work well with regmask_progs, so avoid using ANSI colors in anything that may be part of your regmask_prog trigger. Variables and Codes are not used in regmask_progs, so do not try to use them; it won't work. remove_progUsage: remove_prog [keyword list] This type of mobprog is triggered by removing an object. If the object removed matches the keywords of the remove_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the remove_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a remove_prog all is used, then the remove_prog will trigger from any object at all being removed by the mob. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: remove_prog orange apple banana This will trigger if the object removed has any of the keywords orange, apple, or banana. This means that it would be triggered by removing a banana, an apple pie, or even an orange shield. remove_prog p apple pie delicious This will trigger if the object removed has the exact keywords apple pie delicious. The prog would not be triggered by removing an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. remove_prog all This will trigger if any object is removed. MULTIPLE PROGS: You can have more than one remove_prog on a mob. Generally it is best not to have remove_progs with the same keywords in them, unless they are a remove_prog p with different keyword lists but some of the same keywords – for example a remove_prog p apple red juicy and a remove_prog p apple red poisoned. sell_progUsage: sell_prog [keyword list] This type of mobprog is triggered by selling an item to a shopkeeper. If the item being sold has any of the keywords of the sell_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the item must exactly match that of the sell_prog. If there is not, then any item with any of the keywords in the list in it will trigger it. If a sell_prog all is used, then the sell_prog will trigger for any item at all being sold. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: sell_prog orange apple banana This will trigger if the item being sold has any of the keywords orange, apple, or banana. This means that it would be triggered by selling a banana, an apple pie, or even an orange shield. sell_prog p apple pie delicious This will trigger if the item being sold has the exact keywords apple pie delicious. The prog would not be triggered by selling anything with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. sell_prog all This will trigger if any sort of item is sold. MULTIPLE PROGS: You can have more than one sell_prog on a mob. Generally it is best not to have sell_progs with the same keywords in them, unless they are a sell_prog p with different keyword lists but some of the same keywords – for example a sell_prog p apple red juicy and a sell_prog p apple red poisoned. social_progUsage: social_prog [social name] This type of mobprog is triggered by a social of the looked for name being done in the same room. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: social_prog smile This will trigger if the smile social is done in the same room as the scripted object. MULTIPLE PROGS: You can have more than one social_prog on a mob. Generally it is best not to have social_progs with the same social trigger in them. speak_progUsage: speak_prog [trigger message] This type of mobprog is triggered by the scripted mob saying the trigger line, or if the scripted object is not a mob, it is the same as speech_prog below. If a 'p' is inserted in the prog as above, the line spoken must exactly match the trigger message; if it is not, then any of the keywords listed will trigger the mobprog. A keyword of ALL will trigger on any speech. This type of mobprog is useful for quests driven by player scripts or setting up passwords that must be spoken. This type of prog can also be used to have a mob trigger itself if you want to have multiple connected progs – see complex progs for details. Note that this kind of mobprog is only triggered by someone using the say command. EXAMPLES: speak_prog dog wolf coyote This will trigger the prog whenever dog, wolf, or coyote is said by the scripted mob. If more than one of the keywords is spoken in the same line, the prog will trigger more than once. speak_prog p The dog barks at the cat This will trigger the prog only if the exact expression is said. Note that punctuation counts, although you don't *have* to use it. MULTIPLE PROGS: You can have more than one speak_prog on a mob. It is generally not a good idea to have more than one speak_prog be triggered by the same expression.
speech_progUsage: speech_prog [trigger message] This type of mobprog is triggered by someone other than the scripted mob saying the trigger line, be it mob or player, in the same room as the scripted object. If a 'p' is inserted in the prog as above, the line spoken must exactly match the trigger message; if it is not, then any of the keywords listed will trigger the mobprog. A keyword of ALL will trigger on any speech. This type of mobprog is useful for setting up internal quests, giving out background information to people exploring your zone, or setting up passwords that must be spoken. This type of prog can also be used to have a mob trigger itself if you want to have multiple connected progs – see complex progs for details. Note that this kind of mobprog is only triggered by someone using the say command. EXAMPLES: speech_prog dog wolf coyote This will trigger the prog whenever dog, wolf, or coyote is said in the room with the mob. If more than one of the keywords is spoken in the same line, the prog will trigger more than once. speech_prog p The dog barks at the cat This will trigger the prog only if the exact expression is said. Note that punctuation counts, although you don't *have* to use it. MULTIPLE PROGS: You can have more than one speech_prog on a mob. It is generally not a good idea to have more than one speech_prog be triggered by the same expression. time_progUsage: time_prog [list of hours in the day] This type of mobprog triggers once per mud hour, on the hours of the day listed. This allows you to have a script which triggers infrequently. There are 16 hours per day (0-15) in CoffeeMud. EXAMPLES: time_prog 10 1 2 This will trigger if hour of the day is 10, 1, or 2. time_prog 3 This will trigger on the 3rd hour of every day. unlock_progUsage: unlock_prog [keyword list] This type of mobprog is triggered by unlocking a container or door. If the script is on a container-type object, such as a door or container item, it will trigger only if the object being unlocked is the scripted one. If the target matches the keywords of the unlock_prog, the prog is triggered. If there is a 'p'; placed before the keyword list, the keywords of the object must exactly match that of the unlock_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If the scripted item is not a container or door, and a "unlock_prog all" is used, then the unlock_prog will trigger from any object at all being unlocked. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. As is normal, if the scripted object is a mob, this event will not trigger if the scripted mob is the originator of the activity. EXAMPLES: unlock_prog door gate This will trigger if the object unlocked has any of the keywords door gate. This means that it would be triggered by unlocking a door or gate. unlock_prog p a large chest This will trigger if the object unlocked has the exact keywords a large chest.. The prog would not be triggered by unlocking an object with keywords large or chest or anything except the exact order and wording of the keyword list. unlock_prog all This will trigger if any object is unlocked. MULTIPLE PROGS: You can have more than one unlock_prog on an item, mob, or room. Generally it is best not to have unlock_progs with the same keywords in them, unless they are a unlock_prog p with different keyword lists but some of the same keywords - for example a unlock_prog p door gate and a unlock_prog p door to the gate. wear_progUsage: wear_prog [keyword list] This type of mobprog is triggered by wearing, wielding, or holding an item. If the object worn matches the keywords of the wear_prog, the prog is triggered. If there is a ‘p' placed before the keyword list, the keywords of the object must exactly match that of the wear_prog. If there is not, then any object with any of the keywords in the list in it will trigger it. If a wear_prog all is used, then the wear_prog will trigger from any object at all worn. This type of prog is usually used for in-zone quests and special mob behavior, and has a variety of uses. EXAMPLES: wear_prog orange apple banana This will trigger if the object worn has any of the keywords orange, apple, or banana. This means that it would be triggered by wearing a banana, an apple pie, or even an orange shield. wear_prog p apple pie delicious This will trigger if the object worn has the exact keywords apple pie delicious. The prog would not be triggered by wearing an object with keywords red apple or blackberry pie or anything except the exact order and wording of the keyword list. wear_prog all This will trigger if any object is worn. MULTIPLE PROGS: You can have more than one wear_prog on a mob. Generally it is best not to have wear_progs with the same keywords in them, unless they are a wear_prog p with different keyword lists but some of the same keywords – for example a wear_prog p apple red juicy and a wear_prog p apple red poisoned. Scripting CodesMost commands in your scripts allow you to use variable-like scripting Codes instead of literals. A literal is a specific static string or number, such as 'the hairy blog' or 'green' or '72'. A scripting code, however, is a special string which represents a literal and stands for it in your scripts. Understanding scripting codes is absolutely necessary for you to write scripts successfully. When a DEATH_PROG triggers, for example, it is impossible for the commands that execute to guess the name of the mobs killer. Therefore the name of the killer is stored in a scripting code for you. In this case, that code is $n. This allows you to use the code $n in your DEATH_PROG commands and be sure that wherever you use it, it is referring to "the creature that killed me". Also, when using commands that cause strings to echo, you may want to use a pronoun to refer to the creature who triggers an event. Guessing, however, won't work here either. In the case of our DEATH_PROG example, we could use the code $m and be sure that, whever it appears, the word 'his', 'her', or 'it' will replace it appropriately.
Any of the above codes may be followed by a period and a literal number to designate a particular word inside a string of many words. For instance, if $o evaluates to "a magic wand", then $o.1 would evalulate to "magic". If $l evaluated to "orc bob hassan", then $l.2 would give "hassan". This can be very useful when used with the $l or $L codes to iterate through the contents of a room. This syntax can also be used to generate substrings by following the number with two periods "..". For instance, of $l evaluates to "orc bob hassan", then $l.1.. would give "bob hassan". You can also add .LENGTH# to the end of a variable to return the number of words contained inside the string.
The [function name] must be the name of one of the functions listed in the following chart. All functions must have parenthesis after their names, and most functions require one or more parameters inside the parenthesis. The parameters usually include a [code]. This may be either the string name of either a mob or an item (whichever is appropriate to the function), or a code from the previous chart which represents a mob or an item. The description for each function will specify whether mob names or codes representing mobs are more appropriate, or whether item names or codes representing items are more appropriate. Here is an example of this code being used in a say statement: say I am $%isgood($i)% and my favourite number is $%rand()%. This string would replace the $%.. codes with the results of the given function calls. Here is the list of accepted functions for the $% code. Where 'monster' is referred to below, you may assume this to be whatever object (mob, item, room, exit) which has the Scriptable behavior on it. Usually this is an npc mob. In the case of an item, it refers to a mob who takes the place of the item for scripting purposes. For this reason, using $i and $I codes, or using functions which only return information about the scripted monster when an item is being scripted is totally useless.
Scripting CommandsCommands inside your scripts should each be terminated by a carriage return (ENTER) or a semicolon, depending upon the manner in which your script is presented. Commands are of two general types: MUD Commands, and MOBPROG (MP) Commands. MUD Commands you should already be familiar with, as they include commands such as GET, PUT, SAY, DROP, etc. It is not within the scope of this document to list or describe the standard MUD Commands. The help files inside the mud itself can do a far better job. It is sufficient to say that issuing the command in your script cause the scripted mob to attempt to perform the command exactly as it is written. If you enter a script line such as: get sword .. and there is a sword, the mob will get it. If there is NO sword, the mob will not appear to be doing anything at all. MP Commands are what we will be discussing in more detail here. Like MUD Commands, they each have a syntax and structure which must be followed. commandword parameter1 parameter2 ... parametern Like MUD Commands, MP Commands all have a key command word followed by one or more parameters. As in MUD Commands, those parameters are delimited by spaces. If you need to specify a single parameter which contains a space, you would put double quotes (") around the parameter. say "the scary monster" hi! In an MP Command, however, this is not true. In an MP Command, the single quote (') is used around a parameter when it contains spaces. Keep this difference in mind when writing your scripts, lest you run into problems. This difference is actually more important with MP Functions. This is because most MP Commands only have one parameter, so that parameter word grouping using quotes is usually not necessary. if, else, endifUsage: if [condition] The if command is the cornerstone of Scripting, and the only other condition mechanism outside of the MPWHILE command. The way the if command works is by deciding whether or not the condition that is given is true, and if so, executing the commands following the if condition. When the condition is not true, the commands before an endif statement or, (if given), an else statement are not executed. If an else statement lies between an if statement and the endif statement, then the statements between the else statement and the endif statement will be executed whenever the condition is false, but not ever if the condition is true. Either way, statements after an endif statement are executed regardless. Every if statement MUST have a corresponding endif statement somewhere after it. The else statement is completely optional, but if it is used, it must be between the if statement and the endif statement. A BREAK statement may be included inside an IF..ENDIF block to skip the remaining statements in that block. Of course, everything that happens or doesn't happen in an if condition depends on the condition itself. Every condition consists of a valid function name followed by an open parenthesis, followed by any parameters required by that function, and a close parenthesis. A simple example is below: if sex($n == M) In this example, the sex function is called to determine whether $n (which is a variable representing the cause of a trigger) is male. If the mob who caused the trigger is male, the condition is true. Otherwise it is false. In the particular function above, the '==' symbols mean 'equal to'. Conditional statements may be negated using the "!" character as follows: if !sex($n == M) In this case, the condition evaluates to false if the mob who caused the trigger is male, and true otherwise. Conditional statements may contain more than one function call if they are separated by the key words 'and' or 'or'. In the case of an 'and' key word, the condition evaluates to true if the functions on either side both evaluate to true, and it evaluates to false otherwise. In the case of the 'or' key word, the condition evaluates to true if either of the functions on either side evaluate to true, and false otherwise. Here are some examples of those in use: if sex($n == F) or race($n == Harpy) if sex($n == M) and isevil($n) Lastly, conditional statements may group together their function calls using parenthesis. This can be used to ensure that certain sets of function calls are evaluated together, while others are not. For instance: if sex($n == M) or isevil($n) and race($n == Harpy) if ( sex($n == M) or isevil($n) ) and race($n == Harpy) In these examples, if $n happens to refer to a Good Male Gnome, then the first statement would evaulate to true, while the second statement would evaluate to false. This is because the parenthesis force the sex and isevil checks to be evaulated first in the second example. Please see the section below on functions for a list of the conditional functions and their uses. switch, case, default, endswitchUsage: switch [variable]The switch command is an alternative to the if/endif syntax above for comparing a single variable to many different variables. A switch statement is essentially a stand-in for this syntax: if VAR($i MYVAR == 'value1')Notice how, in the above example, we are comparing the same variable over and over again to different values, and doing something different depending on that value. This is what the switch command allows you to do without having to nest so many if-statements. Here would be the equivalent switch statement to the above: switch $%VAR($i MYVAR)%In the above switch statement, we declare the value we wish to check after the key word switch, which is the value of the variable $i MYVAR. In the ensueing case statements, we declare what we want the value of $i MYVAR to be equal to in order for the commands which follow the case statement to be executed. Each case statement defines its own value which $i MYVAR must be equal to in order for its following commands to be executed. The default statement is a special case is executed only if a value of $i MYVAR did not match any of the previous case values. Finally, the endswitch declares that no more cases will be given. Consider another example: switch $%RANDNUM(5)%In this example, we are comparing a randomly generated number from 1-5 to each of the possible values in our case statements. Since we have covered all possible values of $%RANDNUM(5)%, we do not need to include a default case. for, nextUsage: for $[digit] = [number] to [number] The for command is the simplest way to execute one or more other commands numerous times. It allows you to specify a numeric range for the scripting engine to count from and to, executing the commands after the for statement (and before the next statement) as many times as is required to complete the counting. The value of the current digit during counting is stored in one of the temporary variables $0, $1, $2, $3, ... $9. Here's an example: for $0 = 1 to 10 If you execute the above script, you will see the mpecho command repeated 10 times, which is one time for every digit between 1 and 10. Each time it executes the mpecho command, the value of the temporary variable $0 will be incremented. That's the basics, simple huh? For loops can be nested, so long as all of the outer for loops are using different temporary variables than the inner ones. Since there are 10 temporary variables, this gives you a limit of a nested depth of 10. The two number expressions can be literal numbers as shown above, or any expression which might evaluate to a number, such as $% syntax. Here's an example of what I mean: for $0 = 1 to '$%NUMMOBSROOM(*)%' You'll see that the NUMMOBSROOM() function is used here to return the number of mobs in the room, so we can count them. Each one we count, we can pass the $0 variable used in this loop to the ROOMMOB() function to get their name. Please see the section below on functions for a list of the functions and their uses. For Zero-based counting, there is the alternate syntax that replaces the 'to' key word with 'to<'. This will force the for-loop to count up to, but not including, the last number. For instance: for $0 = 0 to< 5 The above would display 0 1 2 3 4, whereas, with a normal 'to' key word, it would have counted 0 1 2 3 4 5. <SCRIPT>This command denotes the beginning of a section of ECMA Javascript. Any lines of text following this command, and before the adjoining </SCRIPT> command will be assumed to be executable Javascript. These commands can only be embedded in standard event handlers as described above. Javascript is a wholly different language than the standard Scriptable/MOBPROG 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/. Even though the languages are very different, you will
still
be able to use all of the MOBPROG commands, functions, and even the
special string versions of the functions described in the green table
above. When using a command in JavaScript, make sure to
always
surround the parameters to the command with parenthesis, and make sure
all parameters are separated by commas instead of spaces. For
example, in MOBPROG, you might write: if IsPC ($n) However, in Javascript, the exact same effect is
generated by
writing: if( ISPC("$n") ) Notice that, while case is not sensitive for command or function names in MOBPROG, in JavaScript, all MOBPROG commands and functions are in uppercase only. Also notice that, when calling a string function from the green table above, the name of the function must end with a "$" character, to differentiate it from the boolean function calls (eg ISPC above). After you've read the above documentation, there are still a few small details to be aware of before getting started. One is that the Scriptable behavior will provide certain methods for accessing important event-related objects from inside your Javascript. These include the object functions source(), target(), host(), monster(), item1(), item2(), [] objs(), and message(). Another important detail is that Javascript variables defined will be lost from execution to execution, even of the same script. For this reason, additional methods String getVar(String host, String variableName), and void setVar(String host, String variableName, String value) have been provided to save the variables globally. The last important detail relates to semicolon characters. It is lucky that Javascript does not require them, because the Scriptable behavior will strip them out 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 be escaped: \; Here is an example: GREET_PROG 100 mpacctattooUsage: mpacctattoo [target] (-)[tattoo name]If your mud even uses the common account system, this command grants or removes from the target's common player account a tattoo of the given name. This is useful for permanently flagging accounts in some way which can be checked and acted on elsewhere, for instance using the HASACCTATTOO function. The tattoo must begin with the character - to denote removal. See MPTATTOO for the similar command that applies to regular player mobs instead of their accounts. When adding new tattoos, you can prefix the name with a number to create a temporary tattoo that disappears in the given number of ticks. EXAMPLES: mpacctattoo $n smurfkillermpacctattoo $n -smurfkiller mpacctattoo $n '50 smurfkiller' mpaffectUsage: mpaffect [spell name] [target] (nTICKS) [parameters] This command will put the target under the affect of the given Ability (spell, chant, prayer, song, skill, or CoffeeMud property). Properties will be applied normally, while non-properties will be auto-cast. The spell name can be prefixed with property: to force even non-Properties to be applied without auto-casting or any invokation at all. The parameters given apply specifically to CoffeeMud properties, and are unnecessary for most spells, chants, etc. The parameters may be preceeded by a number and the word "TICKS" (no spaces between the number and TICKS) to force the property or skill to remain an effect for a certain period of time. EXAMPLES: mpaffect Invisibility $n mpalarmUsage: mpalarm [ticks] [command] This very simple command will wait the given number of ticks (4 second intervals) before executing the command given in the parameters. This command does NOT end execution. Any commands after mpalarm will be executed immediately. It is only the command given in the mpalarm parameters that will be executed after the delay. It is for this reason that the trigger type function_prog exists: namely to allow you to execute the group of instructions in the function_prog after some delay. EXAMPLES: mpalarm 10 say umm.. what was the question? mpargsetUsage: mpargset [$var] [value or $var]This powerful but complex command is used to change one of the internal object variables, such as $n, $i, $t, $o, $p, $d, $0..$9, to point to a different object. This can then affect subsequent commands that refer to them. While $0..$9 may be set to any value, the standard $n..$d variables must be set to an object of the same kind. MPARGSET will try very hard to resolve the given value as an object, instead of a string. However, you can also put double-quotes "" around the value to force it to be evaluated only as a string. EXAMPLES: mpargset $o $p mpasoundUsage: mpasound [text string] This command will echo the text string to all of the rooms adjacent to the one the mob is in, much like the echo when a mob yells. This can be useful for creating dramatic deaths from mobs, or for use with mobs such as a wandering minstrel or the like. EXAMPLES: mpasound You hear a scream from nearby! SPECIAL NOTES: Keep in mind that mpasound does not echo to those in the room with the mob, only to rooms adjacent to it. So if you want people in the room to hear the mpasound too, you'll need to use an mpecho as well. mpatUsage: mpat [destination] [command] Performs the desired command at a designated location. The destination can be either a room id, a key word from the room description, or the name of a mob. If you need to be need to find mobile mobs or items, you can include the mob or item name, followed by @ followed by a room id or area name. The command can be just about anything you want it to be. This command is very useful for doing slight of hand kind of tricks with mobs by performing actions away from the player, or doing things elsewhere in the zone for you. It has many potential uses. EXAMPLES: mpat MyArea#1232 unlock door SPECIAL NOTES: When using mpat, it is not a bad idea to give your mobs specific, unique keywords so they can be manipulated with no error. The command is usually essential for zones that have complicated quests, and can be used to trigger other mobs, unlock and open doors and chests away from the mob, and a variety of other things. mpbeaconUsage: mpbeacon [destination] [target] This command changes the recall/start room of the target, which must be a player. EXAMPLES: mpbeacon MyArea#1232 all mpbehaveUsage: mpbehave [behavior id] [target] [parameters] This command will put the target under the affect of the given CoffeeMud behavior. The parameters given apply specifically to CoffeeMud behaviors. The Archon may use LIST BEHAVIORS, and AHELP [behavior name] for more information. EXAMPLES: mpbehave Aggressive $n mpcallfuncUsage: mpcallfunc [function name] [parameters] This command allows you to execute a group of other predefined commands without typing them all again. This is done by first defining a group of commands using the trigger function_prog. Once it is defined, the commands inside the function_prog may be executed by placing mpcallfunc followed by the function_prog's name parameter into another set of commands. This is useful for executing a set of commands that would normally have to be typed identically into your triggers over and over again. It is especially useful when used in conjunction with commands like mpalarm. The parameters passed into the mpcallfunc can be referenced using the $g and $G codes. EXAMPLES: mpcallfunc CompleteTask $n 'my house' mpcastUsage: mpcast [spell] [target] This command causes the host mob to cast the given spell, chant, prayer, song, or use the given skill against the given target. Unlike using the mundane cast command, this scripting form does not require the mob to actually have the skill. Although there is still the 1-in-20 chance of failure of any skill, and the level of the host will affect the probability of success. EXAMPLES: mpcast fireball $r mpcastextUsage: mpcastext [spell] [target] [arguments]This command causes the host mob to cast the given spell, chant, prayer, song, or use the given skill against the given target. Unlike using the mundane cast command, this scripting form does not require the mob to actually have the skill. And unlike MPCAST, it also allows you to spell out all of the arguments to the spell, for cases where the spell requires that. Remember that in targeted spells, the first argument is usually the targets name, so specifying that name again can be useful. Also, if you need to separate arguments, be sure to use double-quote "" instead of single quotes, since those strings will be parsed by the coffeemud engine instead of the mobprog engine. Although there is still the 1-in-20 chance of failure of any skill, and the level of the host will affect the probability of success. EXAMPLES: mpcast brainwash '$r' "$r" "I'm a pretty princess"mpchannelUsage: mpchannel [channel name] [message] mpchannel ![channel name] [message]This command causes the host mob to send a message to the given public channel, overriding any read-only restrictions which may be established. If the channel name is preceded by a !, then the message will be unattributed, a system message. EXAMPLES: mpchannel gossip Hello all! mpchannel !info Somewhere, a script is running.mpchooseUsage: mpchoose [pc name] [variable] [choices] [default choice] [prompt string]This command blocks the current coffeemud thread and waits for the player character denoted by the pc name variable to enter a one-letter choice from among the list of choices. This command will then store the chosen value in a variable of the given name under the pc name's context. If the pc name variable does not denote an online player, this command is skipped. The choices are a series of uppercase letters the player may choose from, like 'NSEW' or 'YN'. The default choice will be selected if the player simply hits ENTER instead of entering a choice. The choice is then stored in the variable of the given name as if the script command MPSETVAR [pc name] [variable] [result] was executed (see MPSETVAR). ** WARNING ** This command BLOCKS its current thread. It is therefore NOT appropriate to use this command off any trigger that operates off a tick thread, such as ONCE_PROG (unless executed during Character Creation), TIME_PROG, or similar triggers. It is OK to trigger this off an event trigger, such as GREET_PROG, EXECMSG_PROG and others, so long as you are certain the trigger leading to this prompt came from a command entered by a player-user (as opposed to a MOB generated event, which ultimate comes from tick threads). In short, BE CAREFUL!  This command has no effect if there is no lid or door, or it is already closed. EXAMPLES: mpclose $xN mpconfirmUsage: mpconfirm [pc name] [variable] [default value] [prompt string]This command blocks the current coffeemud thread and waits for the player character denoted by the pc name variable to enter either yes or no, Y or N. This command will then store the chosen value in a variable of the given name under the pc name's context. If the pc name variable does not denote an online player, this command is skipped. The default choice will be selected if the player simply hits ENTER instead of entering a choice, and should be either the letter Y or the letter N (uppercase). The choice (also letter Y or N) is then stored in the variable of the given name as if the script command MPSETVAR [pc name] [variable] [result] was executed (see MPSETVAR). ** WARNING ** This command BLOCKS its current thread. It is therefore NOT appropriate to use this command off any trigger that operates off a tick thread, such as ONCE_PROG (unless executed during Character Creation), TIME_PROG, or similar triggers. It is OK to trigger this off an event trigger, such as GREET_PROG, EXECMSG_PROG and others, so long as you are certain the trigger leading to this prompt came from a command entered by a player-user (as opposed to a MOB generated event, which ultimate comes from tick threads). In short, BE CAREFUL! EXAMPLES: mpconfirm $n MYCHOICE N Are you a dork (Y/N): mpechoat $n You chose $<$n MYCHOICE>. mpdamageUsage: mpdamage [target] [min amount] [max amount] This command does damage to a mob or item specified as the target. The amount of damage will be randomly between the min and max amounts. This command, by default, will never ever kill the target UNLESS the parameters are followed by the word kill as shown in the example below. Also, this command will treat any items that do not normally display a condition (like mundane items, wands, etc) as having 1 hit point. Other items (weapons, armor) will have a number of hit points equal to their condition. This command is useful not only for hurting mobs, but for scratching up their armor when acid falls from the ceiling or something similar.  It does nothing if the mob does not have the skill. Skills can be granted using the mpenable command. EXAMPLES: mpdisable $n fireball mpechoUsage: mpecho [text string] Quite simply, the mpecho command sends a message to the room of the mob. This message can be anything you like. It supports all of the character codes the mud uses, and can also use variables set by the mpsetvar command. This has a wide range of uses, from setting background noise to a mob, to allowing the mob to express itself safely as if speaking. The mpecho command does not set off speech_progs, although it does set off act_progs. EXAMPLES: mpecho $i says, ‘Hey how's it going?' SPECIAL NOTES: Using mpecho $i says, ‘blah' is a safe way to have a mob talk. Anytime you want to have a mob say something, you should use this, unless you want it to trigger speech_progs. Also, remember that whatever is mpechoed is seen be everyone in the room exactly the same. So if you want a message that targets a specific person, see the mpechoat and mpechoaround commands. mpechoaroundUsage: mpechoaround [target] [text string] This command is similar to the mpecho command, but instead of echoing to everyone in the room, can be used to echo to everyone BUT the targeted person. Why would you do this? If used in conjunction with the mpechoat command, you can create text strings which look right to everyone involved. The way to make mpechoaround do this is to use the mpat command. EXAMPLES: mpechoaround $n You hear voices speaking all around you. mpechoatUsage: mpechoat [target] [text string] This command functions similar to the mpecho command, but can be used in such a way that only the targeted person or place sees the text string. This is useful for cutting down on spam from greet_prog mpechos, for example, as well as personalizing the text string for all parties involved in conjunction with the mpechoaround command. It also allows mobs to emulate the announce command. The target may be a local mob name, the word "world", the word "area", a room id, or an area name. If you need to be need to find mobile mobs or items, you can include the mob or item name, followed by @ followed by a room id or area name. EXAMPLES: mpechoat $n You hear voices speaking all around you. mpenableUsage: mpenable [target mob] [ability] [integer proficiency] [parameters] This command grants a skill, spell, prayer, chant, song, expertise, or other ability to the target mob, or can be used to modify the proficiency of an existing skill. This acts like a forced 'GAIN' command, giving the target the skill permanently. The proficiency parameter should be between 0 and 100 when adding a new skill, or ++ followed by an adjustment integer, or -- followed by an adjustment integer. The final parameters are optional. Abilities can be removed with the mpdisable command. EXAMPLES: mpenable $n Spell_Fireball 100 mpendquestUsage: mpendquest [quest name] When giving a quest name, this command forces a Quest which is in progress to shut itself down gracefully, removing its specific mobs, items, and properties from your map. If the Scriptable behavior was granted as part of a Quest, then * may be substituted for the questname. When giving a target mob (or item for that matter) parameter, and if the running script was granted either directly or indirectly by a Quest, this command will remove any scripts associated with that quest (even the one running) from the target. When used in this way, the implementing quest is NOT stopped, shut down, or cleaned up gracefully. EXAMPLES: mpendquest smurfocide mpexpUsage: mpexp [target] [exp amount] This command gives an amount of experience to the target, or a percentage of the experience they need to the next level. This is a useful command to use to award players for completing in zone quests, etc. that you have set up. If you want to award more experience than the capped amount, you can have the mob give several experience awards in a row. It is best when you award an experience award to give some sort of message to the player about why they are receiving the award. EXAMPLES: mpexp $n 500 SPECIAL NOTES: Players
can level off of these experience
awards, just as if they had killed something. Be careful with this
command. You don't want to give out awards for every little thing
characters do, nor do you want to give large awards for menial tasks.
You also will, of course, not want to make it so a mob can accidentally
give the same award over and over endlessly, or something equally
abusable. mpfactionUsage: mpfaction [target mob] [faction id] [new value, range, or +--change] This command forces the victim to gain the given faction, and the given value within it. The target can be a character variable or a keyword of a mob. The faction id is the Faction to give to the player or mob. The new value, difference, or range may be a positive numeric value, a negative numeric value, it may be the name of one of the faction ranges, or it may be a difference expressed by +number or by --number (two - characters are required to distinguish a negative difference from a single negative numeric value). This command can be used to introduce a player to a faction they otherwise would not be able to gain, or it can be used in combination with the FACTION function to modify the value of a faction. EXAMPLES: mpfaction $n alignment.ini 1000 mpforceUsage: mpforce [target] [command] This command forces the victim to do the designated command. The target can be a character variable or a keyword of a mob. This command has a lot of uses, but is mostly use in combat to do particularly nasty things, like force the player to heal the mob, etc. It can also be used to trigger other mobs by forcing them to perform a specific action which triggers an act_prog. EXAMPLES: mpforce $n flee SPECIAL NOTES: Remember that whatever you force something to do, it needs to be typed out exactly as if they were typing the command themselves. That means if you want a player, for example, to be forced to cast ‘heal serious' on your mob, you need to make sure you observe the double-quote rule for word groupings, as opposed to the single quote rule for mobprog commands. mpgotoUsage: mpgoto [destination] Quite simply, this command will move the mob to the designated location. The destination can be a room id, keyword from a room description , or keyword of a mob. If you need to be need to find mobile mobs or items, you can include the mob or item name, followed by @ followed by a room id or area name. There is no message given to this command, so if you want there to be one, you need to include an mpecho in your mobprog. This command is a good way to move your mob around your zone should you need to. EXAMPLES: mpgoto Area#10076 mpgsetUsage: mpgset [target] [variable] [value] This powerful command lets you change all kinds of aspects of the target mob or item or whatever. Valid variable names for items include: "CLASS", "USES", "LEVEL", "ABILITY", "NAME", "DISPLAY", "DESCRIPTION", "SECRET", "PROPERWORN", "WORNAND", "BASEGOLD", "ISREADABLE", "ISDROPPABLE", "ISREMOVABLE", "MATERIAL", "AFFBEHAV", "DISPOSITION", "WEIGHT", "ARMOR", "DAMAGE", "ATTACK", "READABLETEXT", "MINRANGE", "MAXRANGE", "WEAPONTYPE", "WEAPONCLASS", "AMMOTYPE", "AMMOCAPACITY", "HASLOCK", "HASLID", "CAPACITY", "CONTAINTYPES", "NOURISHMENT", "RIDEBASIS", "MOBSHELD", "SENSES", "DISPOSITION", "LEVEL", "ABILITY", "REJUV", "WEIGHT", "HEIGHT", "ARMOR", "DAMAGE", "ATTACK" Additional variable names for items above the official ones include: "MATERIALNAME", "RESOURCENAME", "DISPOSITIONSTR", "SENSESSTR", "OWNER", and "LIQUIDREMAINING" Valid variable names for mobs include: "CLASS", "RACE", "LEVEL", "ABILITY", "NAME", "DISPLAY", "DESCRIPTION", "MONEY", "ALIGNMENT", "DISPOSITION", "SENSES", "ARMOR", "DAMAGE", "ATTACK", "SPEED", "AFFBEHAV", "ABLES", "INVENTORY", "TATTS", "EXPS", "RIDEBASIS", "MOBSHELD", "WHATISELL", "PREJUDICE", "BANKCHAIN", "COININT", "LOANINT", "IGNOREMASK", "POSTCHAIN", "POSTMIN", "POSTLBS", "POSTHOLD", "POSTNEW", "POSTHELD", "ITEMINT", "HITS", "MANA", "MOVE", "HUNGER", "THIRST", "FATIGUE", "STRENGTH", "INTELLIGENCE", "DEXTERITY", "CONSTITUTION", "CHARISMA", "WISDOM", "GENDER", "PARALYSIS SAVE", "SAVE VS FIRE", "SAVE VS COLD", "SAVE VS WATER", "SAVE VS GAS", "SAVE VS MIND", "GENERAL SAVE", "JUSTICE SAVE", "SAVE VS ACID", "SAVE VS ELECTRICITY", "SAVE VS POISON", "SAVE VS UNDEAD", "SAVE VS MAGIC", "SAVE VS DISEASE", "SAVE VS TRAPS", "MAX STRENGTH ADJ.", "MAX INTELLIGENCE ADJ.", "MAX DEXTERITY ADJ.", "MAX CONSTITUTION ADJ.", "MAX CHARISMA ADJ.", "MAX WISDOM ADJ.", "SENSES", "DISPOSITION", "LEVEL", "ABILITY", "REJUV", "WEIGHT", "HEIGHT", "ARMOR", "DAMAGE", "ATTACK", "HITS", "MANA", "MOVE", "HUNGER", "THIRST", "FATIGUE", "BASEHITS", "BASEMANA", "BASEMOVE", "BASEHUNGER", "BASETHIRST", "BASEFATIGUE", "MAXHITS", "MAXMANA", "MAXMOVE", "MAXHUNGER", "MAXTHIRST", "MAXFATIGUE" Additional variable names for mobs above the official ones include: "QUESTPOINTS", "FOLLOWERS", "TRAINS", "PRACTICES", "STINK", "CHARCLASS", "ALIGNMENT", "INCLINATION", "FACTIONID", "FACTIONAMT", "DEITY", "MATTRIB", "CLAN", "CLANROLE", "OBJATTRIB", "CLANROLE", "OWNER", "DISPOSITIONSTR", "SENSESSTR", "BUDGETRESETDATE", "INVENTORYRESETDATE",Valid variable names for player mobs also include: "FRIENDS", "IGNORE", "TITLES", "ALIAS","LASTIP","LASTDATETIME", "CHANNELMASK", "COLORSTR", "PROMPT", "POOFIN", "POOFOUT", "TRANPOOFIN", "TRAINPOOFOUT", "ANNOUNCEMSG", "NOTES", "WRAP", "BIRTHDAY", "ACCTEXPIRATION", "INTRODUCTIONS" Whenever a value of ++ is given for any stat, it will increment that stats value by 1. A value of -- will decrement by one. EXAMPLES: mpgset $n CHARISMA 10 SPECIAL NOTES: Be very careful with this command when dealing with players. If used poorly it can cause bad things to happen to them, so make sure you have good checks to ensure they get affected correctly and fairly. mphealUsage: mpheal [target] [min amount] [max amount] This command heals a mob or item specified as the target. The amount of healing will be randomly between the min and max amounts. This command will ignore any items that do not normally display a condition (like mundane items, wands, etc). Other items (weapons, armor) will have a number of hit points equal to their condition. This command is useful not only for healing mobs, but for repairing their armor when acid falls from the ceiling or something similar. EXAMPLES: mpheal $r 1 10 mphideUsage: mphide [target] This command makes the target totally and completely undetectable by any means, magical or mundane. This is useful for making something "go away", but not really. mpunhide can restore such a hidden thing to sight. EXAMPLES: mphide $n mphitUsage: mphit [victim] This command causes the mob to make a single normal attack on the victim. It will not cause combat, but will preserve the existing combat status of everyone involved. EXAMPLES: mphit $n
mpjunkUsage: mpjunk [object] This command destroys the object that the mob is referring to. The object must be in the mob's inventory or part of its equipment. You can also have a mob mpjunk all, which destroys everything on their person. You can also do things such as mpjunk all.sword or mpjunk all.bread, and can use the character variable $o. The command gives no message about its use, so it is a good way to secretly handle the junking of items. It is useful for getting rid of quest items given to the mob for give_progs, or if you have more complicated mobs where you must perform some sort of action in order to get its equipment, for example. EXAMPLES: mpjunk chalice SPECIAL NOTES: This command is very good for give_progs where you want to destroy the thing given so it can load again or not be used again by the same people. It is a good idea to give quest objects like that unique keywords so there is no mistaking what the mob is mpjunking. mpkillUsage: mpkill [victim] This command basically causes the mob to attack the victim. The only real benefit of using this command is if your mob is low level or attacking someone under the affect of an awe spell. Other than that, there is no difference between this command and say, kill. EXAMPLES: mpkill $n SPECIAL NOTES: Really, this command doesn't get used much. It was built for other MUD's which might have level requirements for kill, etc. You can use it, but it more or less works exactly the same as kill, murder, hit, etc. mplinkUsage: mplink [direction] [target room] [exit class id] ([exit name])This command allows a standard exit to be created from the room in which the scripted object is currently in, to another room in the same area, provided the script is only operating in its origin area. It will NOT overwrite/obliterate any existing exit in the same direction. EXAMPLE: mplink UP 'My Area#12322' OpenNameable my namemploadquestobjUsage: mploadquestobj [questname] [variable expression/name] [$var] This command reads in a named object or string value for the given quest, and stores it in the internal temp variable object referred to by $var. $var may be $n, $o, $p, $i, $t, $d, $0..$9. Normally, this command only works when the object returned is of the same type as the $var, however, since the $0..$9 variables can hold any type of data, it is usually best to use one of those. Either way, this command can profoundly effect subsequent commands that use the $var specified. The quest name may be the name of a loaded quest, or * if this Scriptable object was loaded directly by a Quest script. The variable expressions may be one of these standard string values (non-objects): "CLASS", "NAME", "DURATION", "EXPIRATION", "WAIT", "MINPLAYERS", "PLAYERMASK", "RUNLEVEL", "DATE", "MUDDAY", "INTERVAL" The variable expressions may also be based on one of these quest objects: "LOADEDMOBS", "LOADEDITEMS", "AREA", "ROOM", "MOBGROUP", "ITEMGROUP", "ROOMGROUP", "ITEM", "ENVOBJ", "STUFF" or one of the following Mystery quest objects: "FACTION", "FACTIONGROUP", "AGENT", "AGENTGROUP", "ACTION", "ACTIONGROUP", "TARGET", "TARGETGROUP", "MOTIVE", "MOTIVEGROUP", "WHEREHAPPENED", "WHEREHAPPENEDGROUP", "WHEREAT", "WHEREATGROUP", "WHENHAPPENED", "WHENHAPPENEDGROUP", "WHENAT", "WHENATGROUP", "TOOL", "TOOLGROUP". Some of these objects are actually groups of objects, such as STUFF, LOADEDMOBS, LOADEDITEMS, and the ones that end with ..GROUP. The ones that end in group can be used as-is to load the group of objects into one of the $0..$9 vars. However, you can also tack on a "#" to the end of the name to return the number of items in the group instead of the group itself. After that, you can tack on a number like "#n" to return the nth item in the group. Lastly, tacking "#$" will return just the names of the items, and "#?" will return a random element in the group. See the examples for more information on some of these. EXAMPLES: mploadquestobj 'myquest' 'MOB' $t mploadvarUsage: mploadvar [mob name] [variable name] This command loads a variable stored in the database using the given parameters. The variable is then available to the VAR function, as well as the $< syntax. The mob name can for a variable can be a literal name string or a code like $n or $i. The variable name must be a literal string. EXAMPLES: mploadvar $n KILLS mplockUsage: mplock [target] This command locks the target item or exit. If the target is already locked, or does not have a door or lock, nothing happens EXAMPLES: mplock $xN mplogUsage: mplog error [module] [message] mplog info [module] [message] mplog debug [module] [message]This command outputs the given message to the coffeemud log file. For debug style messages to appear, the appropriate DBGMSGS entry in the coffeemud.ini file must be turned on. EXAMPLE: mplog info MyQuest $n has successfully completed my quest.mpm2i2mUsage: mpm2i2m [target] This strange command turns a target mob into an item, and an item back into a mob. The target may be a mob, or an item which was created with mpm2i2m or the Cage skill. EXAMPLES: mpm2i2m $n SPECIAL NOTES: If anyone comes up with a practical use for this command in an actual script, please let me know! mpmloadUsage: mpmload [mob name] This command loads the mob designated by name into the room. If you want the mob loaded somewhere besides the room the mpmloading mob is located, you'll need to use the mpat command. This command gives no message to the world, so if you want one, you'll use the mpecho command. This command is useful for loading mobs to assist the calling mob in combat, load in-zone quest mobs, etc. The mob of that name will be searched for throughout the map, so if you want to make sure the mob is available for this command, he should be carefully hidden. The fromfile syntax will allow you to load a mob from a cmare file created using the Archon EXPORT MOBS command. The fromgenfile syntax will allow you to generate a random mob from a random-generation formatted xml file, with the mob name followed by the mob tag to search for, with optional id=value definitions after the item tag. EXAMPLES: mpmload the nasty bat SPECIAL NOTES: Remember that this newly loaded mob may not have interacted with the world just yet, so having your mob, for example, mpforce it to kill $n will not work, since the new mob has no idea who $n is. mpmloadshopUsage: mpmloadshop [mob name] This command loads the mob designated by name into the current shopkeeper inventory. If you want the mob loaded somewhere besides the scripted shopkeeper the mpmloading mob script is on, you'll need to use the mpat command. The mob of that name will be searched for throughout the map, so if you want to make sure the mob is available for this command, he should be carefully hidden. The fromfile syntax will allow you to load a mob from a cmare file created using the Archon EXPORT MOBS command. The fromgenfile syntax will allow you to generate a random mob from a random-generation formatted xml file, with the mob name followed by the mob tag to search for, with optional id=value definitions after the item tag. The PRICE= syntax may be used at the end of ANY of the syntaxes to set the price of the mob, otherwise a default price will be used. When this method completes, the value of $9 is automatically set to a string description of the final price. EXAMPLES: mpmloadshop the nasty bat PRICE=40 mpmoneyUsage: mpmoney [target] +[amount] This command changes the amount of money owned by the target. This is a useful command to use to award players for completing in zone quests, etc. that you have set up. The amounts are always as expressed in base local currency. You can optionally specify the name of the currency as part of the amount. EXAMPLES: mpmoney $n +500 gold coins mpnotriggerUsage: mpnotrigger [trigger name] [time in miliseconds] This command will prevent a scriptable event with the given trigger name on the same creature to trigger for the given amount of time. Where trigger name may be any of the above scriptable triggers, such as "greet_prog" or "level_prog" or any other. After the amount of time has passed, the trigger will be allowed. EXAMPLES: mpnotrigger greet_prog 10000 SPECIAL NOTES: This command is useful mainly to most easily prevent a greet_prog from firing for an entire group, or in cases where someone leaves and re-enters very quickly. mpoloadUsage: mpoload [item name] This command loads an item of the designated name into the inventory of the mob. If you want to load an item into a room, you must use the mpoloadroom command. This command gives no message to the world, so if you want one you'll have to use the mpecho command. This command is very useful for loading in-zone quest objects, mob pelts, portals, etc. It has many, many uses. The item of that name will be searched for throughout the map, so if you want to make sure the item is available for this command, it should be carefully hidden. The fromfile syntax will allow you to load an item from a cmare file created using the Archon EXPORT ITEMS command. The fromgenfile syntax will allow you to generate a random item from a random-generation formatted xml file, with the item name followed by the item tag to search for, with optional id=value definitions after the item tag. Finally, the into syntax will allow you to load the item into a pre-existing container, even if the container is in the room. EXAMPLES: mpoload the baseball bat SPECIAL NOTES: You can do a lot with this command. There is no max on items loaded in this way, so keep that in mind. mpoloadroomUsage: mpoloadroom [item name] This command loads an item of the designated name into the same room as the mob. If you want to load an item into a mobs inventory, you must use the mpoload command. This command gives no message to the world, so if you want one you'll have to use the mpecho command. This command is very useful for loading in-zone quest objects, mob pelts, portals, etc. It has many, many uses. The item of that name will be searched for throughout the map, so if you want to make sure the item is available for this command, it should be carefully hidden. The fromfile syntax will allow you to load an item from a cmare file created using the Archon EXPORT ITEMS command. The fromgenfile syntax will allow you to generate a random item from a random-generation formatted xml file, with the item name followed by the item tag to search for, with optional id=value definitions after the item tag. Finally, the into syntax will allow you to load the item into a pre-existing container in the room. SPECIAL NOTES: You can do a lot with this command. There is no max on items loaded in this way, so keep that in mind. Using this command along with the mppurge command can create shifting portals and the like. mpoloadshopUsage: mpoloadshop [item name] This command loads an item of the designated name into the shopkeeper inventory of the scripted mob. If you want to load an item into another shops inventory, you must use the mpat command. The item of that name will be searched for throughout the map, so if you want to make sure the item is available for this command, it should be carefully hidden. The fromfile syntax will allow you to load an item from a cmare file created using the Archon EXPORT ITEMS command. The fromgenfile syntax will allow you to generate a random item from a random-generation formatted xml file, with the item name followed by the item tag to search for, with optional id=value definitions after the item tag. Finally, the price syntax may be added to the end of the any of the others to designate the price of the item, otherwise a default value will be used. When this method completes, the value of $9 is automatically set to a string description of the final price. mpopenUsage: mpopen [target] This command opens a lid on a container, or the door on an exit. This command has no effect if there is no lid or door, or it is already open. EXAMPLES: mpopen $xN mpplayerclassUsage: mpplayerclass [target] [char class id] ([level] [char class id] [level] ...) This command allows you to change the current character class of a player, to add new character classes to a player, and to modify specific class levels all with one command. The first parameter is the player or mobs code. The next parameter must be a valid character class id, such as Fighter or Necromancer. This will instantly set that class as the targets current class, adding it if necessary. This may be optionally followed by a level integer, which will change the class level of that current class. The level parm may then be followed by another character class id, which will change the players current class again, and may be followed again by a level integer to change the new current character class level, and so on. This command only works when the total class levels is equal to the players overall level. Otherwise, the engine will engage in an automatic correction. Keep this in mind when changing class levels. Any positive levels *added* to a class must first be taken away from some other class so that everything ends up equal. EXAMPLES: mpplayerclass $n Fighter mppossessUsage: mppossess [player] [target mob]This command forces the target mob to be controlled by the given player. EXAMPLES: mppossess $s eaglemppracsUsage: mppracs [target] [amount] This command sets the mobs number of practices to the given number, or adjusts their existing practices by an amount upwards or downloads depending on syntax. A number alone will change their existing number of practices to the given number. The ++ syntax followed by a number will raise their amount by the given number. The -- syntax followed by a number will lower their amount by the given number. This is a useful command to use to award players for completing in zone quests, etc. that you have set up. It is best when you reward a player using this command that you alsogive some sort of message to the player about why they are receiving the award. EXAMPLES: mppracs $n 0 SPECIAL NOTES: Be careful
with this command. You don't want to
give out awards for every little thing characters do, nor do you want
to give large awards for menial tasks. You also will, of course, not
want to make it so a mob can accidentally give the same award over and