Prog Section 4

From Immwiki
Revision as of 02:05, 29 April 2011 by Telelion (Talk | contribs) (trying to get these things formatted)

Jump to: navigation, search

Prog Triggers: Comprehensive Listing

"It is by will alone I set my mind in motion. It is by the juice of Sapho 
that thoughts acquire speed, the lips acquire stains, stains become a warning.
It is by will alone I set my mind in motion." -- Mentat Piter de Vries, Dune


PROG TRIGGERS RELATING TO MOVEMENT

entry_prog
 An entry_prog is a prog that triggers whenever the mobile that it is on enters a
 room. So, if you want a mobile that enters a room, greets everyone there, then 
 does a merry jig, an entry_prog is what to use.
 Syntax:
 entry_prog [percentage]
 The entry prog triggers on a chance equal to the percentage value, which is an
 integer between 1 and 100 (inclusive).
   Ex:
   entry_prog 100
   say Hey hey!
 A mobile with this program has a 100% of saying "Hey hey!" when entering a new 
 room. 
 This prog trigger can also be used on objects, where it behaves in an identical
 manner.
 Note: If a mob or object is entering the same room it is presently in (through a
 looped exit, etc.), the entry_prog will not trigger. Additionally, an entry_prog
 will only trigger on a ‘physical’ entry (as opposed to magical or progged 
 transport).
exit_prog
 An exit_prog is a prog that triggers whenever someone exits the room where the 
 mob or object is located. So, if you want a mob that says good-bye to people 
 leaving, or a progged trap on an exit, exit_prog is the thing to use.
Syntax:
 exit_prog [percentage]
 An exit prog will trigger whenever a player or mob exits the room, with a 
 percentage value equal to the argument. 
   Ex:
   exit_prog 90
   say Bye-bye, $N!
 When someone leaves the room, the exit_prog will, 90% of the time, result in
 the mob saying: "Bye-bye, <Short desc of person leaving>!" (Notice that we use
 $N rather than $n, since we should always use the short desc in echoes.)
 Note: An exit_prog triggers when a person leaves the room, but before they 
 reach their destination. HOWEVER, it cannot be used to prevent someone from 
 leaving the room (say, by transporting them elsewhere). At the end of the 
 prog, the "exit" still goes through, and the player is sent to the corresponding 
 destination.
greet_prog
 A greet_prog triggers whenever an entity enters the room where the greet_prog 
 is located. Greet_progs can be used for mobiles which greet players who enter, 
 rooms with a trap that triggers on certain classes of people entering (such as
 a pit trap), or even for mobiles which flee from the sight of pc’s.
 Syntax: greet_prog [Percantage value (i.e., any number from 1-100)]
 A greet_prog triggers whenever a pc enters the room with the object/room/mob. 
 The chance that the greet prog triggers is equal to the percentage value given
 as an argument. 
   Ex:
   greet_prog 50
   say Hello there!
 So, this mob has a 50% chance any time a pc enters the room of triggering the
 prog, at which point the pc will see the mob saying "Hello there!"


all_greet_prog
 An all_greet_prog is identical to a greet_prog, except that it triggers for 
 all people entering the room, whether or not the person is visible. In times 
 past, this was useful for doing ‘greet traps’, since you want the mobile with 
 the trap prog to be able to see the player no matter what. However, with the 
 advent of room_progs [which see everything by default], these are less 
 necessary.
 Syntax: all_greet_prog [percentage]
 As greet_prog, an all_greet_prog triggers on a percantage chance.
 Ex: See above for greet_prog examples.


=== PROG TRIGGERS THAT OCCUR AT SPECIFIC TIMES ===
load_prog
 A load_prog is a prog which triggers whenever a mobile is loaded via a reset 
 (but not via a manual loading). It takes a percentage argument, which determines 
 whether or not it triggers when the mob resets. Load progs are used for loading
 specialized objects on a mobile, determining whether quest-related mobs should load,
 or even for a mob that hides an object when it loads.
 Syntax: 
 load_prog [percentage]
 The load prog triggers when the mobile resets. Of note, since the mobile is not
 "completely there" when the load_prog triggers, actions such as says or emotes
 will not be performed in a load_prog (use mpecho, mpechoat, etc. instead).
   Ex:
   load_prog 100
    mpecho With a clatter of bones, a skeleton claws its way out of the cursed soil!
 When placed on a mob, this echo would be visible to the room whenever it resets.
 So, rather than a "silent repop", we would see this echo.
rand_prog
tick_prog
hour_prog
 A rand_prog is a prog which triggers with a given percentage every pulse. (Pulses
 are one 'round'.). Rand_progs are often used for
 mobs who periodically emote actions, check for the presence of other mobs/objects 
 in the room, or even to ‘count down’ a timer on an object or mob.
 tick_progs and hour_progs are identical to rand_progs; they simply trigger less 
 frequently. A tick_prog will trigger on the tick (every 30-60 seconds), while an hour_prog will do so
 every two ticks, that is, on the hour.
 Syntax: 
 rand_prog [percentage]
 tick_prog [percentage]
 hour_prog [percentage]
 The rand_prog will trigger with a given percentage every pulse.
   Ex:
   rand_prog 1
   mpecho The hen clucks loudly, then pecks at the ground resolutely.
 This rand_prog would occur with 1% chance, every pulse. Players in the room with
 the mob would see the echo periodically, giving the impression of animation on 
 the mob’s part.
 Rand prog notes:
 Only one rand_prog may trigger per mob/object per pulse. Therefore, if you have a 
 rand_prog 100 followed by a rand_prog 20, the rand_prog 20 will never trigger, as
 rand_prog checking stops once the first is executed. 
 Rand_prog does not have $n, as there is no entity that ‘triggers’ a rand_prog. 
 Using $n in a rand_prog will yield random, undesirable, or no results. 
time_prog
 A time_prog is one which occurs at a specified hour of the day. Time_progs can be 
 used for patrolling guards, merchants that close up shop, or even a door that’s only 
 visible at a certain time of day.
 Syntax:
 time_prog [hour of day]
 Time progs will trigger at the specified hour of day, which is a number between 1-24,
 inclusive. (I.e., the times given are in "military" time.)
   Ex:
   time_prog 4
   wake
   mpecho The farmer yawns as he awakens.
   say I guess it’s time to head back to the fields.
 This is a prog one might see on a farmer. Every day at 4 am, the farmer will awaken
 (maybe another time prog puts him to sleep), echo to the room about yawning (4 am is
 awfully early), then comment about what he’s going to do.


=== PROG TRIGGERS THAT OCCUR IN COMBAT, DAMAGE, OR DEATH ===
fight_prog
 A fight_prog is a prog which triggers on a percentage chance each round of combat. 
 Fight_progs can be used to simulate mobs which perform special attacks in combat,
 shout and jeer in a fight, or even randomly teleport away from the player.
 Syntax:
 fight_prog [percentage]
 Triggers on percentage chance, per round.
 Note: Fight_progs will not trigger until after the initial first round of combat.
 This rarely has any effect on prog decisions, but is a factor (the canonical 
 example would be a wizinvis mob you want to unwizi in a fight -- but wizi mobs 
 stop fighting after one round of combat, so it never triggers.)
   Ex: 
   fight_prog 5
   Yell Death to mutant bears!
 Every round, there would be a 5% chance that the mob would yell "Death to the 
 mutant bears!" as a sort of battle cry.
 Other fight prog notes:
 In a fight prog, $n is the person fighting the mob (or individual carrying the
 object) with the prog. 
 Once a fight_prog has triggered, no other fight_progs will be checked for that 
 round. I.e., if there is a fight_prog 100 first, then a fight_prog 20, the 
 fight_prog 20 will never trigger, as the 100 will always take effect.
hitprcnt_prog
 A hitprcnt_prog is a combat prog which triggers when a mobile reaches a specified 
 percentage of its health. Hitprcnt_progs are used for having a mob call guards, 
 teleport away, or to change strategies when they reach a certain level of health.
 Syntax:
 hitprcnt_prog [percentage]
 A hitprcnt_prog will trigger whenever a mobile’s health reaches the percentage value.
   Ex:
   hitprcnt_prog 30
   say I’ll live to fight another day!
   mpgoto 5000
 This mobile will flee when it reaches 30% health, going to the room with vnum 5000.
 hitprcnt_prog notes:
 Hitprcnt_progs can be unreliable. If a mob "skips" being a certain percentage value, 
 it may end up not triggering the prog! (i.e., going from 55% to 45% in one hit, while
 the prog triggers on 50%) Be watchful for this, and be sure to have contingencies in
 case this fails. 
hit_prog
 A hit_prog triggers whenever a mobile or object is on an entity which scores a hit in 
 combat. Hit_progs are used for special effects that occur only when a blow connects, 
 such as a vorpal sword, a mob’s bite being poisonous, etc.
 Syntax:
 hit_prog [percentage]
 Hit_prog triggers on the specified percentage chance, whenever the mobile the prog is 
 on or the object connects with a normal hit.
   Ex:
   hit_prog 50
   mpecho The sword of Kil’ryead glows a wicked red as it connects with the flesh of $N!
 This prog, on a sword, would generate this echo 50% of the time, checked whenever
 the sword hit.
 hit_prog notes:
 $n in a hit_prog is the person being hit (use $i or $o to reference the mob or 
 owner of the object for the person doing the hitting) 
 Only one hit_prog will trigger per hit, so, multiple hit_progs can interfere with
 each other.
death_prog
 A death_prog will trigger whenever a mobile dies, on a specified percentage chance.
 Death_progs are normally used for things like having a mob which has a ‘death rattle’,
 that ‘arises from the dead’ by loading another mob to fight on, or to load special 
 items on death.
 Syntax:
 death_prog [percentage]
 Death_prog will trigger when the mobile dies, with the specified percentage.
   Ex:
   death_prog 100
   mpecho The noble hen thrashes once more, and is still.
 When this mobile dies, players in the room will see this "death rattle" as an echo. 
 Important death_prog notes:
 death_prog triggers AFTER a mobile "dies". Consequently, death_progs which have a mob
 perform specific ‘normal’ actions (saying, emoting, wearing, moving, etc.) will not take
 effect. $n in a death_prog is the person who killed the mobile. Do not attempt to purge
 the mob, or its corpses, with a death_prog. This will only end in tears, as the mob no
 longer exists, and its corpse does not yet exist.  Do not attempt to ‘save’ a mob from
 dying through the use of mpgrant, healing magic, etc., as by the time a death_prog triggers,
 the mob is already dead. 
all_death_prog
 An all_death_prog will trigger any time a mob or pc dies in the room with the entity  
 which has the prog. All_death_progs are used for mobiles that avenge deaths which occur
 in their room, curses which take affect on death, etc.
 Syntax:
 all_death_prog [percentage]
 The all_death_prog triggers on the given percentage whenever someone dies in the same 
 room as the entity with the prog.
   Ex:
   all_death_prog 100
   mpecho With another death, the shrieking of the ghouls grows louder.
 This prog would trigger an echo whenever anyone was killed in the room with it.
 Notes on all_death_prog:
  - $n in an all_death_prog is the killer 
  - $t in an all_death_prog is the victim (i.e., who died)
 See the restriction above about mobiles already being dead by the time (all)_death_prog 
 triggers. All_death_progs will trigger on the death of the entity which has the prog.


=== PROGS SPECIFIC TO OBJECTS OR OBJECT MANIPULATION ===
wear_prog
 A wear_prog triggers on a given percentage whenever a pc or mob wears the object on which
 the prog resides. Wear_progs are used for objects which have an effect when worn (such as
 glasses that let you detect invisible things, etc.), items with a special curse, or the like.
 Syntax:
 wear_prog [percentage]
 Wear prog triggers with the given percentage when a player or mobile wears the item which
 has the prog.
   Ex:
   wear_prog 100
   mpechoat $n The dagger tingles with magical energy as you wield it.
 This wear_prog would echo, with 100%, whenever someone wears it.
 Notes about wear_prog:
  - $n in a wear_prog is the person who wears the item (the same as $o) 
  - wear_progs are only found on objects 
  - wear_progs trigger ‘right after’ the item is worn. So, players will always see the echo of
    the item being worn, then the wear_prog will trigger. 
remove_prog
 A remove_prog triggers whenever an object is removed. Remove_progs are used when a progged
 affect ends when an item is used (such as a magical sword no longer granting zeal when 
 removed), or to trigger effects which are tied to key items being removed.
 Syntax:
 remove_prog [percentage]
 Remove_prog triggers with a chance equal to the percentage whenever an item with the prog
 is removed.
   Ex:
   remove_prog 100
   mpechoat $n You sword says, ‘I trust you will not replace me with a lesser weapon.’
   mpechoaround $n $N’s sword says, ‘I trust you will not replace me with a lesser weapon.’
 This remove_prog will trigger every time you remove the object, and give you the echo above.
 (In this case, it’s probably a sentient sword).
 Notes on remove_prog
  - $n in a remove_prog is the person removing the item. 
  - remove_progs trigger "just after" an item is removed. So, you cannot use them to 
    simulate noremove objects. 
  - Be careful with remove_progs that purge an item -- there can be ill effects to purging 
    an item "just removed". 
  - remove_progs are only usable on objects 
take_prog
 A take_prog triggers when a pc or mobile takes an object, specified in the argument of 
 take_prog. Take_progs are used for treasure guardians who attack people who try to pilfer
 items, for items with a curse that triggers when taken, or even an object that shouts when
 you pick it up!
 Syntax:
 take_prog [complete name field of object]
 A take prog triggers either when an object with this name field is taken by a mob or pc in
 the room in which the prog is located. 
   Ex:
   take_prog egg yellow hen’s
   mpecho The hen squawks in horror!
 This prog, when placed on a hen, would have the mobile reacting to someone taking the item
 with the name field ‘egg yellow hen’s’. 
 Take_prog notes:
  - To have a take_prog trigger on any item at all, use "take_prog all". 
  - Take_prog triggers after the item has been taken, so it cannot be used to stop an item 
    from being picked up (but you can force the taker to drop the item in the prog).
  - If you change the name field at all, all progs linked to it will obviously cease to 
    function. 
sac_prog
 A sac_prog triggers when a given object is sacrificed. Sac_progs can be used to have items
 which anger the gods when sacrificed, or invoke their blessing. It can also be used to 
 terminate a quest which involves the destruction of an item.
 Syntax:
 sac_prog [percentage]
 Sac_prog triggers on a chance equal to percentage when the object in question is sacrificed.
   Ex:
   sac_prog 100
   mpechoat $n As you sacrifice the soulstone, a voice intones, ‘Noooooooooooooo!’
   mpechoaround $n As $N sacrifices the soulstone to the gods, a voice intones, ‘Noooooooooooo!’
 This program, placed on an object, would result in an echo (with 100% probability) when 
 the object was sacrificed.
 Notes on sac_prog:
  - $n in a sac_prog is the entity which sacrifices the object 
  - sac_progs can only occur on objects 
  - sac_progs take affect "just after" the item is destroyed. Do not attempt to purge the item,
    etc. If you need it to be ‘indestructible’, just have it load another instance of the item.


=== PROG TRIGGERS INVOLVING INTERACTION WITH MOBILES ===
speech_prog
 A speech_prog triggers whenever someone (pc or mobile) says a specific phrase in the same
 room as the prog. Speech_prog uses are basically endless, but common one includes keywords
 from quest mobs, mobs that respond to a certain greeting, or even sentient objects which have
 something to say about certain topics.
 Syntax:
 speech_prog [p] [argument]
 Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The
 "p" determines whether or not the match must be exact or simply a substring match.
   Ex:
   speech_prog p Hello
   say Hi there!
 Now, a mobile with this program would respond whenever someone said "hello" to the mob.
 Speech_prog notes:
  - A mobile can trigger itself with its own speech_prog, resulting in an infinite loop!
    So, either avoid keyword use in mobile says, or put pc checks in the body of the prog.
give_prog
 A give_prog will trigger when a mobile is given a specified item. Give_progs are often 
 used for "quest mobs" that react to specific items being given to them, or for mobs that
 require a bribe of something other than gold.
 Syntax:
 give_prog [full name string of item]
 A give_prog returns success if you give the mob the item with the specified name string.
   Ex:
   give_prog soft blue blanket
   say My blanket! I thought that dreadful nefortu had taken it!
 Placed on a mob, this prog would trigger whenever someone gave the mob a soft blue blanket.
 Notes on give_prog:
  - Give_progs can only be used on mobs 
  - In a give_prog, $n is the person who gives the object 
  - In a give_prog, $o references the object given 
  - To make a give_prog trigger on anything, use "give_prog all" 
bribe_prog
 A bribe_prog triggers when a player gives an amount in gold to a mobile. This prog can be
 used for bribable guards, ferryman ("Pay me, and I’ll take you across the river."), or even
 merchants with special items for sale.
 Syntax:
 bribe_prog [integer value of copper coins]
 A bribe_prog will trigger if you give a mobile an amount of coin greater than or equal to 
 the integer value.
   Ex:
   bribe_prog 15
   say Thankee good sir. Now I can by that crutch for my poor boy Inqui’s gimp leg.
 This prog might be placed on a beggar, who would respond when given 15 or more gold.
 Notes on bribe_prog:
  - Bribe_prog can only occur on mobs 
  - Only the first instance of bribe_prog will trigger. Thus, if you have a bribe_prog 1, then
    a bribe_prog 10, and you give the mob 11 gold, you will trigger only the first of the two. 
  - If you want a mob which responds to any amount of gold (and want to have many responses), 
    it might be best to use bribe_prog 1 + use of the goldamt() if check. This works because 
    the mobile will trigger on any giving of gold at all, and can then check his gold total in
    the body of the prog. 
hail_prog
 A hail_prog triggers whenever a player "hails" a mob, through the use of the hail command. It 
 is designed to provide a standard interface for players who wish to communicate with mobiles,
 though it currently does not see widespread use.
 Syntax:
 hail_prog
 hail_prog triggers on a mob when a player types: hail [mob name], then executes the body of the prog.
   Ex:
   hail_prog
   say Greetings to you, $N!
 This returns a greeting when a player hails the mob.
act_prog
 Act_progs are no longer supported, and deprecated with extreme prejudice. They have been replaced 
 by verb_progs and other such improvements. Do not, repeat, do not use any act_progs, as there is 
 no guarantee as to their reliability, or, indeed, even their continued presence. 


=== PROG TRIGGERS INVOKED FROM WITHIN PROGS ===
[I.e., subroutines, functions, and date fields] 
trigger_prog
 A trigger_prog is essentially a subroutine. For those unfamiliar with the term, a ‘subroutine’
 is a separate block of code from the main program body, which can be invoked as needed from 
 there. Typically, various arguments are passed to the subroutine.
 So, let’s break down the parts of a trigger_prog:
 Firstly, there is the trigger_prog itself.
 Syntax: trigger_prog [percentage]
 There is only one trigger prog per entity.
 When invoked, the trigger_prog executes the lines in its body with the given percentage.
 Now, to invoke a trigger prog, there is a command specifically suited for this purpose:
 Syntax:
 mptrigger [target]
 Mptrigger invokes the trigger_prog (which will occur on the trigger_prog percentage). 
 The [target] of an mptrigger becomes the $n of the trigger_prog.  Now, this allows us to
 have trigger_progs which do things like check the state of individual pc’s, etc. However,
 most often, we want a way to apply the subroutine to every entity in a room..
 Thus, we have one more mpcommand:
 Syntax:
 mproomcmd [command] [optional specific target, or "all"]
 mproomcmd executes the [command] once for each member of the room. 
 Now, if the command takes an argument, you can use mproomcmd to execute a command on 
 that target, once for each entity (including pcs and npcs) in the room.  The unique part
 about mproomcmd is that it allows the use of the word "all" is an argument. If "all" is 
 the argument of the command, it will be executed on each person in the room. 
 Now, this can be a little confusing, so let’s consider a test scenario: There is a room 
 with five total entities present: Jolinn, Ramc, Inqui, A hen, An ethron whore
 Let us suppose the ethron whore has the prog:
   rand_prog 100
   mproomcmd tweak
 When this prog activates, we will see:
   An ethron whore looks around for someone to tweak.
   An ethron whore looks around for someone to tweak.
   An ethron whore looks around for someone to tweak.
   An ethron whore looks around for someone to tweak.
 Notice that the command activates once for each entity in the room, excepting the mobile on
 which the prog is located. 
 Important note: An mproomcmd will trigger once for each person in the room, regardless of 
 whether or not the mobile can see said person.
 Now, let’s suppose the prog said:
   rand_prog 100
   mproomcmd tweak $r
 You would see:
   An ethron whore tweaks [random person] affectionately.
   An ethron whore tweaks [random person] affectionately.
   An ethron whore tweaks [random person] affectionately.
   An ethron whore tweaks [random person] affectionately.
 Here, "random person" is any target picked from people visible in the room. Again, we would
 see four emotes, since there are four people in the room to mproomcmd through.
 Finally, let’s suppose the prog said:
   rand_prog 100
   mproomcmd tweak all
 You would see:
   An ethron whore tweaks Jolinn affectionately.
   An ethron whore tweaks a hen affectionately.
   An ethron whore tweaks Inqui affectionately.
   An ethron whore tweaks Ramc affectionately.
 As expected, with the "all" argument, the whore attempts to tweak each person in the  
 room in term. It is of note that, unlike the previous two cases, if the whore could not
 see a given target, she would not target them. (Think of it this way: the mproomcmd is 
 still triggering for each person in the room, but it has an invalid target for people 
 the mobile can’t see, and thus does nothing).
 So, if, say, Ramc were wizi, you would see:
 An ethron whore tweaks Jolinn affectionately.
 An ethron whore tweaks a hen affectionately.
 An ethron whore tweaks Inqui affectionately.
 All right, so, now that we now how to call a trigger_prog, and we know how to make a 
 command take effect on every member of a room, we are now in a condition to:
 Execute a trigger_prog for each person currently in a room. This allows us to do 
 sophisticated things like:
  - Having a mobile that drags every non-flying person currently fighting it underground 
  - Having a teleport ring which transports an entire party when activated 
  - Having a quest reward which gives experience only to scholars in a given party 
  - All tis is possible since you can put basically an arbitrary number of if checks and 
    mpcommands into a trigger_prog, ‘off to the side’, with only one simple command to check 
   it from the main prog. (It would be impossible or very difficult to perform an if check
   on every member of the room otherwise!)
     Example:
     speech_prog p Name the evildoers in the room!
     say Very well, $N.
     mproomcmd mptrigger all
     trigger_prog 100
     if ispc($n)
       if isevil($n)
       say $N is a servant of darkness!
       point $n
       endif
     endif
  So, let’s assume we have the scenario above: 
  In the room is:
  Jolinn (LE)
  Inqui (CE)
  Ramc (NG)
  An ethron whore (G) (She has a heart of gold)
  A hen (E) (Remember Hitchcock’s "the Birds")
  Let’s suppose this prog is on the whore. Now, suppose Inqui says: 
 ‘Name the evildoers in the room!’, triggering the prog. We would see:
    An ethron whore says, ‘Jolinn is a servant of darkness!’
    An ethron whore points at Jolinn.
    An ethron whore says, ‘Inqui is a servant of darkness!’
    An ethron whore points at Jolinn.
 Notice that:
 Ramc is not mentioned, as he is not evil 
 The hen is not mentioned, as it is not a pc. 
 We’ll discuss some more uses of trigger_progs in the advanced progging sections,  
 but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.
data_prog
 A data_prog is a bit unusual, as it itself is never executed as a prog. Rather, a data_prog 
 is more a list of strings [which do not even necessarily have to be executable] stored as data
 under the heading of a prog trigger.
 The data_prog(s) of a mobile, room, or object can be read from the body of any other prog 
 trigger, in sequence. This makes data_progs ideal for things like a mobile which follows a path, 
 has a lengthy set of dialogue responses, or even a way for a mobile to conveniently have a set of 
 random activities not requiring lots of cumbersome if checks.
 So, firstly, let’s examine the structure of a data_prog.
 Syntax:
 data_prog [keyword]
 [line 1]
 [line 2]
 .
 .
 [line n]
 Now, how do we access the contents of a data_prog? Firstly, we have a command which causes the
 mobile to focus on a given data prog.
 Syntax:
 mpsetdata [keyword]
 Mpsetdata sets a mob to begin reading a particular data_prog, specified by the keyword.
 One we have a data_prog set, how do we reference the data inside it? Firstly, we can consider  
 that every entity which has data_progs has a sort of "reader", that has two settings:
  -Which data_prog is being read
  -Which line is the "current line" -- the particular line of the specific data_prog the  
   mobile is currently reading.
 Whenever a mobile mpsetdatas on a given data_prog, not only does it set the "reader" to that
 specific prog, it also sets the "current line" to the first entry in the prog.
 The variable, $d, references the "current line" of a data prog. So, let’s suppose we’ve mpsetdata,
 and now we have a data prog the prog is reading. We’re on the first line of the data prog, but how
 do we move to the NEXT line?
 Fortunately, we have an mpcommand for this: mpnextdata
 Syntax: Mpnextdata
 Mpnextdata basically says, "Take the current data_prog we’re reading, then move one line ahead". 
 If a prog is already at the end, it will advance to a null state for that data_prog, and not reference 
 a line until it is reset through the use of mpsetdata.
 This can all be confusing, so let’s consider an example:
   speech_prog p Do your happy dance
   say Very well. The dance will proceed shortly. 
   say Please note that by saying this, you have restarted the dance.
   mpsetdata dance
   rand_prog 100
   $d
   mpnextdata
   data_prog dance
   emote dances a merry jig (DC 15).
   say La la la
   hug $r
   Yell I have come to a bad end!
 Now, let’s suppose this prog is on a mob, which, for the sake of completeness, we will refer
 to as the hen.   Jolinn, the hen, and Iandir are in a room.  Jolinn says: Do your happy dance
 The following then happens:
   The hen says: Very well. The dance will proceed shortly. 
   The hen says: Please note that by saying this, you have restarted the dance.
 [The hen sets its data reader to the ‘dance’ data_prog]
 Now:
 Shortly thereafter, the rand_prog 100 will trigger. 
 At this point, the rand_prog will attempt to execute $d as a command. $d is the CURRENT line
 of the data_prog. And, since we just set the data_prog, the line is set to the FIRST one.
 So, we would see:
   The hen dances a merry jig (DC 15).
 At this point, the next line executes, which tells the prog to set its data_prog reader to
 the next line in the data_prog. 
 So, the next time the rand_prog triggers, we see:
   The hen says, ‘La la la’
 Again, the data_prog moves to the next line here.  The next rand_prog trigger, we see:
   The hen hugs [Jolinn or Iandir]
 
 The next rand_prog trigger, we see:
   The hen yells, ‘I have come to a bad end!’
 Thereafter, nothing will happen, or be said. Despite being pointed at the data_prog dance,
 it’s also at the end of the lines, and nothing further can be read.
 If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog 
 examples section.


=== PROGS THAT AFFECT OR ALTER PLAYER COMMANDS ===
verb_prog
 A verb_prog is a prog which triggers when a player enters a specific command, or command 
 and specific argument. Most importantly, the command entered by the player need not be an
 existing mud command -- it can be arbitrarily chosen by the builder in the prog.
 To consider why we need verb_progs, let’s consider an important class of things we’d like 
 to do with progs.  The following are all things we might like to see a prog respond to:
  - Pulling a lever which opens a secret door 
  - Throwing a coin in a fountain summoning a genie 
  - Reading a book cursing you 
  - A rock you can push 
  - A door which triggers a poison needle into the person who opens it
 All of these things are classic things one might see in a dungeon, or a fantasy adventure,
 but the problem is that none of the prog_triggers we’ve seen so far can emulate the effect.
 Now, there are two ways to approach this. One is, we could code specific commands or
 prog_triggers for each of the things we need. This would work, but it would take dozens of
 special cases, and every time a builder needed a new command, more coding would have to be 
 done. The second option is to have a prog_trigger which has a user_defined verb (i.e., command)
 and argument. This way, the mud can respond to arbitrary player commands that act on mobs, rooms, or objects.
 You ask for a miracle, I give you the verb_prog.
 Syntax:
 verb_prog p [verb] [argument]
 This verb_prog will trigger whenever the player executes [verb] as a command, and the [argument]
 as the input past the command. The presence of the p determines whether the [argument] must match 
 exactly, or simply be a substring of the actual command argument. 
 IMPORTANT: If the verb_prog has a p, then it will be triggered if the text given in the prog is an
 exact -prefix- of what is typed in. However, If the verb_prog has NO p, then it will be triggered
 if the text given in the prog is found anywhere -in the first word- of what is typed in.
 In short: So basically, multi-word verb_progs are useless with a p.
   Ex:
   prog add verb_prog p hug tree
   mpechoat $n Jolinn jeers at you as you hug the tree.
 If the player were to input ‘hug tree’, they would see:
   Jolinn jeers at you as you hug the tree.
 If the player were to input ‘hug tree softly’, the verb_prog would not trigger, as the
 p requires an exact match.
 Now, if the prog were:
   prog add verb_prog hug tree
   mpechoat $n Jolinn jeers at you as you hug the tree.
 Then, ‘hug tree softly’ would, in fact, trigger the prog.
 Now, there is an additional feature we would like verb_progs to have. Imagine that we have
 a tavern, populated with a very strict bouncer. Being a devout Baptist, the bouncer forbids
 dancing of all kinds. So, we can imagine a verb_prog p dance that would forbid all types 
 attempts to dance. However, let’s also suppose that if the dancer is ethron, he will allow 
 the command to go through (he can’t resist the appeal of the supple green flesh.) How do we
 allow the command through? We can’t just do the echo for the ‘dance’ emote, since the target
 of the command will vary. What we need is a command that executes a command as if the actor
 had actually performed it.
 This is provide by the mpinterpret command.
 NOTA BENE: See the warnings on mpinterpret vs. mpnextinterp below.
 Syntax:
 mpinterpret <variable referencing a pc> <argument of the command>
 mpinterpret will execute the command that triggered the verb_prog as if the pc referenced 
 by the variable had executed it, with the argument specified.
   Ex: 
   prog add verb_prog p dance
   if race($n) == ethron
   mpinterpret $n $x
   else
   say I’m sorry, but my teachings do not allow dancing.
   mpechoat $n The bouncer moves to block your sinful gyrations.
   endif
 So, if an aelin were attempt to enter the command: dance Jolinn, she would see:
   The bouncer says, ‘I’m sorry, but my teachings do not allow dancing.’
   The bouncer moves to block your sinful gyrations.
 If the an ethron lass were to attempt to enter the command: dance Jolinn, she would see:
   You grab him and dance wildly.
 This is because ‘$n’ is the ethron doing the dancing, and $x is ‘Jolinn’. So, when the prog
 reaches that line, mpinterpret <ethron lass> Jolinn is executed as ‘dance Jolinn’. As expected,
 this command allows us to execute the command which triggered the verb prog, with the argument 
 specified by the player.
 IMPORTANT: If you do not have an mpinterpret, the command which triggers a verb_prog will never
 execute. Often times, you will want to execute a command normally (such as when you’ve got a 
 verb_prog on a carry-able object, and want it to execute normally for other people) despite it
 triggering a verb_prog, for which this functionality is vital.
 MORE IMPORTANT  Mpnextinterp versus Mpinterpret

We run into problems when we have multiple verb_progs in the same room. If one of the progs uses the mpinterpret command, the other progs don't get considered at all.

Let's suppose we have a pair of boots that cast fireball whenever you take a step. The boots have a verb_prog west, along with a verb_prog for each other direction. Now we have a room with a wizi mob that has a verb_prog west, intended to prevent anyone from moving west.

boots of fire:

verb_prog west

mpcast 63 51

mpinterpret $n $x


The player standing in the room types "west". The "verb_prog west" on his boots receives his command, casts fireball, and does an "mpinterpret $n $x", which makes him step west. The other prog, which would have stopped him, is bypassed by the mpinterpret.

If the boot prog used "mpnextinterp" instead, the MUD would then check to see whether any other progs were waiting for the "west" command, and if so, pass the command to the next prog in line. If not, the command is interpreted as normal.

For this reason, most verb_progs should use mpnextinterp instead of mpinterpret $n $x.