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]