Daleken Enhanced MUD Programs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
This document describes all the enhancements that have been made to the original MOBProgram code. A knowledge of the workings of the original MOBProgram system is not required but you probably should read the document as not all sections of that document are covered in this file. My apologies for this document, it was written hastily in order that builders could start work on their own programs, further revisions are possible but like I always say "Don't hold your breath!". -- Symposium 6/99
In addition to the above, I should add that this document is often a little too technical for most people's needs and the important sections are a little sparce. This makes the rather simple process of writing a mud program a little daunting to beginners. I hope to write a few simple html pages with the core information on those pages, so hope remains! -- Symposium 2/00
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Table of Contents | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Background | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Once upon a time muds were pretty lifeless places, nothing much happened outside of a player's own imagination. One of the problems was that mobiles weren't terribly intelligent, they were all the same and they could be depended on to react the same way, if they did even react. The problem was that making a mob that little bit more special required a friendly relationship with a coder who would have to hard-code any intelligence, which meant either very few mobiles got smart, or, as is more common, mobiles stayed dumb. The solution proposed was to have mobiles have some sort of soft-coded programs that can be interpreted in game and can be loaded and saved through area files with all the other standard information. This system has vast benefits for the game, it makes the game more intelligent and it makes it easy for builders to create intelligent creatures in their areas. Further thought has since gone into the idea and the conclusion was that while mobiles having their own little programs was nice, much of the really cool ideas involved some far more complex things. Thus the idea to extend the system a little and add programs and triggers for objects and rooms, the two other major components of the MUD. And while we were at it, lets make the programming a little more flexible, not that it has to be difficult just a few extensions to give it a little more whzzz. Once again, the basic idea: let not only mobiles, but objects and rooms react to a myriad of mud events/situations by having them perform a list of commands which can be tailored to the moment through a simple and not so intimidating scheme usable by any creator. While this isn't universally understandable to builders this is one hell of a lot better than writing a lot of C code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Terminology | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In this document there are a few standard terms used, this makes it easier to write and, once you become accustomed to the words, easier to read. First of all you will need to understand the terms, after all we aren't all coders.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Main Additions | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In DalekenMUD the entire program system has had a reworking and it now hardly resembles the original code. The additions made have made it possible to create more intelligent creatures as well as some neat additions which add new dimensions to the base MOBPrograms. There is only one change that should be made to existing mobprograms, for details see the note on the 'rand' function below. (Search for the string 'rand') New TriggersA series of new triggers have been added to allow a wider range of situations in which a mobile will/can react. Object and Room ProgramsObjects and Rooms can now react to situations like mobiles, there are triggers for these as well as being able to react on some of the same triggers as mobiles, Objects and Rooms can react to individual situations themselves. New ParserIF statements have been expanded to allow nested IFs and WHILE statements, this expands the usefulness of a single program and avoids some of the restrictions/bugs of the old system. Sub ProceduresCertain MOBPrograms (they as yet cannot be called on Objects and Rooms) can be triggered from within other programs on the same mob and can even be triggered by another mob. This allows a degree of communication between mobiles and also avoids the nasty long programs that were common previously. VariablesMobiles, Objects and Rooms can now store variables which allow them to remember things for a certain period. This allows some degree of state and further expands the capacity of programs. Expanded SubstitutionThe i.e. you can trigger on "p a rock hits $n on the nose!"Be warned about this type of trigger, once characters get access to the "setname" command, they wont appear as just their name, and immortals almost always have bizarre setnames that will cause this to break. Of course variables can be substituted in any position like the old
Hard-coded FunctionsCombined with the expanded substitution is the new method of functions. This allows simple arithmetic and functions. These new functions are used in the precessing of IF and WHILE statements and they can be substituted to get values throughout the program. String functions are also available, which can turn numbers into strings or find special fields like name and descriptions. There are lots of functions available, LOTS and LOTS and LOTS and... Regular Expression for TriggersTriggers now have the option of triggering on a regular expression. This allows more flexibility. The Wait CommandThis command allows the program to be frozen for a time and to be continued later. The current state: variables and stack, are stored as an event and then the program is restarted after a period of time. Return ValuesPrograms now may return a value from the program. This value may have some affect on how the program continues around it. The value defaults to 1 which generally wont cause any additional affect. Refer to the trigger types below. Unique IdentifiersEvery player and object now has a unique key value that ensures that it is individual. This can be accessed by mudprogs to ensure that a program is always directed at the correct target. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The New Syntax | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There are a few minor changes to the syntax of programs resulting from these enormous changes. Mainly the changes will influence how future programs are run, not impacting too much on already working programs. The same basic structure has been followed to a large extent, mainly there are additions. CommentsAll (decent?) programming languages have at least some support for
comments. So here whenever a line starts with a The IF StatementThis follows the same form as previously: "if" {some conditional statement} [ "or" {some conditional statement} ] . . . [ "or" {some conditional statement} ] [ {program command} ] . . . [ {program command} ] [ "else" [ "if" {some conditional statement} ] ] [ "or" ...] [ {program command} ] . . . [ {program command} ] "endif" There a two major changes to this statement:
The WHILE StatementThis statement is very similar to the IF statement in syntax: "while" {some conditional statement} [ "or" {some conditional statement} ] . . . [ "or" {some conditional statement} ] [ {program command} ] . . . [ {program command} ] [ {program command} ] "endwhile" The only difference between this and an "if" is that the program loops continually while the statement at the top is true. Builders writing "while" statements should be careful that it isn't possible to get into an infinite loop, this is a terminal affliction in all programs. SubstitutionsThe substitution method of the original system has been kept and expanded to allow a few additional substitutions. The MUDProg has references to a few characters and objects and certain values can be obtained and substituted into the program for each of these. When the program is interpreted these values are expanded to suit the situation. Here is a small table of the standard substitutions used, refer to the original documentation if you are confused by this small table.
$$ gives the $ symbol.
KEY:
The name field values ($i, $n, $o...) are values which are commonly used in functions to identify mobs/objects. Unique IdentifiersBy simply adding a hash (
While this may seem a little confusing, it can be extremely useful for avoiding complications in programs where items may be mixed in amoungst a number of other items with the same keyword, or you are looking for a particular mob that has triggered the program. Note: There is also a function for obtaining the unique id number of a character or object, use this when you need to keep tabs on them and they aren't directly related to the program. Special SubstitutionsVariables can be substituted by referring to them by name,
There are also system defined variables The value of a number function can be substituted in general code, thus general algebra/maths can be done in the program, e.g.:
Variables are automatically expanded inside these brackets so there isn't any messy multiple substitutions necessary. Variables are identified by the fact that they don't have a digit at the start and they aren't followed by parentheses. Variables also exist for the current program, these values cease to exist
after the program is run and can be a fair bit tidier if you only want
something for a short period. These values can be set using the command
Number functions are the most commonly used construct in number substitutions as they give access to a wide range of information, a common substitution is:
Number functions are identified by the parser as having alphabetic characters (i.e. a-z and A-Z) at the start and a term in parentheses straight after them. String function substitution is rarely used but it can be used to get a name for something that has a value, most commonly a character class or race, sometimes a skill. These are substituted as a single function only as below:
This demonstrates the use of the table function, using the "class" table the value from the "class" function was looked up and the name of the class substituted. OperatorsIn the number functions and IF and WHILE statements all the standard C style operators below can be used (this time I'm not lying, the old system fudged it, I, on the other hand, am serious):
* - these operators apply to the number to the right only. Logical operators are not evaluated in the same manner as in C, you can't rely on the result of the first term to not have the second term evaluated. all terms are evaluated, relevant or not. For example the following code causes bugs to be reported as when $r doesn't exist the level function cannot be performed: if exist($r) && level($r) < 5 say Hello $r! endif to fix the problem in this case, use the following code: if exist($r) if level($r) < 5 say Hello $r! endif endif Try not to use the binary and logical NOT operators together, who knows what the answer will be, use parentheses if you really must. Sub ProgramsIn order to split up programs into reusable bundles (an idea which hit programming a long time ago) Daleken has now introduced MUDProgram subprograms. The idea is that commonly used bundles of commands can be grouped together in a single, separate program. A new type of program exists whereby these commands can be run from within another program entirely. The sub_prog can be run using the command "sub" with any arguments you like passed in on the line after:
A further addition is that these subprograms can be triggered from another mob/object/room progam by using the "trigger" command. Since any program can return a value, sub programs may also return a value, this value is stored in the variable "subreturn". However this return value is not set when the trigger command is used, instead look at the function "sub" below. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Differences between Mobile, Object and Room Programs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In order to understand the differences in the types of programs, you must first understand how the programs for objects and rooms work to a certain extent. Both Objects and Rooms cannot themselves perform commands, so when they have a program to run the MUD creates a special mob to perform the commands for them. For this reason there are a few commands which Objects and Rooms cannot perform:
Rooms and objects may cast defensive spells on players, but be careful here as strange effects may occur. There are no hard-coded restrictions, however the results from these commands being run from an Object or Room progam could be extremely nasty. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Triggers | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This section describes the different programs that are run as a response to different game events. Most programs are on a first in line only basis, the first program encountered that is run successfully is the last on checked, ie as soon as a program is run the others are ignored. So the order of programs is slightly important. Those which don't use this principle are marked with a *. Note also that triggers of the same name may have totally different application when applied to an object as opposed to a mobile, take care to ensure you are in the right context when using these programs. Argument types are as follows:
Regular Expression SyntaxThis is by no means a complete regular expression help, but it may help with mudprog programming. A regular expression is a series of branches or options separated by '|' symbols. Each branch is comprised of a number of pieces, which are mostly single characters. A piece or character can be followed by a modifier symbol which signifies how many of that piece can be matched:
A piece can be non-character symbols:
A piece can also represent a range of characters by using square brackets
'[]'. Inside these you can put any character and a range is represented
using a '-' (e.g. Regular expressions in this case also have a grouping notation represented
by '\(' and '\)'. These allow you to group branches or pieces into a single
piece. Also these are useful in extracting a sub-string from the triggering
string, as these grouped sets are put in Special variables like ${2} when regular expressions are used are as follows:
Examples:
Common TriggersThese are common to all types of programs, more or less, some restrictions apply to certain types. GLOBAL_PROG (vnum of global program)This program is special in that the program here doesn't actually do anything, the code is totally ignored. This really serves as a reference to a globally created program with the specified vnum. FOr more information see the section below titled "Global Programs". * ACT_PROG (wordlist)This is the most generic of all triggers, any act message that goes to the
room can trigger an * SPEECH_PROG (wordlist)This is triggered when someone speaks. RAND_PROG (percentage)This program is run at regular intervals for mobile, room and object. This can be used to add extra character to mobiles which would normally just stand motionless. * GREET_PROG (percentage)This program is run when a player enters the room. Sneaking characters can avoid this program. This is often used for shopkeepers in combination with the "isopen" function to greet customers. * ALL_GREET_PROG (percentage)Like NOTE: Neither SUB_PROG (the name of the program)Described above. The argument is the name of the program, this should be a single word as this makes referring to the subprog much easier. TIME_PROG (a list of number separated by spaces)When the time reaches any one of the times named in the argument the program is run. REPOP_PROG (percentage)Run when the mobile or object is created and entered into the world. Builders should be careful that the program doesn't kill the mobile concerned. (NOT FOR ROOMS, der!) LOOK_PROG (percentage)Run when a player explicitly looks at the mob/object/room. COMMAND_PROG (list of commands to trigger on)Run when a player types one of the commands in the trigger. The command entered must match the command exactly in order to work properly. In addition the This program triggers in a special way, you must specify the exact command word to trigger on although you can specify several command words. Additionally if you are using this to mask actual commands you can use the following notation to signify part of a command:
The vertical bar signifies that any letters after it are optional,
so that this is equivalent to the long list:
As you can see this is useful for masking system commands that are
commonly abbreviated such as equipment : eq|uipment .
Mobile TriggersFIGHT_PROG (percentage)This program is checked every round that the mob is fighting. DEATH_PROG (percentage)This program is run after the mobile has been killed and just before it is extracted. This can be used to give players their quest prize or something like that or to leave a legacy (maybe drop a box of explosives). Note that this program cannot stop the mobile from dying, this is merely a means of getting a few things done before it dies. The return value of the program is examined and if it is non-zero, the mobile will be free to scream a last death cry. HITPRCNT_PROG (hit point percentage)This program is run every round after the mobiles hitpoints reach below the specified percentage of their maximum, it has been used previously so that the mob then starts casting heal on itself every round. Only one of these programs is run, so if there are multiple programs they ones with higher numbers should be placed last. ENTRY_PROG (percentage)Run when the mobile enters the room, can be used to announce their presence or to check that someone is here or not. GIVE_PROG (object name or "all")This is run when the mobile is given the named object. The argument must be the complete name of the object in order to trigger properly. The first successful trigger is the one that is run, so you can have an "all" trigger catch all rubbish that is given to the mob. BRIBE_PROG (gold amount)This program is run when the mob is given the right amount of gold, only
one ATTACK_PROG (percentage)This program is run when the mobile is first attacked by someone. The mob gets its actions before the attack goes through so using "peace" has no effect and moving out of the room permanently is the only way of stopping the fight occurring. DELAY_PROG (percentage)This program is checked when the mob gets out of imposed delay. This happens when the "delay" command has been used on the mob. This program is used to time programs. Known bug/loophole: if the mob is thrown/smashed/tripped when in delayed by this method it can prolong or shorten the delay. Object TriggersWEAR_PROG (percentage)Triggered when someone wears the object. If the return value is false, the program will prevent the character from wearing the item. REMOVE_PROG (percentage)Triggered when someone removes the object. If the return value is false, the program will prevent the character from removing the item. SAC_PROG (percentage)Triggered when someone sacrifices the object. Like the DEATH_PROG this can't stop the object from being extracted. If the return value is false, the program will prevent the item from being sacrificed. EXAMINE_PROG (percentage)Triggered when someone examines the object, this is the "look in" command as opposed to the actual examine command. This is used for when someone looks in a portal, container or something like that. USE_PROG (percentage)This is triggered on the object type specific use of the object. So for
scrolls this is when it is recited, wands, when zapped, staves when
brandished, etc..., if an object is used somehow this prog is run. Like the
GET_PROG (percentage)Triggered when the object is picked up. If the return value is false, the program will prevent the character from getting the item. DROP_PROG (percentage)Triggered when the object is put back down. If the return value is false, the program will prevent the character from dropping the item. DAMAGE_PROG (percentage)Triggered when the object is damaged in some way. REPAIR_PROG (percentage)Triggered when the object is smithed or repaired. OPEN_PROG (percentage)Triggered when the container object is opened. CLOSE_PROG (percentage)Triggered when the container object is closed. LOOT_PROG (percentage)Triggered when someone loots the container. If the return value is false, the program will prevent the character from getting anything from the chest. Room TriggersSLEEP_PROG (percentage)Triggered when a player sleeps in the room. If the return value is false, the program will stop the player from sleeping. REST_PROG (percentage)Triggered when a player rests in the room. If the return value is false, the program will stop the player from resting. LEAVE_PROG (percentage)Triggered just before a player leaves the room. DROP_PROG (percentage)Triggered by a player dropping an item on the ground, the return value of 0 prevents this from happening. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Global Programs | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
These progams are loaded and saved with an area instead of a particular mobile, object or room. They each have a specific vnum like a mobile, object or room and have their own separate section in the area file. These programs have a type, triggers and commands like any other program.
Through the use of the SPEECH_PROG with
a vnum of 901 and a trigger message of "hello", then we add this program to
all of the guard mobiles in the area by giving them a
GLOBAL_PROG with an argument of "901". Now the guards all have
effectively the same program, all triggering when someone says "hello" and
resulting in the same action, this reduces the duplication of code.
One addition that has been made for use in OLC is the addition of a restriction on what type of thing the program can be added to, this is not enforced in the loading of an area, but it is when the area is being edited online. This ensures that programs designed for mobiles aren't used for objects and rooms primarily, that being the main concern. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Functions | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is a list of all the functions available with a description of how they work. All functions are in the following form:
"function" is the name of the function, "arg1", "arg2", ... are the names of the values that the function works on.THERE ARE LOTS AND LOTS OF FUNCTIONS AVAILABLE. Notation and Variable Types as Used Below
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Commands for Mobiles | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Mobile commands are somewhat restricted in order to provide security from players, there are a number of program only commands that allow mobiles to perform unusual tasks. Unlike the previous MOBPrograms these commands are not included in the regular command table. This means that mob commands can shadow (have the same name but do different stuff) regular commands. Getting Around the RestrictionAs soon as there is a restriction there is a loophole. We found that programs are useless unless mobs can force other mobs to perform these commands. So we invented a loophole. Why bother you ask? Well this gives a central place were we can tighten security rather than a million holes. The "mpcomm" command allows mobiles to access the special commands. For example a mob wants to force another mobile to
Note: the only addition from the force command is the "mpcomm" (which can be shortened to "mp"). PLEASE READ THE NOTES ON FORCE and MPCOMM below. The CommandsASOUND
Sends a message to this room and all the rooms adjacent to it. Useful for powerful mobiles and those with things like music and so forth. AT <location> <command>Much like the immortal command "at", it performs the command at the named location. BREAKThis is an internal mobprogram command, it signifies that the program should break out of the current loop (if there is one) this differs from the original in that it can be used in a while loop and not terminate the program. BURROWCauses the mobile to burrow itself into the ground, thus becoming totalling invisible to everyone, except those with holysight (ie. immortals). CAST <spell> <target>Used like the other command of the same name. PASSAGEOPEN <fromvnum> <tovnum> <direction>PASSAGECLOSE <fromvnum> <direction>This pair of commands allows mobprograms to open and close temporary exits between rooms. This command opens an exit from the room with vnum <fromvnum> to the room with vnum <tovnum> in the direction specified. Mobs can also close this temporary passage by specifying the originating room and the direction to remove. NOTE: these temporary exits aren't saved in area files, so you can create them and leave them if you wish. DAMAGE <character> <amount>Does the specified amount of damage to the character, this is done silently so you have to add your own damage message if you want. This can kill a target so be very careful how much damage you inflict and (more importantly) how you refer to the target after you have inflicted the damage. DELAY <character> <amount>Sets an amount of lag for the character specified. The amount is a number of game pulses that they are lagged for (divide by 4 to get the number of seconds). After being delayed like this a mob can have it's delay_prog triggered. LOCAL <variable> <value>SET <variable> <value>DELETE <variable>UNSET <variable>These commands allow you to set and remove MUDProg variables on a mob/object/room. The set command is most often used with some form of substitution to set the variable. Delete and unset are synonyms for the command that removes a variable and frees up the memory it used. The local command sets a variable on the current program, there is no need to delete these values in the program as they are automatically deleted when the program finishes. Use of variables is a process which cannot be covered in this file as there are many ways to use them, we couldn't even begin to think of the possibilities. This file is not a programming tutorial we have to leave some things up to the creator. DREAM <character> <message>This sends a message to a sleeping character as if they dreamt it. ECHO <message>This echoes the message to all the awake characters in the room. It uses
the ECHOAROUND <character> <message>Sends the message to all in the room except the specified character. ECHOAT <character> <message>Sends the message to the specified character. EVAL ...This builtin command is used for special cases when one set of substitution is not quite enough. This command expands all '$' expressions in the line and then parses the line that results as if it were the normal thing to do. This also includes things like 'eval if ...'. This means that you can use variables within variables if you think it necessary. This command opens up a whole range of options for the scripter, but often it just makes code unreadable. The two main uses:
FORCE <character> <command>QFORCE <character> <command>Forces the character to do the command, much like the imm variety, except silent, the player gets no indication of what they are being forced to do. Be careful to make sure that the character can do this command (see below), otherwise they will get some strange error messages and the program may not run as you expected. !!!IMPORTANT!!!This command is different in a number of respects to the immortal command, the differences are subtle and they probably wont affect the use of the command but there are implications to anyone who wants to do something tricky. The way that the mpcomm command works is that if a player attempts to enter a mob command through this method, the system blocks them as it realises that they are connected via a descriptor. Thus players cannot have mob commands processed in any way at all. The QFORCE command in the mob commands has a little addition which removes the descriptor temporarily from any character (player OR mobile) before running any command. This means that things like mpcomm are allowed and by using this command you can force players to access these mob commands. ANY forced commands will not be shown to the character, you will have to add emotes or echoes to fill the gaps. This has a large number of advantages for MUDProgs but use this only where you know ALL the implications, try to avoid over-using this pretty heavy-duty feature, as you can see here: WARNING! Allowing access to the mob commands doesn't mean that it should be allowed, for instance using "qforce $n mp kill xxx" as opposed to "qforce $n kill xxx" is dramatically different, the second ignores certain checks and may very well allow the player to undertake pkilling against his/her will. YOU HAVE BEEN WARNED!GOTO <location>Transfers the mobile to the specified location, like the imm command. HALTStops the program, no if's or but's. JUNK
JUNK all.
Extracts item(s) from the mobs inventory silently. Be sure you know what you carry it can extracts everything not worn, even object targets of the program, which is very dangerous. You can junk one object, a bunch of objects or the whole lot if you want. KILL <character>Like the player command used so often. This command is the mobile version as mobiles cannot actually "kill" anything by using this command normally. MLOAD
OLOAD
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Miscellaneous Junk | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The once was 'Wish List'Well, I did all those things, aren't I good (scoff). --Sym 8/2/2000 Regarding CPU SlowdownOf course this is making your MUD run slower, DER! The old documentation tried to dodge the issue by going on about aggressive mobiles and so forth, that was merely a way of deflecting the issue. Lets make no bones about this folks, you are adding an interpreted language to your MUD, of course it will make it slower, but that isn't the point is it? You are adding programs to make your MUD better. (Hey even that isn't guaranteed, even the best system can produce rubbish if you can't use it properly, you need someone who can use this sytem first don't you :P ). If you really are concerned about the adverse affects of adding these programs think a little on what it really does, a bigger executable, a few extra checks in various locations (often not commonly called ones) and the occasional parse of a program. This seems to be far outweighed by the benefits, and still Daleken runs fine on a 20MHz machine. Other infoThis is taken straight from the other document because it applies here... There is really no limit to the number of MOBprograms a given mobile can
have and the length of a single command block is only limited by the value of
The MOBprogram stuff runs totally without anything in the mob_commands.c file, but letting mobiles be a bit more godlike has allowed us to do what we consider to be wonderful things. The replicant and polymorphing mobiles described above as well as some nifty mob helping mob interactions are an example. It IS possible to accidentally make mobiles which can trigger in loops. As mentioned in the example at the end of this document, the result is usually a mud crash or major CPU dent. We don't know any way to prevent this from happening, other than careful coding and a restriction of mobile travel from zones of one creator to another (another good reason to not have charmed mobiles do anything). Tracking down the culprit mobile is not always easy. The only thing we have found which always works, is to add a log statement into the MOBprogram driver and fill some disk space until it becomes apparent what commands are repetitively issued. Also, most infinite loops are flukes where the situation just happens to be right and usually it never happens again. CreditsThe reason this code was written was to enhance the playing experience at ThePrincedom (a Merc 2.0 based world scheduled to open in October 1993). The original idea for this type of MOBprogram came from playing on: WORLDS of CARNAGE, a dikumud implemented by Robbie Roberts and Aaron Buhr. Aaron (known as Dimwit Flathead the First) was the original author from what I have been told, and I hope he will not be totally offended and angered by my coding and sharing a mimicked version with the world. This version is probably not as good as the original and I do feel remorse for publishing the idea. However, since Carnage has been down for months without a word of information regarding its return, I am glad to let one of the best features live on in future generations of MUDs. There are no objections to this code being shared, since, aside from a nuclear destruction of all the Temples of Midgaard (excepting the original one!!), bland mobiles are the greatest bane of Dikumuds today. It would be nice to get a message saying you are using the code just for our references. We shant answer questions from anyone until told where they are using the code. *grin* Since this code is not copyrighted, you of course dont have to do anything we say, but it would be nice of you to put the mobprog help screen into your database, and have mobinfo show up somewhere on a more visible help screen (possibly tagged onto the bottom of credits as a see also...) I acknowledge all the work done by the original Diku authors as well as those at Merc Industries and appreciate their willingness to share code. Also, quick thanks to Wraith for doing a little beta-installation testing.
In addition to this DOC file credit section, I'd like to add a thank you to Yaz, Mahatma, Zelda, and the rest of the Marble Mud crew for extensively testing MOBProgram 2.1 for me. You may see MOBPrograms in action as well as their own "flavor" of mud at marble.bu.edu 4000.
What they said goes for me too, I'd like to thank the creators of SMAUG for their version of the MOBPrograms, on which I based some of my ideas for Object and Room programs. Also the creators of the fabulous Death Gate Scripts seen often in CircleMUDs about the place.
Example(s)Ok so there is the sample program(s). You really should see the other file, it really is quite good, here is a simple example from one of our areas, it also demonstrates some of the more advanced features of our system. ? %Type mudprogs speech_prog~ $Args p cast a portal to~ $Comlist # The use of the positional parameter from the trigger string. say You want a portal to ${5} $n? # Note the assumed use of the name() string function. if strcmp(annoyed,name($n)) say You have tried my patience $n! kill $n halt endif if isevil($n) say Walk there you lazy bastard! set annoyed $n else if isgood($n) # No equality operator works on strings so we have to use strcmp() # However this allows implied use of the name() function again. if strcmp(lastportal,name($n)) say You shouldn't ask me too often or I'll get annoyed. set annoyed $n else say Very well, here you go. endif cast portal ${5} set lastportal $n else say You ask a lot of me $n! set annoyed $n cast portal ${5} endif ~ This is a speech_prog which allows a mob to cast a portal at a player's request, however if the player asks too often or is evil his gets hit for his troubles. Neutral players get some grace but not as much as good players. Better for the use of this program would be to use a regexp trigger and match a parenthesised block from the pattern ${r1}. The trigger string would probably look like...
...or something along those lines. This is of course a little smarter, but you are forced to thoroughly test the trigger to ensure you have gotten the correct syntax for the regular expression. For better examples look at caveofkn.are which has on helluva lot of programs to make mudschool smarter. |