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.
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
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 #1000 say 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 1005 addmprog 1001 greet 50 done asave 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 1005 delmprog 1 done asave 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 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).
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.
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.
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
Main
About ...
the site
the author
Rant
Muds
Resources
Mobprog FAQ
Mobprog guide
Mobprog examples
Areas
Games
Morrowind
Rogue-likes
Art
Contact
Misc.
Links
Sitemap