Okay, first off, if you want a brief overview of some things about mobprogs, please check out the FAQ. It will detail a few of the things that you can and can not do, ways to slightly get around things that you can not do and troublesome things that tend to happen over and over. Second, the examples are on another page. You might want to open a new window for the examples, if you’d like to see what I’m talking about in an actual, working mobprog.
But welcome to the Mobprog Guide. It was written for ROM 2.4, and was originally part of the building docs that I wrote for Solace (now defunct, but some former players and immortals are attempting to re-create it). I was receiving many requests from my builders there to teach them how to write mobprogs. However, the chance never seemed to come about to talk with them about writing mobprogs. So the idea got into my head that (1) they could learn them on their own time, (2) the documentation should be much easier to understand than what I had to read to learn them, (3) other people probably want to learn how to write mobprogs, too, and (4) maybe I ought to write that building document I was planning on writing and include the mobprogs there. And so all of that came to pass, the doc (all 55 pages of it) was out in 3 days, and shortly after that, I received an area with several working mobprogs from one of my builders ^.^ So then I later tossed that section of the guide online.
Once I had experience with building online, at a MUD named Kasana (which is now shut down), I decided to add the OLC aspects and commands into a separate guide. However, I have since consolidated them all into one guide. OLC commands are yellow, because yellow is easy to see and I didn’t feel like defining another span class.
This is meant for those who have experience building in ROM; offline building often requires that you must go into the area file in a text editor to add your mobprogs, and if you accidentally delete something (just one little tilde), you could mess your entire area up. Just be careful about what you do.
If you wish to have a copy of this guide for offline use, so you don’t have to go online whenever you want to check up on something, feel free to download a zipped HTML version of this document (13kb). It’s stripped clean of everything but the guide. I am also working on two other versions of the guide; one is a more-or-less plain text printable version, the other is a (please don’t kill me) Microsoft HTML help file.
Quick Table-of-Contents
- How they work
- Why they’re so damn cool
- Making them work
- A list of types of mobprogs
- A list of variables
- A list of viable commands
Section 1: How they work
Without getting overly technical, mobprogs work in a variety of ways.
Each way that they can be used is called a trigger. There are many
kinds of triggers that will activate, or execute the mobprog, in a
variety of situations. One works when a player enters the room with the
mob, another works at random intervals, and yet another works when a
player gives something to the mob.
Mobprogs have two distinct parts: one, as I already mentioned, is
the trigger. The second is the code of the mobprog itself – which is
what makes it work.
Whether you are building with OLC or offline, the trigger line goes
in much the same place. It always accompanies the mobile in the
appropriate section of the area file. Each trigger is accompanied by a
section of code, which is very easy to write and understand. It is
considerably easier than writing in a programming language such as C++
or Java. However, that’s just my opinion. I’m certain that someone
disagrees with me, although anyone who does is obviously insane and not
to be spoken to or trusted. Anyway, the code is always separated from
the trigger line, in the event that you wish to use the same block of
code for more than one different trigger.
Back to Top
Section 2: Why they’re so damn cool
They’re so damn cool because you can make your mobs do almost
whatever you want them to. Once you are proficient at writing mobprogs,
you can make them as interactive as a player. Of course, writing such a
mobprog would be a bit difficult, but it can be done. I leave it up to
you if you wish to do so; I refuse to debug a 400-line mobprog (and if
it were my mobprog, I’d break the thing up into easy-to-manage chunks).
Nearly anything can be done with them. They can greet players, they
can cast spells on players, they can give quests, hints, rewards, etc.
I can’t say enough about how much better they will make your areas,
even if they are simple 2-line mobprogs that do nothing more than make
birds chirp. Every bit more life that you can infuse into your area,
the better and more immersive it will become. They add the depth that
is so badly missing from plain mobiles, who simply stand around and
wait to be killed.
Mobprogs are easy to write. They don’t demand that you bug your
coder to write a special procedure for one single mobile. The code is
inserted directly into the area file that you are making with your
editor, and you can do practically whatever you want. It is simple and
non-intimidating – all you need to do is be willing to invest some time
into learning them.
Back to Top
Section 3: Making them work
To make a mobprog work, you can’t just type a bunch of stuff, and
have things work out perfectly. They have a set structure, syntax and
variables. You will need to learn these in order to make things happen
the way that you want. They are all quite important, as I’m sure you
know. Without structure, knowing the syntax and variables well enough
to recite them in your sleep doesn’t mean a thing.
Offline building
The best way to learn is by example, and so this is a skeleton
mobprog for offline building. Anything inside {braces} is required, and
is of your choosing (you supply the commands that go there), but the
braces should NOT be in your final mobprog. Anything else is something
that is required exactly as typed.
#MOBPROGS#{vnum}{command 1}{command 2}{command 3}{command n}~
The #MOBPROGS section is the very last, following #SPECIALS and
preceding the End of File #$. The #MOBPROGS section is closed with a #0
(that’s a zero). Each separate mobprog is numbered sequentially, using
the same vnums as the area file. If you were assigned vnums 1000 to
1099, you first mobprog would begin at 1000, then 1001, 1002, 1003,
etc. This is so as to avoid conflict with other areas that might be
trying to call the same vnumbered mobprog, never mind the fact that
it’s almost always a bad idea to call something else (be it an object,
mobile, or mobprog) that is in another area file.
The trigger line is placed inside the #MOBILES section, immediately
following the mobile which should have the mobprog; i.e., right before
the #vnum of the next mob. The structure of a trigger line is as
follows:
M {trigger type} {program vnum} {argument}~
The M delineates that this is indeed a mobprog. As with the
code example above, everything in {braces} is required and of your
choosing – you choose the type of trigger, the number of the mobprog,
and the argument for the trigger.
To clarify all of this, a simple trigger and mobprog (number 1004)
that makes a mob (number 1000) say “Hello” and then smile 50% of the
time that a player walked into the room with that mob would go as
follows. It also shows where you should add the trigger line, along
with showing the appropriate sections (the “…” means that I’m
skipping everything between #MOBILES and #MOBPROGS), their closing
tags, and the End of File.
#MOBILES
#1000[details of mob 1000]M greet 1004 50~
#1001[details of mob 1001]~
#0
...
#MOBPROGS
#1000say Hello.smile~
#0
#$
If you wanted to remove a mobprog completely, for whatever reason,
you just need to delete the trigger line and corresponding bit of code.
Back to Top
Online building (OLC)
To make a mobprog work, you first have to create the mobprog. This is easily accomplished by typing mpedit create {vnum},
where {vnum} is the vnum of your mobprog. It is generally the lowest in
your area; for instance, if you were assigned 1000 to 1099, your first
mobprog would be 1000, then 1001, 1002, 1003, etc. Should you have more
mobprogs than you do vnums, consult a psychiatrist, as you clearly have
problems.
After creating the mobprog, you will have to edit it. Simply type mpedit {vnum}, where {vnum} is the vnum of the mobprog you wish to edit. After that, type code.
You will enter the code-editing mode, where you enter your mobprog one
line at a time. It’s much like typing a room description with redit.
Below is a skeleton mobprog, containing the various commands needed.
Anything in {braces} is required, but is of your own choosing (don’t
put braces in the final mobprog). Anything else is something required
exactly as typed here.
{command 1}{command 2}{command 3}{command n}@done
To clarify, a simple mobprog that makes a mob say “Hello” and then smile would go as follows:
say Hello.smile@done
Avoid using the auto-format feature (usually .f or something similar), as it makes a horrible mess out of your mobprog, even though it makes room descriptions prettier. And always asave changed
once your mobprog is done, even if it needs debugging. It’ll save you
the trouble of having to type it all again in case of a hotboot or a
crash.
The trigger line is added when you assign the mobprog to a mob, so
you could enter all of the code first, and then add the trigger lines
if you wanted (I don’t recommend this, though). To do so, medit the mob, and then type addmprog {vnum} {trigger} {argument},
where {vnum} is the vnum of the mobprog you wish to add, {trigger} is
the type of trigger that you wish to use, and {argument} is a value
appropiate for that type of trigger. Here’s an example of this in
action; I’ll use the above “say hello and smile” mobprog as an example.
Let’s say that the mobprog vnum is 1005, and the mobprog vnum is 1001,
and we want the mob to say it 50% of the time that a player walks into
the room with that mob. To do so:
medit 1005addmprog 1001 greet 50doneasave changed
If you wanted to remove the mobprog, you would medit the mob, then type delmprog {number}, where {number} is the number of the mobprog you want to delete. This is different from the vnum.
If you press the Enter key while mediting a mob, you will get a screen
listing the mob’s hp, mana, level, AC, gold carried, vnum, etc. At the
bottom, you will see a listing of all mobprogs assigned to that mob,
looking something like this:
No. Vnum Trigger Phrase-----------------------[1] 1001 greet 50[2] 1004 exit 10[3] 1015 rand 03
To delete the greet mobprog from the example mob and save that change, you would type:
medit 1005delmprog 1doneasave changed
The next section details the types of triggers that you can use in a
mobprog, along with the values that are appropriate for that type of
trigger.
Back to Top
Section 4: A list of types of mobprogs
These are the different types of mobprogs that you can use in an
area. Each is given as the trigger name and the argument that is needed
(phrase, numerical, name/vnum). An explanation for each is also given.
Act – phrase
Act will trigger on nearly anything that you can think of that
does not include says, yells, or emotes. Any action that happens can
cause an act trigger to fire, such as “sits down”, “goes to sleep”, or
“puts a loaf of bread in a leather backpack.” For example, if a player
goes to sleep in a room with a mob who has an act trigger of “goes to
sleep”, you can have the mob wake the player up and yell about sleeping
too much. Don’t get too specific; if you have a mob waiting for someone
to wield the Huge Broadsword of Destruction, the mobprog is practically
useless. Let them be general and as far-ranged as possible, unless
there is a need to have a very specific act trigger, as will be shown
later.
Keep in mind that you will most likely need to observe the action
taking place to get it exactly correct, which is what the act trigger
needs. Easily done by a willing fellow immortal, or by forcing a mobile
to do it.
Speech – phrase
Speech will trigger on a say by a player. The fact that it is by a
player is important – it disallows two mobs to go into talking loops
and lag the MUD until one of them is killed. Because of its precise
nature, it should be limited in use, and the mob should somehow make it
clear that it is looking for a certain answer, and the difficulty in
that is making the mob do it convincingly. If the trigger is a simple
word such as “no”, the prog will fire any time a player says something
containing the letters “no”.
Rand – numerical
Random progs will trigger anytime the percentage roll is lower than
the numerical value specified. Basically, it’s a percent chance that
this will happen. 100 means it will always happen (bad idea – the MUD
will lag unbelievably and you’ll have a lot of people mad at you), and
0 means it will never happen (also a bad idea – you want people to see
the mobprog). Anytime that a player (including immortals and switched
immortals) is in the same area, the mob will begin making its random
checks to see whether it should execute the prog. If successful, the
mob will perform the actions specified in the code, even if a player is
not in the same room. It is one of the most useful mobprogs for giving
a mob personality. You can have birds sing, dogs bark, people look
around or perform socials, etc.
Greet/grall – numerical
Greet and grall (short for “greet all”) are also used with a
percentage value. They are checked whenever a player enters the room
that the mob is in. If the check is successful, the mob will perform
the command specified in the code. There is a large difference between
greet and greet all – greet will only trigger once, and will only
trigger if the mob can see the player. Grall will trigger for every
player that enters the room at the same time, and will trigger no
matter what – that mob can always see a player enter, even if it is
blind, the player is invisible, etc.. It is quite useful for
shopkeepers to greet their customers. Greet will work only if the mob
is not busy – generally meaning, but not limited to, fighting. Grall
will always trigger, even if the mob is fighting.
Entry – numerical
Entry is somewhat like greet, except it is checked whenever the mob
enters a new room. Useful for having friendly mobs which say hello to
players, or for wandering shopkeepers who accost players and try to get
them to buy things. Entry can ONLY be used with a random variable ($r)
in targeted commands, because there is no way to check beforehand how
many players will be entering a room. Visibility must be checked, and
if a mob can not see a player, it will not perform the commands. There
is no trigger that works in the same way as grall and exall. If you
want the mob to have the best chance of seeing people that it normally
could not, give it “detect invis” and “detect hidden”.
Exit/Exall – numerical
This is the opposite of a greet trigger. It fires whenever a player
tries to leave a room through the specified direction: 0 for north, 1
for east, 2 for south, 3 for west, 4 for up, 5 for down (if the MUD you
build for has intermediate directions – northeast and the like – ask
your coder for the numerical equivalents). It is useful for having a
sentinel mob that will not allow players to go in a specific direction
unless they have a certain item or what-have-you. You can specify a
certain target in these, as opposed to entry progs, where the target
must be random.
WARNING – When the trigger fires and the player tries to exit in
the direction that is specified in the trigger, the player will not
move to that room. Instead, if you want the player to go to that room,
you must use a transfer or gtransfer command. This should only
be done for sentinel mobs, because if a mob with an exit program
wanders, the player may find himself in a room he did not want to enter
(indeed, he may find himself on the other side of the area). This
trigger is not checked when a player flees.
Give – name/vnum
Give is checked whenever a player gives something to a mob. If it is
not the object specified in the name or vnum, the trigger will not
fire. This is useful in quests, where the player must give a certain
item to the mob to be rewarded or sent on the next part of the quest.
In that case, give the object a very unique name, or use the vnum of
the object. The mob will always keep what is given to it. However, if
you use an if check to see if the object is incorrect, you can have the
mob drop the object. Also, unless you want the mob to accept any item
with the name specified in the prog, give the item a unique name that
is highly unlikely to be duplicated – something like “swordcoral”.
Don’t make it obvious that the item is somehow special, though – just
make it so that it looks like you forgot to add a space between
keywords ^.^
If this is used for a quest reward sort of program (return the Royal
Shiny Thing to Lord Buttercreme, and he gives you some gravy), I
strongly suggest that you use the purge command to eliminate the
correct thing that is given. Otherwise, the player could steal the
correct item back, give it back to Lord Buttercreme, and have an
infinite cash flow. Nothing prevents the player from getting another
token, though, but that’s harder than just stealing it, returning it,
stealing, returning, ad nauseam.
Bribe – numerical
Bribe is checked whenever money is given to the mob. If it is equal
to or greater than the numerical amount specified, then it will fire.
If not, the trigger will not fire. The mob will not give back the
money, or total the money up – all must be given at once. Also, because
there are two types of currency in ROM, gold and silver coins, you must
give the numerical value in the number of silver coins expected. So if you specify 200, a player can either give 200 silver or 2 gold, and the trigger will fire.
Kill – numerical
This is checked whenever a player attacks a mob, and is triggered only
then. It has very limited usefulness, but is nice for calling in some
reinforcements, running away, or making a very strong first attack. The
prog will trigger whether a player uses the command “kill” or “murder”.
My thanks go to Sardonicus (no, he’s not an OLC command) for that info.
Death – numerical
When the mob dies, this trigger is checked. If successful, the mob will
carry out the commands. It can do anything except purge itself and
heal/resurrect itself (for the sake of the prog, the mobile is set to
standing position so it can do anything). If you try to have a mob
purge itself in a death prog, the MUD will crash (avoid this like the
plague). Healing or resurrecting spells or items will simply not work.
This is useful for a mob to load something, or give a few emotes and
summon in some more mobs, which it can then force to attack the player
who killed it. It’s also an interesting way to have your mobiles
shapeshift at death into something else – like that cute little puppy
turning into a hellhound. My favourite application of this was having
elementals explode upon death, damaging the player ^.^
Delay – numerical
This is a command used in conjunction with mob delay. When the
countdown started in mob delay gets to 0 (the timer is counted in
pulse_mobiles; 6 pulse_mobiles equals 1 tick), this trigger is checked.
If successful, the commands specified are executed. It is difficult to
use well and consistently unless the value given is 100. With this, you
can make a guard that has a greet trigger to tell them to leave, an
exit trigger to not let them pass, a mob delay command in the greet
trigger, and a delay trigger that is set at 100. When the delay runs
out, the guard will say something like “I warned you!” and attack. And
when the guard is dead, the player can pass.
Back to Top
Section 5: A list of variables
There are quite a few variables that can be used in mobprogs. Some will
be used often, while others won’t see much use at all. You can not
specify your own variables for use in mobprogs. Be sure that you’re
using the correct variable, otherwise things can look a little silly.
And be sure to not get confused with similar-looking letters, such as I
and l (capital i, lowercase L).
The variables may be the hardest thing to learn about mobprogs,
because there are so many of them. However, there’s no need to memorise
them all – as I said, some (possibly most) of them are rarely used.
When a command involving them is processed, the variables are converted
into their corresponding values, dependent on several factors, which
are shown below. I’ll try to explain these as simply as I can. I’ve put
them into categories depending on who or what the variables stand for.
Most relate to the player.
I’m going to use socials as my examples for these, but they can be
used in commands, as well. I’m also going to highlight examples in fixed-width yellow.
Variables that refer to mobiles
$i - the first of the names of the mobile itself, in their namelist$I - the short description of the mobile itself, as in "A Beastly Fido"$j - he, she, it - based on sex of $i [the mob's sex]$k - him, her, it - based on sex of $i [the mob's sex]$l - his, hers, its - based on sex of $i
If a Beastly Fido had a namelist of “dog fido beastly”, The $i jumps! would return The dog jumps!
If a mob had a short description of “The Beastly Fido”, then $I attacks! would return The Beastly Fido attacks!.
If our Beastly Fido was a male, then The Beastly Fido looks at you pitifully … $j looks hungry! would return The Beastly Fido looks at you pitifully … he looks hungry!. If our Beastly Fido was a female, it would return The Beastly Fido looks at you pitifully … she looks hungry!. And if it had no gender specified, The Beastly Fido looks at you pitifully … it looks hungry! would be returned.
If our Beastly Fido was a male, then The Beastly Fido wants you to follow $k. would return The Beastly Fido wants you to follow him..
If our Beastly Fido was neuter, then The Beastly Fido growls … you better get away from $l food! would return The Beastly Fido growls … you better get away from its food!
And to tie it all together, using all of our above examples (“dog
beastly fido” for a namelist, “The Beastly Fido” for short desc, gender
male) … $I
growls at you. $j doesn’t seem to have much food, and $j wants you to
get away from what is $l. Maybe you should leave the $i alone. would return The
Beastly Fido growls at you. He doesn’t seem to have much food, and he
wants you to get away from what is his. Maybe you should leave the dog
alone.
Variables that refer to players
$n - the name of whomever caused the trigger to happen; the player$N - the name and title of whomever caused the trigger to happen$t - the name of a secondary character target, as in Bob smiles at Alice$T - the name and title of a secondary character target$r - the name of a random PC in the room with the mobile$R - the name and title of the random PC$q - the name of the mobprog target (see mob remember)$Q - the short description of the mobprog target$e - he, she, it - based on sex of $n [the player's sex]$E - he, she, it - based on sex of $t [as in "Alice smiles at Bob" - $E would refer to Bob]$J - he, she, it - based on sex of $r$m - him, her, it - based on sex of $n [the player's sex]$M - him, her, it - based on sex of $t [see example for $E]$K - him, her, it - based on sex of $r [it remembers the random person chosen until a new random person is chosen]$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
If the player who trigged the mobprog was named Bob, then The Beastly Fido growls at $n. would return The Beastly Fido growls at Bob.
If Bob’s title was “the Superfreak”, then The Beastly Fido growls at $N. would return The Beastly Fido growls at Bob the Superfreak..
If Bob and Alice were standing around, and Bob smiled at Alice, then $t would return “Alice”. Used very rarely.
If Bob and Alice were standing around, and Bob smiled at Alice, and Alice’s title was “, slays Beastly Fidos”, then $T would return “Alice, slays Beastly Fidos”. Used very rarely.
If a Beastly Fido had an entry prog of The Beastly Fido growls at $r!, and it walks into the room where Bob, Alice, Dave and Candice are, then $r would return any of Bob, Alice, Dave or Candice.
If a Beastly Fido had an entry prog of The Beastly Fido growls at $r!, and it walks into the room where Bob, Alice, Dave and Candice are, then $R
would return any of Bob the Superfreak, Alice slays Beastly Fidos, Dave
likes cheese, or Candice needs a sword (assuming that those are their
titles).
If a Beastly Fido had an entry prog of mob remember $r to remember a random player in that room, delayed, and then called a delay prog of mob kill $q, then $q would return the name of the random player that was remembered (such as Bob).
If a Beastly Fido had an entry prog of mob remember $r to remember a random player in that room, delayed, and then called a delay prog of mob kill $Q, then $Q would return the name and title of the random player that was remembered (such as Bob the Superfreak).
For examples of the remaining variables in this section ($e to $L), please see the examples given in the section about variables that refer to mobiles. It’s pretty much the same.
Variables that refer to objects
$o- the first of the names of the primary object$O - the short description of the primary object$p - the first of the names of the secondary object$P - the short description of the secondary object [As in "a brown leather sack"]
If Bob had a sword with the keywords “bloody bits sword”, then $o would return “bloody”.
If an object had a short description of “a sword of bloody bits”, then $O would return “a sword of bloody bits”.
If Bob put his sword of bloody bits into a brown leather sack with keywords “sack leather brown”, then $p would return “sack”.
If an object had a short description of “a brown leather sack”, then $P would return “a brown leather sack”.
Back to Top
Section 6: A list of viable commands
And now for the final section (for which I am glad, because this is
a lot of typing to do ^^;) – the commands you can use in your mobprogs.
This is where the magic happens, because triggers don’t mean a thing if
the mob doesn’t have something to do. There are a whole heap of
commands that you can give to your mobiles, and I believe that this is
a list of them all.
Socials
If it’s a social in your MUD, a mob can perform it. You can give
them targets, as well (smile $n, growl $r, etc.). There’s really not
much else to say about this ^.^
If/Else/Break control flow
A string of if/else/break commands can be given for the mob. They
can be nested, meaning there can be two or more possible commands to be
given within any given ifcheck. All ifchecks must be closed with an
endif. Each needs to be preceded with an if in the actual command, i.e.
if isgood.
In the following, var means a variable (see above), num means a numeric
value, vnum means vnum and name means a keyword for a mob or object. If
a word is in [brackets], then it means that it can be used
interchangeably with the preceding word; a pipe | between two words
means to choose one of the two. Also, in the final checks, == (equal
to) can be replaced with != (not equal to), > (greater than), >=
(greater than or equal to), < (less than) and <= (less than or
equal to).
- isgood var – Checks to see if var is good.
- isevil var – Checks to see if var is evil.
- isneutral var – Checks to see if var is neutral.
- rand num – Checks to see if percentage is less than or equal to rand value.
- mobhere name|vnum – Checks to see if the mob with the name or vnum specified is in the room.
- mobexists name|vnum – Checks to see if the mob with the name
or vnum specified exists in the world. Should be used with vnum or a
very specific name.
- objhere name|vnum – Checks to see if the object with the name or vnum specified is in the room.
- objexists name|vnum – Checks to see if the object with the
name or vnum specified exists in the world. Should be used with vnum or
a very specific name.
- ispc var – Is the thing who triggered the mobprog a player?
- isnpc var – Is the thing who triggered the mobprog a mob?
This is useful for adding a check for a prog not to trigger on a say
command by a pet – those may crash the MUD.
- isimmort var – Is the thing who triggered the mobprog an
immortal? It’s useful for preventing mobprogs from being triggered by
an immortal, especially if imms on your MUD are wizinvis most of the
time.
- carries [has] var name – Does var carry the named object?
- wears [uses] var name – Does var wear the named object?
- race|class var name – Is var a member of the named
race/class? The class name seems to vary, from what I can tell – it may
be a name, like cleric, or it may be an integer, like 1 – please test
the prog before you implement it.
- sex var == integer – Is var‘s sex equal to the integer given (0 = neuter, 1 = male, 2 = female)?
- level var == integer – Is var‘s level equal to the integer given?
- align var == integer – is var‘s alignment equal to
the integer given? Unless your MUD has variable alignment for players,
use 1000 for good, 0 for neutral, and -1000 for evil.
- money var == integer – Does var carry silver equal to integer? Remember that 100 silver = 1 gold.
Immortal commands
Mobs have a selection of immortal commands available to them. All
commands listed below are understood to be preceded with “mob”, i.e. mob transfer.
String means a string must be given, vnum means a vnum must be given,
num means a numerical value must be given and var means a variable
target must be given. Anything in (parentheses) is optional; words
separated by a pipe | mean to choose one of them.
- zecho string – Sends the specified string to the area the mob is in.
- gecho string – Sends the specified string to the entire world.
- echo string – Sends the specified string to the room the mob is in.
- goto vnum – Sends the mob to the specified vnumbered room.
- purge (var) – With no argument, destroys everything in the
room that is not flagged “no_purge”; with an argument (var), destroys
that thing alone. DO NOT use it to “purge $i” in a kill program – attempting to purge a dead mob will result in the MUD crashing.
- transfer var|all vnum – Transfers the target|everyone in the room to the specified vnumbered room.
- gtransfer var vnum – Transfers the target’s group to the specified vnumbered room.
- force var action – Forces var to do the specified action. Players can not be forced to perform certain actions.
- gforce var action – Forces var’s group to do the specified action. Players can not be forced to perform certain actions.
- oload vnum – Loads the specified vnumbered object. Objects
that have a “take” flag set will be loaded into the mob’s inventory;
objects without that flag set will be loaded into the room.
- mload vnum – Loads the specified vnumbered mob into the room.
Delay commands
There are also a few commands which are specifically devoted to the
delay function. There are four of them, and are very important to
remember when constructing your carefully-planned delay progs. You are
planning these, right? Delay-on-the-fly can become a little messy.
- delay num – Sets the mob’s delay timer to the specified
number value. It also ends the program, waiting until 0 is reached in
the countdown timer. It then finds the delay program that is assigned
to the mob, and executes it. The countdown is counted in pulse_mobiles;
there are 6 pulse_mobiles in 1 tick.
- cancel – Cancels a delay command.
- remember var – Remembers the target for a delay program.
- forget – Forgets the previous target of a remember command.
Those are all of the commands that will definitely work when used in a
mobprog. Combine them well and you can have an area where wind blows
through the treetops and birds can be heard singing throughout the
forest. The possibilities are endless. Your coder may have additional
commands added, especially in a modded stock codebase. You will have to
ask him or her whether or not you can use those commands.
Back to Top
