This is a listing of the mobprog triggers that Age of Chaos currently supports. These are the backbone of your mobprogs, and let the mob know when and in what way it should be triggered.
index
act_prog bribe_prog command_prog death_prog entry_prog exit_prog fight_prog give_prog greet_prog hitprcnt_prog load_prog rand_prog special_prog speech_prog
Usage:
>act_prog [trigger message]~
>act_prog p [trigger message]~
>act_prog r [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. Lightbulb, brb, type, and yawn are a few of such socials. 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. Using the ‘r’ in an act_prog means the mobprog will make use of regular expressions. See the Complex Mobprogs tutorial for more details on how to use this very powerful feature.
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 important here as well.
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: Emotes do not trigger act_progs. Socials and mpechos, however, can trigger them. Channels do not set off act_progs either. 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 are not used in act_progs, so do not try to use them; it won’t work. Please note that punctuation is important!
Usage:
>bribe_prog [integer 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 integer money value of the bribe_prog, the prog will go off. If it is less than the value of the bribe_prog, 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.
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.
SPECIAL NOTES: It’s not a bad idea to have a bribe_prog 1 at the end of all of your bribe_progs, even if it is just to have the mob let the player know they need to give a little more money. When a bribe_prog is triggered, the gold given to the mob is actually turned into an object pile of coins in the mobs inventory. To have the mob add the coins to its gold, have the mob do an mpat somewhere hidden drop coins and get coins. It’s not a bad idea, however, to have the mob junk the coins or just leave them on the ground somewhere. Room 1252 is a good room for dropping coins, as is room 25598. Both are hidden rooms used as utility rooms for mobprogs throughout the world.
Usage:
>command_prog [trigger word]~
This mobprog will be triggered when a player inputs the command set to be the trigger word. This command does not need to be an existing command, though it can be. The trigger word must be exact, so a partial command will not work (ie: player must type ‘burn’ not ‘bu’). This trigger currently only supports one word, though it is possible to have additional arguments present using a function. See the below example. This mobprog is useful for allowing players to use commands not normally available in the game. For instance, a mob could have a command_prog for ‘jump’ that teleports a ‘jumping’ player to a ledge above it, even though a ‘jump’ command doesn’t really exist.
EXAMPLES:
>command_prog smoke~
This will trigger whenever a player inputs the command ‘smoke’ in the same room with the mob. They must completely type out ‘smoke’ to trigger the mobprog.
>command_prog howl~
This will trigger whenever a player inputs the command ‘howl’ in the same room with the mob. They must completely type out ‘howl’ to trigger the mobprog. Note that although howl is an existing command, but it may still be used in the command_prog.
>command_prog
ring~
if
/($1,"bell")
mpechoat $#n You ring the bell.
mpechoaround $#n $n rings the
bell.
else
if
!=($1,"")
mpechoat $#n I don't see that
here!
else
mpechoat $#n Ring what?
endif
endif
~
The above example allows you to set a second argument for the command_prog. In this case, the mobprog will be triggered by the player typing ‘ring.’ The %1 represents the potential second argument in the command_prog. If the player types ‘ring bell’ they will cause an mpecho declaring they have rung the bell. If they type just ‘ring’ then %1 is empty or “” and the player gets the message ‘Ring what?’ Finally, if the player tries to ring anything besides ‘bell’ they will get the ‘I don’t see that here!’ message. You can technically have up to nineteen % arguments in the trigger (%1, %2, %3, %4, etc).
MULTIPLE PROGS: You can have multiple command_progs on the same mob without any problems. It is not advisable to have two command_progs with the same trigger, for obvious reasons.
SPECIAL NOTES: If two or more mobs are in the same room and have the same command_prog, only the very first mob in the room will be triggered if the trigger command is inputted. If you want all of the mobs to react to the command_prog trigger, what you can do instead is use an mpechonpc to trigger all of the other mobs in the room to react appropriately. The command_prog and special_prog mobprogs are closely related, and both can make use of the mppunt command, which allows the trigger word to continue as normal rather than be suppressed.
Usage:
>death_prog [integer percentage]~
This mobprog type triggers on the mob’s death. If the random
number between 1 and 100 that is generated is less than or equal to the
percentage of the death_prog, the death_prog will be triggered. 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. The mob is cleared of all spells
that have been cast upon it, and is considered to be standing and thus can
perform just about any action. 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.
EXAMPLES:
>death_prog 15~
There is a 15% chance that the death_prog will trigger on the mob’s death.
>death_prog 100~
There is a 100% chance the death_prog will go off on the mob’s death, or every time the mob dies, it will be set off.
MULTIPLE PROGS: You can have multiple death_progs on the same mob. However,
they must be listed in order from smallest percentage to largest. So if you
have a death_prog 15 and a death_prog 75, the 15 must be listed before the 75.
SPECIAL NOTES: Under no circumstance should you ever mpadd or mppush any command in a death_prog. This will cause the commands to be ignored. Since the mob is ‘dying’ its queue list will be cleared. Thus the commands under the death_prog must occur without being mpadded or mppushed. Also, you can never cause a mob to take an action that will prevent it from following through with death. For example, you cannot have a mob mppurge itself on a death_prog. Doing this will cause bad problems.
Usage:
>entry_prog [integer percentage]~
This type of prog checks a percentage chance every time the mob moves into a new room. If the random number generated is equal to or below the percentage of the entry_prog when the mob steps into a new room, 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.
MULTIPLE PROGS: You can have multiple entry_progs on the same mob. To get them
to work right, however, they must be in increasing order of percentage, so an entry_prog
5 would have to be listed before and entry_prog 75. If you don’t do this your
lower percentage entry_progs will never be set off.
SPECIAL NOTES: Keep in mind that there usually is no $n (actor) in an entry_prog, so an entry_prog 100 to kill $n will normally not work. What you can do is check and see if $r (random) is a pc, and attack that instead. Another option would be to have previously stored a character variable like var-actor into another variable and have the mob check and see if THAT variable is present in the room it has just entered. An entry_prog is triggered by normal movement, entering a portal, a mob that is hunting, fleeing, or a mob that is moved out of a room by gust of wind or spook for example. It does not get triggered by the mpgoto command, teleport spells, etc.
Usage:
>exit_prog [integer percentage]~
This type of mobprog checks a percentage chance every time someone exits the room that the mob is currently in. If the random number generated between 1 and 100 is equal to or below the percentage of the exit_prog, the prog is triggered. Keep in mind exit_progs are triggered by both players and mobs alike. This trigger has a number of uses; a common one is to use an exit_prog to summon fleeing players back to the mob. The prog is only triggered by conventional movement, so it will not be triggered by teleporting or recalling characters, or mobprog transferring for example.
EXAMPLES:
>exit_prog 25~
This prog will be triggered 25% of the time when someone leaves the room where the mob currently is.
>exit_prog 100~
This prog will be triggered 100% of the time when someone leaves the room where the mob currently is. This means every time.
MULTIPLE PROGS: You can have multiple exit_progs on the same
mob. You must have these exit_progs in order from smallest percentage to
largest. So if you have an exit_prog 10 and an exit_prog 100, the 10 must come
before the 100. If you don’t do this, your lower percentage exit_progs won’t go
off.
SPECIAL NOTES: You’ll probably want to do a large number of if checks in
exit_progs, specifically in the difference between mobs and player characters.
Note that exit_progs will trigger even if a person is sneaking, but the mob
must have detect invisibility to see invisible people, infravision to see
people in the dark, and will not see people if blinded.
Usage:
>fight_prog [integer percentage]~
This type of mobprog checks a percentage chance 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, 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.
MULTIPLE PROGS: You can have multiple fight_progs on a mob. However, the lower percentage fight_progs must come first. So if you have a fight_prog 10, a fight_prog 25, and a fight_prog 50, they must go in that order, from smallest percentage to largest. If you don’t do this your lower percentage fight_progs will not go off.
SPECIAL NOTES: All mobs know every spell. So if you want a mob to cast a spell as part of a fight_prog, all you have to do is have the mob cast it. However, if you want a mob to use a skill, you must give the skill to them as part of the mob file using the S field. The skill level at which a mob uses a weave or a skill is based on their elements, which can be configured in the mob file. For more details, look at the mob section of the building docs found on Age of Chaos’ main web page and the various help files for each skill and spell which list the element that they use.
Usage:
>give_prog [keyword list]~
>give_prog p [keyword list]~
>give_prog all~
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 (wow - that’s an ugly 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. If you use a give_prog all with other give_progs, it must be the last give_prog listed, or all other give_progs that come after it will be superceded by the give_prog all.
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. Also, it is usually best if the give_prog is important enough to make use of the nosteal affect for mobs (see the mob section of the AoC Build Docs).
Usage:
>greet_prog [integer percentage]~
This type of mobprog checks a percentage chance every time someone enters the room that the mob is currently in. If the random number generated between 1 and 100 is equal to or below the percentage of the greet_prog, the prog is triggered. Note that greet_progs are triggered by both 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. It is a good idea to use the isqueued function in greet_progs to cut down on spam when multiple players enter the room at the same time, and the ispc or isnpc functions to make sure the person triggering the mobprog isn’t just some hapless wandering mob.
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.
MULTIPLE PROGS: You can have multiple greet_progs on the
same mob. You must have these greet_progs in order from smallest percentage to
largest. So if you have a greet_prog 10 and a greet_prog 100, the 10 must come
before the 100. If you don’t do this, your lower percentage greet_progs won’t
go off.
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 even if a person is sneaking, but the mob
must have detect invisibility to see invisible people, infravision to see
people in the dark, and will not see people if blinded.
Usage:
>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.
MULTIPLE PROGS: You can have multiple hitprcnt_progs on a mob. They must be placed in increasing order or percentages, so that the lowest percentage hitprcnt_progs come first and the higher hitprcnt_progs last. If you don’t set them up this way, the lower percentage progs will never go off.
SPECIAL NOTES: To be honest, hitprcnt_progs aren’t the most reliable. Sometimes, if the mob has a lot of commands in its queue, it may never get around to triggering the hitprcnt_prog. If you don’t mind this fact, then there is no problem, but you may consider using something else. For example, a fight_prog 100 that does an if <(stat($i,”hit”),1000) which would check every round if a mob’s hit points are under 1000. If you do use a hitprcnt_prog, they work best when the percentage is fairly high and there are few complex mobprogs attached to the mob.
Usage:
>load_prog [integer percentage]~
This kind of mobprog checks a percentage chance when the mob loads up and triggers the mobprog if successful. Anytime a mob loads, whether it be after a reboot, when the mob reloads at zone repop after being killed earlier, or loaded by another mob using the mpmload command, this prog will be triggered. The prog will ONLY be triggered this one single time, and never again for the lifetime of the mob. The load_prog will go off regardless of whether or not a player is in the zone with the mob, unlike rand_prog. This mobprog is very useful for setting up a mob with permanent affects, setting up a zone’s quests, etc. It is far more efficient to use than rand_prog in a lot of instances when you only need something done once and want it done reliably and as soon as possible.
EXAMPLES:
>load_prog 20~
This load_prog will be triggered 20% of the time when the mob loads.
>load_prog 75~
This load_prog will be triggered 100% of the time when the mob loads.
MULTIPLE PROGS: You can have multiple load_progs on a mob. If you do this, it is imperative that you do so in increasing order. So, if you have a load_prog 75 and a load_prog 100, the load_prog 75 should always be placed before the load_prog 100. If you don’t do this, your lower probability load_progs will not go off.
SPECIAL NOTES: One thing to pay attention to is that this mobprog goes off fairly quickly. Therefore, it is usually advisable, if a mob is going to be affecting other mobs or objects in the zone, that it be loaded fairly close to the end of the .zon file. This isn’t 100% necessary, but does ensure that the mobs and objects you may be affecting with your load_prog mob actually exist when the load_prog is being called and can be affected normally.
Usage:
>rand_prog [integer percentage]~
This kind of mobprog checks a percentage chance every pulse_mobile, which is a period of time of about nine seconds. 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 pulse_mobile. This means it would be a good bet that it will be set off every 45 seconds or so, although this isn’t guaranteed.
>rand_prog 75~
This rand_prog will be triggered 75% of each pulse_mobile. This means the prog should go off every 14 seconds or so. This kind of high probability rand_prog is best left to mobs that who will perform an action once and never do it again.
MULTIPLE PROGS: You can have multiple rand_progs on a mob. If you do this, it is imperative that you do so in increasing order. So, if you have a rand_prog 5 and a rand_prog 25, the rand_prog 5 should always be placed before the rand_prog 25. If you don’t do this, your lower probability rand_progs will not go off.
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 you need a mob to set itself up in a way that is only performed once, strongly consider using a load_prog to do the same sort of thing which is far more efficient. While it might be ‘atmospheric’ to have mobs sitting around doing various things randomly, if overdone it can be really irritating rather than add to any ambience, so try to get a good balance when using rand_progs.
Usage:
>special_prog [trigger word]~
This mobprog will be triggered when a player inputs the command set to be the trigger word. This command must be an existing command to work. The trigger word does not have to be fully typed out to trigger (ie: typing ‘w’ would be sufficient if the special_prog was ‘west’). This trigger currently only supports one word, though it is possible to have additional arguments present using a function. See the below example. The mobprog can be used in a number of ways. First of all, you can use it to suppress a command so the player simply cannot use it. It can also be used to have the mob react to the command then allow the player to continue (using the mppunt command). Another way to use it would be to have different things happen to the player when they use the command – for example, a player types ‘north’ expecting to head north into one room while being sneakily mptransferred to another room instead.
EXAMPLES:
>special_prog north~
This will trigger whenever a player inputs the command ‘north’ in the same room with the mob. The player could also just type ‘n’ or any other ‘short’ version of the command and the mobprog would be triggered.
>special_prog camp~
This will trigger whenever a player inputs the command ‘camp’ in the same room with the mob. The player could also type ‘ca’ or any other abbreviation.
>special_prog
weave~
if
/($1,"’silence’")
mpechoat
$#n You can’t seem to weave the silence spell here!
mpechoaround $#n $n can’t seem to
weave the silence spell here!
else
if
!=($1,"")
mppunt
else
mpechoat $#n Weave what?
endif
endif
~
The above example allows you to set a second argument for the special_prog. In this case, the mobprog will be triggered by the player typing ‘weave.’ The %1 represents the potential second argument in the special_prog. If the player types ‘weave ‘silence’’ they will cause an mpecho declaring they can’t weave the silence spell. If they type just ‘weave’ then %1 is empty or “” and the player gets the message ‘Weave what?’ Finally, if the player tries to weave anything besides ‘’silence’’ the special_prog gives the mppunt and the player can weave the spell as normal. You can technically have up to nineteen % arguments in the trigger (%1, %2, %3, %4, etc).
MULTIPLE PROGS: You can have multiple special_progs on the same mob without any problems. It is not advisable to have two special_progs with the same trigger, for obvious reasons.
SPECIAL NOTES: If two or more mobs are in the same room and have the same special_prog, only the very first mob in the room will be triggered if the trigger command is inputted. If you want all of the mobs to react to the special_prog trigger, what you can do instead is use an mpechonpc to trigger all of the other mobs in the room to react appropriately. The command_prog and special_prog mobprogs are closely related, and both can make use of the mppunt command, which allows the trigger word to continue as normal rather than be suppressed.
Usage:
>speech_prog [trigger message]~
>speech_prog p [trigger message]~
>speech_prog r [trigger message]~
This type of mobprog is triggered by someone saying the trigger line, be it mob or player. 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. 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. Using the ‘r’ in a speech_prog means the mobprog will make use of regular expressions. See the Complex Mobprogs tutorial for more details on how to use this very powerful feature.
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.
SPECIAL NOTES: Keep in mind that mobs can trigger speech_progs, even their own. This is why we use mpecho to make the mob appear to be talking instead of using say, unless we want the mob to trigger itself or other mobs. Keep in mind too that speech does not trigger act_progs; it triggers speech_progs.
|
A MUD based on Robert Jordan's Wheel of Time series. With roleplaying encouraged through
guilds, clans, clanwars, holywars and throne wars. Experience the Wheel of Time world in a
whole new way: in an Age ravaged by the Last Battle. The time lace has been broken, the barrier
between dream and reality shattered. Weaves. Clans. Crafting. Huge World. Free Online Role Playing Game or commonly called RPG. The most unique Free Online RPG set in the Wheel of Time world.
|