Mprog Compendium

No clear results from Google images on what an Mprog looks like.

For every entry in this database, I will attempt to explain to the fullest degree possible the various ways every mobprog command, trigger, and ifchk works in the Cleft of Dimensions. If you're just a tourist, check out some examples

Optimizing Mobprogs

Mobprogs are the biggest use of CPU time for the Cleft of Dimensions. Because of this, builders are encouraged to design and write progs with efficiency in mind. Below are some guidelines to follow:

• Random progs attempt to execute on every game tick. Because of this, they should be small and efficient.
  • It is vastly more efficient to give a mob a 'random 50' prog, than a 'random 100' prog that begins with 'if rand 50'.
    • The same is true of any prog trigger with a percentile parameter!
  • A 'schedule all' prog will only attempt to execute every minute instead, if that's acceptable.
  • A delay prog that re-sets the acting mob's delay, can also be used instead of a random prog, as long as the initial delay amount is set by a spawn prog or some other method.

• The 'break' command will end prog execution immediately.
  • In a vnum-stacked prog, put the most frequent users first, and end those blocks with a 'break'. Without a break, the rest of the prog will still be parsed!!

• "Vnum Stacking" is a method of using one mprog vnum on multiple mobs by making blocks of code within 'if vnum $i == ####' checks.
  • This can conserve vnums within an area, but in exchange makes each vnum-stacked prog less efficient to process.
  • Avoid vnum stacking random progs, or other progs that are called frequently, like delay or schedule.

• The 'mobexists' and 'objexists' ifchecks with words are the least efficient in the entire mobprog language, despite efforts to speed them up.
  • This is because they must compare their input string to every single name component of every single mob/obj in the entire world.
  • Both of these ifchecks can be used with a vnum instead. This is MUCH, MUCH faster, because it doesn't actually count anything; mob and object index data keep track of what's been loaded and unloaded!
  • This doesn't mean these ifchecks are off limits! Just avoid using them on progs that run frequently.

• Update_always mobs will execute all their progs even when a player is not in the area.
  • However, when a player leaves an area, it stays active for several minutes anyway.
  • Areas are also active for several minutes when the game first boots up.
  • Because of this, you probably don't need update_always on your mob unless it's running schedule progs.
  • Update_always and random progs are a bad mix that I will scold you for.

• Schedule, delay, and random progs WILL NOT execute if the mobile is fighting, UNLESS the mob is also flagged as update_always

IFCHECKS

   rand 		if rand 30		- if random number between 1 and 100 is < 30
   exists		if exists $n		- does $n exist somewhere This check is for use with variables, not names
   ishere   		if ishere $q            - is $q in this room?
   mobexists		if mobexists 1233	- is there mob vnum 1233 somewhere
   			if mobexists fido	- is there a fido mob somewhere     !!! WARNING !!! this is cpu-intensive. use a vnum instead if possible!
   			if mobexists 5.2839	- are there at least 5 mobs of vnum 2839 anywhere
   objexists		if objexists 1233	- is there obj vnum 1233 somewhere
   			if objexists sword	- is there a sword obj somewhere    !!! WARNING !!! avoid this too, for the same reasons
   			if objexists 500.sword	- are there at least 500 swords in the entire world? !!! and this
   mobhere		if mobhere fido		- is there a 'fido' mob in this room?
			if mobhere 1233		- is there mob vnum 1233 in this room?
   objhere		if objhere bottle	- is there a 'bottle' obj in this room?
	-can't see in	if objhere 1233		- is there obj vnum 1233 in this room?
	 containers
   isself		if isself $n            - evaluate equivalence between a character and the acting mob
   people		if people > 4		- does room contain > 4 people
   players		if players > 1		- does room contain > 1 pcs *in event obj progs the player doesn't count in if players checks
   mobs   		if mobs > 2		- does room contain > 2 mobiles
   clones		if clones > 3   	- are there > 3 mobs of $i's vnum here
   duplicates		if duplicates $n > 3	- are there > 3 mobs of $n's vnum here
   order		if order == 0		- is mob the first in room

   hour 		if hour > 11		- is the time > 11 o'clock
        Sunrise occurs at 6am (hour 6)
        Sunset occurs at 6pm (hour 18)
   day                  if day > 0              - is today not the first day of the week
        0 - Mana Holy Day
        1 - Luna Day        
        2 - Salamando Day
        3 - Undine Day
        4 - Dryad Day
        5 - Jinn Day
        6 - Gnome Day
   sky  		if sky > 2     		- is the sky rating > cloudy
	0 - dry
	1 - cloudless
	2 - cloudy
	3 - raining
	4 - lightning
   wind 		if wind > 2		- is the wind rating > breeze
	0 - stale
	1 - none
	2 - breeze
	3 - windy
	4 - gale
   sector		if sector $i == 5       - sector check
       0 - inside       1 - city         2 - field        3 - forest     
       4 - hills        5 - mountain     6 - swim         7 - noswim
       8 - unused       9 - air          10 - desert      11 - rock
       12 - road        13 - enter       14 - snow        15 - swamp
       16 - jungle      17 - ruins       18 - mount2      19 - coastal
       20 - developed   21 - void        22 - lava

   ispc   		if ispc $n 		- is $n a pc
   isnpc		if isnpc $n 		- is $n a mobile
   isgood		if isgood $n 		- is $n good
   isevil		if isevil $n 		- is $n evil
   isneutral		if isneutral $n 	- is $n neutral
   isimmort		if isimmort $n		- is $n immortal
   ischarm		if ischarm $n		- is $n charmed */
   isfollow		if isfollow $n		- is $n following someone
   isactive		if isactive $n		- is $n's position > SLEEPING
   isdelay		if isdelay $i		- does $i currently have a delay counter
   isvisible		if isvisible $n		- can mob see $n
   isfighting		if isfighting $n        - fighting check
   hastarget		if hastarget $i		- does $i have a valid remembered target
   istarget		if istarget $n		- is $n mob's remember target

   affected		if affected $n blind	- is $n affected by blind
   affected2		if affected2 $n frenzy  - (second set of affects, see mob template for list)
   shielded  		if shielded $n charge	- is $n shielded by charge
   act			if act $i sentinel	- is $i flagged sentinel
   act2 		if act2 $i noattack	- is $i flagged noattack
   off           	if off $i berserk	- is $i flagged berserk
   imm           	if imm $i fire		- is $i immune to fire 
   vuln    		if vuln $i electricity  - is $i vulnerable to electricity
   res        		if res $i cold          - is $i resistant to cold
   carries		if carries $n sword	- does $n have a 'sword'
			if carries $n 1233	- does $n have obj vnum 1233
                                               - (doesn't check to see if wearing, ONLY if in inventory)
   wears		if wears $n lantern	- is $n wearing a 'lantern'
			if wears $n 1233	- is $n wearing obj vnum 1233
   upon      		if upon $n motorcycle   - is $n riding/using as furniture a 'motorcycle
             		if upon $n 1233         - is $n riding/using as furniture obj vnum 1233
   has    		if has $n weapon	- does $n have obj of type weapon
   uses  		if uses $n armor	- is $n wearing obj of type armor
   pos			if pos $n standing	- is $n standing
   name  		if name $n puff		- is $n's name 'puff'
   clan 		if clan $n 'tuna' 	- does $n belong to clan 'tuna'
   race 		if race $n dragon	- is $n of 'dragon' race
   class		if class $n wizard	- is $n's class 'wizard'
   subclass		if subclass $n > 0      - subclass check
   skill		if skill $n 'big boo'   - does $n have the big boo skill
   skillchk		if skillchk $n 'fire' > 90 - character's skill percentage check
   objtype		if objtype $o scroll	- is $o a scroll type obj
   quest		if quest $n nerb1	- is quest flag nerb1 toggled for $n
   remort		if remort $n > 1        - has $n remorted at least once?
                                                 (New characters start at "if remort == 1";
                                                  first remort is at "if remort == 2")
   brief 		if isbrief $n 		- does $n have 'brief' toggled? *only works for players

   vnum 		if vnum $i == 1233  	- virtual number check
   room 		if room $i == 1233	- room virtual number
   roomaff		if roomaff sandstorm    - room affect check ('? roomaff' in editor to see valid flags)
   roomflag		if roomflag dark	- room flag check ('? room' in editor to see valid flags)
   area                if area $i == 1         - is $i in the immortal area?
   align		if align $n < -1000	- alignment check
   level		if level $n < 5		- level check
        		if level $o == 0        - works on objects too
   sex			if sex $i == 0		- sex check
	0 - none
	1 - male
	2 - female
	3 - (unused)
	4 - plural
	5 - spivak
   innate		if innate $n == 1	- innate check
       0 - None
       1 - Water
       2 - Moon
       3 - Wood
       4 - None (Don't use)
       5 - Wind
       6 - Earth
       7 - Fire
   size		if size $n < 2		- size check
	0 - tiny
	1 - small
	2 - medium
	3 - large
	4 - huge
	5 - giant

   counter		if counter $i >= 6 	- mob counter check
   money		if money $n > 500	- money check (in silver)
   objval0		if objval0 $o > 1000 	- object value[] checks 0-4 (check object type in oedit for relevant variables)
   objval1						-for money in bribe triggers use objval0 for silver and objval1 for gold
   objval2
   objval3
   objval4
   objcost		if objcost $o >= 50 	- cost of the obj in silver
   objweight		if objweight $o < 100 	- weight of the obj in 1/10lbs
   objextra		if objextra $o glow 	- does $o have glow
   objextra2		if objextra2 $o unique 	- is $o unique
   objextra3		if objextra3 $o owned 	- is $o owned
   objcond 		if objcond $o > 50 	- object condition value check

   grpsize		if grpsize $n > 6	- group size check
							-a solo player is a group size of 0
							 -all pets and charmies count toward group size
							  -they don't count if they aren't in the room with the target
   str			if str $n > 13		- strength check
   int			if int $i < 18		- intelligence check
   wis			if wis $q == 25		- wisdom check
   dex			if dex $f >= 8		- dexterity check
   con			if con $g <= 20		- constitution check
   hpchk		if hpchk $n < 15 	- hit point check
   hpcnt		if hpcnt $i > 30	- hit point percent check
   mpchk        	if mpchk $i > 8  	- mana point check
   mpcnt		if mpcnt $i > 50 	- mana percentage check
   mvchk 		if mvchk $i > 25 	- movement point check
   drunk		if drunk $n >= 5        - drunkenness check
   khcount		if khcount $n > 30	- did $n kill more than 30 things?
   khexists		if khexists $n 1234	- did $n kill a mob of vnum 1234? 
   enchant		if enchant $o > 10	- does $o have a total enchantment modifier of more than 10? NOTE: armor enchants are negative
   recentdam		if recentdam $i > 4	- is my recent_dam variable (aka $a) greater than 4?
   localx              if localx $i = 3           - is the current room at the localx 3 position?
   localy              if localy $i = 10          - is the current room at the localy 10 position? Note that these are the variables for the protuna minimap, and they'll be zero in every room if the builder hasn't created a map and set them
   

IFCHKS can be used with 'or', 'and', and 'else'. Ex:
 	-NOTE: 'else' can be combined with 'or' and 'and' ifchks.
		if room $i >= 500 		- is the room vnum both greater than or equal to 500 and less than or equal to 1000?
		and room $i <= 1000 			i.e. between 500 and 1000, including both 500 and 1000.

 		if dex $n > 12 			- are $n's dex AND str both greater than 12?
 		and str $n > 12

		if hour >= 18 			- is the hour later than 6pm or earlier than 6am?
		or hour <= 6 				i.e. is it between 6pm and 6am, including both 6pm and 6am.
								*'or' must be used for this type of 'evening' check because
								the numbers don't circle like a real clock - it can't be both
								greater than 18 and less than 6.
		if class $n thief 		- is $n a thief OR a warrior?
		or class $n warrior

		if uses $n weapon 		- does $n have an object type of 'weapon' equipped?
		 mob exitpermit 			yes: they may pass through.
		else
		 say You need a weapon first! 		no: mob says You need a weapon first!
 		endif

      -If you want to get REALLY in-depth, you can use both 'and' & 'or' in a prog, too!

                if affected $i haste
                or affected $i slow
                and shielded $i zombie
                say I have either haste or slow, and I definitely have zombie!
                else
                say I might have any one of haste, slow, or zombie, I might have haste AND slow without zombie...
                say Or I might just have none of the above!
                endif

                if carries $i apple
                and carries $i sword
                or carries $i dagger
                say I have an apple for sure, and either a sword or a dagger!
                else
                say I have neither an apple and a sword, nor an apple and a dagger.
                say But I might have an apple and no weapon, or both weapons... or nothing!
                endif

 
       Just be sure to watch the order of your ifchecks, it can make the difference between a working prog and a malfunctioning one!


Every if needs an endif. 'Or', 'and', and 'else' do not require additional endifs.

VARIABLES

There are two types of variables that are used in mobprogs. There is a limited set of variables than can be used with ifchecks, and there is a far more diverse set of variables than can be used with everything else. Additionally, there are variables outside of mobprogs that deal with items such as gender, but those are covered by the general variables listed below and are outside the scope of this document anyway. The variables listed below are in alphabetical order.

Ifcheck Variables:

$c     the current combat target of the remember target
$d	random player-targetable entity
$D     random charmie or pet
$f	the pet of the mob remember target
$g	the master of the mob remember target
$h     random player or charmie or pet
$i	the acting mob itself
$n	the target of the mob
$o	the target object of the mob
$p	the secondary target object of the mob (act trigger only)*
$q	the mob remember target
$r	random character in room
$t	the secondary target of the mob (act trigger only)*
$u     the mob remember target of the mob remember target
$y     the original actor in a chain of event progs

These codes return numbers instead of a mob or object target:

$a     the amount of last successful mob damage OR mob award exp
$B     the level of the mob remember target
$z	the counter of the acting mob

For use in event mprogs:

$n	is the targetted mob or player
$o	is the targetted object
$i	is the acting player
$p	is the actual event item being activated
$y	will always refer to the person using the event item
    (useful when the event forces other mobs)
$n and $o cannot exist at the same time in an event mprog
players are considered to be vnum 0 when using a 'vnum $i' check.

General Variables:

	$a	the numerical damage amount of the last successful Mob Damage
	$A	the name of the mob's object target, without quotes  
	$b	the race (for PCs) or shortdesc (for mobs) of the mob's remember target
	$B	the level of the mob's remember target
	$c	the name of the current combat target of the mob's remember target
	$C	the short desc of the current combat target of the mob's remember target
	$d	the name of a random player-aligned mobile (i.e. pet or charmie) in the room
	$D	the name of a random player-targetable mobile or PKable player in the room
	$e	the subject pronoun of the mob's target
	$E	the subject pronoun of the mob's secondary target*
	$f	the name of the pet of the mob's remember target
	$F	the short desc of the pet of the mob's remember target
	$g	the name of the master of the mob's remember target
	$G	the short desc of the master of the mob's remember target
	$h	the name of a random player OR player-aligned mobile in the room
	$i	the name of the acting mob
	$I	the short desc of the acting mob
	$j	the subject pronoun of the acting mob (he/she/it)
	$J	the subject pronoun of a random character
	$k	the object pronoun of the acting mob (him/her/it)
	$K	the object pronoun of a random character
	$l	the possessive adjective of the acting mob (his/her/its)
	$L	the possessive adjective of a random character
	$m	the object pronoun of the mob's target
	$M	the object pronoun of the mob's secondary target*
	$n	the name of the mob's target
	$N	the short desc of the mob's target
	$o	the name of the mob's object target
	$O	the short desc of the mob's object target
	$p	the name of the mob's secondary object target*
	$P	the short desc of the mob's secondary object target*
	$q	the name of the mob's remember target
	$Q	the short desc of the mob's remember target
	$r	the name of a random character
	$R	the short desc of a random character
	$s	the possessive adjective of the mob's target
	$S	the possessive adjective of the mob's secondary target*
	$t	the name of the mob's secondary target*
	$T	the short desc of the mob's secondary target*
	$u	the name of the mob's remember target's remember target
	$U	the short desc of the mob's remember target's remember target
	$X	the subject pronoun of the mob remember target
	$y	the name of the original user of an event item, because $i can change in different force/call contexts
	$Y	the object pronoun of the mob remember target
	$z	the counter of the acting mob
	$Z	the possessive adjective of the mob remember target
	$$	an actual dollar sign symbol, in case you needed that

OR:

	Name	Short Desc	Subject Pronoun	Object Pronoun	Possessive Adjective
	For Targetting	For Echoing	He/She/It	Him/Her/It	His/Her/Its
Acting Mob	$i	$I	$j	$k	$l
Mob's Target	$n	$N	$e	$m	$s
Secondary Target*	$t	$T	$E	$M	$S
Object Target	$o	$O
Secondary Object*	$p	$P
Random Character	$r	$R	$J	$K	$L
Mob Remember Target	$q	$Q	$X	$Y	$Z
Remember Target's Pet	$f	$F
Remember Target's Master	$g	$G
Remember Target's Remember Target	$u	$U

• The secondary target variables are a bit odd. Basically, they only work when a target or mob is related indirectly to the mob. For example, if Griswald opened a box and the mob had an act prog execute on that, the box would be $p. Or if Griswald parried Ami's attack and the mob had an act prog execute on that, Ami would be $t. $p and $t cannot exist at the same time.

MOB COMMANDS

The commands are grouped logically, not alphabetically. Commands that serve a similar purpose are grouped together, since I thought it would be more helpful that way. Every command has the appropriate syntax listed under it. Stuff in <brackets> denotes necessary parameters, stuff in [brackets] denotes unnecessary parameters. A synopsis of every command is listed as well. At the bottom of every entry I list examples of every command's usage.

A list of examples is given for each command. Every command has up to five basic examples and a further list of advanced usages for the command. In general, I try to draw no more than one example from each area, unless a given area has two or more distinctly different advanced usages of a command. The examples can be accessed via mpdump.

BREAK

break

This command will immediately stop the mobprog. Nothing else below a 'break' statement will be processed. This is often used to stop a prog short when one thing happens, so that later events in the same prog will not happen. It's commonly used in vnum-stacking.

Examples: 451, 456

ECHO

mob echo <string>

This command sends a text message to every player in the room. It is the basic command to output whatever you want via mobprogs. There are many more specialized versions of this command, all of which are listed below. Oftentimes echo is a better choice than having a mob say or emote something.

Examples: 1362, 2206, 2553, 1161, 4715

ECHOAT

mob echoat <target> <string>

This command will echo a message to the specific player targetted in the room and no one else. In combination with the echoaround command, this can allow for messages that simulate real commands. Usually the echo command is preferable, but echoaround combined with echoat can allow for the distinction between "you" and "$n" in messages. Echoat is useful in events such as someone being telepathed to, or if you just want to hide a certain message from other players in the room.

Examples: 1072, 33, 152, 1502, 3007

ECHOAROUND

mob echoaround <target> <string>

This command will echo a message to every player in the room with the exception of the target. In combination with the echoat command, this can allow for messages that simulate real commands. Usually the echo command is preferable, but echoaround combined with echoat can allow for the distinction between "you" and "$n" in messages. Echoaround is generally useful when you want to hide certain messages from the target player.

Examples: 1462, 4001, 4807, 3129, 4072

ASOUND

mob asound <string>

This command is similiar to echo. Unlike echo, however, asound will echo a message to every room that the mob's current room has an exit to - i.e., the surrounding rooms. What's interesting about asound is that it doesn't echo to the room the mob is in, only adjacent ones. It will echo through doors, but will not echo through portals or one-way exits leading INTO the mob's room.

Examples: 4017, 5683, 2217, 5494, 2714

ZECHO

mob zecho <string>

This command is a more powerful version of echo, echoing a message to every player in the mob's current area. Staff will get a "mob echo>" in front of every zecho message, but players won't. The applications of this command are pretty straightforward, and they can easily add some flavor to your area.

Examples: 1035, 1003, 182

GECHO

mob gecho <string>

This command is a more powerful version of zecho, echoing a message to every player in the MUD. There probably aren't that many times anybody would want to use this, but it's a powerful command and it's there. Staff will get a "mob echo>" in front of every gecho message, but players won't.

Examples: 419

DECHO

mob decho <string>

As mob echo, but will not show the echo to the user.

GOTO

mob goto <location>

This command transfers the mobile from the current room to another. The location parameter takes many different arguments. When given a number, goto will transfer the mob to the given room number. When given any single word, goto will transfer the mob to the first relevant mob or object in the world. In this case, only exact keywords are allowed, partials are not accepted. An interesting fact about goto is that it stops the mob's combat during the transfer, so it acts like a localized mob peace. Also, use of the goto command can disguise a mob's death cry - shown in the examples below. Mob goto can transfer through safe or no_mob room flags and can move sentinel mobs.

Examples: 4004, 2712, 3116, 1021, 5555
Adv. Examples: 2115, 4069, 1212, 1549, 2262, 71, 4851, 1053, 187, 733

TRANSFER

mob transfer <target> [location]

This command transfers the target to the given location. The location can be a room vnum or a single *exact* keyword for a given mob or object. If location is omitted, the command will transfer the target to the room the mob is in. The target can be any mob or player in the world. Mob transfer can also transfer "all," which will move all characters in the mob's room. Mob transfer can transfer through safe or no_mob room flags and move sentinel mobs.

Examples: 1452, 4014, 2708, 4854, 1714

GTRANSFER

mob gtransfer <target> [location]

This command works just like transfer, except it transfers everyone in the target's group as well as the target. However, you cannot gtransfer all. Besides that, it is entirely identical to transfer.

Examples: None.

MLOAD

mob mload <vnum>

This command loads a mob with the chosen vnum into the same room as the acting mob. It can load mobs from any area and into any room with no restrictions. It only takes vnums as a parameter - you cannot mload specific words. While the command appears straightforward, it can be used creatively.

Examples: 1206, 1453, 39, 3119, 154
Adv. Examples: 2729, 2262, 4076, 1404, 4849, 1563, 1003

OLOAD

mob oload <vnum> [level] [R] [W]

This command loads an object with the chosen vnum into the inventory of the mobile. If the item cannot be taken into inventory, it is generated on the floor. "R" will send the object to the room, and "W" will make the mob wear the object, if possible, instead of placing it in inventory. The [level] and [R] or [W] parameters are not necessary to use mob oload, but in order to load something into the room or equipped onto the mob using R or W, the level parameter has to be defined, as well. However, the function of altering the level of the loaded object is defunct, so it's typical to simply use '0 R' or '0 W' to load objects in these ways. What's great about loading objects is that they can be used as "counters" in mobprogs, illustrated in some examples below.

Examples: 1475, 1360, 3126, 2381, 2127
Adv. Examples: 2232, 178, 5670, 4818

MCLONE

mob mclone <target>

This command creates a perfect duplicate of a target mobile, including any modifications to it, such as restring/face fields, equipment, inventory, affects, etc. It cannot clone PCs.

OCLONE

mob oclone <target> [I]

This command creates a perfect duplicate of a target object, including any modifications to it, such as restringed fields, affects, etc. By default, it will load the cloned object into the room, regardless of where the original object was. "I" can be added to the command to force the new object to appear in the mob's inventory instead.

OTRANSFER

mob otransfer <target> <location>

This command transfers an object to a given location. The target object can be in the room, in the mob's inventory, or part of the mob's equipment. The location parameter can be a room vnum or an *exact* argument for a mobile or object anywhere in the world. Unlike the regular transfer command, the location is mandatory. Unfortunately, no matter what the location is, the target object will always transfer to the room the location is in, never the actual character specified. NOTE: items inside containers cannot be otransfered, but ifchks can see them.

Examples: 4868

PURGE

mob purge [target]

This command can delete items or mobiles from the room the mob is in. It has powerful and versatile purposes. Mob purge without a parameter will purge all mobs and items in the room that lack the nopurge flag. Mob purge with a target can purge any mobile in the room or any object in the room or in the mob's inventory or equipment. Mob purge will never purge player characters. A mob can "mob purge self," but do so sparingly - it appears to be able to crash the MUD at times. When you do use "mob purge self," try to place it as close to the end of mobprogs as possible. For extra security, always place 'break' right after a mob purge self command.

Examples: 53, 3149, 4829, 1581, 710
Adv. Examples: 1005, 3123

JUNK

mob junk <item>

This command can destroy any item the mob has in inventory or is wearing as equipment. The <item> parameter is very versatile. You can junk all, or junk 'all something', or just junk a specific item. It works just like the get command in this regard. It also takes variables such as $o. Mob junk cannot junk items on the ground or items in a player's inventory. NOTE: items inside containers cannot be junked, but ifchks can see them.

Examples: 1476, 2109, 1360, 2710, 4886
Adv. Examples: 3146, 2216, 4015, 2387, 727, 1009, 1212, 5491, 3113

REMOVE

mob remove <target> <vnum/name>

This command removes the given object from the target's inventory or equipment. The target must be in the same room as the mob. The vnum parameter specifies the vnum of the object to be removed from the target. Mob remove will only remove one object each time it is used, even if the player is carrying multiple of that object vnum. Mob remove can also take a name argument, but be incredibly diligent when using this as it could potentially remove a different object that shares a name keyword. (For example, do not 'mob remove $n sword' because it will almost certainly not remove the item you intend!) Alternately, all can be used instead of a vnum - this will remove every object the target has. (Don't do this to players!) Removed objects are completely destroyed, not dropped to the floor or given to the mob. This means be careful when using it. Do not 'mob remove' things from players' inventories without good reason.

Examples: 1027, 4829, 1314, 1162, 5556

FLEE

mob flee

This command causes the mob to instantly run to an adjoining room. It only works if the mob is not currently fighting (simply use 'flee' for this). The mob will not flee through closed doors or into no_mob rooms, and it will not flee into the same room as it started in (via looped exits). It will cause a normal 'leaves east' type echo. The way it works is that the mob tries, six times, to run in a random direction. If at the end of those six attempts it hasn't found a valid exit, the mob does nothing. Because of this, mob flee is more likely to work in rooms with more exits than rooms with fewer exits.

Examples: 1006

KILL

mob kill <target>

This command will force the mob to attack the target. The target parameter can be either a variable like $n or an actual name like goomba. It ignores almost all of the restrictions the regular kill command has - for example, a mob can attack a person who is already fighting someone else, or it can attack through a safe room. Here are the only restrictions: the target must be in the same room as the mob, the mob can't attack itself, and charmed mobs can't attack their masters. When your mobile absolutely must attack someone, you want to use this instead of the regular kill command.

Examples: 4700, 1456, 2712, 3123
Adv. Examples: 1514, 2352, 3014, 1060, 161, 172

ASSIST

mob assist <target>

This command works similarly to kill. It functions somewhat differently than the regular assist command. Mob assist will force the mob to attack whoever the target is fighting with. The target parameter can be either a variable like $n or an actual name like goomba. It does not relieve the target of fighting, it merely draws the mob into the fray. Mob assist will attack under any circumstances unless: the target isn't in the same room as the mob, the mob is trying to assist itself, the target is not fighting, or the mob is already fighting.

Examples: None. This command is not mentioned in the standard mprog documentation.

HIT

mob hit <target>

Similar to Kill and Assist, this command causes the mob to attack the target. However, it doesn't care if the actor is already fighting -- this makes it useful for simulating special attacks.

Examples: 1456

PEACE

mob peace

This command stops all fighting in the same room as the mob. It works exactly like the staff command of the same name. Besides furthering the cause of pacifism, it's ideal for creating a gap in the fighting to execute commands that can't be done while fighting, then resuming the brawl. Additionally, it's a helpful command to use with inert or passive mobs. Please note that this command does NOT work when used with the 'DAMTYPE' trigger - the player will not cease combat due to the mechanic priority between the two.

Examples: 5669, 4001, 3014, 172, 3139

SKILL

mob skill <command>

This command allows the mob to execute almost any skill. The given command is parsed like a regular command, except that, when this command is executed, the mob is treated as having 75% adequacy in all skills in the game. Therefore, skills that are normally forbidden to mobs can be used with the mob skill command. By using the adept and inept act2 flags, the proficiency of the mob at skills can be increased or decreased by 25%.

Examples: 2511

DAMAGE

mob damage <target> <min> <max> [damtype] [lethal] [safe] [percent]

This command directly damages the target. This will work when the mob is not in combat and will not initiate combat. The target can be any character in the same room as the mob, or it can be all, which targets all characters in the room. Mob damage does a random number of hitpoints damage between min and max. Min and max are not dice, they are a flat range. Mob damage can do negative damage, which will heal the target - however, mob damage will not send the target's hp above maximum. Note that healing this way ignores zombie status, distribute, etc.
Damtype specifies what damage type to use in respect to resistances and vulnerabilities. It can be any damage type you see with "? imm" in medit. A given mob damage can only have one given damtype.
If you type "lethal" at the end of the command, the mob damage can kill the target. Otherwise, the target's hp will not drop below 0. [damtype] and [lethal]'s positions in the command are interchangeable. If you type "safe" at the end of the command, the mob damage will not hurt characters in the same group as the mob; however, this is only relevant to "all" mob damages.
The "percent" keyword changes the min and max from a damage quantity into a percentage of the target's maximum HP. It will not do more damage than the target's current HP, however.

Examples: 4061, 4831, 1704, 1532

DAMECHO

mob damecho "message to target" "message to room" <target> <min> <max> [damtype] [lethal] [safe] [percent]

This command is extremely similar to 'mob damage' but allows echoes to the target and the room the target is in, with a number on the end for damage. This command will initiate combat, unlike mob damage.

Because the message strings are parsed by the mprog interpreter BEFORE being passed to the damage_next() function, $ variables will not work as expected when using the 'all' parameter. To show each actual victim's short desc in the "message to room", use the unintuitive $$N (with two dollarsigns) instead of $n.

Examples: 701

CAST

mob cast <spell> [target]

This command allows a mob to cast any of the spells normally available to players. The spell parameter takes an argument, and you'd type in given spell there just like you would with the regular cast command. The target can be any mob or object in the room or mob's inventory, or, depending on the spell, no target at all. Mob cast costs no mana. You'll usually want to pair this command with a mob echo for more flavor.

Examples: 4001, 2203, 4838, 301, 4716

MANA

mob mana <target> <min> <max>

This command drains mana from the target. It works in a similar fashion to mob damage, but it is less complex. The target can be any character in the same room as the mob, or it can be "all," which targets all characters in the room. Mob mana does a random number of mana damage between min and max. Min and max are not dice, they are a range. Mob mana can drain negative mana to cause restoration, but it will not give more mana than a character has max. Likewise, it will never send mana below 0. Mob mana $i commands are an excellent way to make realistic spellcasting for mobs, especially when combined with mob cast and mob damage commands, in addition to the mpchk ifchk.

Examples: 3139, 2748, 169, 701. This command is unique to CoD.

AWARD

mob award <target> <type> <value> [scaled]

This command can award various points to the target. It works almost exactly like the staff command of the same name. The target argument can be any character in the world, but cannot be a mob or a staffer. Below is a chart of type arguments and their relevant range of values:

gold	-10000	10000		prac	10	-10		exp	-10000	10000
silver	-10000	10000		train	5	-5 		align   -100    100

Use this command sparingly and only as a reward for doing important stuff. It is best used in conjunction with the mob quest command, especially when dealing with experience, practices, or trains.

The 'scaled' argument is optional, which causes awarded experience to scale by 0-200% based on the level difference between target and mob, like XP gained from kills. Please keep in mind to level lock large experience rewards to keep quests relevant to the actual level of their area when not using scaled.

It's possible to use 'mob award $i' but ONLY do this in event progs, where $i is the player.

Examples: 2260, 4022, 1027, 1116, 32. This command is unique to CoD.

ADVANCE

mob advance <target> <value>

This command will advance the target to the specified level. This command MUST be used carefully, as it can reduce the target's level as well. The target can only be a player and not a mob. This command should also be used SPARINGLY as we should not be providing multiple level skips in the game and is mostly intended for use in RARE, PROMO-TYPE event objects and event content. To properly use this command without accidentally over- or under-leveling the player, the following set-up should be used, where the final 'mob counter' is the amount of levels you wish to grant the player:

mob remember $n
mob counter $B
mob counter 1
mob advance $n $z

QUEST

mob quest <target> <+/-/=> <questflag>

This command modifies the value of a quest flag on the target character. Quest flags are unique, hardcoded flags that save whether a mob has completed a certain event or not. Target is an argument and can refer to any player in the world. Mob quest does not work with mob targets. <+/-/=> indicates whether to set or unset the relevant quest flag; + and = are exactly the same. Each area automatically comes with 16 quest flags, regardless of the total vnums of the area, that will use the syntax of [area name]1-16 (without .are) ex. 'truce1'.

Examples: 54, 3113, 2390, 4874, 1596. This command is unique to CoD.

QUESTALT

mob questalt <target> <+/-/=> <questflag>

As mob quest, but for the now-defunct hardcoded quest flags.

SET

mob set <target> <skill> <percent>

This command will set a player's skill% in the specified skill or spell. This is usually used to award quest skills at 1%.

Skills that are in a player's class list, but not learned yet, are actually already learned at 1% and will be unlocked for use when the player also meets the level requirement. Mob set'ing them to 2% or higher will make them practicable/usable immediately.

Examples: 823, 8947

PETIFY

mob petify <target> $i

This command makes the mob using the command the pet of the target. It works almost exactly like the staff command of the same name. Mob petify will not work if the target already has a pet. Mobs can only petify themselves, this command only works with 'self' (variable $i) as the victim.

Examples: 2106, 3196, 700, 707, 715. This command is unique to CoD.

FORCE

mob force <target> <command>

This command forces the given target to perform the given command. The target can be anyone in the same room as the mobile, excluding the mobile itself. The target can also be "all," which will affect every character in the room that the mob can see and who is not staff. The command can be any regular command - or if the target is a mob, a mob command - but it cannot be an ifcheck. This can be a very powerful command.

Examples: 5660, 3130, 2710, 3014, 2387

GFORCE

mob gforce <target> <command>

This command works just like force, except it forces everyone in the target's group as well as the target. The target must be in the same room as and not be the mob. Besides that, it is entirely identical to force.

Examples: 5276

VFORCE

mob vforce <vnum> <command>

This command works just like force, except it forces every character in the world of the specified vnum to do the given command. Vnum must be a number. Vforce will not force the mob that executed the command, or players, or characters that are currently fighting. Besides that, it is entirely identical to force.

Examples: None.

MFORCE

mob mforce <target> <command>

This command is similar to force, but it allows a mob to force a player to perform commands that players cannot normally perform, i.e. mob commands. It can only target a single player and not the player's group. It is very useful for a variety of things, as mob commands behave differently than player commands and can allow for interesting mechanics. For example, use mforce to have a player use 'mob oload' for a quest reward, as this bypasses item and weight carry limits, so there won't be any issues having them receive the item.

Examples: None (for now).

AT

mob at <location> <command>

This command allows a mob to perform any single action at any location on the MUD. It's like using a mob goto, a command, and another mob goto to return all in one command. The location can be a vnum or an *exat* keyword for a mob or object. The command parameter works just like a regular line of code in a mobprog. The <command> can be any regular or mob command, but it cannot be an ifcheck. If you want to perform multiple commands and ifchecks in a remote room, use multiple mob goto statements instead.

Examples: 4073, 1003, 5664, 735, 2387

DELAY

mob delay <pulses>

This command sets the delay timer for the mob. The delay timer is measured in pulses - to see how quickly pulses count down, cast a buff spell and see how its timer works (one pulse is about 4 seconds). When the delay timer hits zero, the mob's delay trigger prog will execute, if it has one. Unless a mob has update_always, its delay counter won't tick down unless there are players in the area - staff do not count. So when debugging progs, you may note in mpstat that the delay counter can stagnate. Mob delay is an intensely useful function and requires some thought to figure out. Due to the nature of mob delay, many potential example mobprogs are split up over several progs and are difficult to show here. Note that

Examples: 182, 1005, 1502, 1061, 1806

CANCEL

mob cancel

This command cancels the mob's delay timer. It sets it to zero and stops the mob's delay triggers from activating. While waiting enough pulses will also let the delay timer reach zero, that will make the mob's delay triggers activate. This will not.

Examples: 4011, 1009

REMEMBER

mob remember <target>

This command stores the name of a target in the mob's memory. Target is one argument and can be either a name or a variable. The target can be anywhere in the world. Once remembered, the target's name is stored as $q for the mob and will remain until a mob forget command, a new mob remember, or the mob's death. Mobs will remember players through player deaths, but will forget a player when that player logs out. A mob's memory can be seen with mpstat. If a mob has no target, it will remember the first person who walks into the room with it - note this, as it can cause problems for some mobprogs. Due to the nature of mob remember, many potential example mobprogs are split up over several progs and are difficult to show here.

Examples: 4065, 1211, 1053, 1015, 160

FORGET

mob forget

This command empties the mob's memory. It is the opposite of mob remember and almost always appears accompanying it. Besides mob forget, the only way to clear mob memory is to kill the relevant mob (although you can always store a new target to mob memory with a new mob remember).

Examples: 738, 1501, 3142, 5508, 2727

CALL

mob call <vnum> [victim] [obj1] [obj2]

This command executes a mobprog subroutine. Essentially, when you put in a mob call command, the MUD goes into the mobprog of the given vnum and executes it. Once the sub-prog finishes, the main prog continues as normal. Victim, obj1, and obj2 are optional parameters that specify what $n, $o, and $p are in the subroutine, respectively. If they are left out, the subroutine will execute with $n, $o, and $p set to null. If you want these variables to be null, just type null in the appropriate fields. Victim, obj1, and obj2 will look for mobs or objects in the same room as the mob. A mobprog can call itself recursively, but the MUD will stop such infinite loops after 5 recursive calls. IMPORTANT: Even if there is a break inside of a called prog, this only breaks the called prog. The original prog will still continue afterwards. Do not add a 'mob purge self' or any other potentially crashy command in a called prog unless there is an additional break within the main prog right after the called prog.

Examples: 1368, 47, 1400, 2395, 5661

GCALL

mob gcall <vnum> [victim|'null'] [object1|'null'] [object2|'null']

This command functions exactly like 'mob call', but will execute the called program once for every member of "victim"'s group, with $n iterating over groupmates across the loops. This includes NPC groupmates. The order of execution is based on the arrangement of the group members in the room; the original "victim" will not necessarily be first.

Groupmates who are no longer in the room when it's "their turn" will not have the prog executed on them, so be careful when combining this with commands like gforce and gtransfer.

If there is no victim specified, or the victim isn't in the same room, then the program will execute exactly once. In this case, $n in the called prog will be null.

Examples:

For gcall-based quest exp, first make a dedicated mprog, e.g. mpdump 17375:

* Called by prog 1001. Booster statue in Truce. Grants lv10 XP then returns to original level.
if ispc $n
 if quest $n truce6
 else
  mob mset $i level 10
  mob award $n exp 500 scaled
  mob mset $i level 5
  mob echoat $n {WYou have completed a quest and gain $a experience!{x
 endif
 mob quest $n + truce6
endif

Then, call that prog in the main mobprog, e.g. mpdump 1001:

mob echo Something clatters within the statue's head, and an LED spits out of
its mouth.
mob gcall 17375 $n

COUNTER

mob counter <value OR 'zero'>

This command allows basic addition and subtraction operations to be performed on a variable stored on a mob. An ifcheck exists to take advantage of the command (if counter). The value parameter can be either positive or negative to perform either addition or subtraction. The word 'zero' sets the counter to zero.

Examples: 21, 22

FACE

mob face <long/short/name> <string>

This command changes the mob's long or short desc, or name, to whatever is specified.

Examples: 9038

FLAG

mob flag <victim> <flag type> <flag> +/-

The Flag command can modify the act, act2, aff, aff2, shield, imm, res, vuln, off, or behav flags of a mob. A mob can use this command to change its own abilities on the fly.

SDAMAGE

mob sdamage ??? ???

Appears to be an uncoded solution to the problem that the $a flag fixed.

SPAWN

mob spawn <victim> <room vnum>

The Spawn command will change the target's recall point to the specified room vnum.

Examples: 9098

RESCUE

mob rescue <victim>

The Rescue command works as the Rescue skill does, but without the restrictions on grouping or any skill checks.

EXITPERMIT

mob exitpermit

Exitpermit allows mobs with exit progs to allow the character through the exit normally, instead of requiring transfer commands or other sneaky tricks.

Examples: 2917

ASSET

mob asset <victim> <art/sound> <file> [duration in beats]

The Asset command is used for enhanced asciiart and sound functions using the Project Tuna client. For advanced usage, see Project_Tuna#Mob Asset.

Examples: 10289, 12002

OSET

mob oset <object name> <field> <value>

Fields: name(a), short(a), long(a), level(#), wear(a), extra(a), extra2(a), extra3(a), condition(#)****, weight(#), cost(#), timer(#), value0(#), value1(#), value2(#), value3(#), value4(#) or v0-v4

• condition is not oset into a true value but adjusted ex: mob oset $o condition -20 will reduce its condition by 20 regardless of its previous condition.

More fields: ed(keyword "new extra desc"), add (affect #modifier), apply(flag bitvector), delaffect(#)

Value: (a) = requires a string or bit/flag name in place of value (#) = requires a numerical value

Mob oset will only target objects in the mob's inventory or in the same room as the mob. This command is very powerful, and can have complex syntax.

MSET

mob mset <target> <field> <value>

Fields: str(#), dex(#), sex(a/#), level(#), maxhp(#), hp(#), maxmana(#), mana(#), maxmove(#), move(#), alignment(#), damtype(a), hitroll(#), damroll(#), magroll(#), saves(#), dicecount(#), dicetype(#), acbash(#), acslash(#), acpierce(#), acexotic(#)

This command seems to be incompletely implemented. Mobs can currently only mset themselves, but can be mob forced by other mobs to mset themselves.

• See Oset_and_mset_tips_and_tricks for more information

RSET

mob rset <field/affect/command> <string/value/duration>

This allows a mob to temporarily edit the room they are standing in. These changes should not save through copyovers or crashes.

• Available fields: name <string>, desc <string>, heal <value>, mana <value>, xpos <value>, ypos <value>
• Available affects: sandstorm , blizzard , frostveil, darkness, flash, firetrap, brainstorm, consecrate_neutral, consecrate_good, consecrate_evil, quicksand, hprain, sunstroke, timewarp, timestop, meteo, grease, skylight
• Available commands: save, reset <"area"/"room">

• • There is a 500-ish character limit to 'mob rset desc <string>'.

ADDLAG

mob addlag <target> <value>

This command adds beats of lag to a player (in which they can not act or move at all). Allowed value is anywhere from 1 to 999. Useful for keeping players still during a story scene or if mobs need to perform their actions without player interruption.

CLAN

mob clan <target> <clan>

This command allows a mob to add a player to a clan instead of requiring an Immortal's assistance. The clan must already be created, however.

PRETITLE

mob mforce <target> mob pretitle self <pretitle>

This command allows a mob to set a player's pretitle instead of requiring an Immortal's assistance. Technically a mob can only set their own pretitle to avoid setting someone else's pretitle by mistake, so this syntax causes the mob to force the player to set their own pretitle.

ANCIENTCAVE

mob ancientcave

This command re-randomizes the ancient cave area. Don't use this unless you know exactly what you're doing, as the ancient cave receptionist mob already does this periodically.

Examples: 13275

ADDLOG

mob addlog

This command allows a mob to write to the mud's log, for debug purposes. It will write the short desc and vnum of the mob, followed by the argument. It may be useful for debugging mprogs that have a lot of moving parts.

MOB TRIGGERS

The triggers are listed alphabetically, since there aren't all that many of them and the ones that have a similar purpose have a similar name. Triggers are mostly self-explanatory, so the main use of this section will be to give examples of how the triggers are used in the MUD. Examples of usage will not be given in this section, but I will attempt to describe situations in which the triggers are usable. To see the triggers on any given mob, mpstat them.

ACT

addmprog <vnum> act <phrase>

The act trigger is the most versatile and basic trigger there is. The act trigger reads output directly from the MUD. It will activate when the <phrase> text appears to the mob. This means that act triggers will activate when a mob or player says something, when a mob or player does a social, or when a mob or player does an action (like give or eat or sleep). However, the act trigger will not activate on emotes. Act triggers are case insensitive. If an act trigger includes color codes, as with a color coded object being opened, the act trigger <phrase> itself will require the color codes in order to trigger correctly. Act triggers can use one or more words in <phrase> - to set the phrase as multiple words, surrounded the phrase with "quotation marks." When triggered by someone's speech, the act prog will activate before the <phrase> is actually spoken - making it look out of order. Many mobiles have an act prog with the phrase "talks to you," which triggers on the talk social. This is especially common in towns and with humanoid mobs.

BRIBE

addmprog <vnum> bribe <amount, in silver>

DAMTYPE

addmprog <vnum> damtype <type of damage/"all">

The damtype trigger is activated when a mob receives damage of a particular type. Be aware that multiple-hit attacks such as Pearl, kick, etc. will trigger the prog with every hit. The damtype specified is it's number, not its name:

 0 - None*     1 - Bash      2 - Pierce    3 - Slash     4 - Fire      5 - Cold      6 - Electric
 7 - Acid      8 - Poison    9 - Negative 10 - Holy     11 - Energy   12 - Mental   13 - Draining
14 - Water    15 - Light    16 - Other*   17 - Harm*    18 - Charm    19 - Sound    20 - Wood
21 - Silver   22 - Iron     23 - Wind     24 - Earth    25 - Dark

• "all" can be also specified to trigger on any damage

• Very, very few attacks use the None, Other, Harm, or Charm damtype to actually deal damage.

DEATH

addmprog <vnum> death <percent>

DELAY

addmprog <vnum> delay <percent>

The delay trigger is activated when the delay timer for the mob decrements to 0. To set a mob's delay timer, use the mob delay command. The trigger has a <percent> chance of activating when the delay timer hits 0, although in almost every usage of this command, 100 is used for the <percent> parameter. Delay triggers are known to occasionally and randomly not work. Delay timers will only count down if players are currently in the mob's area or have recently been in the area. It is important to note that delay triggers are checked at the same time as schedule and random triggers. A simultaneous schedule trigger activation will override a delay trigger, and a delay trigger will likewise override a random trigger activation.

EXALL

addmprog <vnum> exall <exit number/"all">

The exall trigger works exactly like the exit trigger with the difference that the mob does not have to see the target character in order to activate the trigger. For further information, please see the EXIT trigger.

ENTRY

addmprog <vnum> entry <percent>

The entry trigger is activated whenever the mob walks into a new room. The trigger has a <percent> chance of activating on each mob movement. The entry trigger does not carry a $n target into the mobprog, so, in general, this trigger is not as useful as greet or grall.

EXIT

addmprog <vnum> exit <exit number/"all">

The exit trigger is checked whenever a PC tries to exit the mob's room. The trigger will activate whenever a player tries to use <exit number>'s exit. It is important to note that if an exit trigger activates, the player's movement will be cancelled - so if you want a player to be able to move after an exit trigger has been activated on him, you'll need to use the mob transfer or mob exitpermit commands. The exit trigger will only activate if the mob can see the target character. Exit triggers will activate for mobiles as well, so exceptions will have to be made within the prog to avoid this if desired.

The following <exit numbers> collaborate with the indicated exits:

0 - north  1 - east  2 - south  3 - west  4 - up
5 - down   6 - ne    7 - nw     8 - se    9 - sw

FIGHT

addmprog <vnum> fight <percent>

The fight trigger is checked at the end of each combat round for the mob. The trigger has a <percent> chance of activating each round. Both a hpcnt trigger and a fight trigger can activate in the same combat round. Most mob combat routines are activated with the fight trigger.

GIVE

addmprog <vnum> give <object>

The give trigger is checked when an object is given to the mob. When an item of keyword <object> is given to the mob, the trigger activates. The phrase 'all' can be used for <object> to cause the give trigger to activate when any item is given to the mob. In the mobprog triggered by the give trigger, the variable $o represents the object given. It is common practice to design all give triggers with the 'all' phrase and then have specific object keywords checked within the mobprog. This is so that objects can be given back to the character who gave them with the 'give $o $n' statement.

GRALL

addmprog <vnum> grall <percent>

The grall trigger works exactly like the greet trigger with the difference that the mob does not have to see the target character in order to activate the trigger. For further information, please see the GREET trigger.

GREET

addmprog <vnum> greet <percent>

The greet trigger is checked whenever a character enters the room that the mob occupies. It has a <percent> chance of activating each time a character enters the room. Note that if several characters enter the room simultaneously, such as when characters travel in a group, the greet trigger will activate for each of the characters. The greet trigger activates for mobiles as well as players, so exceptions must be made within the prog to ignore them if desired. The greet trigger will only activate if the mob can see the target character.

HPCNT

addmprog <vnum> hpcnt <hp percent>

The hpcnt trigger is checked at the end of each combat round for the mob. The trigger will activate if the mob's hp percentage drops below the <hp percent> level. Both a hpcnt trigger and a fight trigger can activate in the same combat round. Hpcnt is frequently used as an easy way to activate mob desperation attacks.

KILL

addmprog <vnum> kill <percent>

The kill trigger is checked when someone initiates combat with the mob. The trigger has a <percent> chance of activating whenever someone initiates combat with the mob. This trigger only activates when someone attempts to kill the mob when it was not previously fighting. That is to say that the trigger activates only when combat is initiated, not when additional characters (such as groupmates) start attacking the mob.

RANDOM

addmprog <vnum> random <percent>

The random trigger is checked once every mob pulse for the game. A mob pulse is equal in frequency to a combat pulse. For reference, there are 15 mob pulses in a tick and a mob pulse triggers about once every 4 seconds. Random triggers have a <percent> chance of activating every mob pulse, but only if players are currently in the mob's area or have recently been in the area. A mob with the update_always act flag will have its random triggers checked every mob pulse, regardless of the status of players. Random triggers are commonly used for all sorts of mob activity. It is important to note that random triggers are checked at the same time as schedule and delay triggers, and the simultaneous activation of either of these triggers will prevent a random trigger from happening. Random triggers can activate while a mobile is fighting, but sometimes it will not, so it is not reliable.

SCHEDULE

addmprog <vnum> schedule <hour/"all">

The schedule trigger is checked once every hour, on the hour. The <hour> parameter equals a number from 0 to 23, where 0 is midnight and 12 is noon. If the <hour> equals the current hour, then the trigger activates. Schedule triggers are commonly used for time-based mob activity, especially mobs that move based on the time of day. It is important to note that schedule triggers are checked at the same time as random and delay triggers, and the activation of a schedule trigger will override any simultaneous delay or random trigger.

• By using the "all" keyword instead of a numerical hour, this trigger can also be set to execute every in-game hour, which is about once per minute. This is similar to a Random 100 trigger, but somewhat less frequent and therefore using less of the server's CPU time.

SPAWN

addmprog <vnum> spawn <percent>

The spawn trigger is checked whenever a mob is reset into an area or loaded, either with a mob mload command or an immortal load mob command. When the mob is loaded or reset into the area, there is a <percent> chance that the spawn trigger will activate. For the most part, the spawn trigger is used to load equipment onto a mob when one does not want said equipment reset 100% of the time like with a normal reset, but there are a wide variety of uses.

SPEECH

addmprog <vnum> speech <phrase>

The speech trigger is mostly identical to the act trigger, with the biggest difference being that the speech trigger only activates when a mob or player uses the 'say', 'osay', or 'tell' commands. The speech trigger is best used when one wants to limit mob response to speech instead of actions. Of further interest, the speech trigger will occur AFTER the target has actually spoken, unlike the act trigger. For further information, please see the ACT trigger.

SURRENDER

addmprog <vnum> surrender <percent>

The surrender trigger, while present on the triggers list, is defunct and is not actually used.

• I like using this trigger to show what mprogs my mob calls within its other mprogs. -Ageatii

Mobprog Troubleshooting

Aside from improperly coding mobprogs, they sometimes don't work for less obvious reasons. Below is a basic guide to help troubleshoot mobprogs that appear like they should be working. You can also always ask other Builders for help.

Inside Progs

There's nothing much more to say about checking for typos other than, checking for them. Assuming nothing is simply misspelled, there are other typo-like errors to look for.

• Ensure placement of the variable(s) in the right place in the command, i.e. "give $n $o" is backward.
• A common error is to accidentally type things like, "mob get item" instead of simply "get item". Mobs can perform basic tasks without a 'mob' signifier.
• A space at the end of a mob command will cause it to not fire. Spaces at the beginning of lines are allowed and do not interfere with the command firing, but at the end, e.g. "mob peace ", they will cause the command to not work. Highlight your mobprog and check for accidental spaces at the end of commands where it seems to be breaking.
• If the mobprog is shared with other mobprogs in the same vnum, ensure a previous mprog is not breaking the ones after it. Missing or extra endifs in previous mobprogs can also cause these errors, so a perfectly written mobprog may not execute if it's stacked with another incorrectly written prog ahead of it in the stack.
• Double check things like "if vnum $i" checks to make sure the mob that is supposed to perform the action is properly written.

Trigger Errors

• An act trigger for a mob that requires a social needs syntax as the mob sees it. This will be the same as seeing the social used on yourself, so forcing a mob to use the social on you will show you what the mob being acted upon will see.
• It is unadvised to use any part of the social echo that includes a pronoun, as there are many pronouns and you would have to add an additional trigger for each pronoun possible. This may still wind up breaking in the future if we add more genders.
• Act triggers that involve an item with color codes require the actual typed characters in perfect sync with the short of the item. This means if you color code your item like so, "a {Ggreen{R snapple{X" but write your act trigger like so, "a {Ggreen {Rsnapple{X", the act trigger will not fire. Remember: The game doesn't "see" colors, it sees the color codes as characters.
• If mobprogs do not appear to be triggering at all, please double check the wiki to ensure they do not interfere with other mobprogs, for example schedule triggers override simultaneous delay and random triggers. Two different mobprogs with the same trigger can't both activate at once, either.
• Ensure you are using the proper variant of GREET vs. GRALL and EXIT vs. EXALL if these appear to be improperly firing. Only use greet and exit if you do not want the mob to react to sneaking, hiding, or otherwise invisible players.

Further Testing Tips

• A good method for troubleshooting a mobprog that otherwise appears to be properly written is to have the mob 'say' or otherwise announce each step of the mobprog. Adding the variables being used into the says can help ensure that other parts are happening correctly as well. When you do not see the expected extra says, you can assume the error is somewhere close by.
• Utilizing "mpstat [mobname]" will also help ensure that expected behaviors are occurring in the background, as far as counters, remember target, and delay timers.
• While testing a prog that involves a quest flag, you can force mobs to quest you and unquest you to ensure each step of the prog is reacting properly to the quest flags.
• Immortals cannot be forced by mobs, so it's common practice to make a test character to bring in and test such mobprogs for accuracy.