MadROM Documentation

The #MOBPROGS section

** Note: most of this taken from the DOC file which came with the MOBprograms distribution file. The patch work will be pretty bad. Sorry.... it just tells you what you need to know!

Ways to associate programs with MOBS:

The first involves a simple in-file approach. In the mobile section of your area files, at the end of the mobile's block (i.e. on the line following the typical position/default position/sex line), append any number of MOBprograms (using the syntax above) followed by a line starting with a '|' (pipe). This is demonstrated above.

The second method is to add a #MOBPROGS section to the area files. Logically this section should follow the #MOBILE section since otherwise the mobiles probably wont have space allocated for them. In the #MOBPROGS section, list as many lines as you desire of:

"M" {Vnum} {MOBprogram_filename} NL

followed by a line starting with a 'S' (case insensitive) The Vnum is whatever number mobile to which you are associating the MOBprogram. The MOBprogram_filename is the name of the external file of MOBprograms. It is not case insensitive and may include directory heirarchies (foo/bar/xx).

/ It is up to you which method you use. I would prefer that all * builders working on our project pick one and stick with it...makes life * easier for me.... * I don't think it is possible to have a single file with all of your * programs for all of your mobs...might be a suggestion for murph. /

--Trigger Types Triggers are fairly easy to add, but this basic list should hold for most needs. Their names, argument list syntaxes, and translation into more articulate english are given below:

in_file_prog The argument is a single word which is the location of the stored file as referenced from the running directory. -Dummy trigger. Not valid in any file, only for use in loading files from the first method described two sections above.

act_prog The argument is a list of keywords separated by spaces. If the first word is the character 'p' by itself then the rest of the word list is considered to be a phrase. The trigger is activated whenver a keyword (or the phrase) is contained in the act() message. Both the phrase and keywords are case insensitive. -Most general trigger. Applies to almost every event which happens in the mud. Anytime the function act() is called with a message to be delivered TO_CHAR,TO_VICT,TO_ROOM,etc. the act can be triggered. Basically this will trigger on almost everything you'll ever want (and some things you wont as well) For example: MOBprogram: >act_prog p pokes you in the ribs.~ This trigger will only be activated if a mobile receives a message in which the above five words are found in the exact order and spacing given. Note that the period is needed because the words must be found on their own. This eliminates confusion when the keyword is 'hi' and a message with the word 'this' is being checked.

speech_prog The argument is the same as for an act_prog. -This is only triggered when the keyword or phrase is contained in a message which has been said by a PC in the same room as the mob. The PC restriction is not necessary, but makes infinite loops between two talking mobiles impossible. It also makes it impossible for two NPC's to stand and discuss the weather however.

rand_prog The argument is a number betweeen 1 and 100 inclusive. -This trigger is checked at each PULSE_MOBILE and if the argument is greater than a percentage roll the trigger is activated. This will happen even if there is no PC in the room with the mob, but there must be plauers in the same area. It is useful to give mobiles a bit of a personality. For instance a janitor who stops to spit tobacco, or complain about the hours, or wonder why there are no woman janitors on muds, or a fido which barks or growls or pees on the curb is much more alive than one which just sits there scavenging.

fight_prog The argument is a percentage like in rand_prog. -Useful for giving mobiles combat attitude. It is checked every PULSE_VIOLENCE when the mobile is fighting. Can be used to cast spells, curse at the opponent, or whatever. Only the first successful one will be processed to save time. Also, this means that the mobile wont get lucky and 1. curse, cast a fireball and 2. spit on the player, cast another fireball in the same pulse.

hitprcnt_prog The argument is a percentage. -Is activated at each PULSE_VIOLENCE when the mobile is fighting. It checks to see if the hitpoints of the mobile are below the given percentage. Multiple hitprcnt_progs should be listed in increasing order of percent since a 40% will always be activated before a 20% and, only the first successful hitprcnt trigger is performed.

greet_prog Again a percentage argument. -Whenever someone enters the room with the mobile, and the mobile saw the person enter, this is checked. Good for shopkeepers who want to welcome customers, or for pseudo-aggressive mobiles which need to discriminate on who they attack.

all_greet_prog Again a percentage argument. -Like greet_prog, but it can be triggered even if the mobile didnt see the arrival (i.e. sneak, invis, etc). Most useful for faking teleport rooms (if your mobiles can transfer) or for impassable guardians. NOTE: neither greet_prog is activated if the mobile is fighting.

entry_prog Again a percentage argument. -The opposite of a greet_prog. Whenver the mobile itself enters a new room, this can be triggered. Useful for looking around, or waving or other things that real PCs do when they arrive at a crowded room. Only the first successful one of these is done so the mobile doesnt look stupid by repeating commands resulting from multiple MOBprograms.

give_prog The argument is either the complete name of an object, or the word 'all'. A complete name is like: "sword shiny magic" vs "sword". It is whatever is on the line of the object section following the VNUM. -This is triggered whenever something is given to the mobile. Best used for quests. Since the first successful trigger is the only one of this type which is processed, having an "all" argument give_prog at the end of the MOBprogram list is essentially a default response.

bribe_prog The argument is any positive integer number. -This trigger is activated whenever money is given to the mobile. If the amount given exceeds the number, then process the commands. Note again, that an argument of '1' would act as a default response. If money is given to a mobile with this trigger type, instead of the cash being added to mob->gold, the mobile is instead given a pile of coins in the proper amount. In this way, the mobile can drop the coins or refer to the object by "amount" (short description:"%d gold coins") This surely has some drawbacks, but it lets the mobile do something with the bribe (NOTE: dropping it and getting it turns it into cash) This can be done sneakily if a NPC-only "at" command exists.

death_prog The argument is a percent once again. -When the mobile dies, if the random percentage is less than the argument the mobile performs the MOBprogram commands rather than the usual death_cry sequence. This is done before the corpse is made, so the commands can be considered the mobiles last gasp. It could perhaps destroy the items it was holding, or create some, or cast a spell on the killer and the room, or even goto a new location and die there (with a text message, the corpse would seem to vanish) The position of the mobile is set to STANDING, and so it can do all the normal commands, without worrying about being DEAD. However, even if the mobile restores itself to full hitpoints, it will still die. This is not a way to immortal mobiles. However, the last thing this mobile does could be to goto some vacant room, load a fresh version of itself, drop all its items, force the new mobile to get all the items and wear them, send the new mobile back to the character who killed it and force the new mobile to attack that character. Along with a text message which said the mobile restored itself, this might be a convincing effect. (Note that your kitten could turn into a dragon this way too). Of course this assumes that some NPC commands have been implemented.

-- Variables

You can use these anywhere in your program to reference names.

variable mobile actor victim random object 2nd_object

name $i $n $t $r $o $p shrt_desc/title $I $N $T $R $O $P he/she/it $j $e $E $J -- -- '$'symbol=$$ him/her/it $l $m $M $L -- -- his/hers/its $k $s $S $K -- -- a/an -- -- -- -- $a $A

--Control Flow Syntax In place of any legal mud command in a MOBprogram, one can substitute a flow of control command. Here is the syntax for a flow of control command.

"if" " " {if_check_1} "(" {argument} ")" [ {operator} {value} ] NL [ "or" " " {if_check_2} "(" {argument} ")" [ {operator} {value} ] NL ] . . . [ "or" " " {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 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 line: 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.

The break command bails out of the entire MOBprogram regardless of the level if nesting.

These are all the if_checks:

ifcheck argument? meaning

rand(num) Is a random percentage less than or equal to num isnpc($) Is $ an NPC ispc($) Is $ a PC isgood($) Does $ have a good alignment isfight($) Is $ fighting isimmort($) Is the level of $ greater than max_mortal ischarmed($) Is $ affected by charm isfollow($) Is $ a follower with their master in the room isaffected($) & integer Is ($->affected_by & integer) true (person only) hitprcnt($) == percent Is the hit/max_hit of $ equal to percent inroom($) == integer Is the room of $ equal to integer (person only) sex($) == integer Is the sex of $ equal to integer position($) == integer Is the position of $ equal to integer level($) == integer Is the level of $ equal to integer class($) == integer Is the class of $ equal to integer goldamt($) == integer Does $ have a gold total equal to integer objtype($) == integer Is the type of $ equal to integer (armor,boat,etc) objval#($) == integer Is $->value[#] equal to integer (# from 0-3) number($) == integer Is the vnum of $ equal to integer name($) == string Is the name of $ equal to string align($) == integer Is the alignment of $ equal to integer tribe($) == string Is the tribe_abbreviation of $ equal to string isleader($) Is the target equal to true (is a leader?) ispet($) Is the target a pet isntpet($) Is the target NOT a pet race($) == string Is the race of the target equal to string mobhere($) == integer Is target in_room->vnum equal to integer (no integer for local room) objhere(vnum) == integer Is object vnum in room->(integer) hasobj($) == integer Is $* carrying obj->vnum->(integer) in $s inventory?

--Operators Most of the basic numeric operators are legal and perform the same function as in C. The string operators are a bit more confusing. There are negative versions of some of the operators. These are not strictly needed, since the if/else construct of Control Flow commands can handle either case.

Numeric Operators: == != > < >= <= & | String Operators: == != / !/

For strings, == and != check for exact match between the two strings and the other two, / and !/ check to see if the second string is contained in the first one. This is so things like: if name($n) / guard will respond true to "cityguard" "guard" "guardian" etc. Using == on a name implies that you are matching the complete name "cityguard guard" or whatever. The string operators are case SENSITIVE.

--Special commands to use in programs!

Here are the basic MOBcommands that we found to be enticing:

MPDAMAGE {kill} Damages a target according to min and max. Using the kill arg will allow this attack to be lethal, otherwise it'll merely take the target to 0 hp. This is silent and will require descriptive echos.

MPSTAT shows the MOBprograms which are set on the mob of the given name or vnum and some basic stats for the mobile

MPASOUND text_string 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.

MPJUNK destroys the object refered to in the mobiles inven. 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 MOBprogram trigger on the 'full inventory'). Use of the "inven" arg will only cause items in the mobiles inventory to be extracted.

MPECHO text_string MPECHOAT text_string MPECHOAROUND text_string prints the text message to the room of the mobile. The three options let you tailor the message to goto victims or to do things sneaky like having a merchant do: mpat guard mpechoat guard rescue_please This coupled with a guard act_prog trigger on rescue_please to mpgoto $n and mpecho $I has arrived. is an affective way of quickly bringing guards to the scene of an attack.

MPLOAD M[obile] MPLOAD O[bject] loads the obj/mobile into the inven/room of the mobile. Even if the item is non-takable, the mobile will receive it in the inventory. This lets a mobile distribute a quest item or load a key or something.

MPKILL lets a mobile kill a player without having to murder and be fifth level. Lots of MOBprograms end up with mpkill $n commands floating around. It works on both mobiles and players.

MPPURGE [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, mppurge $i will indeed purge the mobile, but it MUST be the last command the mobile tries to do, otherwise the mud cant reference the person trying to do the commands and bad things happen.

MPGOTO 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 mpecho commands if they are desired.

MPAT perfoms the command at the designated location. Very useful for doing magic slight of hand tricks that leave players dumbfounded.. such as metamorphing mobiles, or guard summoning, or corpse vanishing.

MPTRANSFER [dest] 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 transfered to the destination. Good for starting quests or things like that. There is no message given to the player that it has been transfered and the player doesnt do a look at the new room unless the mob forces them to. Immortals cannot be transfered.

MPTECHO (MadROM only...will work only if the mob with this prog is given an X tribe in the area file, so that he belongs to that tribe). Lets the mob echo a message to all members of the Tribe that the mob belongs to.

MPMORPH (this is available on MadROM, but may not be available on other muds) shapeshifts the victim into a specified mobile. I strongly suggest that the mobile prog include a 'mpoload mob to be morphed into' before the morph command, and that a check for ispc victim be done first.

MPFORCE 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. This cannot be used on immortals.