Twilight Realms

Official Scripting Guide

 

 

Ever wonder why some areas are spammy and others are just plain dull? Scripting. Mobiles are great and usually abundant, but left to their own, they do nothing but stand there and wait to be slaughtered. So to make things come alive we use scripting.

The variables are as follows:

$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 scripting target (see MOB REMEMBER)

$Q the short description of the scripting 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 doesn't 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 wei rd 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 scripting.

The following help files are available for these triggers (or will be):

act ___bribe___ death___ entry

fight ___give ___greet___ grall

kill___ hpcnt___ random___ speech

exit___ exall___ delay

Trigger

Prog

SYNTAX

 

ACT

ACT_PROG

addmprog [vnum] [trigger] [phrase]

when an action causes a mob to respond

BRIBE

BRIBE_PROG

addmprog [vnum] bribe [number]

when an amount of coin is given to the mob

DEATH

DEATH_PROG

addmprog [vnum] death [number]

when the mobile dies, but it executes the script prior to dying

DELAY

DELAY_PROG

Addmprog [vnum] delay [number]

Calls for a delay in the script

ENTRY

ENTRY_PROG

addmprog [vnum] entry [number]

when the mob enters a room

EXIT

EXIT_PROG

addmprog [vnum] exit [number]

when a player is trying to exit in a certain direction

EXALL

EXALL_PROG

addmprog [vnum] exall [number]

exiting

FIGHT

FIGHT_PROG

addmprog [vnum] fight [number]

give the mob “character" while it's in combat

GIVE

GIVE_PROG

addmprog [vnum] give [vnum2]

when something is given to a mob and it gives something else

GREET

GREET_PROG

addmprog [vnum] greet [number]

whenever a player enters the room

GRALL

GRALL_PROG

addmprog [vnum] grall [number]

when every player enters a room, best used with mob_remember

HPCNT

HPCNT_PROG

addmprog [vnum] hpcnt [number]

Checked every round of combat

KILL

KILL_PROG

addmprog [vnum] kill [number]

this is checked whenever the player attacks the mob

RAND

RAND_PROG

addmprog [vnum] random [number]

random occurrences that add to the "reality" of an area

SPEECH

SPEECH_PROG

addmprog [vnum] speech [string]

when a phrase is the trigger (string)

 

ACT Syntax: addmprog [vnum] [trigger] [phrase]

Keyword : 'act'

Argument: string

The argument is a phrase, a text string. The trigger is activated whenever the phrase is contained in the act ( ) message.

NOTE: 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. Output of "say", "shout" and "emote" do not trigger this event.

BRIBE Syntax: addmprog [vnum] bribe [number]

Keyword : 'bribe'

Argument: number

The argument is any positive integer number.

NOTE: 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. Also note that if the script is not triggered (because of too little money having been given), the mobile still keeps the money...

ROM 2.4 NOTE: Since ROM 2.4 has two different types of currency (gold and silver coins), for bribe trigger the amount to be given is converted to silver coins with the rate of 1 gold = 100 silver, thus the number in the number in the argument should be the expected amount in silver coins.

DEATH Syntax: addmprog [vnum] death [number]

Keyword : 'death'

Argument: number

The argument is a percent once again.

NOTE: 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 (see help MOB_REMOVE and MOB_JUNK), or create some (see help MOB_OLOAD), or cast a spell (see help MOB_CAST) on the killer and the room, or even goto a new location (see help MOB_GOTO) 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).

NOTE: NEVER use the following script in a Death prog: mob purge $i (using mob purge $i will result in a game >>Crash<<) If this happens for any reason I will personally hunt you down and make you fix it. Your status as an Immortal on Twilight Realms could be jeopardized.

 

DELAY Syntax: addmprog [vnum] delay [number]

Keyword: ‘delay'

Argument: number

A percentage argument.

What this does is causes a delay in a script. For example: you want a mob to run a script and have it fire another program that you specified, so you can have pauses between a mobile doing something. Like the mob will scream at a player, then pause, and if the player hasn't moved, the mob will scream at him again. It will only delay once per mob/room/obj.

 

ENTRY Syntax: addmprog [vnum] entry [number]

Keyword : 'entry'

Argument: number

Again a percentage argument.

NOTE: The opposite of greet trigger. Whenever 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.

IMPORTANT: In an entry program, the mobile can only refer to a random pc ($r in if checks) -- there's no way to know how many PCs exist in the room the mobile enters! Also, you must check visibility of the target in your program.

 

EXIT Syntax: addmprog [vnum] exit [number]

Keyword : 'exit'

Argument: number

Argument is the exit number (0:north, 1:east, 2:south 3:west etc.)

NOTE: The opposite of entry trigger. This is activated when PC tries to leave a room through an exit indicated by the argument, and the mobile sees the person leave. Useful for having a single guardian to

watch several exits. An exit trigger works better than an entry trigger, since you can refer to a specific PC instead of a random PC.

IMPORTANT: If this event is triggered, the victim will not move through the exit. If necessary, you must move the character yourself in your program (see MOB TRANSFER/MOB GTRANSFER). Also, this event is not triggered when a character flees from combat or the mobile is not in its default position.

 

EXALL Syntax: addmprog [vnum] exall [number]

Keyword : 'exall'

Argument: number

Argument is the exit number (0 = north etc. )

The same as exit trigger, but it can be triggered even if the mobile cannot see the person trying to leave the room or if the mobile is busy.

 

FIGHT Syntax: addmprog [vnum] fight [number]

Keyword : 'fight'

Argument: number

The argument is a percentage.

NOTE: Useful for giving mobiles combat attitude. It is checked every PULSE_VIOLENCE when the mobile is fighting. Can be used to cast spells (see help MOB_CAST), curse at the opponent, or whatever. Only the first successful one will be processed to save time. Also, this means that the mobile won't get lucky and 1. curse, cast a fireball and 2. spit on the player, cast another fireball in the same pulse.

 

GREET Syntax: addmprog [vnum] greet [number]

Keyword : 'greet'

Argument: number

A percentage argument.

NOTE: 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. Greet trigger activates only when the mobile is not busy (fighting, sitting, sleeping etc.). If you want to be sure to catch all players, use grall.

 

GRALL Syntax: addmprog [vnum] grall [number]

Keyword : 'grall'

Argument: number

Again a percentage argument.

NOTE: Like greet, but it can be triggered even if the mobile didn't see the arrival (i.e. sneak, invis, etc) or is busy. Most useful for faking teleport rooms or for impassable guardians.

 

HPCNT Syntax: addmprog [vnum] hpcnt [number]

(Hit Po int Percentage)

Keyword : 'hpcnt'

Argument: number

The argument is a percentage.

NOTE: 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 hpcnt triggers should be listed in increasing order of percent since a 40% will always be activated before a 20% and, only the first successful trigger is performed. (See also help MOB_FLEE).

 

KILL Syntax: addmprog [vnum] kill [number]

Keyword : 'kill'

Argument: number

The argument is a percent once again.

NOTE: This trigger is checked whenever a PC attacks the mobile. The check occurs only ONCE, in the beginning of combat. Useful for summoning assistance etc. (See help MOB_MLOAD).

 

RANDOM addmprog [vnum] rand [number]

Keyword : 'random'

Argument: number

The argument is a number between 0 and 99 inclusive.

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

Note that this trigger is checked only when there are players in the area.

 

SPEECH Syntax: addmprog [vnum] speech [string]

Keyword : 'speech'

Argument: string

NOTE: This is only triggered when the 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.

 

DROP GET GIVE PUT TAKE

Syntax: drop <object>

Syntax: drop <amount> coins

Syntax: get <object>

Syntax: get <object> <container>

Syntax: give <object> <character>

Syntax: give <amount> coins <character>

Syntax: put <object> <container>

DROP drops an object, or some coins, on the ground.

 

GET gets an object, either lying on the ground, or from a container, or even from a corpse. TAKE is a synonym for get.

GIVE gives an object, or some coins, to another character. Another way to use give is when you give a mob an item. Say you set it up so that a mob is actively hunting particular herbs, if given those herbs, it will repay the character by offering them another item, or money. Also useful in writing quests.

syntax is: addmprog [vnum] give [vnum2] with vnum2 being the item the mob wants' vnum

PUT puts an object into a container.

DROP, GET and PUT understand the object names 'ALL' for all objects and 'ALL.object' for all objects with the same name.

Now on to building your scripts.

MPEDIT Create begins creation of a new script

A VNUM is the script virtual number that identifies the program. The number must be unique across area files (like mobile and object vnums).

CODE enters the script editor to begin writing the script. The same commands apply here as for editing or writing descriptions in regular building. Do not forget to save and save often!

I'll use asterisks to define what is done * * . This is a greet all script for my office mob. This script will cause her to greet anyone she sees entering the room.

 

Mpedit create 1250

Code

Medit 1250

Addmprog 1250 Grall 100

Translation:

MPEDIT CREATE 1250 *creates script 1250*

CODE *enters editor to begin writing the script*

*Script of whatever you want the mob to perform*

Example:

if name $n Kechara

say Greetings, my Mistress!

emote bows deeply.

Else

Snort

Say I do not answer to thee, only to my Mistress!

Endif

*Save your script*

MEDIT 1250 *enters the edit for mob 1250*

Addmprog 1250 Grall 100 *adds/links the script 1250 to mob 1250 to greet anyone who enters the room*

DONE *exits medit*

NOTE 1: Omit all unnecessary spaces from your scripts. If you must have indentation, use TAB.

NOTE 2: For each if/else there must be an endif. Failure to insert the appropriate number of endifs will cause the script not to work, or only work up to a certain point.

 

--------------------------Linking Scripts to Mobs--------------------------------

 

Once you've written your script, you must link the script to appropriate mobiles.

Command: Addmprog {Vnum} {Keyword} {Argument}

You must be in MEDIT to add a script to the mobile.

Example: Addmprog 1250 grall 100

Explanations:

The KEYWORD is a single word, hereafter referred to as a TRIGGER , see below for explanations.

The VNUM is the script virtual number.

The ARGUMENT is the argument that triggers the event.

--Example

addmprog 1250 grall 100

In the above example, a GREETALL trigger is defined. When the mobile sees someone entering the room, the mobile will execute script number 1250.

NOTE: Several mobiles can use the same script, i.e. scripts can be SHARED with several mobiles. The keyword and trigger argument can be different for each mobile even if they share the same script code.

Now you've created and added your first script. Where you go and what you do from here is limited only by your imagination. Remember not all mobs need to be scripted. It can get spammy when every creature is talking your ear off, emoting like crazy or just being a royal pain. The usual ratio is 2:1, meaning out of every 2 mobs, at least one will be scripted.

EXAMPLES

ACT_PROG EXAMPLE

ADDMPROG act_prog pokes you in the ribs 100

if isnpc $n

chuckle

poke $n

break

else

if level $n <= 5

or isgood $n

tell $n I would rather you didn't poke me.

else

if level $n > 15

scream

say Ya know $n. I hate being poked!!!

if mobhere guard

mob force guard kill $n

endif

kill $n

break

endif

slap $n

shout MOMMY!!! $N is poking me.

endif

endif

time to translate. The trigger will only happen when the mobile gets the message “... pokes you in the ribs...” If the offender (recall the $n and $N refer to the char who did the poking...) is an NPC, then the mobile merely chuckles and pokes back. If the offender was a PC then good and low level characters get a warning, high-level chars get attacked, and midlevel chars get slapped and whined at. Also, when attacking, the mobile will check if there are guards in the room (if mobhere guard) and if one is found, it will be forced to attack the player, too (mob force guard mob kill $n). Notice the use of the script command, “mob force”.

B. EXIT EXAMPLE

This program could be used on a temple guardian mobile, whose job is to prevent evil characters from entering the sanctuary. Let's assume the exit to the temple is north (exit 0) and the temple antechamber is room 2301.

exit_prog north

if isgood $n

say Hail!

emote salutes $n.

if carries $n holy

mob transfer $n 2301

else

say If you wish to enter the temple, get a holy symbol.

endif

else

curse $n.say Get lost, you scum!

endif

How this works: The trigger is activated when the player tries to exit north from the room. If the player is of good alignment, the guard will greet the player. However, the guard will not let the player to the temple unless he or she carries a holy symbol. If the player is neutral or evil, the guard will curse and block the way.

C. DELAY/REMEMBER EXAMPLE

GRALL_prog 100

if isevil $n

say You infidel! Go away or face the wrath of Jehosephat!

mob remember $n

mob delay 30

break

endif

 

delay_prog 30

if hastarget $i

growl

mob echo $I screams and attacks $Q.

mob kill $q

else

mob forget

endif

 

How this works: When the player enters a room, the mobile checks if the player is evil. If this is the case, the mobile makes the player the target (mob remember) and sets up a delay of 30 seconds.

When the delay expires, program is activated. The mobile checks if the target is still in the room (hastarget), and if the player hasn't left, the mobile attacks ($q and $Q refer to the target). If the player has left, the mobile will forget the player (mob forget)..

One other type of script I'm hoping to see implemented is the timered scripts. These are great for stationary mobs like shopkeepers, bartenders and so on. The script calls for the mob to perform certain actions or say things at timed intervals. Mobs can be set to react to a key phrase which will call the script.

Example:

mob echoat $n $T brushes back your hair and bites you on the neck!

mob kill $n

if isgood $n

say Bah! Your blood tastes most foul. You are not fit for consumption! Away with you!!

Mob transfer $n 5500

else

if isneutral $n

say You are not worth the time and effort it would take to drain your feeble carcass.

mob transfer $n 5500

else

if isevil $n

say Ahhhhhh, the exquisite taste of bad blood!

mob timer 10 say Hold still you tasty morsel!

mob timer 15 say How you do you expect me to drain your life if you don't hold still?

mob timer 19 say Cease your struggles, you pathetic creature, you are only prolonging your agony!

mob timer 23 say The blood of evil ones flows through you!

mob timer 24 emote licks your blood from its lips and grins evilly.

endif

endif

endif

 

Translation:

This causes the mob to bite anyone who enters the room it is in. Their alignment triggers the mob's actions. If the player is of good or neutral alignment, the creature transfers the player to another room. If the player is of an evil nature, the creature responds to its timered script while combating the player. The times are the seconds that the mob will perform the action so after 10 seconds the mob will say the first command, at 15 seconds will say the next command and so on. These types of scripts do not need combat to be induced. Any action can prompt them.

 

COMMAND_INDEX

The following is an index of all the help files for mob commands (or will soon be):

MOB COMMAND - HELP FILE

-Script Commands

Script commands are special commands that allow mobiles to perform immortal-like actions within a script (transferring players or loading items, for example). Most script commands them are wiz commands which have been changed to allow for mobiles to perform the commands. In this version of scripts, players have been prevented from using these commands by adding a separate interpreter for script commands. This also speeds up (in most cases) script execution when script commands are used. All script commands are preceded with the word 'MOB' on the command line.

 

Syntax: MOB HUNT ['clear'|victim]

HUNT causes the mob to stop hunting whoever he is at the moment, and start hunting the victim specified. The victim does not have to be visible to the mobile to be hunted by the mobile. This does not guarantee that he will catch up with him, however.

'hunt clear' will stop a mobile from hunting anyone. A mobile may only hunt one victim at a time.

 

Syntax: MOB ASOUND [string]

MOB ZECHO [string]

MOB GECHO [string]

MOB RECHO [room vnum] [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.

RECHO sends an echo to the room vnum specified.

Syntax: MOB DESCRIBE ['obj'|'mob'] [name] [type|'reset'] [string]

DESCRIBE lets a mobile effectively rename or redescribe an object or another mobile. For good practice, the mobile should be in the same room as the object or mobile he/she is attempting to redescribe. You cannot redescribe PC mobiles, attempting to do so will trigger an error message, so please make the appropriate checks in your script code first.

If you wish to 'reset' the mobile or object back to its ORIGINAL unaltered descriptions (the ones that are default for that particular object, you may substitute the type for 'reset'.

Types of descriptions that can be altered are:

name long short description

Description strings are automatically formatted, the others are not. This command can be used to 'restring' an object or a mobile. Po ssible uses are shapeshifting mobiles, objects that are charred in battle, and mobile restringers. However, please do not use this to make a mobile restringer, as there is a special procedure for them already.

 

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 affective 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 HEAL [victim] ['hp', 'stamina' or 'magic'] [amount]

NOTE: HEAL allows you to increase the amount of hit points, stamina, or spell points (magic) a player or other mobile has, up to their current maximum. It can be used negatively, to subtract the same from the victim, down to a minimum of 0 or 1 (in the case of hit points). It cannot be used to kill a creature, however, as the minimums are enforced.

Example: mob heal self 1000

Example: mob heal $N 500

Example: mob heal $N -250

 

Syntax: MOB TELEPORT [victim] [type]

NOTE: TELEPORT lets you have your mob teleport himself or someone else to random locations within the world. Type can be one of the following: zone, zone-novirtual, anywhere, anywhere-novirtual, or area. If the victim is mounted, or mounted by someone else, it will transport them as well. If the victim is fighting, it will stop the fight. The teleport victim, if awake, will automatically be shown the room description of the room he teleports into.

 

Syntax: MOB MEMORY [victim name|'clear'] [memory type]

[duration|'default'|'forget'] [intensity|'default']

[string]

sa MEMORY is a complex function that allows you to directly manipulate a mobile's memory information. Memory is used to remember fleeing mobiles and attack them later; to run away from them if they see them again; to remember something the person has said to them; etc.

'memory clear ' will wipe that particular type of memory from the mobile's memory. A victim's name is not required.

'memory clear' will wipe the mobile's memory completely. Otherwise, a victim name must be specified, and it must be someone in the current room and visibile to the mobile.

Memory type can be one of the following memory types:

hating fearing customer friend indifferent information

Memory duration can be a number from 0 to 999, each number stands for one normal game tick. Therefore a duration of 10 would mean that the mobile would remember the memory addition for 5 real time minutes.

If 'default' is specified, the duration will be 4 + the mobile's level.

If 'forget' is specified (or the duration is 0), the memories that the mobile has of the victim and of the type specified will be erased.

Memory intensity is a percentage rating from 1-100, and is how strong the memory is for that mobile. For example, a mobile might be remembering someone as memory type 'friend' with an intensity rating of 80% - this would mean that the mobile would be best friends with the person, but may or may not want to lay down his or her life for them. Another example is that the mobile might be indifferent to someone with an intensity rating of 5% - this would mean that they are most probably ignoring the person.

If you specify memory type as 'information', then a specific string (all that follows intensity) will be stored in memory for later use by the mobile. You will need to specify this string.

By default, duplicate memory entries will be cleared when a new one is added of the same type and for the same target. This is true of all the memory types except information, of which you can remember as much as you like about the mobile.

It is up to the builder to make sure that memory entries that conflict each other (such as a mobile hating and being friends with someone at the same time) in order to keep problems from occuring.

 

The system will automatically make aggressive mobs hate someone if they flee after attacking, and will make any mob that has attempted to flee from an attacking person automatically fear them. Keep this in mind when adding memory.

Mobile memory can be checked by the ifcheck 'memory', which is used in the following manner:

if memory $n hating

or if memory $n information friend

or if memory $n information whatever

You can use the memory ifcheck to check and see if a mobile is remembering $* as one of the types of memory listed above, or if the memory is of type 'information' you can do a wild string match (or a full case-insensitive string match, as in the second example) on the information stored in the mobile's memory string. This can be useful for remembering if the target has visited the mobile in the past and if they spoke about a certain quest item, or whatever. You may also use the string $A to put the argument that the person just spoke in the case of a speech_prog.

Mobile memory is completely cleared each boot.

 

Syntax: MOB MLOAD [vnum]

MOB OLOAD [vnum] [level] {'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. 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. The optional 3rd parameter can be specified; 'room' means to load the object to the room, 'wear' means to force the mobile to wear the object loaded (useful for equipping mobiles on the fly).

 

Syntax: MOB KILL [victim]

Lets a mobile attack a player. This does not kill the target, but rather initiates combat. It works on both mobiles and players.

 

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" behavior.

 

Syntax: MOB REMOVE [victim] [vnum|'all']

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.

 

Syntax: MOB JUNK [object]

Destroys the object refered 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 script trigger on the 'full inventory')

 

Syntax: MOB PURGE [vnum or name] ['object' or 'mobile'] DO NOT EVER USE without getting permission from an Imp, head builder or lead builder.

 

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 game can't reference the acting mobile trying to do the commands and bad things happen.

 

'Object' and 'mobile' are not required after the purge argument for backwards compatibility; however it is recommended that if you are using vnums o r d ubious names that you always specify which type (mobile or object) to purge from the room.

yExample: mob purge 4901 object

 

Syntax: MOB TIMER [seconds] [command or script # to call]

Timer causes a delay in execution of either a command or another script program.

Example: mob timer 500 say Well, I just rule.

In the above example, when the trigger that called the timer is hit, 5 minutes from then the mobile will say 'Well, I just rule'.

 

Another example: mob timer 300 2039

In the above example, when the trigger that called the timer is hit, 5 minutes from then the mobile will call script #2039.

 

Please note that you cannot have variables other than the mob-specific variables (such as $I, $i, etc. and their offspring) or variables that don't require a specific trigger (i.e., a greet_prog - you would not have a $n variable).

You cannot issue calls to functions that exist on other mobiles.

The maximum number of seconds a timer can be delayed is 3600, which is one hour.

The script that the timer calls should be type 'function_prog *' which isn't used for anything but mob call and mob timer.

 

Syntax: MOB CALL [script #]

This will execute another script program immediately. The script # is the script vnum of a function_prog *, which is created for this purpose.

You cannot issue calls to functions that exist on other mobiles.

 

Syntax: MOB FOLLOW [victim]

Causes the mobile to follow the person specified. Mobiles cannot follow if they are already in a formation themselves, and attempting to do so will generate an error message - this needs to be checked first. This does not prompt for a request, so it is available for NPCs as well as PCs, and causes them to follow instantly.

If 'self' or 'me' is specified as the target, the mobile will disband his formation.

 

Syntax: MOB AT [location] [command]

Perfoms the command at the designated location. Very useful fo r d oing magic slight of hand tricks that leave players dumbfounded.. such as metamorphing mobiles, or guard summoning, or corpse vanishing.

 

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 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 playe r d oesnt 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.

 

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 NPCs from the game (by forcing them to purge themselves).

 

Syntax: MOB CAST [spell] [victim]

Lets the mobile 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 LOG [text argument]

Writes a message to the system log file. This is useful for special quests, to record suspected problems with mobiles, etc. To view the system logfile you must contact a level 250 Immortal.

 

Syntax: MOB REWARD [reward type] [value or spell]

Lets the mobile reward a player with one of the possible rewards: practice, questpoint, experience, skill, gold, ap, or restore. Practice, Questpoint, Gold, and Experience require numeric values. Skill can either have a spell number (for instance, if you are rewarding someone a spell inscribed on a scroll or spellbook) or have the name of a spell. Restore just restores the person, if they are dead they will be reincarnated; either way their hit points, spell points, and stamina will be maxed and they will be stripped of certain offensive spells, such as curse or web.

NOTE: Use of this mob command is restricted; do not use it unless you have direct permission from an implementor.

 

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.

 

Syntax: MOB DELAY

MOB CANCEL

MOB DELAY sets the time in seconds after which the mobile's delay trigger is activated. If the mobile has a program defined fo r d elay trigger, the program is executed when the timer expires.

MOB CANCEL resets the delay timer to zero.

 

Syntax: MOB REMEMBER [victim]

MOB FORGET

This command enables the mobile to remember a player for future reference in a script. 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 OPENPASSAGE [from vnum] [to vnum] [direction]

MOB CLOSEPASSAGE [from vnum] [to vnum] [direction]

This command enables the mobile to create o r d estroy exits leading in certain directions, with or without being in the room that they lead to. For instance, a mobile might want to trap a player within his chambers by causing a boulder to cover the exit, or might open a secret door magically in exchange for some item, or if the player asks him in the right way. The direction can be any of the normal directions, i.e., north, south, east, west, up, down, northeast, northwest, southeast, and southwest.

 

Loading Mobiles and Objects

No doubt you want to load objects and mobiles in your scripts 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 script 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 "pur gem aster". 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 pur gem aster, and it will be destroyed sometime later.

The following is a list of available help directories (or will be):

HELP TRIGGER_INDEX

HELP COMMAND_INDEX

HELP VARIABLES

HELP MOB_TRIGGERS

HELP IF_CHECKS

HELP PURGEMASTER

HELP OBJ_PROGS

HELP EXAMPLES_INDEX

 

Room scripting and object scripting follow pretty much the same logic where in the script itself the word MOB is replaced with:

ROOM - for rooms

OBJ - for objects

example:

mob echo [string]

room echo [string]

obj echo [strings]

 

 

Once again, if you have any questions or doubts about what you are trying to make your mobs do, ask!! Other Immortals who have been scripting a little longer will be able to point you in the right direction. Mistakes cause game crashes and while the mistakes can be interesting, they tie up resources while someone goes in to fix the problem, not to mention the down time of the game that you work so hard on =)

 

Good Luck,

The Immortal Staff Of Twilight Realms

 

============== QUICK REFERENCE SHEET===================

 

trigger argument and what must happen to activate trigger

-----------------------------------------------------------------------------

act STRING to match from act ( ) to 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

----------------------------------------------------------------------------

variable mobile actor victim random target object 2nd_object

-----------------------------------------------------------------------------

name $i $n $t $r $q $o $p

short_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)

is charm $* 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 script 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

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]

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]

+++++++++ EXAMPLES +++++++++++++++

 

if isnpc $n

chuckle

poke $n

break

else

if level $n <= 5

or isgood $n

tell $n I would rather you didnt poke me.

else

if level $n > 15

scream

say Ya know $n. I hate being poked!!!

if mobhere guard

mob force guard kill $n

endif

kill $n

break

endif

slap $n

shout MOMMY!!! $N is poking me.

endif

endif

Ok.. time to translate.. the trigger will only happen when the mobile gets the message "... pokes you in the ..." If the offender (recall the $n and $N refer to the char who did the poking...) is an NPC, then the mobile merely chuckles and pokes back. If the offender was a PC then good and low level characters get a warning, high level chars get attacked, and midlevel chars get slapped and whined at. Also, when attacking, the mobile will check if there are guards in the room (if mobhere guard) and if one is found, it will be forced to attack the player, too (mob force guard mob kill $n). Notice the use of a MOBcommand "mob force". Note that two of these mobiles could easily get into an infinite poke war which slows down (or frequently crashes) the mud just a bit :( Be very careful about things like that if you can. (i.e dont respond to a poke with a poke, and try not to let heavily programmed robot mobiles wander around together. More on that is given above.) Also, it is clear that the 'order' command could get confused with the 'or' control flow. However, this is only the case when 'order' is abbreviated to its two letter form, and placed immediately following an 'if' line. Thus, if you want to be that malicious in trying to break the MOBprogram code, noone is going to stand in your way (However, the result of this would be a bug message and a bail out from the ifcheck so things dont really break)

 

Another example:

This program could be used on a temple guardian mobile, whose job is to prevent evil characters from entering the sanctuary. Let's assume the exit to the temple is north (exit 0) and the temple antechamber is room 2301

if isgood $n

say Hail!

emote salutes $n.

if carries $n holy

mob transfer $n 2301

else

say If you wish to enter the temple, get a holy symbol.

endif

else

curse $n

say Get lost, you scum!

endif

 

How this works: The trigger is activated when the player tries to exit north from the room. If the player is of good alignment, the guard will greet the player. However, the guard will not let the player to the temple unless he or she carries a holy symbol. If the player is neutral or evil, the guard will curse and block the way.

 

Example of using DELAY and REMEMBER

 

if isevil $n

say You infidel! Go away or face the wrath of mighty Mota!

mob remember $n

mob delay 10

break

endif

 

Example 2.

if hastarget $i

growl

mob echo $I screams and attacks $Q.

mob kill $q

else

mob forget

endif

 

How this works: When the player enters a room, the mobile checks if the player is evil. If this is the case, the mobile makes the player the target (mob remember) and sets up a delay of 10 * PULSE_MOBILE.When the delay expires, program #1003 is activated. The mobile checks if the target is still in the room (hastarget), and if the player hasn't left, the mobile attacks ($q and $Q refer to the target). If the player has left, the mobile will forget the player (mob forget).

 

Example of MOB CALL:

 

greet 1004 100

if isgood $n

else

mob call 1006 $n null null

endif

 

example 2.

mob echo Suddenly, a bright aura surrounds $I!

mob cast 'heal' $n

mob echoat $n $I points $l finger at you in fury!

mob echoaround $I points $l finger at $N in fury!

mob cast 'curse' $n

 

Click for a printable version ____WORD PAD____NOTEPAD____MS WORD

Back To Index