This is a listing of the mobprog types 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.
act_prog
Usage:
>act_prog [trigger message]~
>act_prog p [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.
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.
bribe_prog
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 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.
death_prog
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.
entry_prog
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. 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.
fight_prog
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. For more details, look at the mob section of the building docs found on Age of Chaos’ main web page.
give_prog
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.)
>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.
greet_prog
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 if isqueued function in greet_progs to cut down on spam when multiple players enter the room at the same time.
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.
hitprcnt_prog
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.
rand_prog
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 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.
speech_prog
Usage:
>speech_prog [trigger message]~
>speech_prog p [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.
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.