Mprog Guide Written By Xzylvador From Aarchon Mud
MPROGS

TABLE OF CONTENTS

    The Basic Idea
    About This Version
    Mprog creation Syntax
    Linking MOB programs
    Trigger Types
    Variables
    Operators
    Control Flow Syntax
    If_checks in Control Flow
    New Commands of Interest
    Regarding CPU Slowdown
    Loading Mobiles and Objects
    Miscellaneous Information
    --------------------------
    Quick Reference Sheet
    Examples

-----------------------------The Basic Idea---------------------------------

Ever wonder why most MUDs either seem dead or overcrowded? The answer
is probably partially due to the fact that the mobiles never do anything
but wait to be slaughtered.  Unless someone has gone to great lengths
and added many special procedures, most mobiles have no idea you are in
the room with them and rarely listen to what you say. The typical Midgaard
mayor wanders happily along even when the populace pokes him, waves his
City Key about, unlocks his gates, or frenchs his secretary, etc. So a way to
give the mobiles a bit more spirit would be neat. Enter the MOB programs.

TRIGGERS AND SCRIPTS

The backbone of the MOB programs shall be called triggers from this
point on.  Essentially, they are procedure calls placed in sneaky places in
the mud code which provide the context for what is going on around the
mobile.  So, if something happens in the mobile's room and a trigger is
activated, then a list of commands is sent to the interpreter in the
mobile's name, thus making her/it/him do an appropriate something.

VARIABLES

Since knowing the appropriate response for every mobile to every
possible trigger is not easy, this command list shouldn’t be a rigid script,
but needs to be somehow unique for the mobile and the situation.  However, in
order to know the situation, a mobile needs to know more about the trigger
than that it just happened. So, we have to include some sort of variables
as well to set the context appropriately.

MOBPROGRAMS VS. SPEC_PROCS

As most implementors know, most area creators are not versed in
coding, but usually have great ideas. Therefore, whatever system is used needs
to be quite simple. This is not to demean creators in anyway. Simply, it is
useless to have a powerful system, if the only person able to write anything
is someone who finds C coding in general to be exciting and non frustrating.
If that is going to be the case, then stick to the special procedures, since
there is no bound to what a complex special procedure can accomplish. Yet,
from experience working on several MUDs, most admins and implementors prefer
not to be writing one shot spec_procs to satisfy the needs of their creators.

Thus, the basic idea: let mobiles react to a myriad of mud events/situations 
by having them perform a list of commands which can be tailored to the moment 
through a simple and un-intimidating scheme usable by any creator.

---------------------------About This Version-------------------------------

I started writing this “manual” while editing Newt’s mprog manual. Since I do wish to show my respect to his efforts, and Natasha’s efforts, I will keep this part:
    My implementation of MOB programs owes a lot to the original MOB program
code by Natasha. However, having heard reports about instability of the code
supplied, and because the code seemed unnecessarily complex to me, I decided
to rewrite the MOB program driver. Admittedly, I have dropped out several
features that were present in the original version, such as reacting to
several triggers at once and string comparison in if_checks. On the other
hand, the MOB program code has been simplified and made more stable (there
are no memory leaks), and several new if_checks and MOB commands have been
added. The system of linking MOB programs to mobiles has been changed to allow
procedure-like calls.
    This version is an adaptation of my earlier MOB program system I
created for Imperium Gothique MUD. The IG system has object and room programs
as well, but I chose to omit them from this version.
    -- Newt

This mprog manual was written for Aarchon Mud. I felt the need to write a new mprog guide since the code on Aarchon has been heavily modified, and we use OLC to create mprogs, not the standard ROM this guide was written for.
    - Xzylvador
----------------------------Mprog creation Syntax-------------------------------

Mprogs are created with OLC, so basically, the same way rooms, objects, mobs or anything else is created. Simply start with ‘MPEDIT CREATE <vnum>’.
You’ll enter a description editor, similar to the ones you edit rooms with.
Typing ‘CODE’ will put you in the editor itself, where you enter the code of your mprogs.
Typing ‘@’ will put you back in mpedit.
Typing ‘DONE’ in mpedit will put you back in the normal game.

--------------------------Linking MOB programs--------------------------------

After writing a program, you will have to link it to a mob to make it do something. Mprogs always are triggered with an event. To add an mprog to a mob, you first enter MEDIT and start editing the mob. 
To add the mprog to a mob, type ‘ADDMP <MPROG_VNUM> <TRIGGER> <ARGUMENT>’.

Explanations:
The MPROG_VNUM is the vnum you used in MPEDIT.
The TRIGGER is one of the events that will start the mprog.
The ARGUMENT is the argument the TRIGGER needs, this can be many things, depending on the type of trigger.

Example:
“addmp 1000 death 50”

This example will make the mob start mprog 1000 when it dies. The 50 is an argument to the trigger, in this case a percentile chance for it to trigger. In this case, when the mob dies, it has 50% chance to trigger mprog 1000.

Also note that one mprog can be used on different mobs, with different triggers. Where one mob uses mprog 1000 when it dies, another mob could use mprog 1000 when someone enters the room.

-----------------------------Trigger Types----------------------------------

In the above example, we used the DEATH trigger, there are many other triggers, all listed here, with an explanation. Small examples on how to add them and what they would do are added, but you can find better examples at the end of this guide.

ACT
Keyword    : 'act'
Argument: string

Explanation: The argument is a phrase, a text string. The trigger is activated
whenever the phrase is contained in the    act() message. It will trigger on anything that happens in the room and matches the string pattern you added. It can be used for a lot of things. Do note that when adding it and you want to trigger on a line instead of one word, you have to place the string between quotation marks. Also note that emotes will NOT trigger this.
Example: Addmp 1000 act ‘sits down.’ This will trigger when someone sits down in the room.

SPEECH
Keyword : 'speech'
Argument: string

Explanation: A speech trigger is only triggered when someone in the room says something. It’s not case sensitive (meaning ‘HeY, HoW ARE You’ is the same as ‘hey, how are you’). Like in ACT triggers, the SPEECH trigger also needs to be put in quotation marks if you want it to trigger on more words.
Example: Addmp 1000 speech ‘can I enter please?’. This triggers when a player asks ‘can I enter please?’ in the room the mob is in.

RANDOM
Keyword : 'random'
Argument: number

Explanation: The argument is a number between 0 and 99 inclusive.
A random trigger randomly triggers every 3 seconds (every fighting round). It can be used for a lot of things, making a janitor clean, making some shopkeepers yell about their products… RANDOM triggers only trigger when there is a player in the area, if you want it to trigger always, you have to set the mob act to update_always.

GREET and GRALL (greet all)
Keyword : 'greet'
Argument: number

Keyword : 'grall'
Argument: number

Explanation: Both GREET and GRALL have a percentile chance as an argument, like RANDOM. They are both triggered when someone enters the room. The difference is that a GREET trigger only triggers when the mob actually sees the person enter, so a sneaking person wouldn’t be greeted, and if the mob can’t see invis, it won’t greet invis persons neither. GRALL always triggers, even if the mob can’t see the person.
Example: “Addmp 1000 grall 75” Has a 75% chance to trigger when someone enters the room, even if  the mob can’t see the person.

ENTRY
Keyword : 'entry'
Argument: number

Explanation: The argument, again, is a percentile chance.
ENTRY triggers are triggered when the mob enters a room. It can be used to wave at everyone in the room the mob walks in, or to attack everyone.
Example: “Addmp 1000 entry 100” This will ALWAYS trigger the mprog (100% chance) when the mob enters a room.

EXIT/ EXALL (exit all)
Keyword : 'exit'
Argument: number

Keyword : 'exall'
Argument: number

Explanation: Argument is the exit number (0:north 1:east 2:south 3:west 4:up 5:down 6:northeast 7:southeast 8:southwest 9:northwest)
EXIT/EXALL is triggered when someone LEAVES the room. EXIT will only trigger when the mob sees the person leaving (sneak or invis persons can just pass). EXALL will always trigger, even if the mob can’t see the person leaving.
One problem EXIT triggers give, is that the movement of the player is always blocked. If a player triggers an exit trigger, even if the mob just wants to say bye, the player won’t move. You will have to use “mob transfer” or “mob gtransfer” to move the player.
Example: “Addmp 1000 exit 0” If you put this on a guard, the guard will stop anyone going north, unless they sneak past him or they go invis.

GIVE
Keyword : 'give'
Argument: string or object vnum

Explanation: The argument is either the vnum of an object, “all” (making it trigger no matter what the player gives the mob) or some words. Some caution is required, since if you give ‘long sword’ as argument, it compares to see if ONE of the words matches with the given item. So ‘long sword’ will trigger if a person gives “a long bow” or “a plastic sword”. Object vnums are usually used on grall triggers. The mprog will trigger when the player gives a matching object to the mob. Money doesn’t work with give triggers, you need a bribe trigger for that. Examples:
    “Addmp 1000 give 1234” triggers when the player gives the mob the object with vnum 1234.
    “Addmp 1000 give all” always triggers, no matter what object the player gives.

BRIBE
Keyword : 'bribe'
Argument: number

Explanation: The argument is any positive amount of silver the mob needs to trigger the mprog. Mobs treat 1 gold as 100 silver.
If too much money is given, the mprog will still trigger like normal. If too little money is given, the mob will just keep the money without triggering the mprog.
Example: “Addmp 1000 bribe 10000” will trigger then the player gives 10000 silver to the mob, or when he gives 100 gold.

KILL
Keyword : 'kill'
Argument: number

Explanation: The argument is a percentile chance to trigger the mprog. The KILL trigger is triggered only ONCE in the BEGINNING of a fight. When a player types “kill <mob>” or uses an offensive spell to attack the mob, the mob will start the mprog. This can be used for a quick spellup, to make the mob run away, or to summon some guards.
Example: “Addmp 1000 kill 95” has a 95% chance to trigger the mprog when a player attacks the mob.

FIGHT
Keyword : 'fight'
Argument: number

Explanation: The argument is again a percentile chance to trigger the mprog. Every fighting round, the mob will check the percentile chance, if the roll is right, the mprog will trigger. This can be used to make the mob cast spells or use skills.
Example: “Addmp 1000 fight 50” Every round, there is a 50% chance the mob triggers the mprog, and start casting some spells, or taunts his enemy.

HPCNT (HIT POINT PERCENTAGE)
Keyword : 'hpcnt'
Argument: number

Explanation: Again, the argument here is a percentage. But not a percentage that sets the chance of triggering the mprog. The argument tells the mob how low his hitpoints have to be in a fight to trigger the mprog. Look at the bottom of this chapter to see how you can make a mob perform different actions at different hit point percentages. HPCNT is checked every fighting round. It can be used to make a mob flee, yell for help, heal itself, etc…
Example: “Addmp 1000 hpcnt 25” will make the mob trigger mprog 1000 when he is at 20% of his health.

DEATH
Keyword : 'death'
Argument: number

Explanation: The argument is again a percentage to check if the mprog triggers or not. When the mob dies, the percentage will be checked, if the roll is less then the percentage, the mprog will trigger.
DEATH mprogs trigger BEFORE the mob is dead and before a corpse gets created, so a mob can quickly goto another room to die, without being looted or anyone seeing it die. It can also destroy its inventory (see MOB JUNK). See a death trigger as a mob’s last breath or final gasp, it can be pretty cruel if you want it to be. A mob can’t heal or restore itself though, it did die. To prevent the death, it’ll have to load another version of itself and disappear.

DELAY
Keyword : 'delay'
Argument: number

NOTE:      The argument is a percentage chance. This trigger activates when the delay of a mobile (set with the MOB DELAY command) expires. This trigger can be used to create staged mobile behaviour, for example, a guardian could see a player entering a room, give a warning and activate a delay. If the player is still present when the delay expires, the guard would attack the player. (See also MOB REMEMBER). A mobile can have several delay triggers, but every time the delay timer expires, all the triggers are checked and the first successful one executed.
Example: “Addmp 1000 delay 100” if the mob delay expires, the delay mprog will always trigger. (A better example of delay can be find at the end of this guide.)

SURRENDER
Keyword : 'surrender'
Argument: number

Explanation: The argument is a percentage showing the chance of the mprog triggering. Surrender is triggered when a player surrenders while fighting the mob. The fight will automatically start when the player surrenders. If you want the mob to just laugh at the player for his weakness, and continue fighting, you’ll have to put that in the mprog. If a mob doesn’t have a SURRENDER trigger, or the percentile check failed, the fight just goes on.
Example: “Addmp 1000 surr 75” there’s a 75% chance the mob accepts a players surrender.

DEFEAT
Keyword: ‘defeat’
Argument: number

Explanation: The argument, surprise surprise, is again a percentile chance.
DEFEAT is triggered when a player dies in the same room the mob is in, the mob doesn’t have to be the one killing the player to trigger the mprog. A defeat mprog will add a death in the players pfile, but it will not show any info on any channel. Also, the player doesn’t get put back at recall when a defeat mprog triggers, but stays in the room he/she/it died in.
Example: “Addmp 1000 defeat 101” would keep everyone who dies in the room there, and always trigger the mprog.

SOCIAL
Keyword: ‘social’
Argument: social

Explanation: The argument is one of the socials on the mud. To trigger a social mprog, you have to target the mobile with the social. Just typing kiss for example won’t do anything, but ‘kiss guard’ will trigger the mprog. Also, the social doesn’t show when it triggers an mprog. So ‘flip switch’ will not show something like “You flip a switch over your shoulder”, but it will show what the mprogs shows.
Example: “Addmp 1000 social kiss” will trigger the mob if you try to kiss it.

TRY
Keyword: ‘try’
Argument: string

Explanation: TRY socials can be used for everything a player does that you can’t trigger with socials or act. TRY triggers when a players tries something in the room that matches the pattern. If the player is standing in front of a tree for example, he can type ‘try to climb tree’. If there’s a TRY trigger in the room with ‘climb’ or ‘climb tree’ as argument, the mprog will start.
Example: “Addmp 1000 try to dig” could make the player dig a hole and escape if he has a shovel.

DRBOMB (DROP BOMB)
Keyword: ‘drbomb’
Argument: number

Explanation: The argument again is a percentile chance of triggering. When a person drops a bomb in the room, the percentile roll is checked.
Example: “Addmp 1000 drbomb 100” would make everyone drop to the ground or run away screaming.

EXBOMB (EXPLODE BOMB)
Keyword: ‘exbomb’
Argument: number

Explanation: The argument (once again) is a percentile chance of triggering. When a bomb explodes in the room, the mprog will trigger.

RESET
Keyword: ‘reset’
Argument: number

Explanation: Argument is a percentile check again. Will trigger when the area repops.

Although usually the order the mprogs get placed on a mob doesn’t matter, in some cases it does matter very much.
If you have 2 triggers of the same type, the mob will always take the first one that triggers, and forget about the other ones.
So, suppose I have a mob and I want it to do different things when I give it 50 silver, 100 silver or 150 silver, the other will be important then, because if I give 150 silver, and the 100 or 50 silver triggers trigger first, the 150 will never trigger.
Typing ‘show’ or just pressing enter in medit will show you the order, it will look something like this:

THIS IS WRONG!
MOBPrograms for [1000]:        Doing this will always trigger the 50 silver
 Number Vnum Trigger Phrase    mprog, and never the others.
 ------ ---- ------- ------    Giving the mob 150 gold also means he got 50
[    0] 1000   BRIBE 50        silver, so he’ll run that one, and forget about
[    1] 1001   BRIBE 100       the other triggers.
[    2] 1002   BRIBE 150       

The right order would be:

 Number Vnum Trigger Phrase    
 ------ ---- ------- ------    
[    0] 1000   BRIBE 150       Now, if the mob is given 150 silver, he’ll take 
[    1] 1001   BRIBE 100       the first mprog, and function right.
[    2] 1002   BRIBE 50        Giving it 100 silver, would never trigger the 150
                               then take the 100 mprog and forget the third
                               bribe trigger.

------------------------------Variables------------------------------------

To make things a bit more personal, and make mobs address you and eachother with their names, you need to use variables. These are dollar signs, followed by a character, telling the mob what it should take.

$i    the first of the names of the mobile itself.
$I    the short description of the mobile itself.
$n    the name of whomever caused the trigger to happen.
$N    the name and title of whomever caused the trigger to happen.
$t    the name of a secondary character target (i.e A smiles at B)
$T    the short description, or name and title of target (NPC vs PC)
$r    the name of a random PC in the room with the mobile
$R    the short description, or name and title of the random PC
$q    the name of the MOB program target (see MOB REMEMBER)
$Q    the short description of the MOB program target

$j    he,she,it based on sex of $i.
$e    he,she,it based on sex of $n.
$E    he,she,it based on sex of $t.
$J    he,she,it based on sex of $r.

$k    him,her,it based on sex of $i.
$m    him,her,it based on sex of $n.
$M    him,her,it based on sex of $t.
$K    him,her,it based on sex of $r.

$l    his,hers,its based on sex of $i.
$s    his,hers,its based on sex of $n.
$S    his,hers,its based on sex of $t.
$L    his,hers,its based on sex of $r.

$o    the first of the names of the primary object (i.e A drops B)
$O    the short description of the primary object
$p    the first of the names of the secondary object (i.e A puts B in C)
$P    the short description of the secondary object

    Also, in if_checks, the accepted variables are the basic ones
(i,n,t,r,o,p,q).  If a variable is referenced that doesnt exist, then the
value is simply left blank or replaced with "someone"/"something" in
output (i.e referring to $o when the trigger is: A kisses B)

    If variable $q has not been defined, it is automatically set to the
last player that has triggered the program being executed (i.e. variable $n).
Once $q has been defined, it can be modified with MOB REMEMBER and MOB
FORGET commands in a program. Variable $q lets the mobile "remember" a player
across different programs, which can be useful. Note that $q is set
automatically only the FIRST TIME the mobile executes a program, every time
thereafter it must be set with MOB REMEMBER.

    The only problem with the variables is that the secondary object and
the secondary target are passed by act() in the same location.  This means that
if you reference $t in an  A puts B in C  situation, the result will probably
be a happy mud crash or some weird side effect, especially if $t is used in
an if_check (i.e. if isnpc($t) in the above situation) The basic fix for this
is to change everyone who calls the act() procedure to specify a secondary
object and a secondary character. But that is a fairly comprehensive trivial
twiddle, so we left it the way it is so that, you aren’t forced to make all
those twiddles to use the MOB programs.

--------------------------------Operators-----------------------------------

    Most of the basic numeric operators are legal and perform the same
function as in C.

Operators: == != > < >= <=

---------------------------Control Flow Syntax------------------------------

In many of your mprogs, you will have to check things to determine the action of your mobiles. I could show you a whole page of strange signs and words, but you’d have to know some other programming languages to really understand, so I’ll give you some easy examples. The more complicated version is shown below.

To use IF_CHECKS in your mprogs, you will have to know the variables.
Suppose I have a gorgeous woman in a room, greeting all the males who enter with a kiss and curtsey to all the females.
The first you need to know is that you can’t check to see if someone’s “male” or “female” but you have to check with the sex-bits of the person. (sexless = 0, male = 1, female = 2) Why it is like that, doesn’t matter. Also, you’ll have to select a “target” you want to greet. As shown above, $n is the person who triggered the mprog, so we’ll work with that now.
GRALL trigger on a mob:
if sex $n == 1
  kiss $n
else
  curtsey $n
endif    Checks if the person who triggered the mprog is male
Kisses the person if he’s male
If the person didn’t turn out to be male
Curtsey to the person who triggered the mprog
Ends the check
That’s a pretty simple mprog: if this, do that, else, do that.

Now, we did forget one thing… what if the person is sexless?
In this program it only checks if $n is male, if not, the mob thinks $n is female, even if it’s sexless.
Now, suppose we want to kiss sexless beings too, and only curtsey to females.
if sex $n == 1
or sex $n == 0
  kiss $n
else
  curtsey $n
endif    Is the person male
OR is the person sexless
Kiss him/it
He’s not sexless or male, do something else
Curtsey, it has to be a woman!
Stop checking.
So now we kiss males and sexless beings, and curtsey to woman… But what if we want to do different things for all 3? 
We’ll have to add another check to see if the person is sexless.
if sex == 1
  kiss $n
else
  if sex == 0
    frown $n
  else
    curtsey $n
  endif
endif    Checks if the person who triggered the mprog is male
Kisses the person if he’s male
If the person didn’t turn out to be male
Checks if the person is sexless
Frowns at the sexless person
If the person isn’t sexless neither
It must be a female, curtsey!
Stops the check to see if $n is sexless.
Stops the check to see if $n is male.

Now, we make a guy that kisses every woman… but she has to be level 50 or higher, else we won’t do anything.
if sex $n == 2
and level $n >= 50
  kiss $n
endif    Is the person female
AND is the level of the person higher or equal to 50
Both: kiss!
Stop the check.

I hope this clarifies how “if”, “or” and “and” works… You can combine them and throw them together as much as you want, but always remember, for every IF, you have to put an endif somewhere.
If you want a more technical layout, feel free to read the next part, else, skip it and see what other things you can check for. If this still is too complicated, there are some more easy examples at the end of the guide, playing around with those should help you some more.

    In place of any legal mud command in a MOB program, one can substitute a
flow of control command. Here is the syntax for a flow of control command.
The parts between [ and ] are optional.

"if" " " {if_check_1} {argument} [ {operator} {value} ] NL
[ "or" " " {if_check_2} {argument} [ {operator} {value} ] NL ]
[ "or" " " {if_check_N} {argument} [ {operator} {value} ] NL ]
[ "and" " " {if_check_N} {argument} [ {operator} {value} ] NL ]
[ "and" " " {if_check_N} {argument} [ {operator} {value} ] NL ]
    [ {program_command_1} NL ]
    [ {program_command_2} NL ]
    [ "break" NL ]
    [ {program_command_N} NL ]
 [ "else" NL ]
    [ {program_command_1} NL ]
    [ {program_command_2} NL ]
    [ "break" NL ]
    [ {program_command_N} NL ]
"endif" NL

    Basically, it is: an 'if' line, followed by zero or more 'or' lines,
followed by zero of more 'and' lines ('and' and 'or' lines can be in any order)
followed by zero or more legal mud commands, which may contain a 'break' line,
possibly followed by an 'else' line , followed by zero or more legal mud
commands, which may contain a 'break' line, followed by an 'endif' line.
The only new syntax labels are all in the IF/OR/AND line:
--Explanations
An IF_CHECK is a string which describes under what context to compare things.
The ARGUMENT is the reference point from which the LHS of an expression comes.
The OPERATOR indicates how the LHS and RHS are going to be compared.
The VALUE is the RHS of the expression to be compared by the operator.

------------------------If_Checks In Control Flow---------------------------

The list below shows all kinds of if_checks there are, and their arguments and possible operators, you probably won’t use half of them, but it’s always fun to know what possibilities there are. Any '==' operator can be replaced with any of
the available ones described above.  The argument $* refers to any of the
variables which make sense for that if_check (i.e. for an if_check which is
referencing a person the only valid variables would be $i, $n, $t, $r or $q)
A value type of string is a sequence of characters. It does not need to be
included in quotes or anything like that (i.e. if name $n fido )

There are five types of if checks:

Type 1: Keyword and value

rand      num           Is random percentage less than or equal to num
mobhere   vnum           Is a NPC with this vnum in the room
mobhere   name           Is a NPC with this name in the room
objhere   vnum           Is an object with this vnum in the room
objhere   name           Is an object with this name in the room
mobexists name           Does NPC 'name' exist somewhere in the world
objexists name           Does object 'name' exist somewhere in the world

Type 2: Keyword, comparison and value

people     ==    integer       Is the number of people in the room equal to integer
players    ==    integer       Is the number of PCs in the room equal to integer
mobs       ==   integer    Is the number of NPCs in the room equal to integer
clones     ==    integer    Is the number of NPCs in the room with the same
                 vnum as the NPC who activated the program equal
                 to integer
order      ==    integer    Is the order (of several similar NPCs) of the NPC
                 who activated the trigger equal to integer
hour       ==    integer    Is the hour (game time) equal to integer

Type 3: Keyword and actor

isnpc      $*           Is $* an NPC
ispc       $*           Is $* a PC
isgood     $*           Does $* have a good alignment
isneutral  $*           Does $* have a neutral alignment
isevil     $*           Does $* have an evil alignment
isimmort   $*           Is $* an immortal (level of $* > LEVEL_HERO)
ischarm    $*           Is $* affected by charm
isfollow   $*           Is $* a follower with their master in the room
isactive   $*           Is $*'s position > POS_SLEEPING
isdelay    $*           Does $* have a delayed MOB program pending
isvisible  $*           Is $* visible to NPC who activated the program
hastarget  $*           Does $* have a MOB program target in the room
istarget   $*           Is $* the target of NPC who activated the program

Type 4: Keyword, actor and value

affected   $*   'affect'   Is $* affected by 'affect'
act        $*   'act'      Is $*'s ACT bit 'act' set
off        $*   'off'      Is $*'s OFF bit 'off' set
imm        $*   'imm'      Is $*'s IMM bit 'imm' set
res        $*   'res'      Is $*'s RES bit 'imm' set
vuln       $*   'vuln'     Is $*'s VULN bit 'imm' set
carries    $*   'name'     Is $* carrying object 'name'
wears      $*   'name'     Is $* wearing object 'name'
has        $*   'type'     Does $* have object of item_type 'type'
uses       $*   'type'     Is $* wearing object of item_type 'type'
name       $*   'name'     Is $*'s name 'name'
pos        $*   'position' Is $*'s position 'position' (sleeping etc.)
clan       $*   'name'     Does $* belong to clan 'name'
race       $*   'name'     Is $* of race 'name'
class      $*   'name'     Is $*'s class 'name'
objtype    $*   'type'     Is $*'s item_type 'type'

Type 5: Keyword, actor, comparison and value

vnum       $*      == integer Is $*'s virtual number equal to integer
hpcnt      $*      == integer Is $*'s hitpoint percentage equal to integer
room       $*      == integer Is vnum of the room $* is in equal to integer
sex        $*      == integer Is $*'s sex equal to integer
level      $*      == integer Is $*'s level equal to integer
align      $*      == integer Is $*'s alignment equal to integer
money      $*      == integer Does $* have money (in silver) equal to integer
objval#       $*    == integer Is $*->value[#] equal to integer (# from 0-4)

NOTE: The original MERC 2.2 MOB programs used parenthesis '(' and ')'
around variables. In this version, they are not allowed. Also, parameters
MUST BE separated with spaces (if level $n<10 is NOT valid, correct syntax
is: if level $n < 10).

------------------------New Commands Of Interest-----------------------------
1. DIAGNOSTIC COMMANDS
    These two new commands are available to immortal players.

Syntax:  MPSTAT <mobile>
    Displays the triggers and MOB program vnums defined for the mobile.

Syntax:  MPDUMP <vnum>
    Displays the MOB program code of given vnum.

Syntax: VLIST / FVLIST MPROG
Shows a list of all the mprogs in the area, or a list of all the vnums you have left to build new mprogs.

2. MOBCOMMANDS

MOB commands are special commands only mobiles (and Implementors) can use.
Mobiles use these commands to perform actions only immortals can perform.
All MOB commands are preceded with the word 'MOB' on the command line.

Syntax:  MOB AT [location] [action]
MOB at is similar to the immortal command at. It allows the mob to perform actions in rooms they aren’t in. The location can be a room vnum or the name of a player or a mob. The action can be a normal action, like a social, or dropping something, but also a special command or a spell, so the mob can spell itself up in another room without the players seeing anything.
Example: “MOB AT 1001 drop staff” Will make the mob drop a staff in room 1001. Noone in the same room the mob is in will see the action, but players standing in room 1001 will see the mob drop the staff, although they don’t see the mob arriving or leaving, since it’s never even been there.

Syntax:  MOB ASOUND [string]
     MOB ZECHO  [string]
     MOB GECHO  [string]

    ASOUND prints the text string to the rooms AROUND the mobile in the
    same manner as a death cry. This is really useful for powerful
    aggressives and is also nice for wandering minstrels or mobiles like
    that in concept.
    ZECHO prints the string to all players in the same area with the
    mobile.
    GECHO prints the string to all players in the game.

Syntax:  MOB ECHO                 [string]
     MOB ECHOAT      [victim] [string]
     MOB ECHOAROUND  [victim] [string]

    ECHO displays the string to everyone in the room.
    ECHOAT displays    the string to the victim only.
    ECHOAROUND displays the string to
    everyone except the victim.
    The three options let you tailor the message to goto victims or to do
    things sneaky like having a merchant do:
    mob at guard mob echoat guard rescue_please
    This coupled with a guard act trigger on rescue_please to:
    mob goto $n
    mob echo $I has arrived.
    It is an effective way of quickly bringing guards to the scene of
    an attack. (Note that the merchant has to be the only one of its
    kind in the game or have a unique name, otherwise the guard might
    go to different mobile...).

Syntax:  MOB MLOAD [vnum]
     MOB OLOAD [vnum] 
     MOB OLOAD [vnum] 1 room/wear

        MLOAD creates a mobile and places it in the same room with the mobile.
    OLOAD loads the object into the inventory of the mobile. 
        If the item is non-takable, it will load in the room instead of the mob’s inventory.
    OLOAD <vnum> 1 ROOM always loads the object in the room.
    OLOAD <vnum> 1 WEAR loads the object, and makes the mob wear it.
(Don’t ask me what the 1 is for, I don’t know, I don’t care, I’m a teacher, not a coder :p)

Syntax:  MOB KILL [victim]

    Makes the mobile attack the victim.

Syntax:  MOB FLEE

    Causes a mobile to unconditionally flee from combat. Can be used
    for example with the hit point percentage trigger to simulate
    "wimpy" behaviour.

Syntax:  MOB REMOVE [victim] [vnum|'all'|'money']
         MOB REMOVE [victim] <wear-loc> ['inv'|'room'|'get']

    Lets the mobile to strip an object of given vnum from the victim.
    Objects removed are destroyed. If the vnum is replaced with "all",
    the whole inventory of the victim is destroyed. This command is
    probably most useful for extracting quest items from a player
    after a quest has been completed.
When targetting a wear-loc, adding no third parameter will destroy the object. Adding ‘inv’ will move the object to the players inventory. ‘room’ will send the object to the floor. ‘get’ will move the object to the mobiles inventory.
WARNING: If you have a piece of equipment, and its name is a wear-loc
    the mob will always target the wear-location. In these cases use the
    vnum of the object.

Syntax:  MOB JUNK [object]

    Destroys the object referred to in the mobile's inventory. It prints
    no message to the world and you can do things like junk all.bread or
    junk all. This is nice for having janitor mobiles clean out their
    inventory if they are carrying too much (have a MOB program trigger on
    the 'full inventory')

Syntax:  MOB PURGE [argument]

    Destroys the argument from the room of the mobile. Without an argument
    the result is the cleansing of all NPC's and items from the room with
    the exception of the mobile itself.  However, mob purge $i will indeed
    purge the mobile, but it MUST be the last command the mobile tries to
    do, otherwise the mud cant reference the acting mobile trying to do the
commands and bad things happen. NEVER let a mob purge itself during a fight or with a death mprog, this usually leads to a crash.

Syntax:  MOB GOTO [location]

    Moves the mobile to the room or mobile or object requested. It makes
    no message of its departure or of its entrance, so these must be
    supplied with echo commands if they are desired.

Syntax:  MOB TRANSFER  [victim|'all'] [location]
     MOB GTRANSFER [victim]       [location]
     MOB OTRANSFER [object]       [location]

    Sends the victim to the destination or to the room of the mobile as a
    default.  if the victim is "all" then all the characters in the room
    of the mobile are transferred to the destination.  Good for starting
    quests or things like that.  There is no message given to the player
    that it has been transferred and the player doesn’t do a look at the
    new room unless the mob forces them to.
    Gtransfer works like transfer, except that the group the victim
    belongs    to is transferred with the victim.
Otransfer transfers an object in the room. The object must be in the same room the mob is in, or in the mobs inventory.

Syntax:  MOB FORCE  [victim|'all'] [command]
     MOB GFORCE [victim]       [command]
     MOB VFORCE [vnum]         [command]

    Forces the victim to do the designated command. The victim is not told
    that they are forced, they just do the command so usually some mpecho
    message is nice.  You can force players to remove belongings and give
    them to you, etc.  The player sees the normal command messages (such as
    removing the item and giving it away in the above example)  Again, if
    the victim is "all" then everyone in the mobiles room does the command.
    Gforce works like force except that it affects the group the victim
    belongs to.
    Vforce affects all mobiles with given vnum in the game world. This
    is useful for, for example, purging certain type of NPC’s from the
    game (by forcing them to purge themselves).

Syntax:  MOB CAST [spell] [victim]

    Lets the mobile to cast spells. Beware, this does only crude validity
    checking and does not use up any mana. All spells are available
    regardless of the race or other abilities of the mobile. Casting the
    spell occurs silently, but spell effects are displayed normally.

Syntax:  MOB DAMAGE [victim|'all'] [min] [max] {lethal}

    Causes unconditional damage to the victim. Specifying "all" as
    victim causes damage to all characters in the room except the mobile.
    Min and max parameters define the minimum and maximum amounts of
    damage caused. By default, the damage is non-lethal, but by supplying
    the optional 'lethal' parameter, the damage can kill the victim.
    This command is silent, you must echo all messages yourself in the
    program. Useful for implementing special attacks for mobiles.
    NOTE: Damage lowering spells such as armor, shield, sanctuary etc. and
the targets AC lowers the damage. Also, there is a limit of 30000 damage. If you want certain death, do 10 * 30000 non-lethal damage, and then one lethal 30000 damage.

Syntax:  MOB F
     MOB CANCEL

    MOB DELAY sets the time in PULSE_MOBILE after which the mobile's
    delay trigger is activated. If the mobile has a program defined
    for delay trigger, the program is executed when the timer expires.
    MOB CANCEL resets the delay timer.

Syntax:  MOB REMEMBER [victim]
     MOB FORGET

    This command enables the mobile to remember a player for future
    reference in a MOB program. The player can subsequently be referred
    as '$q' in programs activated by the mobile. MOB FORGET clears
    the target. Note that if the first time the mobile runs a program,
    $q is automatically set to the player who triggered the event.
    Most commonly this command is used in delayed programs, where the
    mobile has to remember the player who triggered the original
    event, for example to continue conversation.

Syntax:  MOB CALL [vnum] {victim} {target1} {target2}

    This command lets you call MOB programs from within a running one,
    i.e. to call a MOB program subroutine. The first parameter is the
    vnum of the program to execute, the second is the victim's name
    (for example $n), and the third and fourth are optional object
    names. All other parameters except vnum can be replaced with
    word 'null' indicating ignored parameter.
    MOB programs can be called recursively, but as a safety measure,
    parser allows only 5 recursions.

Syntax:  MOB RESTORE [target]
    This restores the target, putting hp, mana and moves back to maximum,
curing all kinds of disease and poison, and removing all the bad spells the target is affected by.

Syntax:  MOB PEACE
    Stops every fight in the room.

Syntax:  MOB ACT [‘act’]
    Sets the ACT bit of a mob. For a list of acts, type ‘? act’ in medit.

--------------------------Commenting mob programs------------------------------
You can add comment in an mprog by adding a * (an asterix). Lines starting with this get ignored by the mob, but it can make long and difficult mprogs a bit easier to read.

--------------------------Making mobs remember things--------------------------
Since there is no way to make a mob remember things, like where it was in a part of a quest or a story, there are other ways to get around this inconvenience.
The easiest example or where you need this: An old man tells a story about a time long ago.
Since the story can be 2 pages long, and pretty much spams the hell out of everyone when he says it all in one time, you have to use delays to make him talk slower. Now, since there is no way to remember where the man is in his story, he’d probably repeat the first part of his story, or randomly pick a part of the story, first telling the last part, then the beginning twice, then the last part… It’s a mess.
Therefore, the immortals on Aarchon offer you a way to make mobs remember where they stopped last time. OBJECTS!
Create some unique sticky objects, the mob can load them and junk them, and that way remember where he is in his story.
First he tells the first part, then he loads object 1000 and starts a delay 2.
Then, since you can only have one delay mprog, the whole story is put in one mprog.
When the delay triggers, he checks what object he has, notices he has object 1000, tells the second part, junks the object, loads object 1001 and delays himself again.
The delay mprog triggers again, he checks and sees he has object 1001. He tells the third part, junks the object, loads objects 1002 and delays again..
And so on and so on ‘till the story is over.

I understand telling stories is rather boring, but there are many more possibilities using this way of object variables.

--------------------------Loading Mobiles and Objects--------------------------

No doubt you want to load objects and mobiles in your MOB programs with "mob oload" and "mob mload". There are two problems connected to this. One is that mloaded mobiles will appear without equipment and the other is that it is difficult to keep track of the number of created mobiles and objects.

If you want to mobiles to appear in your area as a result of the
players' action, create a "storage room". Define resets for the mobiles
as usual (equipment etc.) and place them in the storage room. When you
need to use the mobiles, just "mob transfer" them to the location you
want. This is better than creating mobiles on the fly, since you don't have
to worry about creating too many mobiles or equipping them, area resets
take care of all that.

If you have a MOB program that creates new mobiles, you might want to make the mobiles "self-destructing". This is easiest to do with a random trigger that checks if the mobile is doing anything useful and possibly does 'mob purge $i'.

Another possibility is to use a "purgemaster". Create a storage room with a single mobile. Attach a random trigger that does 'mob purge' to that mobile. Now, when you need to get rid of anything, just 'mob transfer' the mobile or item to purgemaster, and it will be destroyed sometime later.

===================CUT HERE FOR QUICK REFERENCE SHEET========================

MOB program quick reference to triggers/variables/ifchecks/mobcommands

-----------------------------------------------------------------------------
Area file format
-----------------------------------------------------------------------------
#MOBILES

M {trigger} {program vnum} {argument}~

#MOBPROGS

#{program vnum}
{program code}~

-----------------------------------------------------------------------------
trigger    argument and what must happen to activate trigger
-----------------------------------------------------------------------------
act        STRING     to match a message sent to the room
social     STRING    to match a social that targets the mobile
speech     STRING     to match in dialogue (say, tell) to mobile
rand       PERCENT     chance to check whenever a PC is in the mobiles zone
bribe      INTEGER     miminum amount of silver coins given to mobile
give       OBJECT NAME, OBJECT VNUM or ALL to match when obj given to mobile
greet      PERCENT     chance to check if visible char enters mobile's room
grall      PERCENT     chance to check when any char enters mobile's room
entry      PERCENT     chance to check when mobile moves to a new room
exit       EXIT NUMBER    a visible char tries to exit mobile's room
exall      EXIT NUMBER    any char tries to exit mobile's room
kill       PERCENT    chance to check when the mobile begins fighting
fight      PERCENT     chance to check at fight_pulse if mobile is fighting
hpcnt      PERCENT     lower than mobile's hit/max_hit if mobile is fighting
death      PERCENT     chance to check after mobile has been slain
surr       PERCENT      chance to activate when a char surrenders to mobile
delay      PERCENT      chance to trigger when a mob’s delay reaches 0
surrender  PERCENT    chance to react to a player surrendering
drbomb     PERCENT      chance to act when a bomb is dropped in a room
exbomb     PERCENT      chance to act when a bomb explodes
defeat     PERCENT      chance to activate when a player dies in the room
try        STRING       to match the command a player uses with TRY
reset      PERCENT      chance to trigger when the area repops

----------------------------------------------------------------------------
variable         mobile actor victim random target    object 2nd_object
-----------------------------------------------------------------------------
  name             $i    $n     $t     $r    $q       $o       $p
shrt_desc/title    $I    $N     $T     $R    $Q       $O       $P
he/she/it          $j    $e     $E     $J    $X       --       --
him/her/it         $l    $m     $M     $L    $Y       --       --
his/hers/its       $k    $s     $S     $K    $Z       --       --
a/an               --    --     --     --    --       --       --

----------------------------------------------------------------------------
ifcheck    argument(s)     meaning
-----------------------------------------------------------------------------
rand       num           Is random percentage less than or equal to num
mobhere    vnum           Is a NPC with this vnum in the room
mobhere    name           Is a NPC with this name in the room
objhere    vnum           Is an object with this vnum in the room
objhere    name           Is an object with this name in the room
mobexists  name           Does NPC 'name' exist somewhere in the world
objexists  name           Does object 'name' exist somewhere in the world
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
people     ==    integer       Is the number of people in the room equal to integer
players    ==    integer       Is the number of PCs in the room equal to integer
mobs       ==   integer    Is the number of NPCs in the room equal to integer
clones     ==    integer    Is the number of NPCs in the room with the same
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
isnpc      $*           Is $* an NPC
ispc       $*           Is $* a PC
isgood     $*           Does $* have a good alignment
isneutral  $*           Does $* have a neutral alignment
isevil     $*           Does $* have an evil alignment
isimmort   $*           Is $* an immortal (level of $* > LEVEL_HERO)
ischarm    $*           Is $* affected by charm
isfollow   $*           Is $* a follower with their master in the room
isactive   $*           Is $*'s position > POS_SLEEPING
isdelay    $*           Does $* have a delayed MOBprogram pending
isvisible  $*           Is $* visible to NPC who activated the program
hastarget  $*           Does $* have a MOBprogram target in the room
istarget   $*           Is $* the target of NPC who activated the program
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
affected   $*   'affect'   Is $* affected by 'affect'
act        $*   'act'      Is $*'s ACT bit 'act' set
off        $*   'off'      Is $*'s OFF bit 'off' set
imm        $*   'imm'      Is $*'s IMM bit 'imm' set
res        $*   'res'      Is $*'s RES bit 'res' set
vuln       $*   'vuln'     Is $*'s VULN bit 'vuln' set
carries    $*   'name'     Is $* carrying object 'name'
wears      $*   'name'     Is $* wearing object 'name'
has        $*   'type'     Does $* have object of item_type 'type'
uses       $*   'type'     Is $* wearing object of item_type 'type'
name       $*   'name'     Is $*'s name 'name'
pos        $*   'position' Is $*'s position 'position' (sleeping etc.)
clan       $*   'name'     Does $* belong to clan 'name'
race       $*   'name'     Is $* of race 'name'
class      $*   'name'     Is $*'s class 'name'
objtype    $*   'type'     Is $*'s item_type 'type'
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
vnum       $*      == integer Is $*'s virtual number equal to integer
hpcnt      $*      == integer Is $*'s hitpoint percentage equal to integer
room       $*      == integer Is vnum of the room $* is in equal to integer
sex        $*      == integer Is $*'s sex equal to integer
level      $*      == integer Is $*'s level equal to integer
align      $*      == integer Is $*'s alignment equal to integer
money      $*      == integer Does $* have money (in silver) equal to integer
objval#       $*    == integer Is $*->value[#] equal to integer (# from 0-4)

-----------------------------------------------------------------------------
MOBcommand argument_list       MOBcommand argument_list
-----------------------------------------------------------------------------
ASOUND        [text_string]       ECHO       [text_string]
GECHO      [text_string]           ZECHO      [text_string]
ECHOAT     [victim] [text_string]  ECHOAROUND [victim] [text_string]
MLOAD        [vnum]                  OLOAD      [vnum] [level] {wear|room}
KILL        [victim]           FLEE
REMOVE     [victim] [vnum]         MOB JUNK   [object]
REMOVE     [victim] [wear-loc] [none|room|get|inv]
PURGE      [argument]              AT         [dest] [command]
GOTO       [dest]                  TRANSFER   [victim] [dest]
GTRANSFER  [victim] [dest]         OTRANSFER  [object] [dest]
FORCE      [victim] [command]      GFORCE     [victim] [command]
VFORCE     [vnum]   [command]      CAST       [spell] [victim]
DAMAGE     [victim] [min] [max] {lethal}
DELAY                           CANCEL
REMEMBER   [victim]               FORGET
CALL       [vnum] [victim] [target1] [target2]
ACT        [act]                   PEACE
======================END OF QUICK REFERENCE SHEET===========================

+++++++++++++++++++++++++++++++ EXAMPLES ++++++++++++++++++++++++++++++++++++
A simple mprog, an exall 0 on the guard. The room north –the one he’s guarding- has 1001 as vnum. Since exall triggers block ALL movement, you will have to transfer the player if he wears an employee badge. (badge vnum = 1000)
If carries $n 1000
or wears $n 1000
 emote checks your badge.
 nod $n
 say You may enter.
 mob transfer $n 1001
else
 look $n
 say You must be an employee to enter.
endif

================================================================================
Next mprog isn’t really harder, it will just look like that because it acts different depending on the players alignment and sex.
A greet (or grall) mprog on a Cleric in Gani’s Temple. 
(sexless = 0, male = 1, female = 2)

if isgood $n
 bow $n
 mob cast ‘bless’ $n
 if sex $n == 1 
  say Welcome to Gani’s temple, Lord $n.
 endif
 if sex $n == 0
  say Welcome to Gani’s temple, $n.
 endif
 if sex $n == 2
  say Welcome to Gani’s temple, Lady $n.
 endif.
else
 if isevil $n
  say You are not welcome in this place of beauty and peace!
  say Leave out of free will or feel Gani’s wrath!
  mob remember $n
  mob delay 5
 else
  frown $n 
  say You are welcome in Gani’s Temple.
  say Just behave yourself.
 endif   
endif
--------------------------
The Cleric will welcome and bless any good aligned person entering. He’ll frown at neutral players, but welcome them as long as they behave. Now, if the person is evil, the Cleric will remember the person and wait a while (delay 5 is about 15 seconds).
Now let’s have a look at what the delay mprog could look like:
if hastarget $i
 say $q, I warned you. Evil beings are not welcome here!
 emote utters the words ‘agin’f ghurb’.
 mob echoat $q Gani’s wrath does {G{%INCONCEIVABLE{x things to you!
 mob echoaround $q Gani’s wrath does {G{%INCONCEIVABLE{x things to $q!
 mob damage $q 7777 7777 lethal
 mob transfer $n 10204
 mob forget
else
 mob forget
endif

So first, he checks to see if the evil player he warned is still there. If he is, he’ll do 7777 damage to the player, which will kill him if he has too few hitpoints. Then he’ll send the player to Palace Square (that’s room 10204).
The echo’s are there to make it look nice. Since mob damage never shows anything, just does damage, we needed something to make it more real.
================================================================================

The next mprog is used a lot on high level mobs, to make the fights a lot harder. It’s pretty simple. It will either dispel a random person, cast “cure mortal” on itself, or cast a random draconian spell.

if rand 33
 mob cast 'dispel magic' $r
else
 if rand 50
  mob cast 'cure mortal' $i
 else
  if rand 20
   mob cast 'gas breath' $r
  else
   if rand 50
    if rand 50
     mob cast 'lightning breath' $r
    else
     mob cast 'frost breath' $r
    endif
   else
    if rand 50
     mob cast 'acid breath' $r
    else
     mob cast 'fire breath' $r
    endif
   endif
  endif
 endif
endif

The following mprog is totally 100% useless, but it does illustrate how complicated an mprog with a lot of ‘nested’ if’s can get. Therefore, use either comment or make sure you use an easy layout, so you can see what IF_CHECK you are in.

if name $n Xzylvador
  if rand 50
    if rand 50
      if rand 50
        say Yo, whassup X!
      else
       smile $n
      endif
    else
      if rand 50
        say Hello Xzylvador, had another day of hard work?
      else
        embrace $n
        say Welcome home.
      endif
    endif
  else
    if rand 50
      if rand 50
        straight self
        curts $n
      else
        smile $n
        say Lie down on your blankie for a while :)
      endif
    else
      if rand 50
        say Xzyl! How are you!
        hop $n
      else
        giggle $n
      endif
    endif
  endif
endif
if name $n Eris
 smile $n
 say Eris! How are you!
 say I'm sure X will be more then happy to see you!
endif

--------------------------Regarding CPU Slowdown-------------------------------

In the original MERC 2.2 MOB program documentation Nata'sha and Kahn wrote:
    "We have no real idea how slow this makes a mud. However, you will
find that if you are judicious with your use of MOBprograms, you can either
do little damage, or even reduce the effort on your server!  This means that
mobile polling (including the rand_progs) need only be checked when players
are around. This reduces computation of random_stuff a little, but it is
still a polling method, and subject to a basic inefficiency there. However,
aside from the rand_progs, the only additional slowdowns will be when the
mobile is responding to the situation, and you would get that from a special
procedure as well (although MOB programs are surely not as efficient as
compiled C code)"
    I have used MOB programs extensively in my own mud without adverse
effects. This version of MOB programs polls random triggers only when there
are players in the area, so the load is kept to minimum. I would venture
to claim that in most cases, line lag will exceed machine lag even with
ample and complex use of MOB programs.

-------------------------Miscellaneous Information-----------------------------

    There is really no limit to the number of MOB programs a given mobile
can have. However, the length of a single command block is limited by the
value of MAX_STRING_LENGTH.  In my version it was around 4k, so that is
probably about 100 lines.  The indentation spaces shown in the example
above are NOT required, but do make it easier to read (and debug). HOWEVER,
all spaces and indentations are loaded into memory as a part of the
program, so you're using up memory unnecessarily. Memory usage can also be
reduced by using subroutines (see MOB CALL).

    It IS possible to accidentally make mobiles which can trigger in
loops. Infinite loops have been prevented, but in case of a loop, the mobile
behaviour is undefined.

    The list of variables and triggers and if_checks will grow
continuously as mud creators demand the ability to do certain things. If you
have a request or if you have a new one, I don't mind hearing about them,
and if you find bugs, I shall gladly attempt to squash them for you. As
additions or fixes are made, the code will occasionally be redistributed.
However, if you want a current version, please feel free to ask. When the
code is redistributed, a file containing the change history from the original
release will be provided (when possible) to allow you to patch in the changes
with low grief.

----------------------------------Credits-----------------------------------

    The reason this code was written was to enhance the playing
experience at ThePrincedom (a Merc 2.0 based world scheduled to open in
October 1993)

    The original idea for this type of MOB program came from playing on:
WORLDS of CARNAGE, a dikumud implemented by Robbie Roberts and Aaron Buhr.
Aaron (known as Dimwit Flathead the First) was the original author from what
I have been told, and I hope he will not be totally offended and angered
by my coding and sharing a mimicked version with the world. This version
is probably not as good as the original and I do feel remorse for publishing
the idea. However, since Carnage has been down for months without a word of
information regarding its return, I am glad to let one of the best features
live on in future generations of MUDs.

    There are no objections to this code being shared, since, aside from
a nuclear destruction of all the Temples of Midgaard (excepting the original
one!!), bland mobiles are the greatest bane of Dikumuds today. It would be
nice to get a message saying you are using the code just for our references.
We shant answer questions from anyone until told where they are using the
code. *grin*  Since this code is not copyrighted, you of course dont have to
do anything we say, but it would be nice of you to put the mobprog help
screen into your database. and have mobinfo show up somewhere on a more
visable help screen (possibly tagged onto the bottom of credits as a see
also...)

    I acknowledge all the work done by the original Diku authors as well as
those at Merc Industries and appreciate their willingness to share code.
Also, quick thanks to Wraith for doing a little beta-installation testing.

N'Atas-Ha                                                    June, 1993
natasha@gs118.sp.cs.cmu.edu

    In addition to this DOC file credit section, I'd like to add
a thank you to Yaz, Mahatma, Zelda, and the rest of the 4th Realm crew for
extensively testing MOB Program 2.1 for me.  You may see MOB Programs in
action as well as their own "flavour" of mud at marble.bu.edu 4000.

Kahn                                Oct 28th, 1993
MERC Industries

    This driver was rewritten by me in summer '95. I also added
room and object programs (not in ROM 2.4 version). While I acknowledge the
skill and insight of the above people who conceived the original MOB program
idea, they should not be held responsible in any way for this release.
I can't promise I will be able to support this code in the future, use at your
own risk. However, if you're using this code, and/or have bug reports or
improvements, I'd be glad to hear from you. The revised MOB programs can be
seen in action at Imperium Gothique, mud.pitek.fi 4000. This code may be
freely used and distributed, but some favorable publicity (such as having
my name appended to your in-game credits) would encourage me to develop
this software.

Newt@Imperium Gothique                    May 1995-Jan 1996
mn54196@uta.fi                        (am I lazy or what?)

This guide was modified by Xzylvador to fit on Aarchon. Any code changed done to the mprog code have been made by Smote, Quirky, Rimbol and last but certainly not least: Bobble.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License