Difference between revisions of "Prog Section 4"

From Immwiki
Jump to: navigation, search
m (→‎load_prog)
(→‎hour_prog)
 
(4 intermediate revisions by 2 users not shown)
Line 85: Line 85:
 
====tick_prog====
 
====tick_prog====
 
====hour_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.
+
: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.
 
: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.
Line 105: Line 105:
 
: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.  
 
: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.  
+
: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====
 
====time_prog====
Line 307: Line 307:
 
:    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====
 +
 +
: 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===
 
===Prog Triggers Involving Interaction with Mobiles===
Line 404: Line 449:
 
===Progs Invoked by Other Progs===
 
===Progs Invoked by Other Progs===
 
[I.e., subroutines, functions, date fields, and inception_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====
 
====trigger_prog====
Line 547: Line 618:
 
: We’ll discuss some more uses of trigger_progs in the advanced progging sections,   
 
: 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.
 
: but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.
−
 
−
: '''NOTE:''' Trigger_progs will not function if attached to a room.
 
  
 
====data_prog====
 
====data_prog====
Line 649: Line 718:
 
: If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog  
 
: If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog  
 
: examples section.
 
: examples section.
−
 
  
 
===Progs that Affect or Alter Player Commands===
 
===Progs that Affect or Alter Player Commands===

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.
Retrieved from "http://gelatinous-cube.net/neongrey/index.php?title=Prog_Section_4&oldid=2929"