DARKOVER 2.1
Mobprog Documentation for Darkover MUD
Version 1.1.6
Written by: Danar
Last Updated: March 11, 2001
Index:
-------------------------------------------------------------------------------
1.........Introduction
2.........Example
3.........Program structure
4.........Triggers
5.........Variables
6.........Variable conversion
7.........Program control
8.........Command extensions
9.........Operators
10........if expressions
11........Mobprog commands
12........Miscellaneous values
1.........Introduction
-------------------------------------------------------------------------------
Well, I suck at writing documentation, but I'll do my best. The short way to
describe the Darkover mobprog system is, it is very close to the generic system
you can find on most Circle based MUDs. Our entire system is somewhat different
so we were forced to write it from scratch, but it did give us the ability to
write things the way we wanted to. Anyway, this version emulates most of the
basic mobprog functions you've come to know and love. Whenever we use variables,
they are designed after the act() function so $n represents the mob with the
prog, $N the person (mob or player) that causes the prog to be fired. Things
such as $p and $r will be coming soon to allow attachment of progs to objects
and rooms, respectively. If you've read a previous version of this document and
just want to see what has changed recently, check the Changelog link on the
previous page. So, without further ado...
2.........Example
-------------------------------------------------------------------------------
I'm a big fan of learning by example, so I'm going to put an example based on
our system here, and then explain each part of it. One note to potential
builders and prog authors: DON'T EVER USE TABS! I'm all for readable and
pretty code, but do it with spaces, not tabs. Not everyone will see the same
spacing if you use tabs, as well as the prog parser won't handle it.
P mob_prog combat_vict|combat_notvict
if is_pc($N)
if level($N) <= 10
mexec say %ch-name%, you may want to stay out of here, it can get pretty mean.
elseif level($N) <= 30
mexec say Good luck %ch-name%, go get 'em!
elseif level($N) <= 50
mexec say Aren't you a little old to be here %ch-name%?
mtrans char 1260
mforce char look
mat 1260 say Sit here to think how bad you've been!
else
mexec sigh
mexec say Another god trying to get uppity with the morts!
mexec poke %ch-name%
endif
endif
mgoto 1204
mexec say Ahhh.. home at last..
~
Ok, breaking the various command types down line by line.
P mob_prog combat_vict|combat_notvict
- This loads a new mob_prog for the mob that fires on the combat_vict and
combat_notvict events. A full list of these events can be found below.
You can fire a single prog on multiple events by separating them with
the | character. Also, a quick note on command triggered events such
as cast and steal. If the mob_prog fires successfully, the command will
not execute. Meaning, if a mob has a steal trigger and it fires, the
original steal command will not go through. If you wish it to look like
it did, you, for instance, can load the object, give covertly to the
player, have the mob junk his version, and then echo the steal message
to the player.
if is_pc($N)
- This shows the basic if structure. Again, a full list of the available
if expressions can be found below. There are 2 basic types of
expressions. The first is like is_pc(), it simply checks a true/false
value. The second is like the level() on the next line where you can
compare it to another value. You can find a full list and explanation
of all the available operators below, but it functions just like any
other programming language (if you've used one). Of course, if you
haven't used one before, I dunno, you're screwed I guess. Notice that
every if block MUST have an endif at the bottom. If it doesn't you
will get nasty, nasty results, so stick with putting it in.
mexec say %ch-name%, you may want to stay out of here, it can get pretty mean.
- There are two basic types of commands. First, there are commands that
start with mexec. This command will be parsed, first to remove the
mexec from it. Then, the variables like %ch-name% will be replaced
with the character/mob/etc proper name just like you'd refer to them
in a normal command. For instance, the example command would end up:
say Danar, you may want to stay out of here, it can get pretty mean.
The other type of command is the pre-made versions such as mtrans,
mforce, and mat. These are specially built and will be listed below
with the exact arguments needed, etc below. The quick distinction
between what needs to be a premade function and what doesn't is the
level needed to use the command. Mobs are prevented from using
Immortal commands. at, force, trans, etc can't be used within an
mexec command. So, we have the premade versions.
3.........Program structure
A quick note on the command words you can use in your program.
- There is of course the if/elseif/else/endif looping sequence that we have
in the example above. More descriptions of the available if-checks can be
found a little farther down in this document.
- There is a 'return ' command. If you used to use the 'halt' command,
you just need to replace it with 'return 0' to mimic the same behavior.
You can check the documentation on each trigger to see how the return values
will affect the behavior after the prog executes. If you don't have a
return value specified to end your prog, it will return a 1 by default.
- You can use the 'break' keyword to exit out of a nested if statement. So,
if you're contained within an if-block and wish to skip the rest of it,
you can use this to get to the first line after the next 'endif'.
4.........Triggers
This is the current list of available events. As with the other things, if you
can come up with a high-level event submit it to me or whoever is in charge of
code maintenance, and they can add it. I will also list the appropriate values
for the $ variables within each trigger, because they are not always the same.
As noted in the example above, you can stack multiple triggers for a single prog
by using the '|' character. For instance, you can say:
P mob_prog text die|combat_vict|combat_notvict
and the prog itself would run whenever someone says something with the word 'die'
in it or when itself or anything else in the room is attacked. This allows you
to keep your progs cleaner by not having to repeat them simply with different
triggers, etc. WARNING: Make sure you account for all your $n and $N type codes
in the progs. They will be filled with whatever information that prog trigger
wants, so if $n means one thing in one trigger, it has to mean the same thing in
another or you will get undesired behavior.
- death
Variables: None
Returns: All values are the same, the mob will die no matter what.
Summary: As you can imagine this fires off when a mob dies. Since it does
not cover the actual killing blow, both $n and $N are set to the mob
itself. So, stay away from directed commands and such while using
this trigger. Also, no matter what is done inside the prog, the mob
will still die, there's no way to stop that. However, you can
emulate immortality, by loading another version of the mob and then
sending the mob to Limbo (or another appropriate/inaccessible place)
to actually die.
- combat_vict
Variables: None
Returns: All values are the same, the combat will begin after execution.
Summary: This will execute when combat is initiated in the same room with the
mob and the mob itself is the target of said combat. $n is set to
the mob itself and $N is set to the person that has initiated battle.
This is a good way to allow mobs to react to aggressive behavior
either by evading actual combat or totally whooping the person's ass.
You can 'return 1' if you wish to prevent the combat from happening,
so if you want your guards to not annihilate a newbie, etc, do that,
otherwise if you just wish to open a can on someone as well as fight
them, make sure to 'return 0'.
- combat_notvict
Variables: None
Returns: All values are the same, the combat will begin after execution.
Summary: This will execute when combat is initiated in the same room with the
mob, but the mob is NOT the target. Again, $n is set to the mob
itself, and $N is set to the person starting the battle. This is a
handy way to make a guard that would protect other people in the room
by hauling a person off to jail or even assisting the person getting
hit. As in combat_vict, return 1 to prevent combat and return 0 to
allow it.
- combat_round
Variables: None
Returns: Returning 1 will prevent 'normal' attacks for that round of combat.
This is handy for preempting combat in favor of a specific action or
combination of attacks. Returning 0 will allow 'normal' attacks after
prog runs.
Summary: This is fired at the beginning of each combat round for each player
and mob. So it's not the actual beginning of the round for everyone
at the same time. However, it is before each person's attacks,
whatever they may end up being. Since this is concerned only with
the mob only, the only values we can extract are the value of the mob
itself (which is set to $n) and the primary combatant, ie tank, is
set to $N. A sample use of this event internal to the code is the
Dragon behavior. It checks the chance to breathe, tail whip, and
fear on each COMBAT_ROUND event. This is a quick way to limit
yourself to one special attack per round, so they don't do all 3 in
sequence.
- cast
Variables: spell (the spell number of the spell that was caught)
Returns: Returning a 1 will prevent the casting of the spell, and a 0 will allow
the cast after the prog executes.
Summary: This executes upon every cast made by someone which is targeted at
the mob. $n refers to the mob (ie target of the spell) and $N refers
to the caster. A quick illustration of a use here is the
bounce_damage proc which turns a spell around and nukes the caster
with it (ala Moraelin Magistrate, etc).
- steal
Variables: None
Returns: Returning a 1 will prevent the steal act, and a 0 will allow the
stealing to happen after the prog executes.
Summary: This trigger fires when someone uses the 'steal' command on the mob.
$n, as always, refers to the mob, and $N is the person trying to
steal from them. The uses of this are somewhat limited, but could
prevent a player from stealing a key, or some such desire.
- quest_reward
Variables: None
Returns: Returning a 1 will prevent the rewards from being given out, and a 0
will allow traditional behavior after the execution.
Summary: As the name indicates, this is what executes when a mob has a
traditional quest file and that quest has been fulfilled. $n is the
mob with the quest file and $N is the person that has fulfilled the
quest, whether it be monetary or item based. An example use of this
trigger is when an unnamed saint gets his requested items and then
proceeds to smack the party around.
- birth
Variables: None
Returns: All values behave the same, the birth can not be prevented.
Summary: This happens when the mob is load, but BEFORE it is put into its
final room. At the time of the trigger firing, it will technically
be in room 0 (The Void). This will allow it to load mobs, etc, but
it needs to take into account the fact that it will not be in it's
final location. So you can NOT reference people in the room, etc.
You can however, use non-specific commands like mload or mexec for
example. This is a good way to do random load objects, etc rather
than in the zone file. It will end up to function the same either
way, basically, but it's a lot easier to see what is happening in a
mobprog. One note, rarenum can NOT be taken into account when loaded
this way.
- receive_coin
Variables: amount (the amount given to the mob)
Returns: All values behave the same, the coin will always be received.
Summary: This fires when the mob receives any money. The money has already
been applied to the mob's total, so you can return it or deal with it
in any other way if you need to. $N refers to the person that gave
the money to the mob, while $n refers to the mob itself.
- receive_item
Variables: item (the vnum of the item given to the mob)
item_name (the first alias word of the item)
Returns: All values behave the same, the item will always be received.
Summary: This fires when the mob receives an object. The object has already
been moved to the mob's inventory, so you can wield it, junk it, or
whatever else you want to do with it. $N refers to the person that
gave the object, while $n is the mob that received it.
- move
Variables: None
Return: All values behave the same, the mob will always end up in the new room.
Summary: This fires when the mob itself wanders or tracks to another room.
It is already in the new room rather than a state of flux as in the
birth prog, so if you want to move to another room from there or
some other action, you can. Note that both $n and $N refer to the
mob itself.
- entry
Variables: None
Returns: All values behave the same, the person can not be prevented entry.
Summary: This fires whenever a mob or player enters the room with the mob in
it. As usual, $N is the person entering the room, while $n is the
mob itself. Excellant for guards and aggro-emulation, but here is
one warning. This trigger will fire no matter if the person is
invisible, hidden, sneaking..whatever. So, if you don't want the
mob to get super X-ray vision all of a sudden remember to toss in
a few isaffected() calls to make sure the person isn't supposed to
be hidden. Also, make sure to remember that it echoes for EACH
person entering the room. So, if a 15 person group comes in, it'll
exec for each group member. The simple way around this is to use
an 'mpause 4' (ie 1 second) so that the first person in a group
would trigger it, but the rest wouldn't and then you can continue
as you wanted to after the 1 second.
- hour_change
Variables: hour (the hour it just became)
Returns: All values are the same, the time will always change.
Summary: This fires whenever the mud's hour changes (not the real world hour).
$n and $N both point to the character, so you can only reference
them. The variables and values are the same for this as for the hour(),
day(), etc. if-checks below.
- day_change
Variables: day (the day is just became)
Returns: All values are the same, the time will always change.
Summary: Exactly the same as hour_change except it fires when the day changes.
- month_change
Variables: month (the month it just became)
Returns: All values are the same, the time will always change.
Summary: Exactly the same as hour_change except it fires when the month changes.
- year_change
Variables: year (the year is just became)
Returns: All values are the same, the time will always change.
Summary: Exactly the same as hour_change except it fires when the year changes.
- rand
Variables: None
Returns: A value of 1 will prevent the execution of other progs on this round
of random executions. Returning a 0 will allow the execution of other
random progs during this round. It's best NEVER to return 0, in case
it tries to execute like 4 separate progs at the same time.
Summary: Every 10 seconds, the random progs are checked. Whether you just
say things like the old quest files, or actually do something like
load a mob and pet it is up to you. x stands for the percentage
you want the random prog runs. So, if you look over time, a 50%
rand prog will run once every 20 seconds. Sometimes it will run
every 10 seconds and other times it will only run once every 30
seconds. Since there is no initiating entity, both $n and $N point
to the mob.
- action
Variables: None
Returns: Returning a 1 will prevent the execution of the actual command after
the prog executes. Returning a 0 will allow the prog to run as well
as have the person's command execute afterwards.
Summary: This will react to when people use specific command numbers. You
can ask an Immortal (preferably a coder) which number (represented
by x), represents which command. For instance you could say
'action 15' which represents the 'look' command.
Note: the command in question will be caught by the prog when it
executes, so if you want the mob to do something AND have the
party responsible for running the proc to execute the command,
you need to use the mforce function to force them to execute the
command.
- text
Variables: None
Returns: All values are the same, you can't prevent the received text after it
has already been received.
Summary: This triggers whenever the text appears in the text that is send
to the mob, but only from a 'say' or a 'tell'. Whether is just
one word or a sequence of 5 words, it has to match it all before
firing. There's no telling exactly where the text came from so
both $n and $N refer to the mob itself.
Note: Mobs cannot set off each other's text progs to prevent looping, if
this is truly required, ask Shalla about "named events".
5.........Variables
The first thing to talk about when it comes to variables is that there are
two kinds of variables. There are local as well as global variables. What is
the difference you ask? Well a local variable can only be accessed by the
prog that is it involved with. So, if you make a variable in, for instance,
a combat_vict prog, it can only be accessed from there. So, if the mob also
has a death prog, those variables can't be accessed from there. On the other
hand, a global variable can be accessed from any prog attached to a mob. A
couple of miscellaneous notes:
- Don't just use all global variables. It WILL catch up to you and bite you
in the ass, and it's just bad practice.
- If you have a global and local variable with the same name, the local
variable will be given preference when it is accessed in a prog.
Now, with that out of the way, you access the variables by surrounding the
variable's name with the '%' character. So, if you wanted to use a variable
named 'foo' (remember locals take precedence over globals) in an mecho command,
you would use the command: 'mecho room This is %foo%.' Also, fyi, if you want
to use % in your command for some reason, you must put two % signs in the text
in it's place. Then, rather than trying to translate it into a variable value,
it will just replace it will a single sign.
There are certain variables that are pre-defined for any prog execution. Some
are related to the trigger and are listed with each trigger above. While the
rest are pre-defined for all the progs we have here. Here's a list of them:
%char.name% - Name of the person triggering the prog (MAY BE THE MOB!)
%char.hp% - The character's current hit points
%char.maxhp% - The character's max hit points
%char.mana% - The character's current mana
%char.maxmana% - The character's max mana
%char.move% - The character's current moves
%char.maxmove% - The character's max moves
%char.sex.e% - The character's sex (he/she/it)
%char.sex.m% - " " " (him/her/it)
%char.sex.s% - " " " (his/hers/its)
%char.level% - The character's level
%char.race.num% - The character's race (numeric value from values below)
%char.race.text% - The character's race (text equivalent, ie Berserker)
%char.class.num% - The character's class (numeric value from values below)
%char.class.text% - The character's class (text equivalent, ie Gnome)
%mob.name% - Name of the mob the prog is attached to
%mob.hp% - The mob's current hit points
%mob.maxhp% - The mob's max hit points
%mob.mana% - The mob's current mana
%mob.maxmana% - The mob's max mana
%mob.move% - The mob's current moves
%mob.maxmove% - The mob's max moves
%mob.sex.e% - The mob's sex (he/she/it)
%mob.sex.m% - " " " (him/her/it)
%mob.sex.s% - " " " (his/hers/its)
%mob.level% - The mob's level
%mob.race.num% - The mob's race (numeric value from values below)
%mob.race.text% - The mob's race (text equivalent, ie Dragon)
6.........Variable conversion
Ok, now you can access your variables, but you need to know that there are 2
commands to assign values to your variables. First, the local_var() command:
'local_var(test) = test value 1'. Now this constructs a local variable for just
this prog with the name 'test'. Notice that when specifying a value, we don't
use the '%' on either side, that's just for accessing it from within a command.
If you then went and accessed this variable like: 'mecho room This is %test%.'
Each person in the room would see the text 'This is test value 1.' As you
would imagine, you can use the global_var[] command in exactly the same way.
In regular commands, you can do just as I did above, but in if-checks you need
to make sure to use the provided num() and str() functions. You can read more
about those in more detail below where they are discussed again. Also, you
can't 'unset' a variable perse, but you can set the variable to nothing by
executing: 'local_var[test] ='. For the purposes of local and global
variables, this will do what you need to allow the global variable of the same
name to be used.
7.........Program control
There is a command called 'mprog' that has several options which control the
way the program executes. These are commands and their available options are
listed below.
mprog debug [on|off]
8.........Command extensions
This is a simple section dealing with the topic of the basic command
structure. If you have a command that needs to be split onto two lines (or
more), you can just add a '\' (without the quotes) to the end of the line.
The command executor will remove the top line after and including the
'\' operator. It will also remove any trailing spaces just prior to
the '\' and the leading spaces on the second (ie connecting) line.
This combined line will then be executed as if it was a regular command,
so don't do anything special other than the '\' operator. Also, you can
insert comments into your code by using the '*' operator. It doesn't matter
if there are spaces in front of it, as long as the * is the first non-space
character on a line, the rest of the line will be disregarded as a comment.
Also, you can insert blank lines with the comments to help your readability.
9.........Operators
This discusses the various operators you can use in the above if checks.
There are 2 types, integer and string, so make sure you're using the
right one when you try something. Integer operators will only work on
numbers and string operators only work on text.
Integer:
- == (equal-to)
- != (Opposite of equal-to, also called not-equal-to)
- > (greater than)
- < (less than)
- >= (greater than or equal to)
- <= (less than or equal to)
String:
- == (equal-to, it is case-sensitive, so it must match EXACTLY)
- != (not-equal-to, this is also case-sensitive)
- / (contains operator, it returns positive when the right side exists
somewhere within the left side. It is also case-sensitive)
- !/ (not contains, the exact opposite of the previous / operator)
10........if expressions
As the example above talks about, there is a strict structure that must
be followed. You can then use the various if expressions to control
what happens where. One note about the right hand values. They can be a
single value such as 'if pcrace($n) == 3' or it can be multiple values
placed together with the | character like 'if pcrace($n) == 1|3|5'
Please note that there is no space between the values. This will work with
both numerical as well as string values, but make sure to think through the
logic of the 'or' values depending on the operator itself. Search for
'De Morgan's Laws' as pertains to logic if you don't know what I mean, but
want to learn.
- if num(x)
-------------
This converts whatever is in x into a number to compare to the value on
the right hand side. This allows you to use variables inside if expressions
rather than only in commands. You would say something like:
local_var(test) = 5
if num(%test%) >= 5
mecho room Yes!
endif
- if str(x)
-------------
This functions much the same as the num() function, but it does everything
with strings rather than numbers. So if you wanted to be able to check
for substrings and such in a variable you could say:
local_var(test) = test1|test2|test3
if str(%test%) / test1
mecho room Yes!
endif
- if ispc(x)
--------------
As it says, it will return a positive if x is a player. x is allowed to
be $n and $N only.
- if isnpc(x)
---------------
This is the opposite of the previous command. It will return positive
only when x is NOT a player. Again, x is allowed to be $n and $N.
- if isimmortal(x)
--------------------
This command returns whether x is level 51 or above. It does not matter
whether x is a player or a mob, since both have a level. $n and $N are
acceptable values for x.
- if ismortal(x)
------------------
Again, the opposite of the previous, it will return positive when x is
below level 51. Still, mobs and players are both valid types, so $n
and $N are valid values for x.
- if isaffected(x) y
----------------------
This will tell you if x is affected by a spell/skill number represented
by y. Valid values for x are $n and $N, and y can be any integer. Valid
integers will vary with the exact number of skills and spells we have at
any given time. These can be found by using sinfo (as an Immortal only)
or by asking an Immortal what skill/spell is which value.
- if isfighting(x)
--------------------
This returns true if the target is currently engaged in combat with anyone.
Valid values for x are $n and $N.
- if combat()
---------------
This returns true if there is combat in the room, whether the mob or player
are involved or not. This is especially useful for guards and such that
need to watch for unauthorized combat going on.
- if exit_exists(x)
---------------------
This checks the room that the mob itself is in for available exits. If
the exit exists it will return true. Valid values are for x are north,
east, south, west, up, and down.
- if rand(x)
--------------
This is a random number generator. x is the probability that the command
will return a positive response. So, if you want it to return 9 times
out of 10, you would use rand(90), or if you wanted it 5% of the time,
you'd say rand(5). x must be between 1 and 100, inclusive, meaning 0 and
below and 101 and above are not accepted.
- if year() y
--------------------------
This compares the current game year to the specified value of y. You
can check the current date within the MUD using the 'time' command.
At the time of this writing, we're sitting at the year 306, but that may
change by the time you read this.
- if month() y
---------------------------
This will compare the current game month to the specified value of y.
There are 17 months per year here on Darkover, so stick to 1 to 17 for
your y values or else you'll get some bogus results.
- if day() y
-------------------------
This compares the current game day to the specified value of y. We have
35 days per month on Darkover, so keep your y restricted to 1 to 35 or you
will get unexpected results.
- if hour() y
--------------------------
This compares the current game hour to your value of y. We have 24 hours
per day just like the real world, and we use a military time plan on
Darkover, so use hour values 0 to 23 (0-11 being morning, 12-23 being
evening just like in the real world).
- if holding(x)
-----------------
This checks to see if the mob the prog is attached to has the item
specified by x in it's inventory. x represents the item by using its
vnum. So, if I say:
if holding(28069)
mecho room Yes!
endif
it will return true only if the item with vnum 28069 is in it's inventory.
- if equipped(x)
------------------
This works much like 'holding' above, except that it checks the mob's
equipment (ie worn items) list. x still represents the vnum of the item,
and it returns true only if the item is worn -somewhere- (there is no
way to currently tell -where- it is worn or how many of them are worn).
- if vnum(x) y
---------------------------
This will only work on mobs. x can be $n and $N depending on the exact
situation. Make sure to associate this inside an if check using is_npc()
to make sure you don't try to do anything bad on a player. The operator
will depend on what exactly you want to do and y will be an integer that
represents some mob in the game.
- if hp(x) y
-------------------------
This returns the number of hitpoints x has. Therefore, it is valid for
both mobs and players, so $n and $N are both valid for x.
- if room(x) y
---------------------------
This returns the room that x is currently in. It doesn't whether x is
a player or a mob since both exist in single rooms, so $n and $N are
both valid.
- if sex(x) y
--------------------------
This returns a value that represents the mob or player's sex, so $n and
$N are both acceptable. The values for each possibility are found below.
- if position(x) y
-------------------------------
This returns a value that represents the mob or player's current position,
so $n and $N are both acceptable. Each associated possiblity are listed
below.
- if level(x) y
----------------------------
This is a lower level version of the isimmortal and ismortal allowing you
to fine tune things a bit more. It will work for both $n and $N.
- if pcclass(x) y
------------------------------
This returns a value for the player's class. Only $N is valid for x since
classes do not affect the behavior of mobs. The associated values are
listed below.
- if pcrace(x) y
-----------------------------
This returns a value for the player's race. Only $N is valid for x since
mob's races are different than player's races. The associated values are
listed below.
- if mobrace(x) y
------------------------------
This returns a value for the mob's race. Only $n is valid for x. The
possible values for it are listed below.
- if objtype(x) y
------------------------------
This is functional but unusable for now. This returns the object type
of the object the prog is attached to. Therefore, only $p is valid for
x. The possible values are below.
- if objval(x) y
-----------------------------
This is functional but unusable for now. This returns the object value
in question. Each object has 0, 1, 2, and 3 values, so x can be those
4 values only.
- if name(x) y
---------------------------
This differs a bit from the previous operator based if checks. This
returns the name of the mob or player (so you can use both $n and $N),
but it returns it as a string rather than a number, so you are restricted
to the string operators talked about below.
11........Mobprog commands
Here's the basic list of available commands and a brief explanation of what
they do and are capable of.
- global_var[] =
------------------------------------
This allows you to manipulate the global variable represented by
as discussed above in the 'Variables' section. can be anything you
want stored, but it -will- be translated into a string for storage. It is
up to you to use the num() function later if you want it to be a string.
Note that the syntax uses square brackets, not parentheses.
- local_var[] =
-----------------------------------
This is identical to the global variable specification in all respects
except where the variable can be accessed from (only in the same mobprog
for locals, etc). Note the use of square brackets and not parentheses.
- mecho [mob|char|room|zone]
--------------------------------
This echoes the text to the specified target. If you echo it to the mob,
it will go back to the mob involved in the mobprog. Be warned, that this
will run the possibility of triggering another 'text' triggered mobprog.
The other possibilities are 'char' and 'room' which go to the character
or mob responsible for triggering the prog and the room the mob is in
(but NOT the 'char' and 'mob' targets) respectively. 'zone' will go to
the entire zone that the mob is currently in. The various variables you
can use are listed below. It's best to use these, but ONLY in mecho()
so it'll ensure the correct capitalization for names, etc.
$n (name for the initiator)
$N (name for the mob)
$m (him/her/it for the initiator)
$M (him/her/it for the mob)
$s (his/hers/its for the initiator)
$S (his/hers/its for the mob)
$e (he/she/it for the initiator)
$E (he/she/it for the mob)
- mload [mob|obj] [mob/obj #]
mload [gold] [amount]
-------------------------------
The valid types are 'mob', 'obj', and 'gold', depending on what you are wanting
to do. This will load the mob/obj with the specified vnum. If it is a mob, it
will load that mob in the room with the mob running the prog. If it is an obj,
it will load the object and place it in the mob's inventory. If you use the gold
target, it adds that amount (which must be positive) to the mob's on-hand gold,
not what they have in the bank, etc. There is no message talking about the
loading, so if you wish it to be visible to the players, you need to use mecho
for the message. After you use the mload command a series of variables become
available to you. The scheme is of this plan:
%lastload.[mob|obj].[name|vnum]
%lastload.[gold].[amt]
Now, the gold one is pretty simple, but one thing about the mob/obj name
variable. It only contains the first word of the keyword name. So, if the
mob is a keyword list like 'puck elf asskicker', it will only be 'puck' in
that variable. This is intended for you to be able to refer to them in
future commands like 'mexec give %lastload.mob.name% sword' and the like.
- mequip [obj vnum] [wear position]
-------------------------------------
This equip the mob with the prog with the specified object in the specified
position. This ignores all checks like str/weight, min int/wis/dex, etc, so
make sure this is really what you want to do. If you want those checks to
run for some reason, do an 'mload' and then an 'mexec wear' sequence to emulate
what a player would echo to do it. The wear positions are the same as those
used in the zone files (0-17 at the time of this writing), so see the zone.txt
file for the list of those when needed.
- mgive [exp] [exp amount]
mgive [skill|spell] [skill/spell number] [skill/spell level]
----------------------------------------------------------------
This 'gives' certain things to the player responsible for triggering the prog.
The exp variation can take a positive or negative value for the amount, so you
can both reward and penalize a player if need be. The skill/spell variation
is related to granting and revoking the use of a skill/spell. This is highly
used in the teacher progs, but should be RARE anywhere else in the game. You
can get the skill/spell number from an Immortal if you don't have access to one
yourself, and the skill/spell level needs to be in the range 0 to 101, where
0 takes the skill/spell away from the player and 101 makes it always succeed
(for most skills/spells anyway). Note, above 97 is reserved for Immortal use,
you should never set a skill higher than 97 for a player.
- mgoto
------------------
This will move the mob with the prog to the specified room. This is also
a silent command, so the players will not see the mob enter. If you wish
them to see something, you need to use mecho for the message.
- mat
--------------------------
This allows the mob with the prog to execute a command in some other room.
This can be used as a trigger for other mobs, or to silently heal the
mob without players seeing.
- mtrans [char|[room char|obj|all]]
-------------------------------
This will move the targeted players and mobs from their current room to
the specified room #. It is a silent move, so if you want the person to
see that they're gone, you need to use mforce to make them do a 'look'.
When using the 'room' target, you can choose to move all the mob, objs,
or both, but one of the 3 -must- be chosen.
- minvis [on|off]
------------------
This will cause the mob to wizinvis/unwizinvis. This is a silent prog.
This is useful for having the mob do things you do not wish for players
to see.
- mforce [char|room]
--------------------------------
This forces the target to execute the specified command. They will have
no ability to save or anything. A good comparison is to the Immortal force
command you see before we reboot, etc.
- msetpos [char|mob|room]
--------------------------------------
This alters the targets position silently. It allows you to set the person
to any position (listed below), but if you want them to know they got set,
you need to tell them about it with an echoat or echo. Be careful with the
Dead position, it will most likely result in their death even if they really
had 1k+ hp. Also, positions such as Mortally Wounded and Stunned will not
last if they HP is not set accordingly as well as that position. Fighting
will also not last if the person is not indeed in combat (which sets the
Fighting position for you anyway).
- mskill [args]
---------------------------------------
Much like the 'mspell' command below, this executes a given skill for the
mob. The can be found by an Immortal should you need to know one.
The [args] field is optional, and only used when the command in question needs
one. For instance, if you wanted to 'battlecry' you'd do something like
'mskill 353', but if you wanted to backstab someone you would do something
like 'mskill 154 danar' to backstab me.
- mspell [char|mob|area|all|arg ]
---------------------------------------------------------
This casts the spell that is represented by the . This number can
be found in the sinfo command within the mud or by asking a coder if you don't
have access to an Immortal character. If the target is an area spell, specify
the area target to simplify the code checking. The all target is reserved for
a single target spell. You can't use it with an area spell under any
circumstances. It will loop through all the people in the room and cast the
single target spell on each person. It doesn't matter if it is a nuke or a
healing spell, every person will get one cast on them individually. The arg
argument is used when there is a specific target that needs to be resolved.
It will take the 'target' field above and try to resolve it into a target IN
THE SAME ROOM, and use that entity as the spell's target. This is useful, for
example, in healing a specific mob when in combat or nuking a specific person
if you want to be really mean (ie 'mspell arg othen').
- mdamage [char|area]
---------------------------------------
This will cause damage to the target. If area is specified, then damage will
occur to all characters in the room. The dice of the damage is: XdY+Z. The
damage occurs without any messages, so you should us mecho to give the char
and/or the room messages so they know what happened.
- mpeace [char|mob|room]
--------------------------
This stops the fighting of the specified target. Valid targets are char, mob,
and all. If using the char or mob option, it will stop the target and anyone
in the room fighting that person. If you use the 'all' option it will stop
any combat in the room whether it involves the mob or not. It will silently
stop said combats, so make sure to mecho a message if you want people to
understand what happened.
- mexit_add '' ''
----------------------------------------------------------------------------------
This mirrors the exit creation from the wld files. The is a value
of 0 up to 5, just like the "D" variable in the wld files. The valid
values for , , and are exactly the same as
they are in the wld files for simplicity. The keywords represent how one
refers to the exit if it's a door, etc. The desc is just like in the wld file
also for when you 'look' in a certain direction. Note the ' characters on
either side of the and sections. These 4 characters are a
MUST. Without them, you'll get a bunch of junk. Also, note that you don't
need a newline after the field as you do in the wld file.
- mexit_remove
----------------------------
This will remove an exit in a certain room. It only works if there's already
an exit in that direction. The valid values for are 0 up to 5,
just like the numbers "D" in the world files.
- mwait [char|mob|room]