Difference between revisions of "Prog Section 4"

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

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

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

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

  Syntax:

: eat_prog and drink_prog trigger on a chance equal to percentage when the item in question is eaten or drunk from.

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.

    mpechoat $n The wine has strong flavours of berries and herbs, with a surprising but pleasant earthy backnote. The finish is marvlously spicy.

    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.

    mpechoat $n The sweet, effervescent wine has an immediate hint of strawberry to the taste, rounding out with raspberries, and other, more exotic fruits.

: This program, placed on an object, will cause any number of wines within to have delicious flavour.

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

: 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

: something to say about certain topics.

Syntax:

: "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:

:    So, either avoid keyword use in mobile says, or put pc checks in the body of the 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:

A give_prog returns success if you give the mob the item with the specified name string.

: Placed on a mob, this prog would trigger whenever someone gave the mob a soft blue blanket.

: - 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"

: A bribe_prog triggers when a player gives an amount in gold to a mobile. This prog can be

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

  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.

====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,

  Syntax:

: hail_prog triggers on a mob when a player types: hail [mob name], then executes the body of the prog.

  Ex:

: This returns a greeting when a player hails the mob.

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

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

: A sub_prog defines a subroutine. For those unfamiliar with the term, read the trigger_prog section

: but more generally. One of the biggest differences is that sub_progs are named, and thus

: the mpcallsub command.

  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.

: 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

: Firstly, there is the trigger_prog itself.

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

: Mptrigger invokes the trigger_prog (which will occur on the trigger_prog percentage).

mproomcmd [command] [optional specific target, or "all"]

: mproomcmd executes the [command] once for each member of the room.

: about mproomcmd is that it allows the use of the word "all" is an argument. If "all" is

: Now, this can be a little confusing, so let’s consider a test scenario: There is a room

: Let us suppose the ethron whore has the prog:

  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

   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:

  An ethron whore tweaks a hen 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

: So, if, say, Ramc were wizi, you would see:

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:

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

    speech_prog p Name the evildoers in the room!

    say Very well, $N.

:  So, let’s assume we have the scenario above:

:  In the room is:

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

: but for now, just be aware of what a trigger_prog does, and be mindful of the possibilities.

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

.

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

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 

: 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

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

   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 hen says: Very well. The dance will proceed shortly.  

  The hen says: Please note that by saying this, you have restarted the dance.

: 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

  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:

: Again, the data_prog moves to the next line here.  The next rand_prog trigger, we see:

  The hen hugs [Jolinn or Iandir]

  The hen yells, ‘I have come to a bad end!’

: If that’s confusing, it’s fine -- we’ll be returning to data_progs in the advanced prog  

: examples section.

: 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 door which triggers a poison needle into the person who opens it

: but the problem is that none of the prog_triggers we’ve seen so far can emulate the effect.

: 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

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

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

  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:

: If the player were to input ‘hug tree softly’, the verb_prog would not trigger, as the

: p requires an exact match.