Difference between revisions of "Prog Section 4"

From Immwiki
Jump to: navigation, search
(hour_prog)
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Prog Triggers: Comprehensive Listing =
+
== Prog Triggers: Comprehensive Listing ==
 +
 
 
  <i>"It is by will alone I set my mind in motion. It is by the juice of Sapho</i>  
 
  <i>"It is by will alone I set my mind in motion. It is by the juice of Sapho</i>  
 
  <i>that thoughts acquire speed, the lips acquire stains, stains become a warning.</i>
 
  <i>that thoughts acquire speed, the lips acquire stains, stains become a warning.</i>
 
  <i>It is by will alone I set my mind in motion."</i> -- Mentat Piter de Vries, Dune
 
  <i>It is by will alone I set my mind in motion."</i> -- Mentat Piter de Vries, Dune
  
  <b>PROG TRIGGERS RELATING TO MOVEMENT:</b>
+
   
 +
===Triggers Relating to Movement===
  
<b>entry_prog</b>
+
====entry_prog====
  An entry_prog is a prog that triggers whenever the mobile that it is on enters a
+
: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.
  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:
+
Syntax:
  entry_prog [percentage]
+
entry_prog [percentage]
  
  The entry prog triggers on a chance equal to the percentage value, which is an
+
:The entry prog triggers on a chance equal to the percentage value, which is an integer between 1 and 100 (inclusive).
  integer between 1 and 100 (inclusive).
+
  
    Ex:
+
Ex:
    entry_prog 100
+
entry_prog 100
    say Hey hey!
+
say Hey hey!
  
  A mobile with this program has a 100% of saying "Hey hey!" when entering a new  
+
:A mobile with this program has a 100% of saying "Hey hey!" when entering a new room.
  room.  
+
:This prog trigger can also be used on objects, where it behaves in an identical manner.
  
  This prog trigger can also be used on objects, where it behaves in an identical
+
: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).
  manner.
+
  
  Note: If a mob or object is entering the same room it is presently in (through a
+
====exit_prog====
  looped exit, etc.), the entry_prog will not trigger. Additionally, an entry_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.
  will only trigger on a ‘physical’ entry (as opposed to magical or progged  
+
  transport).
+
  
  <b>exit_prog</b>
+
  Syntax:
  An exit_prog is a prog that triggers whenever someone exits the room where the
+
exit_prog [percentage]
  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.
+
  
<b>Syntax:</b>
+
:An exit prog will trigger whenever a player or mob exits the room, with a percentage value equal to the argument.
  exit_prog [percentage]
+
  
  An exit prog will trigger whenever a player or mob exits the room, with a
+
Ex:
  percentage value equal to the argument.
+
exit_prog 90
 +
say Bye-bye, $N!
  
    Ex:
+
: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.)
    exit_prog 90
+
    say Bye-bye, $N!
+
  
  When someone leaves the room, the exit_prog will, 90% of the time, result in
+
: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
  the mob saying: "Bye-bye, <Short desc of person leaving>!" (Notice that we use
+
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.
  $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
+
====greet_prog====
  reach their destination. HOWEVER, it cannot be used to prevent someone from
+
: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.
  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.
+
  
  <b>greet_prog</b>
+
  Syntax: greet_prog [Percantage value (i.e., any number from 1-100)]
  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.  
  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:
+
Ex:
    greet_prog 50
+
greet_prog 50
    say Hello there!
+
say Hello there!
  
  So, this mob has a 50% chance any time a pc enters the room of triggering the
+
: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!"
  prog, at which point the pc will see the mob saying "Hello there!"
+
  
  
<b>all_greet_prog</b>
+
====all_greet_prog====
  An all_greet_prog is identical to a greet_prog, except that it triggers for  
+
: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.
  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]
+
Syntax: all_greet_prog [percentage]
  
  As greet_prog, an all_greet_prog triggers on a percantage chance.
+
:As greet_prog, an all_greet_prog triggers on a percentage chance.
  
  Ex: See above for greet_prog examples.
+
Ex: See above for greet_prog examples.
  
  
<b>PROG TRIGGERS THAT OCCUR AT SPECIFIC TIMES:</b>
+
===Triggers Occurring at Specific Times===
  
<b>load_prog</b>
+
====load_prog====
  A load_prog is a prog which triggers whenever a mobile is loaded via a reset  
+
:A load_prog is a prog which triggers whenever a mobile is loaded via a reset (but not via a manual mpmloading -- use 'edit room reset' instead to test). 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.
  (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:  
+
Syntax:  
  load_prog [percentage]
+
load_prog [percentage]
  
  The load prog triggers when the mobile resets. Of note, since the mobile is not
+
: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).
  "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:
+
Ex:
    load_prog 100
+
load_prog 100
    mpecho With a clatter of bones, a skeleton claws its way out of the cursed soil!
+
  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.
+
: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.
  So, rather than a "silent repop", we would see this echo.
+
  
<b>rand_prog</b>
+
====rand_prog====
<b>tick_prog</b>
+
====tick_prog====
<b>hour_prog</b>
+
====hour_prog====
  A rand_prog is a prog which triggers with a given percentage every pulse. (Pulses
+
: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. Rand_progs fire roughly once every 4 seconds.
  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  
+
: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.
  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:  
+
Syntax:  
  rand_prog [percentage]
+
rand_prog [percentage]
  tick_prog [percentage]
+
tick_prog [percentage]
  hour_prog [percentage]
+
hour_prog [percentage]
  
  The rand_prog will trigger with a given percentage every pulse.
+
:The rand_prog will trigger with a given percentage every pulse.
  
    Ex:
+
Ex:
    rand_prog 1
+
rand_prog 1
    mpecho The hen clucks loudly, then pecks at the ground resolutely.
+
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
+
: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.
  the mob would see the echo periodically, giving the impression of animation on  
+
  the mob’s part.
+
  
  Rand prog notes:
+
:'''Rand prog notes:'''
  Only one rand_prog may trigger per mob/object per pulse. Therefore, if you have a  
+
: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 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.  
+
: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.
  Using $n in a rand_prog will yield random, undesirable, or no results.  
+
  
<b>time_prog</b>
+
====time_prog====
  A time_prog is one which occurs at a specified hour of the day. Time_progs can be  
+
: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.
  used for patrolling guards, merchants that close up shop, or even a door that’s only  
+
  visible at a certain time of day.
+
  
  Syntax:
+
Syntax:
  time_prog [hour of day]
+
time_prog [hour of day]
  
  Time progs will trigger at the specified hour of day, which is a number between 1-24,
+
: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.)
  inclusive. (I.e., the times given are in "military" time.)
+
  
    Ex:
+
Ex:
    time_prog 4
+
time_prog 4
    wake
+
wake
    mpecho The farmer yawns as he awakens.
+
mpecho The farmer yawns as he awakens.
    say I guess it’s time to head back to the fields.
+
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
+
: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.
  (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.
+
  
  
<b>PROG TRIGGERS THAT OCCUR IN COMBAT, DAMAGE, OR DEATH</b>
+
===Triggers Activated by Combat, Damage, or Death===
  
<b>fight_prog</b>
+
====fight_prog====
  A fight_prog is a prog which triggers on a percentage chance each round of combat.  
+
: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.
  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:
+
Syntax:
  fight_prog [percentage]
+
fight_prog [percentage]
  
  Triggers on percentage chance, per round.
+
:Triggers on percentage chance, per round.
  
  Note: Fight_progs will not trigger until after the initial first round of combat.
+
: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.)
  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:  
+
Ex:  
    fight_prog 5
+
fight_prog 5
    Yell Death to mutant bears!
+
Yell Death to mutant bears!
  
  Every round, there would be a 5% chance that the mob would yell "Death to the  
+
:Every round, there would be a 5% chance that the mob would yell "Death to the mutant bears!" as a sort of battle cry.
  mutant bears!" as a sort of battle cry.
+
  
  Other fight prog notes:
+
:Other fight prog notes:
  In a fight prog, $n is the person fighting the mob (or individual carrying the
+
: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.
  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.
+
  
<b>hitprcnt_prog</b>
+
====hitprcnt_prog====
  A hitprcnt_prog is a combat prog which triggers when a mobile reaches a specified  
+
: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.
  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:
+
Syntax:
  hitprcnt_prog [percentage]
+
hitprcnt_prog [percentage]
  
  A hitprcnt_prog will trigger whenever a mobile’s health reaches the percentage value.
+
:A hitprcnt_prog will trigger whenever a mobile’s health reaches the percentage value.
  
    Ex:
+
Ex:
    hitprcnt_prog 30
+
hitprcnt_prog 30
    say I’ll live to fight another day!
+
say I’ll live to fight another day!
    mpgoto 5000
+
mpgoto 5000
  
  This mobile will flee when it reaches 30% health, going to the room with vnum 5000.
+
:This mobile will flee when it reaches 30% health, going to the room with vnum 5000.
  
  hitprcnt_prog notes:
+
:hitprcnt_prog notes:
  Hitprcnt_progs can be unreliable. If a mob "skips" being a certain percentage value,  
+
: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.  
  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.  
+
  
<b>hit_prog</b>
+
====hit_prog====
  A hit_prog triggers whenever a mobile or object is on an entity which scores a hit in  
+
: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.
  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:
+
Syntax:
  hit_prog [percentage]
+
hit_prog [percentage]
  
  Hit_prog triggers on the specified percentage chance, whenever the mobile the prog is  
+
:Hit_prog triggers on the specified percentage chance, whenever the mobile the prog is on or the object connects with a normal hit.
  on or the object connects with a normal hit.
+
  
    Ex:
+
Ex:
    hit_prog 50
+
hit_prog 50
    mpecho The sword of Kil’ryead glows a wicked red as it connects with the flesh of $N!
+
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
+
:This prog, on a sword, would generate this echo 50% of the time, checked whenever the sword hit.
  the sword hit.
+
  
  hit_prog notes:
+
:hit_prog notes:
  $n in a hit_prog is the person being hit (use $i or $o to reference the mob or  
+
:$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.
  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.
+
  
<b>death_prog</b>
+
====death_prog====
  A death_prog will trigger whenever a mobile dies, on a specified percentage chance.
+
: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.
  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:
+
Syntax:
  death_prog [percentage]
+
death_prog [percentage]
  
  Death_prog will trigger when the mobile dies, with the specified percentage.
+
:Death_prog will trigger when the mobile dies, with the specified percentage.
  
    Ex:
+
Ex:
    death_prog 100
+
death_prog 100
    mpecho The noble hen thrashes once more, and is still.
+
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.  
+
:When this mobile dies, players in the room will see this "death rattle" as an echo.  
  
  Important death_prog notes:
+
:Important death_prog notes:
  death_prog triggers AFTER a mobile "dies". Consequently, death_progs which have a mob
+
: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.  
  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.  
+
  
<b>all_death_prog</b>
+
====all_death_prog====
  An all_death_prog will trigger any time a mob or pc dies in the room with the entity
+
: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.
  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:
+
Syntax:
  all_death_prog [percentage]
+
all_death_prog [percentage]
  
  The all_death_prog triggers on the given percentage whenever someone dies in the same  
+
:The all_death_prog triggers on the given percentage whenever someone dies in the same room as the entity with the prog.
  room as the entity with the prog.
+
  
    Ex:
+
Ex:
    all_death_prog 100
+
all_death_prog 100
    mpecho With another death, the shrieking of the ghouls grows louder.
+
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.
+
:This prog would trigger an echo whenever anyone was killed in the room with it.
  
  Notes on all_death_prog:
+
:Notes on all_death_prog:
  - $n in an all_death_prog is the killer  
+
: - $n in an all_death_prog is the killer  
  - $t in an all_death_prog is the victim (i.e., who died)
+
: - $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  
+
: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.
  triggers. All_death_progs will trigger on the death of the entity which has the prog.
+
  
  
<b>PROGS SPECIFIC TO OBJECTS OR OBJECT MANIPULATION</b>
+
=== Progs Specific to Objects or Object Manipulation ===
  
<b>wear_prog</b>
+
====wear_prog====
  A wear_prog triggers on a given percentage whenever a pc or mob wears the object on which
+
: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.
  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:
+
Syntax:
  wear_prog [percentage]
+
wear_prog [percentage]
  
  Wear prog triggers with the given percentage when a player or mobile wears the item which
+
:Wear prog triggers with the given percentage when a player or mobile wears the item which has the prog.
  has the prog.
+
  
    Ex:
+
Ex:
    wear_prog 100
+
wear_prog 100
    mpechoat $n The dagger tingles with magical energy as you wield it.
+
mpechoat $n The dagger tingles with magical energy as you wield it.
  
  This wear_prog would echo, with 100%, whenever someone wears it.
+
:This wear_prog would echo, with 100%, whenever someone wears it.
  
  Notes about wear_prog:
+
:Notes about wear_prog:
  - $n in a wear_prog is the person who wears the item (the same as $o)  
+
: - $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 are only found on objects  
  - wear_progs trigger ‘right after’ the item is worn. So, players will always see the echo of
+
: - 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.  
    the item being worn, then the wear_prog will trigger.  
+
  
<b>remove_prog</b>
+
====remove_prog====
  A remove_prog triggers whenever an object is removed. Remove_progs are used when a progged
+
: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.
  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:
+
Syntax:
  remove_prog [percentage]
+
remove_prog [percentage]
  
  Remove_prog triggers with a chance equal to the percentage whenever an item with the prog
+
:Remove_prog triggers with a chance equal to the percentage whenever an item with the prog is removed.
  is removed.
+
  
    Ex:
+
Ex:
    remove_prog 100
+
remove_prog 100
    mpechoat $n You sword says, ‘I trust you will not replace me with a lesser weapon.’
+
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.’
+
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.
+
: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).
  (In this case, it’s probably a sentient sword).
+
  
  Notes on remove_prog
+
: Notes on remove_prog
  - $n in a remove_prog is the person removing the item.  
+
- $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  
+
- remove_progs trigger "just after" an item is removed. So, you cannot use them to  
    simulate noremove objects.  
+
:    simulate noremove objects.  
  - Be careful with remove_progs that purge an item -- there can be ill effects to purging  
+
- Be careful with remove_progs that purge an item -- there can be ill effects to purging  
    an item "just removed".  
+
:    an item "just removed".  
  - remove_progs are only usable on objects  
+
- remove_progs are only usable on objects  
  
<b>take_prog</b>
+
====take_prog====
  A take_prog triggers when a pc or mobile takes an object, specified in the argument of  
+
: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!
  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:
+
Syntax:
  take_prog [complete name field of object]
+
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
+
: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.  
  the room in which the prog is located.  
+
  
    Ex:
+
Ex:
    take_prog egg yellow hen’s
+
take_prog egg yellow hen’s
    mpecho The hen squawks in horror!
+
mpecho The hen squawks in horror!
  
  This prog, when placed on a hen, would have the mobile reacting to someone taking the item
+
: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’.  
  with the name field ‘egg yellow hen’s’.  
+
  
  Take_prog notes:
+
: Take_prog notes:
  - To have a take_prog trigger on any item at all, use "take_prog all".  
+
- 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  
+
- 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).
+
:    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  
+
- If you change the name field at all, all progs linked to it will obviously cease to  
    function.  
+
:    function.  
  
<b>sac_prog</b>
+
====sac_prog====
  A sac_prog triggers when a given object is sacrificed. Sac_progs can be used to have items
+
: 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  
+
: 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.
+
: terminate a quest which involves the destruction of an item.
  
  Syntax:
+
Syntax:
  sac_prog [percentage]
+
sac_prog [percentage]
  
  Sac_prog triggers on a chance equal to percentage when the object in question is sacrificed.
+
: Sac_prog triggers on a chance equal to percentage when the object in question is sacrificed.
  
    Ex:
+
  Ex:
    sac_prog 100
+
  sac_prog 100
    mpechoat $n As you sacrifice the soulstone, a voice intones, ‘Noooooooooooooo!’
+
  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!’
+
  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  
+
: This program, placed on an object, would result in an echo (with 100% probability) when  
  the object was sacrificed.
+
: the object was sacrificed.
  
  Notes on sac_prog:
+
: Notes on sac_prog:
  - $n in a sac_prog is the entity which sacrifices the object  
+
- $n in a sac_prog is the entity which sacrifices the object  
  - sac_progs can only occur on objects  
+
- sac_progs can only occur on objects  
  - sac_progs take affect "just after" the item is destroyed. Do not attempt to purge the item,
+
- 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.
+
:    etc. If you need it to be ‘indestructible’, just have it load another instance of the item.
  
 +
====eat_prog====
 +
====drink_prog====
  
<b>PROG TRIGGERS INVOLVING INTERACTION WITH MOBILES</b>
+
: An eat_prog is only useful on food, and fires when the object is eaten.
 +
: A drink_prog is used on drinkcontainers or on fountains
 +
: Both are generally used to provide echoes describing the flavour of the item, but can also be used for other effects, such as a fountain that blesses you when you drink from it.
 +
: Well-used eat_progs and drink_progs are key to ensuring players don't just eat a hundred waybread.
  
  <b>speech_prog</b>
+
  Syntax:
  A speech_prog triggers whenever someone (pc or mobile) says a specific phrase in the same
+
eat_prog [percentage]
  room as the prog. Speech_prog uses are basically endless, but common one includes keywords
+
drink_prog [percentage]
  from quest mobs, mobs that respond to a certain greeting, or even sentient objects which have
+
  something to say about certain topics.
+
  
  Syntax:
+
: eat_prog and drink_prog trigger on a chance equal to percentage when the item in question is eaten or drunk from.
  speech_prog [p] [argument]
+
  
  Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The
+
Ex:
  "p" determines whether or not the match must be exact or simply a substring match.
+
>eat_prog 100
 +
mpechoat $n The taenosil meat adds a delicate taste to the garlicky tomato sauce, but is somehow not overwhelmed, accenting the texture of the firm strands of pasta.
  
    Ex:
+
: This program, placed on an object, would cause it to taste like spaghetti with delicious taenosil ragu.
    speech_prog p Hello
+
    say Hi there!
+
  
  Now, a mobile with this program would respond whenever someone said "hello" to the mob.
+
Ex:
 +
>drink_prog 100
 +
if objval2() == 2
 +
    mpechoat $n The wine has strong flavours of berries and herbs, with a surprising but pleasant earthy backnote. The finish is marvlously spicy.
 +
endif
 +
if objval2() == 22
 +
    mpechoat $n The strong liqueur has a complex, herbal flavour. The combination is beyond compare, even though it is near to impossible to  discern the individual herbs in the mixture.
 +
endif
 +
if objval2() == 20
 +
    mpechoat $n The sweet, crisp mead has only hints of the taste of honey, and has a smooth, flowery finish.
 +
endif
 +
if objval2() == 18
 +
    mpechoat $n The faint scent of apples tickles your nose as you drink, and the finish has hints of both pear and citrus fruit.
 +
endif
 +
if objval2() == 19
 +
    mpechoat $n The sweet, effervescent wine has an immediate hint of strawberry to the taste, rounding out with raspberries, and other, more exotic fruits.
 +
endif
  
  Speech_prog notes:
+
: This program, placed on an object, will cause any number of wines within to have delicious flavour.
  - 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.
+
  
<b>give_prog</b>
+
: Notes on eat_prog and drink_prog:
  A give_prog will trigger when a mobile is given a specified item. Give_progs are often
+
:  - As with a sac_prog, eat_progs (and drink_progs if the container is set to not be refillable) occur after the item is consumed.
  used for "quest mobs" that react to specific items being given to them, or for mobs that
+
:  - When applying a drink_prog to a drinkcontainer, if you ever have v4 (refillable) set to 'yes', you should make sure any echoes either apply to all liquids (such as a waterskin making things taste stale and leathery) or that you check the identity of the liquid it contains (using if objval2() and the list of liquids in the oedit documentation). This will ensure you do not have water that tastes like wine.
  require a bribe of something other than gold.
+
:
 +
:    You do not need to do this with fountains, because the liquid within never changes from what you set it to, and if a drinkcontainer is nonrefillable, it will be discarded once it is empty so there is less concern of it changing here as well. This is a good thing to do in general to cut down on item clutter, anyway.
  
  Syntax:
+
===Prog Triggers Involving Interaction with Mobiles===
  give_prog [full name string of item]
+
  
  A give_prog returns success if you give the mob the item with the specified name string.
+
====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.
  
    Ex:
+
Syntax:
    give_prog soft blue blanket
+
speech_prog [p] [argument]
    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.
+
: 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.
  
  Notes on give_prog:
+
  Ex:
   - Give_progs can only be used on mobs
+
   speech_prog p Hello
  - In a give_prog, $n is the person who gives the object
+
   say Hi there!
  - In a give_prog, $o references the object given
+
   - To make a give_prog trigger on anything, use "give_prog all"
+
  
<b>bribe_prog</b>
+
: Now, a mobile with this program would respond whenever someone said "hello" to the mob.
  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:
+
: Speech_prog notes:
  bribe_prog [integer value of copper coins]
+
:  - 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.
  
  A bribe_prog will trigger if you give a mobile an amount of coin greater than or equal to  
+
====give_prog====
  the integer value.
+
: 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.
  
    Ex:
+
Syntax:
    bribe_prog 15
+
give_prog [full name string of item]
    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.
+
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!
  
  Notes on bribe_prog:
+
: Placed on a mob, this prog would trigger whenever someone gave the mob a soft blue blanket.
  - 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.  
+
  
  <b>hail_prog</b>
+
: Notes on give_prog:
  A hail_prog triggers whenever a player "hails" a mob, through the use of the hail command. It
+
: - Give_progs can only be used on mobs
  is designed to provide a standard interface for players who wish to communicate with mobiles,
+
:  - In a give_prog, $n is the person who gives the object
  though it currently does not see widespread use.
+
:  - In a give_prog, $o references the object given
 +
:  - To make a give_prog trigger on anything, use "give_prog all"
  
  Syntax:
+
====bribe_prog====
  hail_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.
  
  hail_prog triggers on a mob when a player types: hail [mob name], then executes the body of the prog.
+
Syntax:
 +
bribe_prog [integer value of copper coins]
  
    Ex:
+
: A bribe_prog will trigger if you give a mobile an amount of coin greater than or equal to
    hail_prog
+
: the integer value.
    say Greetings to you, $N!
+
  
  This returns a greeting when a player hails the mob.
+
  Ex:
 +
  bribe_prog 15
 +
  say Thankee good sir. Now I can by that crutch for my poor boy Inqui’s gimp leg.
  
<b>act_prog</b>
+
: This prog might be placed on a beggar, who would respond when given 15 or more gold.
  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.  
+
  
 +
: 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.
  
<b>PROG TRIGGERS INVOKED FROM WITHIN PROGS</b>
+
====hail_prog====
[I.e., subroutines, functions, and date fields]
+
: 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.
  
  <b>trigger_prog</b>
+
  Syntax:
  A trigger_prog is essentially a subroutine. For those unfamiliar with the term, a ‘subroutine’
+
hail_prog
  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:
+
: hail_prog triggers on a mob when a player types: hail [mob name], then executes the body of the prog.
  Firstly, there is the trigger_prog itself.
+
  
  Syntax: trigger_prog [percentage]
+
  Ex:
  There is only one trigger prog per entity.
+
  hail_prog
 +
  say Greetings to you, $N!
  
  When invoked, the trigger_prog executes the lines in its body with the given percentage.
+
: This returns a greeting when a player hails the mob.
  
  Now, to invoke a trigger prog, there is a command specifically suited for this purpose:
+
====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.
  
  Syntax:
 
  mptrigger [target]
 
  
  Mptrigger invokes the trigger_prog (which will occur on the trigger_prog percentage).
+
===Progs Invoked by Other Progs===
  The [target] of an mptrigger becomes the $n of the trigger_prog. Now, this allows us to
+
[I.e., subroutines, functions, date fields, and inception_progs]
  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:
+
====sub_prog====
 +
: A sub_prog defines a subroutine. For those unfamiliar with the term, read the trigger_prog section
 +
: below. Sub_progs were added many years after trigger progs, to provide the same functionality,
 +
: but more generally. One of the biggest differences is that sub_progs are named, and thus
 +
: a given entity (mob, obj, room) can have an arbitrary number of them. To invoke a sub_prog, use
 +
: the mpcallsub command.
  
  Syntax:
+
>sub_prog do_stuff
  mproomcmd [command] [optional specific target, or "all"]
+
mpecho I'm in a subroutine!
  
  mproomcmd executes the [command] once for each member of the room.
+
>verb_prog p test
 +
mpcallsub do_stuff
  
  Now, if the command takes an argument, you can use mproomcmd to execute a command on
+
>speech_prog testing
  that target, once for each entity (including pcs and npcs) in the room. The unique part
+
  mpcallsub do_stuff
  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
+
: Note that like mptrigger, mpcallsub can supply a target, which will become the $n variable of the
  with five total entities present: Jolinn, Ramc, Inqui, A hen, An ethron whore
+
: subroutine. If the target is not specified, $n will not be defined for that subroutine.
  
  Let us suppose the ethron whore has the prog:
+
>verb_prog p othertest
 +
mpcallsub do_stuff $n
  
    rand_prog 100
+
: Note that $r is carried over into the subroutine, so that it will be consistent with the calling prog.
    mproomcmd tweak
+
: Be careful with sub_prog as you would with verb_progs, lest you cause infinite recursion (as when the
 +
: sub_prog calls itself -- this can be valid if handled correctly, but be careful!)
  
  When this prog activates, we will see:
+
====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.
  
    An ethron whore looks around for someone to tweak.
+
: So, let’s break down the parts of a trigger_prog:
    An ethron whore looks around for someone to tweak.
+
: Firstly, there is the trigger_prog itself.
    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
+
Syntax: trigger_prog [percentage]
  which the prog is located.
+
  
  Important note: An mproomcmd will trigger once for each person in the room, regardless of
+
: There is only one trigger prog per entity.
  whether or not the mobile can see said person.
+
: When invoked, the trigger_prog executes the lines in its body with the given percentage.
  
  Now, let’s suppose the prog said:
+
: Now, to invoke a trigger prog, there is a command specifically suited for this purpose:
  
    rand_prog 100
+
Syntax:
    mproomcmd tweak $r
+
mptrigger [target]
  
  You would see:
+
: 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..
  
    An ethron whore tweaks [random person] affectionately.
+
: Thus, we have one more mpcommand:
    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
+
Syntax:
  see four emotes, since there are four people in the room to mproomcmd through.
+
mproomcmd [command] [optional specific target, or "all"]
  
  Finally, let’s suppose the prog said:
+
: mproomcmd executes the [command] once for each member of the room.
  
    rand_prog 100
+
: Now, if the command takes an argument, you can use mproomcmd to execute a command on
    mproomcmd tweak all
+
: 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.
  
  You would see:
+
: 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
  
    An ethron whore tweaks Jolinn affectionately.
+
: Let us suppose the ethron whore has the prog:
    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 
+
  rand_prog 100
  room in term. It is of note that, unlike the previous two cases, if the whore could not
+
  mproomcmd tweak
  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:
+
: When this prog activates, we will see:
  
  An ethron whore tweaks Jolinn affectionately.
+
  An ethron whore looks around for someone to tweak.
  An ethron whore tweaks a hen affectionately.
+
  An ethron whore looks around for someone to tweak.
  An ethron whore tweaks Inqui affectionately.
+
  An ethron whore looks around for someone to tweak.
 +
  An ethron whore looks around for someone to tweak.
  
  All right, so, now that we now how to call a trigger_prog, and we know how to make a
+
: Notice that the command activates once for each entity in the room, excepting the mobile on
  command take effect on every member of a room, we are now in a condition to:
+
: which the prog is located.  
  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:
+
: Important note: An mproomcmd will trigger once for each person in the room, regardless of
      speech_prog p Name the evildoers in the room!
+
: whether or not the mobile can see said person.
      say Very well, $N.
+
      mproomcmd mptrigger all
+
  
      trigger_prog 100
+
: Now, let’s suppose the prog said:
      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:
+
   rand_prog 100
   In the room is:
+
   mproomcmd tweak $r
  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:  
+
: You would see:
  ‘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 tweaks [random person] affectionately.
    An ethron whore points at Jolinn.
+
  An ethron whore tweaks [random person] affectionately.
    An ethron whore says, ‘Inqui is a servant of darkness!’
+
  An ethron whore tweaks [random person] affectionately.
    An ethron whore points at Jolinn.
+
  An ethron whore tweaks [random person] affectionately.
  
  Notice that:
+
: Here, "random person" is any target picked from people visible in the room. Again, we would
  Ramc is not mentioned, as he is not evil
+
: see four emotes, since there are four people in the room to mproomcmd through.
  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, 
+
: Finally, let’s suppose the prog said:
  but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.
+
  
<b>data_prog</b>
+
  rand_prog 100
  A data_prog is a bit unusual, as it itself is never executed as a prog. Rather, a data_prog
+
  mproomcmd tweak all
  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
+
: You would see:
  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.
+
  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.
  
  Syntax:
+
: As expected, with the "all" argument, the whore attempts to tweak each person in the 
  data_prog [keyword]
+
: room in term. It is of note that, unlike the previous two cases, if the whore could not
  [line 1]
+
: see a given target, she would not target them. (Think of it this way: the mproomcmd is
  [line 2]
+
: 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).
  .
+
  [line n]
+
  
  Now, how do we access the contents of a data_prog? Firstly, we have a command which causes the
+
: So, if, say, Ramc were wizi, you would see:
  mobile to focus on a given data prog.
+
  
  Syntax:
+
An ethron whore tweaks Jolinn affectionately.
  mpsetdata [keyword]
+
An ethron whore tweaks a hen affectionately.
  Mpsetdata sets a mob to begin reading a particular data_prog, specified by the keyword.
+
An ethron whore tweaks Inqui affectionately.
  
  One we have a data_prog set, how do we reference the data inside it? Firstly, we can consider 
+
: All right, so, now that we now how to call a trigger_prog, and we know how to make a
  that every entity which has data_progs has a sort of "reader", that has two settings:
+
: command take effect on every member of a room, we are now in a condition to:
  -Which data_prog is being read
+
: Execute a trigger_prog for each person currently in a room. This allows us to do
  -Which line is the "current line" -- the particular line of the specific data_prog the 
+
: sophisticated things like:
    mobile is currently reading.
+
- 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!)
  
  Whenever a mobile mpsetdatas on a given data_prog, not only does it set the "reader" to that
+
    Example:
  specific prog, it also sets the "current line" to the first entry in the prog.
+
    speech_prog p Name the evildoers in the room!
  The variable, $d, references the "current line" of a data prog. So, let’s suppose we’ve mpsetdata,
+
    say Very well, $N.
  and now we have a data prog the prog is reading. We’re on the first line of the data prog, but how
+
    mproomcmd mptrigger all
  do we move to the NEXT line?
+
  
  Fortunately, we have an mpcommand for this: mpnextdata
+
    trigger_prog 100
  Syntax: Mpnextdata
+
    if ispc($n)
 +
      if isevil($n)
 +
      say $N is a servant of darkness!
 +
      point $n
 +
      endif
 +
    endif
  
  Mpnextdata basically says, "Take the current data_prog we’re reading, then move one line ahead".
+
:  So, let’s assume we have the scenario above:
  If a prog is already at the end, it will advance to a null state for that data_prog, and not reference
+
:  In the room is:
  a line until it is reset through the use of mpsetdata.
+
:  Jolinn (LE)
 +
:  Inqui (CE)
 +
:  Ramc (NG)
 +
:  An ethron whore (G) (She has a heart of gold)
 +
:  A hen (E) (Remember Hitchcock’s "the Birds")
  
  This can all be confusing, so let’s consider an example:
+
:  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:
  
     speech_prog p Do your happy dance
+
     An ethron whore says, ‘Jolinn is a servant of darkness!’
     say Very well. The dance will proceed shortly.  
+
     An ethron whore points at Jolinn.
     say Please note that by saying this, you have restarted the dance.
+
     An ethron whore says, ‘Inqui is a servant of darkness!’
     mpsetdata dance
+
     An ethron whore points at Jolinn.
  
    rand_prog 100
+
: Notice that:
    $d
+
: Ramc is not mentioned, as he is not evil
    mpnextdata
+
: The hen is not mentioned, as it is not a pc.
  
    data_prog dance
+
: We’ll discuss some more uses of trigger_progs in the advanced progging sections, 
    emote dances a merry jig (DC 15).
+
: but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.
    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
+
====data_prog====
  to as the hen.   Jolinn, the hen, and Iandir are in a room.  Jolinn says: Do your happy dance
+
: A data_prog is a bit unusual, as it itself is never executed as a prog. Rather, a data_prog
  The following then happens:
+
: 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 hen says: Very well. The dance will proceed shortly.  
+
: The data_prog(s) of a mobile, room, or object can be read from the body of any other prog
    The hen says: Please note that by saying this, you have restarted the dance.
+
: 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.
  
  [The hen sets its data reader to the ‘dance’ data_prog]
+
: So, firstly, let’s examine the structure of a 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).
+
Syntax:
 +
data_prog [keyword]
 +
[line 1]
 +
[line 2]
 +
.
 +
.
 +
[line n]
  
  At this point, the next line executes, which tells the prog to set its data_prog reader to
+
: Now, how do we access the contents of a data_prog? Firstly, we have a command which causes the
  the next line in the data_prog.  
+
: mobile to focus on a given data prog.
  
  So, the next time the rand_prog triggers, we see:
+
Syntax:
 +
mpsetdata [keyword]
 +
Mpsetdata sets a mob to begin reading a particular data_prog, specified by the keyword.
  
    The hen says, ‘La la la’
+
: 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.
  
  Again, the data_prog moves to the next line here. The next rand_prog trigger, we see:
+
: 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?
  
    The hen hugs [Jolinn or Iandir]
+
: Fortunately, we have an mpcommand for this: mpnextdata
 
+
  The next rand_prog trigger, we see:
+
  
    The hen yells, ‘I have come to a bad end!’
+
Syntax: Mpnextdata
  
  Thereafter, nothing will happen, or be said. Despite being pointed at the data_prog dance,
+
: Mpnextdata basically says, "Take the current data_prog we’re reading, then move one line ahead".
  it’s also at the end of the lines, and nothing further can be read.
+
: If a prog is already at the end, it will advance to a null state for that data_prog, and not reference
  If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog
+
: a line until it is reset through the use of mpsetdata.
  examples section.
+
  
 +
: This can all be confusing, so let’s consider an example:
  
<b>PROGS THAT AFFECT OR ALTER PLAYER COMMANDS:</b>
+
  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
  
<b>verb_prog</b>
+
  rand_prog 100
  A verb_prog is a prog which triggers when a player enters a specific command, or command
+
  $d
  and specific argument. Most importantly, the command entered by the player need not be an
+
  mpnextdata
  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
+
   data_prog dance
  to do with progs.  The following are all things we might like to see a prog respond to:
+
   emote dances a merry jig (DC 15).
   - Pulling a lever which opens a secret door
+
   say La la la
   - Throwing a coin in a fountain summoning a genie
+
   hug $r
   - Reading a book cursing you
+
   Yell I have come to a bad end!
   - 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,
+
: Now, let’s suppose this prog is on a mob, which, for the sake of completeness, we will refer
  but the problem is that none of the prog_triggers we’ve seen so far can emulate the effect.
+
: to as the hen.  Jolinn, the hen, and Iandir are in a room. Jolinn says: Do your happy dance
 +
: The following then happens:
  
  Now, there are two ways to approach this. One is, we could code specific commands or
+
  The hen says: Very well. The dance will proceed shortly.  
  prog_triggers for each of the things we need. This would work, but it would take dozens of
+
  The hen says: Please note that by saying this, you have restarted the dance.
  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.
+
: [The hen sets its data reader to the ‘dance’ data_prog]
  Syntax:
+
: Now:
  verb_prog p [verb] [argument]
+
: 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:
  
  This verb_prog will trigger whenever the player executes [verb] as a command, and the [argument]
+
  The hen dances a merry jig (DC 15).
  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
+
: At this point, the next line executes, which tells the prog to set its data_prog reader to
  exact -prefix- of what is typed in. However, If the verb_prog has NO p, then it will be triggered
+
: the next line in the data_prog.  
  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.
+
: So, the next time the rand_prog triggers, we see:
  
    Ex:
+
  The hen says, ‘La la la’
    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:
+
: Again, the data_prog moves to the next line here.  The next rand_prog trigger, we see:
  
    Jolinn jeers at you as you hug the tree.
+
  The hen hugs [Jolinn or Iandir]
 +
 
 +
: The next rand_prog trigger, we see:
  
  If the player were to input ‘hug tree softly’, the verb_prog would not trigger, as the
+
  The hen yells, ‘I have come to a bad end!’
  p requires an exact match.
+
  
  Now, if the prog were:
+
: 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.
  
    prog add verb_prog hug tree
+
===Progs that Affect or Alter Player Commands===
    mpechoat $n Jolinn jeers at you as you hug the tree.
+
  
  Then, ‘hug tree softly’ would, in fact, trigger the prog.
+
====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.
  
  Now, there is an additional feature we would like verb_progs to have. Imagine that we have
+
: To consider why we need verb_progs, let’s consider an important class of things we’d like  
  a tavern, populated with a very strict bouncer. Being a devout Baptist, the bouncer forbids
+
: to do with progs. The following are all things we might like to see a prog respond to:
  dancing of all kinds. So, we can imagine a verb_prog p dance that would forbid all types
+
:  - Pulling a lever which opens a secret door
  attempts to dance. However, let’s also suppose that if the dancer is ethron, he will allow
+
:  - Throwing a coin in a fountain summoning a genie
  the command to go through (he can’t resist the appeal of the supple green flesh.) How do we
+
:  - Reading a book cursing you
  allow the command through? We can’t just do the echo for the ‘dance’ emote, since the target
+
:  - A rock you can push
  of the command will vary. What we need is a command that executes a command as if the actor
+
:  - A door which triggers a poison needle into the person who opens it
  had actually performed it.
+
  
  This is provide by the <b>mpinterpret</b> command.
+
: All of these things are classic things one might see in a dungeon, or a fantasy adventure,
  <b>NOTA BENE: See the warnings on mpinterpret vs. mpnextinterp below.</b>
+
: but the problem is that none of the prog_triggers we’ve seen so far can emulate the effect.
  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
+
: Now, there are two ways to approach this. One is, we could code specific commands or
  by the variable had executed it, with the argument specified.
+
: 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.
  
    Ex:  
+
: You ask for a miracle, I give you the verb_prog.
    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:
+
Syntax:
 +
verb_prog p [verb] [argument]
  
    The bouncer says, ‘I’m sorry, but my teachings do not allow dancing.’
+
: This verb_prog will trigger whenever the player executes [verb] as a command, and the [argument]
    The bouncer moves to block your sinful gyrations.
+
: 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.  
  
  If the an ethron lass were to attempt to enter the command: dance Jolinn, she would see:
+
: '''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.
  
    You grab him and dance wildly.
+
: So basically, multi-word verb_progs are useless with a p.
  
  This is because ‘$n’ is the ethron doing the dancing, and $x is ‘Jolinn’. So, when the prog
+
  Ex:
  reaches that line, mpinterpret <ethron lass> Jolinn is executed as ‘dance Jolinn’. As expected,
+
  prog add verb_prog p hug tree
  this command allows us to execute the command which triggered the verb prog, with the argument
+
  mpechoat $n Jolinn jeers at you as you hug the tree.
  specified by the player.
+
  
  IMPORTANT: If you do not have an mpinterpret, the command which triggers a verb_prog will never
+
: If the player were to input ‘hug tree’, they would see:
  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.
+
  
  <b>MORE IMPORTANT</b>  Mpnextinterp versus Mpinterpret
+
  Jolinn jeers at you as you hug the tree.
  
We run into problems when we have multiple verb_progs in the same room. If  
+
: If the player were to input ‘hug tree softly’, the verb_prog would not trigger, as the
one of the progs uses the mpinterpret command, the other progs don't get
+
: p requires an exact match.
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
+
: Now, if the prog were:
  
mpcast 63 51
+
  prog add verb_prog hug tree
 +
  mpechoat $n Jolinn jeers at you as you hug the tree.
  
mpinterpret $n $x
+
: 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
+
: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",
+
: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
+
:which makes him step west. The other prog, which would have stopped him, is
bypassed by the mpinterpret.
+
:bypassed by the mpinterpret.
  
If the boot prog used "mpnextinterp" instead, the MUD would then check to see
+
: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
+
: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
+
:the command to the next prog in line. If not, the command is interpreted as
normal.
+
:normal.
  
For this reason, most verb_progs should use mpnextinterp instead of  
+
:For this reason, most verb_progs should use mpnextinterp instead of  
mpinterpret $n $x.
+
:mpinterpret $n $x.
  
 
[[category:Leviticus]]
 
[[category:Leviticus]]

Latest revision as of 20:50, 5 March 2016

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


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 percentage chance.
Ex: See above for greet_prog examples.


Triggers Occurring 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 mpmloading -- use 'edit room reset' instead to test). 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. Rand_progs fire roughly once every 4 seconds.
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.


Triggers Activated by 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.

eat_prog

drink_prog

An eat_prog is only useful on food, and fires when the object is eaten.
A drink_prog is used on drinkcontainers or on fountains
Both are generally used to provide echoes describing the flavour of the item, but can also be used for other effects, such as a fountain that blesses you when you drink from it.
Well-used eat_progs and drink_progs are key to ensuring players don't just eat a hundred waybread.
Syntax: 
eat_prog [percentage]
drink_prog [percentage]
eat_prog and drink_prog trigger on a chance equal to percentage when the item in question is eaten or drunk from.
Ex:
>eat_prog 100
mpechoat $n The taenosil meat adds a delicate taste to the garlicky tomato sauce, but is somehow not overwhelmed, accenting the texture of the firm strands of pasta.
This program, placed on an object, would cause it to taste like spaghetti with delicious taenosil ragu.
Ex:
>drink_prog 100
if objval2() == 2
    mpechoat $n The wine has strong flavours of berries and herbs, with a surprising but pleasant earthy backnote. The finish is marvlously spicy.
endif
if objval2() == 22
    mpechoat $n The strong liqueur has a complex, herbal flavour. The combination is beyond compare, even though it is near to impossible to  discern the individual herbs in the mixture.
endif
if objval2() == 20
    mpechoat $n The sweet, crisp mead has only hints of the taste of honey, and has a smooth, flowery finish.
endif
if objval2() == 18
    mpechoat $n The faint scent of apples tickles your nose as you drink, and the finish has hints of both pear and citrus fruit.
endif
if objval2() == 19
    mpechoat $n The sweet, effervescent wine has an immediate hint of strawberry to the taste, rounding out with raspberries, and other, more exotic fruits.
endif
This program, placed on an object, will cause any number of wines within to have delicious flavour.
Notes on eat_prog and drink_prog:
- As with a sac_prog, eat_progs (and drink_progs if the container is set to not be refillable) occur after the item is consumed.
- When applying a drink_prog to a drinkcontainer, if you ever have v4 (refillable) set to 'yes', you should make sure any echoes either apply to all liquids (such as a waterskin making things taste stale and leathery) or that you check the identity of the liquid it contains (using if objval2() and the list of liquids in the oedit documentation). This will ensure you do not have water that tastes like wine.
You do not need to do this with fountains, because the liquid within never changes from what you set it to, and if a drinkcontainer is nonrefillable, it will be discarded once it is empty so there is less concern of it changing here as well. This is a good thing to do in general to cut down on item clutter, anyway.

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.


Progs Invoked by Other Progs

[I.e., subroutines, functions, date fields, and inception_progs]

sub_prog

A sub_prog defines a subroutine. For those unfamiliar with the term, read the trigger_prog section
below. Sub_progs were added many years after trigger progs, to provide the same functionality,
but more generally. One of the biggest differences is that sub_progs are named, and thus
a given entity (mob, obj, room) can have an arbitrary number of them. To invoke a sub_prog, use
the mpcallsub command.
>sub_prog do_stuff
mpecho I'm in a subroutine!
>verb_prog p test
mpcallsub do_stuff
>speech_prog testing
mpcallsub do_stuff
Note that like mptrigger, mpcallsub can supply a target, which will become the $n variable of the
subroutine. If the target is not specified, $n will not be defined for that subroutine.
>verb_prog p othertest
mpcallsub do_stuff $n
Note that $r is carried over into the subroutine, so that it will be consistent with the calling prog.
Be careful with sub_prog as you would with verb_progs, lest you cause infinite recursion (as when the
sub_prog calls itself -- this can be valid if handled correctly, but be careful!)

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.
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.