Prog Section 4
From Immwiki
Revision as of 02:05, 29 April 2011 by Telelion (Talk | contribs) (trying to get these things formatted)
Prog Triggers: Comprehensive Listing
"It is by will alone I set my mind in motion. It is by the juice of Sapho that thoughts acquire speed, the lips acquire stains, stains become a warning. It is by will alone I set my mind in motion." -- Mentat Piter de Vries, Dune
PROG TRIGGERS RELATING TO MOVEMENT
entry_prog An entry_prog is a prog that triggers whenever the mobile that it is on enters a room. So, if you want a mobile that enters a room, greets everyone there, then does a merry jig, an entry_prog is what to use.
Syntax: entry_prog [percentage]
The entry prog triggers on a chance equal to the percentage value, which is an integer between 1 and 100 (inclusive).
Ex: entry_prog 100 say Hey hey!
A mobile with this program has a 100% of saying "Hey hey!" when entering a new room.
This prog trigger can also be used on objects, where it behaves in an identical manner.
Note: If a mob or object is entering the same room it is presently in (through a looped exit, etc.), the entry_prog will not trigger. Additionally, an entry_prog will only trigger on a ‘physical’ entry (as opposed to magical or progged transport).
exit_prog An exit_prog is a prog that triggers whenever someone exits the room where the mob or object is located. So, if you want a mob that says good-bye to people leaving, or a progged trap on an exit, exit_prog is the thing to use.
Syntax: exit_prog [percentage]
An exit prog will trigger whenever a player or mob exits the room, with a percentage value equal to the argument.
Ex: exit_prog 90 say Bye-bye, $N!
When someone leaves the room, the exit_prog will, 90% of the time, result in the mob saying: "Bye-bye, <Short desc of person leaving>!" (Notice that we use $N rather than $n, since we should always use the short desc in echoes.)
Note: An exit_prog triggers when a person leaves the room, but before they reach their destination. HOWEVER, it cannot be used to prevent someone from leaving the room (say, by transporting them elsewhere). At the end of the prog, the "exit" still goes through, and the player is sent to the corresponding destination.
greet_prog A greet_prog triggers whenever an entity enters the room where the greet_prog is located. Greet_progs can be used for mobiles which greet players who enter, rooms with a trap that triggers on certain classes of people entering (such as a pit trap), or even for mobiles which flee from the sight of pc’s.
Syntax: greet_prog [Percantage value (i.e., any number from 1-100)] A greet_prog triggers whenever a pc enters the room with the object/room/mob. The chance that the greet prog triggers is equal to the percentage value given as an argument.
Ex: greet_prog 50 say Hello there!
So, this mob has a 50% chance any time a pc enters the room of triggering the prog, at which point the pc will see the mob saying "Hello there!"
all_greet_prog An all_greet_prog is identical to a greet_prog, except that it triggers for all people entering the room, whether or not the person is visible. In times past, this was useful for doing ‘greet traps’, since you want the mobile with the trap prog to be able to see the player no matter what. However, with the advent of room_progs [which see everything by default], these are less necessary.
Syntax: all_greet_prog [percentage]
As greet_prog, an all_greet_prog triggers on a percantage chance.
Ex: See above for greet_prog examples.
=== PROG TRIGGERS THAT OCCUR AT SPECIFIC TIMES ===
load_prog A load_prog is a prog which triggers whenever a mobile is loaded via a reset (but not via a manual loading). It takes a percentage argument, which determines whether or not it triggers when the mob resets. Load progs are used for loading specialized objects on a mobile, determining whether quest-related mobs should load, or even for a mob that hides an object when it loads.
Syntax: load_prog [percentage]
The load prog triggers when the mobile resets. Of note, since the mobile is not "completely there" when the load_prog triggers, actions such as says or emotes will not be performed in a load_prog (use mpecho, mpechoat, etc. instead).
Ex:
load_prog 100
mpecho With a clatter of bones, a skeleton claws its way out of the cursed soil!
When placed on a mob, this echo would be visible to the room whenever it resets. So, rather than a "silent repop", we would see this echo.
rand_prog tick_prog hour_prog A rand_prog is a prog which triggers with a given percentage every pulse. (Pulses are one 'round'.). Rand_progs are often used for mobs who periodically emote actions, check for the presence of other mobs/objects in the room, or even to ‘count down’ a timer on an object or mob.
tick_progs and hour_progs are identical to rand_progs; they simply trigger less frequently. A tick_prog will trigger on the tick (every 30-60 seconds), while an hour_prog will do so every two ticks, that is, on the hour.
Syntax: rand_prog [percentage] tick_prog [percentage] hour_prog [percentage]
The rand_prog will trigger with a given percentage every pulse.
Ex: rand_prog 1 mpecho The hen clucks loudly, then pecks at the ground resolutely.
This rand_prog would occur with 1% chance, every pulse. Players in the room with the mob would see the echo periodically, giving the impression of animation on the mob’s part.
Rand prog notes: Only one rand_prog may trigger per mob/object per pulse. Therefore, if you have a rand_prog 100 followed by a rand_prog 20, the rand_prog 20 will never trigger, as rand_prog checking stops once the first is executed.
Rand_prog does not have $n, as there is no entity that ‘triggers’ a rand_prog. Using $n in a rand_prog will yield random, undesirable, or no results.
time_prog A time_prog is one which occurs at a specified hour of the day. Time_progs can be used for patrolling guards, merchants that close up shop, or even a door that’s only visible at a certain time of day.
Syntax: time_prog [hour of day]
Time progs will trigger at the specified hour of day, which is a number between 1-24, inclusive. (I.e., the times given are in "military" time.)
Ex: time_prog 4 wake mpecho The farmer yawns as he awakens. say I guess it’s time to head back to the fields.
This is a prog one might see on a farmer. Every day at 4 am, the farmer will awaken (maybe another time prog puts him to sleep), echo to the room about yawning (4 am is awfully early), then comment about what he’s going to do.
=== PROG TRIGGERS THAT OCCUR IN COMBAT, DAMAGE, OR DEATH ===
fight_prog A fight_prog is a prog which triggers on a percentage chance each round of combat. Fight_progs can be used to simulate mobs which perform special attacks in combat, shout and jeer in a fight, or even randomly teleport away from the player.
Syntax: fight_prog [percentage]
Triggers on percentage chance, per round.
Note: Fight_progs will not trigger until after the initial first round of combat. This rarely has any effect on prog decisions, but is a factor (the canonical example would be a wizinvis mob you want to unwizi in a fight -- but wizi mobs stop fighting after one round of combat, so it never triggers.)
Ex: fight_prog 5 Yell Death to mutant bears!
Every round, there would be a 5% chance that the mob would yell "Death to the mutant bears!" as a sort of battle cry.
Other fight prog notes: In a fight prog, $n is the person fighting the mob (or individual carrying the object) with the prog. Once a fight_prog has triggered, no other fight_progs will be checked for that round. I.e., if there is a fight_prog 100 first, then a fight_prog 20, the fight_prog 20 will never trigger, as the 100 will always take effect.
hitprcnt_prog A hitprcnt_prog is a combat prog which triggers when a mobile reaches a specified percentage of its health. Hitprcnt_progs are used for having a mob call guards, teleport away, or to change strategies when they reach a certain level of health.
Syntax: hitprcnt_prog [percentage]
A hitprcnt_prog will trigger whenever a mobile’s health reaches the percentage value.
Ex: hitprcnt_prog 30 say I’ll live to fight another day! mpgoto 5000
This mobile will flee when it reaches 30% health, going to the room with vnum 5000.
hitprcnt_prog notes: Hitprcnt_progs can be unreliable. If a mob "skips" being a certain percentage value, it may end up not triggering the prog! (i.e., going from 55% to 45% in one hit, while the prog triggers on 50%) Be watchful for this, and be sure to have contingencies in case this fails.
hit_prog A hit_prog triggers whenever a mobile or object is on an entity which scores a hit in combat. Hit_progs are used for special effects that occur only when a blow connects, such as a vorpal sword, a mob’s bite being poisonous, etc.
Syntax: hit_prog [percentage]
Hit_prog triggers on the specified percentage chance, whenever the mobile the prog is on or the object connects with a normal hit.
Ex: hit_prog 50 mpecho The sword of Kil’ryead glows a wicked red as it connects with the flesh of $N!
This prog, on a sword, would generate this echo 50% of the time, checked whenever the sword hit.
hit_prog notes: $n in a hit_prog is the person being hit (use $i or $o to reference the mob or owner of the object for the person doing the hitting) Only one hit_prog will trigger per hit, so, multiple hit_progs can interfere with each other.
death_prog A death_prog will trigger whenever a mobile dies, on a specified percentage chance. Death_progs are normally used for things like having a mob which has a ‘death rattle’, that ‘arises from the dead’ by loading another mob to fight on, or to load special items on death.
Syntax: death_prog [percentage]
Death_prog will trigger when the mobile dies, with the specified percentage.
Ex: death_prog 100 mpecho The noble hen thrashes once more, and is still.
When this mobile dies, players in the room will see this "death rattle" as an echo.
Important death_prog notes: death_prog triggers AFTER a mobile "dies". Consequently, death_progs which have a mob perform specific ‘normal’ actions (saying, emoting, wearing, moving, etc.) will not take effect. $n in a death_prog is the person who killed the mobile. Do not attempt to purge the mob, or its corpses, with a death_prog. This will only end in tears, as the mob no longer exists, and its corpse does not yet exist. Do not attempt to ‘save’ a mob from dying through the use of mpgrant, healing magic, etc., as by the time a death_prog triggers, the mob is already dead.
all_death_prog An all_death_prog will trigger any time a mob or pc dies in the room with the entity which has the prog. All_death_progs are used for mobiles that avenge deaths which occur in their room, curses which take affect on death, etc.
Syntax: all_death_prog [percentage]
The all_death_prog triggers on the given percentage whenever someone dies in the same room as the entity with the prog.
Ex: all_death_prog 100 mpecho With another death, the shrieking of the ghouls grows louder.
This prog would trigger an echo whenever anyone was killed in the room with it.
Notes on all_death_prog: - $n in an all_death_prog is the killer - $t in an all_death_prog is the victim (i.e., who died)
See the restriction above about mobiles already being dead by the time (all)_death_prog triggers. All_death_progs will trigger on the death of the entity which has the prog.
=== PROGS SPECIFIC TO OBJECTS OR OBJECT MANIPULATION ===
wear_prog A wear_prog triggers on a given percentage whenever a pc or mob wears the object on which the prog resides. Wear_progs are used for objects which have an effect when worn (such as glasses that let you detect invisible things, etc.), items with a special curse, or the like.
Syntax: wear_prog [percentage]
Wear prog triggers with the given percentage when a player or mobile wears the item which has the prog.
Ex: wear_prog 100 mpechoat $n The dagger tingles with magical energy as you wield it.
This wear_prog would echo, with 100%, whenever someone wears it.
Notes about wear_prog:
- $n in a wear_prog is the person who wears the item (the same as $o)
- wear_progs are only found on objects
- wear_progs trigger ‘right after’ the item is worn. So, players will always see the echo of
the item being worn, then the wear_prog will trigger.
remove_prog A remove_prog triggers whenever an object is removed. Remove_progs are used when a progged affect ends when an item is used (such as a magical sword no longer granting zeal when removed), or to trigger effects which are tied to key items being removed.
Syntax: remove_prog [percentage]
Remove_prog triggers with a chance equal to the percentage whenever an item with the prog is removed.
Ex: remove_prog 100 mpechoat $n You sword says, ‘I trust you will not replace me with a lesser weapon.’ mpechoaround $n $N’s sword says, ‘I trust you will not replace me with a lesser weapon.’
This remove_prog will trigger every time you remove the object, and give you the echo above. (In this case, it’s probably a sentient sword).
Notes on remove_prog
- $n in a remove_prog is the person removing the item.
- remove_progs trigger "just after" an item is removed. So, you cannot use them to
simulate noremove objects.
- Be careful with remove_progs that purge an item -- there can be ill effects to purging
an item "just removed".
- remove_progs are only usable on objects
take_prog A take_prog triggers when a pc or mobile takes an object, specified in the argument of take_prog. Take_progs are used for treasure guardians who attack people who try to pilfer items, for items with a curse that triggers when taken, or even an object that shouts when you pick it up!
Syntax: take_prog [complete name field of object]
A take prog triggers either when an object with this name field is taken by a mob or pc in the room in which the prog is located.
Ex: take_prog egg yellow hen’s mpecho The hen squawks in horror!
This prog, when placed on a hen, would have the mobile reacting to someone taking the item with the name field ‘egg yellow hen’s’.
Take_prog notes:
- To have a take_prog trigger on any item at all, use "take_prog all".
- Take_prog triggers after the item has been taken, so it cannot be used to stop an item
from being picked up (but you can force the taker to drop the item in the prog).
- If you change the name field at all, all progs linked to it will obviously cease to
function.
sac_prog A sac_prog triggers when a given object is sacrificed. Sac_progs can be used to have items which anger the gods when sacrificed, or invoke their blessing. It can also be used to terminate a quest which involves the destruction of an item.
Syntax: sac_prog [percentage]
Sac_prog triggers on a chance equal to percentage when the object in question is sacrificed.
Ex: sac_prog 100 mpechoat $n As you sacrifice the soulstone, a voice intones, ‘Noooooooooooooo!’ mpechoaround $n As $N sacrifices the soulstone to the gods, a voice intones, ‘Noooooooooooo!’
This program, placed on an object, would result in an echo (with 100% probability) when the object was sacrificed.
Notes on sac_prog:
- $n in a sac_prog is the entity which sacrifices the object
- sac_progs can only occur on objects
- sac_progs take affect "just after" the item is destroyed. Do not attempt to purge the item,
etc. If you need it to be ‘indestructible’, just have it load another instance of the item.
=== PROG TRIGGERS INVOLVING INTERACTION WITH MOBILES ===
speech_prog A speech_prog triggers whenever someone (pc or mobile) says a specific phrase in the same room as the prog. Speech_prog uses are basically endless, but common one includes keywords from quest mobs, mobs that respond to a certain greeting, or even sentient objects which have something to say about certain topics.
Syntax: speech_prog [p] [argument]
Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The "p" determines whether or not the match must be exact or simply a substring match.
Ex: speech_prog p Hello say Hi there!
Now, a mobile with this program would respond whenever someone said "hello" to the mob.
Speech_prog notes:
- A mobile can trigger itself with its own speech_prog, resulting in an infinite loop!
So, either avoid keyword use in mobile says, or put pc checks in the body of the prog.
give_prog A give_prog will trigger when a mobile is given a specified item. Give_progs are often used for "quest mobs" that react to specific items being given to them, or for mobs that require a bribe of something other than gold.
Syntax: give_prog [full name string of item]
A give_prog returns success if you give the mob the item with the specified name string.
Ex: give_prog soft blue blanket say My blanket! I thought that dreadful nefortu had taken it!
Placed on a mob, this prog would trigger whenever someone gave the mob a soft blue blanket.
Notes on give_prog: - Give_progs can only be used on mobs - In a give_prog, $n is the person who gives the object - In a give_prog, $o references the object given - To make a give_prog trigger on anything, use "give_prog all"
bribe_prog
A bribe_prog triggers when a player gives an amount in gold to a mobile. This prog can be
used for bribable guards, ferryman ("Pay me, and I’ll take you across the river."), or even
merchants with special items for sale.
Syntax: bribe_prog [integer value of copper coins]
A bribe_prog will trigger if you give a mobile an amount of coin greater than or equal to the integer value.
Ex: bribe_prog 15 say Thankee good sir. Now I can by that crutch for my poor boy Inqui’s gimp leg.
This prog might be placed on a beggar, who would respond when given 15 or more gold.
Notes on bribe_prog:
- Bribe_prog can only occur on mobs
- Only the first instance of bribe_prog will trigger. Thus, if you have a bribe_prog 1, then
a bribe_prog 10, and you give the mob 11 gold, you will trigger only the first of the two.
- If you want a mob which responds to any amount of gold (and want to have many responses),
it might be best to use bribe_prog 1 + use of the goldamt() if check. This works because
the mobile will trigger on any giving of gold at all, and can then check his gold total in
the body of the prog.
hail_prog A hail_prog triggers whenever a player "hails" a mob, through the use of the hail command. It is designed to provide a standard interface for players who wish to communicate with mobiles, though it currently does not see widespread use.
Syntax: hail_prog
hail_prog triggers on a mob when a player types: hail [mob name], then executes the body of the prog.
Ex: hail_prog say Greetings to you, $N!
This returns a greeting when a player hails the mob.
act_prog Act_progs are no longer supported, and deprecated with extreme prejudice. They have been replaced by verb_progs and other such improvements. Do not, repeat, do not use any act_progs, as there is no guarantee as to their reliability, or, indeed, even their continued presence.
=== PROG TRIGGERS INVOKED FROM WITHIN PROGS === [I.e., subroutines, functions, and date fields]
trigger_prog A trigger_prog is essentially a subroutine. For those unfamiliar with the term, a ‘subroutine’ is a separate block of code from the main program body, which can be invoked as needed from there. Typically, various arguments are passed to the subroutine.
So, let’s break down the parts of a trigger_prog: Firstly, there is the trigger_prog itself.
Syntax: trigger_prog [percentage] There is only one trigger prog per entity.
When invoked, the trigger_prog executes the lines in its body with the given percentage.
Now, to invoke a trigger prog, there is a command specifically suited for this purpose:
Syntax: mptrigger [target]
Mptrigger invokes the trigger_prog (which will occur on the trigger_prog percentage). The [target] of an mptrigger becomes the $n of the trigger_prog. Now, this allows us to have trigger_progs which do things like check the state of individual pc’s, etc. However, most often, we want a way to apply the subroutine to every entity in a room..
Thus, we have one more mpcommand:
Syntax: mproomcmd [command] [optional specific target, or "all"]
mproomcmd executes the [command] once for each member of the room.
Now, if the command takes an argument, you can use mproomcmd to execute a command on that target, once for each entity (including pcs and npcs) in the room. The unique part about mproomcmd is that it allows the use of the word "all" is an argument. If "all" is the argument of the command, it will be executed on each person in the room.
Now, this can be a little confusing, so let’s consider a test scenario: There is a room with five total entities present: Jolinn, Ramc, Inqui, A hen, An ethron whore
Let us suppose the ethron whore has the prog:
rand_prog 100 mproomcmd tweak
When this prog activates, we will see:
An ethron whore looks around for someone to tweak. An ethron whore looks around for someone to tweak. An ethron whore looks around for someone to tweak. An ethron whore looks around for someone to tweak.
Notice that the command activates once for each entity in the room, excepting the mobile on which the prog is located.
Important note: An mproomcmd will trigger once for each person in the room, regardless of whether or not the mobile can see said person.
Now, let’s suppose the prog said:
rand_prog 100 mproomcmd tweak $r
You would see:
An ethron whore tweaks [random person] affectionately. An ethron whore tweaks [random person] affectionately. An ethron whore tweaks [random person] affectionately. An ethron whore tweaks [random person] affectionately.
Here, "random person" is any target picked from people visible in the room. Again, we would see four emotes, since there are four people in the room to mproomcmd through.
Finally, let’s suppose the prog said:
rand_prog 100 mproomcmd tweak all
You would see:
An ethron whore tweaks Jolinn affectionately. An ethron whore tweaks a hen affectionately. An ethron whore tweaks Inqui affectionately. An ethron whore tweaks Ramc affectionately.
As expected, with the "all" argument, the whore attempts to tweak each person in the room in term. It is of note that, unlike the previous two cases, if the whore could not see a given target, she would not target them. (Think of it this way: the mproomcmd is still triggering for each person in the room, but it has an invalid target for people the mobile can’t see, and thus does nothing).
So, if, say, Ramc were wizi, you would see:
An ethron whore tweaks Jolinn affectionately. An ethron whore tweaks a hen affectionately. An ethron whore tweaks Inqui affectionately.
All right, so, now that we now how to call a trigger_prog, and we know how to make a
command take effect on every member of a room, we are now in a condition to:
Execute a trigger_prog for each person currently in a room. This allows us to do
sophisticated things like:
- Having a mobile that drags every non-flying person currently fighting it underground
- Having a teleport ring which transports an entire party when activated
- Having a quest reward which gives experience only to scholars in a given party
- All tis is possible since you can put basically an arbitrary number of if checks and
mpcommands into a trigger_prog, ‘off to the side’, with only one simple command to check
it from the main prog. (It would be impossible or very difficult to perform an if check
on every member of the room otherwise!)
Example:
speech_prog p Name the evildoers in the room!
say Very well, $N.
mproomcmd mptrigger all
trigger_prog 100
if ispc($n)
if isevil($n)
say $N is a servant of darkness!
point $n
endif
endif
So, let’s assume we have the scenario above: In the room is: Jolinn (LE) Inqui (CE) Ramc (NG) An ethron whore (G) (She has a heart of gold) A hen (E) (Remember Hitchcock’s "the Birds")
Let’s suppose this prog is on the whore. Now, suppose Inqui says: ‘Name the evildoers in the room!’, triggering the prog. We would see:
An ethron whore says, ‘Jolinn is a servant of darkness!’
An ethron whore points at Jolinn.
An ethron whore says, ‘Inqui is a servant of darkness!’
An ethron whore points at Jolinn.
Notice that: Ramc is not mentioned, as he is not evil The hen is not mentioned, as it is not a pc.
We’ll discuss some more uses of trigger_progs in the advanced progging sections, but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.
data_prog A data_prog is a bit unusual, as it itself is never executed as a prog. Rather, a data_prog is more a list of strings [which do not even necessarily have to be executable] stored as data under the heading of a prog trigger.
The data_prog(s) of a mobile, room, or object can be read from the body of any other prog trigger, in sequence. This makes data_progs ideal for things like a mobile which follows a path, has a lengthy set of dialogue responses, or even a way for a mobile to conveniently have a set of random activities not requiring lots of cumbersome if checks.
So, firstly, let’s examine the structure of a data_prog.
Syntax: data_prog [keyword] [line 1] [line 2] . . [line n]
Now, how do we access the contents of a data_prog? Firstly, we have a command which causes the mobile to focus on a given data prog.
Syntax: mpsetdata [keyword] Mpsetdata sets a mob to begin reading a particular data_prog, specified by the keyword.
One we have a data_prog set, how do we reference the data inside it? Firstly, we can consider that every entity which has data_progs has a sort of "reader", that has two settings: -Which data_prog is being read -Which line is the "current line" -- the particular line of the specific data_prog the mobile is currently reading.
Whenever a mobile mpsetdatas on a given data_prog, not only does it set the "reader" to that specific prog, it also sets the "current line" to the first entry in the prog. The variable, $d, references the "current line" of a data prog. So, let’s suppose we’ve mpsetdata, and now we have a data prog the prog is reading. We’re on the first line of the data prog, but how do we move to the NEXT line?
Fortunately, we have an mpcommand for this: mpnextdata Syntax: Mpnextdata
Mpnextdata basically says, "Take the current data_prog we’re reading, then move one line ahead". If a prog is already at the end, it will advance to a null state for that data_prog, and not reference a line until it is reset through the use of mpsetdata.
This can all be confusing, so let’s consider an example:
speech_prog p Do your happy dance say Very well. The dance will proceed shortly. say Please note that by saying this, you have restarted the dance. mpsetdata dance
rand_prog 100 $d mpnextdata
data_prog dance emote dances a merry jig (DC 15). say La la la hug $r Yell I have come to a bad end!
Now, let’s suppose this prog is on a mob, which, for the sake of completeness, we will refer to as the hen. Jolinn, the hen, and Iandir are in a room. Jolinn says: Do your happy dance The following then happens:
The hen says: Very well. The dance will proceed shortly. The hen says: Please note that by saying this, you have restarted the dance.
[The hen sets its data reader to the ‘dance’ data_prog] Now: Shortly thereafter, the rand_prog 100 will trigger. At this point, the rand_prog will attempt to execute $d as a command. $d is the CURRENT line of the data_prog. And, since we just set the data_prog, the line is set to the FIRST one. So, we would see:
The hen dances a merry jig (DC 15).
At this point, the next line executes, which tells the prog to set its data_prog reader to the next line in the data_prog.
So, the next time the rand_prog triggers, we see:
The hen says, ‘La la la’
Again, the data_prog moves to the next line here. The next rand_prog trigger, we see:
The hen hugs [Jolinn or Iandir] The next rand_prog trigger, we see:
The hen yells, ‘I have come to a bad end!’
Thereafter, nothing will happen, or be said. Despite being pointed at the data_prog dance, it’s also at the end of the lines, and nothing further can be read. If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog examples section.
=== PROGS THAT AFFECT OR ALTER PLAYER COMMANDS ===
verb_prog A verb_prog is a prog which triggers when a player enters a specific command, or command and specific argument. Most importantly, the command entered by the player need not be an existing mud command -- it can be arbitrarily chosen by the builder in the prog.
To consider why we need verb_progs, let’s consider an important class of things we’d like to do with progs. The following are all things we might like to see a prog respond to: - Pulling a lever which opens a secret door - Throwing a coin in a fountain summoning a genie - Reading a book cursing you - A rock you can push - A door which triggers a poison needle into the person who opens it
All of these things are classic things one might see in a dungeon, or a fantasy adventure, but the problem is that none of the prog_triggers we’ve seen so far can emulate the effect.
Now, there are two ways to approach this. One is, we could code specific commands or prog_triggers for each of the things we need. This would work, but it would take dozens of special cases, and every time a builder needed a new command, more coding would have to be done. The second option is to have a prog_trigger which has a user_defined verb (i.e., command) and argument. This way, the mud can respond to arbitrary player commands that act on mobs, rooms, or objects.
You ask for a miracle, I give you the verb_prog. Syntax: verb_prog p [verb] [argument]
This verb_prog will trigger whenever the player executes [verb] as a command, and the [argument] as the input past the command. The presence of the p determines whether the [argument] must match exactly, or simply be a substring of the actual command argument.
IMPORTANT: If the verb_prog has a p, then it will be triggered if the text given in the prog is an exact -prefix- of what is typed in. However, If the verb_prog has NO p, then it will be triggered if the text given in the prog is found anywhere -in the first word- of what is typed in.
In short: So basically, multi-word verb_progs are useless with a p.
Ex: prog add verb_prog p hug tree mpechoat $n Jolinn jeers at you as you hug the tree.
If the player were to input ‘hug tree’, they would see:
Jolinn jeers at you as you hug the tree.
If the player were to input ‘hug tree softly’, the verb_prog would not trigger, as the p requires an exact match.
Now, if the prog were:
prog add verb_prog hug tree mpechoat $n Jolinn jeers at you as you hug the tree.
Then, ‘hug tree softly’ would, in fact, trigger the prog.
Now, there is an additional feature we would like verb_progs to have. Imagine that we have a tavern, populated with a very strict bouncer. Being a devout Baptist, the bouncer forbids dancing of all kinds. So, we can imagine a verb_prog p dance that would forbid all types attempts to dance. However, let’s also suppose that if the dancer is ethron, he will allow the command to go through (he can’t resist the appeal of the supple green flesh.) How do we allow the command through? We can’t just do the echo for the ‘dance’ emote, since the target of the command will vary. What we need is a command that executes a command as if the actor had actually performed it.
This is provide by the mpinterpret command. NOTA BENE: See the warnings on mpinterpret vs. mpnextinterp below. Syntax: mpinterpret <variable referencing a pc> <argument of the command>
mpinterpret will execute the command that triggered the verb_prog as if the pc referenced by the variable had executed it, with the argument specified.
Ex: prog add verb_prog p dance if race($n) == ethron mpinterpret $n $x else say I’m sorry, but my teachings do not allow dancing. mpechoat $n The bouncer moves to block your sinful gyrations. endif
So, if an aelin were attempt to enter the command: dance Jolinn, she would see:
The bouncer says, ‘I’m sorry, but my teachings do not allow dancing.’ The bouncer moves to block your sinful gyrations.
If the an ethron lass were to attempt to enter the command: dance Jolinn, she would see:
You grab him and dance wildly.
This is because ‘$n’ is the ethron doing the dancing, and $x is ‘Jolinn’. So, when the prog reaches that line, mpinterpret <ethron lass> Jolinn is executed as ‘dance Jolinn’. As expected, this command allows us to execute the command which triggered the verb prog, with the argument specified by the player.
IMPORTANT: If you do not have an mpinterpret, the command which triggers a verb_prog will never execute. Often times, you will want to execute a command normally (such as when you’ve got a verb_prog on a carry-able object, and want it to execute normally for other people) despite it triggering a verb_prog, for which this functionality is vital.
MORE IMPORTANT Mpnextinterp versus Mpinterpret
We run into problems when we have multiple verb_progs in the same room. If one of the progs uses the mpinterpret command, the other progs don't get considered at all.
Let's suppose we have a pair of boots that cast fireball whenever you take a step. The boots have a verb_prog west, along with a verb_prog for each other direction. Now we have a room with a wizi mob that has a verb_prog west, intended to prevent anyone from moving west.
boots of fire:
verb_prog west
mpcast 63 51
mpinterpret $n $x
The player standing in the room types "west". The "verb_prog west" on his boots receives his command, casts fireball, and does an "mpinterpret $n $x", which makes him step west. The other prog, which would have stopped him, is bypassed by the mpinterpret.
If the boot prog used "mpnextinterp" instead, the MUD would then check to see whether any other progs were waiting for the "west" command, and if so, pass the command to the next prog in line. If not, the command is interpreted as normal.
For this reason, most verb_progs should use mpnextinterp instead of mpinterpret $n $x.
