This section defines the encounters that may occur when the mud calls an encounter table. Like the #RESETS, the #ENCOUNTERTABLES create objects, load mobiles, equip those mobiles, and so on. Unlike the #RESETS, an encounter table cannot close doors or randomize rooms. On the other hand, an encounter table can execute a mobprog without a mobile present.
The #ENCOUNTERTABLES area header can have more than one encounter table. Each encounter table is specified by a vnum and a series of single-line commands. These commands are:
Here's an example of how the #ENCOUNTERTABLES area header is set up, taken from Shamrock's Cafe:
#ENCOUNTERTABLES #1 D 10 mShamrockCafeEncounters01 * mobprog D 10 mShamrockCafeEncounters02 * mobprog O 5 1 3 1d1+0 0 201 * clump of purple flowers O 5 1 3 1d1+0 0 202 * handful of white flowers O 5 1 3 1d1+0 0 203 * a small mushroom O 5 1 5 1d1+0 3 0 * choose a random object M 20 1 4 1d1+0 4 0 * choose a mobile #2 D 10 mShamrockCafeEncounters03 * mobprog D 10 mShamrockCafeEncounters04 * mobprog M 40 1 1 1d1+0 0 205 * a drunk E 5 7 0 * choose a torso clothing E 7 8 0 * choose a leg item E 8 9 0 * choose a foot item #3 O 35 1 2 1d1+0 0 :108:12819 * a yellow flower O 35 1 2 1d1+0 0 :68:300 * some herbs O 30 1 2 1d1+0 0 :68:304 * some wildflowers . . . #0
Again, each encounter table under #ENCOUNTERTABLES begins with its own vnum (see our previous discussion of vnums in the introduction to the #AREAS area header.). The encounter table then ends at the next vnum or, if the #ENCOUNTERTABLES area header is ending, at #0. The body of each encounter table is a series of single-line commands and comments.
Here's the breakdown of the commands:
The format for inserting mobiles into your area is as follows:
M [chance] [room limit] [area limit] [copies] [table vnum] [mob vnum]
1.slot: M signifies that a mobile is being loaded.
2.slot: the chance a mobile is loaded into the room.
3.slot: total number of copies of that mobile that may exist in the room.
4.slot: total number of copies of that mobile that may exist in the area.
5.slot: the number of mobiles placed in the room, given in terms of ndn+n.
6.slot: the table from which to draw the mobile (if [mob vnum] not used).
7.slot: the vnum of the specific mobile (if [table vnum] not used).
Examples:
M 10 2 3 1d2+0 0 202 M 20 2 4 1d2+0 4 0 M 2 1 1 1d1+0 0 :31:2540
The first example has a 10% chance of choosing one or two mobiles from a specific mob vnum in the area file, that is, mobile 202. If the room already has two such mobs in it (including any that may have wandered in from another room), the encounter will forfeit the choice (the mud will create no additional mobs there.) If the area has three of the same mob in it, no additional mobs of that same vnum will be made.
The second example resembles the first, differing only in that the encounter draws on a table internal to the area file, that is, table 4. If the table is called, the maximums specified by the command (2 and 4, respectively) will be ignored, and the new maximums found in table 4 will be used.
The third example resembles the first two, except it draws on a mob from a different area file. Yes, this can be done, and it will override any maximum world copies of that area file. (The area file specifies only 20 goblins of a specific vnum to exist in the world - the encounter table can place additional mobs of the same kind elsewhere in the world, or even in the same area file, thus going over the maximum allotted by the resets.)
G give an object to a mobileThe format for giving objects to mobiles into your area is as follows:
G [copies] [table vnum] [item vnum]
1.slot: G signifies that an item is being given to a mobile.
2.slot: the number of copies given to the mobile.
3.slot: the table from which to draw the object (if [item vnum] not used).
4.slot: the vnum of the object (if [table vnum] not used).
Examples:
G 1d1+0 0 26 G 2d1+0 15 0 G 1d1+0 0 :13:4159
The first example gives one copy of a specific item (26) from the area file to the mobile.
The second example gives two objects from a different table in the area file, which may or may not have randomly chosen objects in it, to the mobile.
The third example gives one copy of a specific item from a different area file to the mobile. This means any object from any file may be given to the mobile.
Note: Limits on items are respected, so by randomly placing that awesome (and limited) battleaxe on a mobile, you run the risk of that item not appearing on the mobile because the limit of the object has been reached.
E equip an object to a mobileThe format for equipping objects to mobiles into your area is as follows:
E [wear location] [table vnum] [item vnum]
1.slot: E signifies that an item is being equipped to a mobile.
2.slot: the wear location of the mobile.
3.slot: the table from which to draw the object (if [item vnum] not used).
4.slot: the vnum of the object (if [table vnum] not used).
Examples:
E 0 0 119 E 9 8 0 E 16 :27:8 0
The first example equips an object from the area file (119) to the "light" wear location of mobile.
The second example equips an object from a table within the area file (table 8) to the mobile's "hand" wear location. The table may have random objects to choose from.
The third example equips an object from an encounter table within a different area file to the mobile's "wield" wear location.
Note: Limits on items are respected, so by equipping that legendary (and limited) sheath to a mobile, you run the risk of that item not appearing on the mobile because the limit of the object has been reached.
R create a random objectThe format for creating random objects is as follows:
R [chance] [copies] [wearflag] [imbue]
1.slot: R signifies the creation of a random object.
2.slot: the chance a random object is created.
3.slot: the number of random objects created in terms of ndn+n.
4.slot: the wearflag of the object(s) created.
4.slot: chance that the random item will be imbued (rarely above 1).
Example:
R 30 1d2+0 16 1
The example above gives a 30 percent chance of creating one or two random weapons, which have a one percent chance of being imbued. Random items are the items created by the mud's random item creator.
Note: you should use this command ONLY in sub-tables for the give and equip commands.
O load an object into a room or sub-tableThe format for loading objects into your area is as follows:
O [chance] [room limit] [area limit] [copies] [table vnum] [object vnum]
1.slot: O signifies that an object is being loaded.
2.slot: the chance an object is loaded into the room or table.
3.slot: total number of copies of that object that may exist in the room.
4.slot: total number of copies of that object that may exist in the area.
5.slot: the number of objects placed in the room, given in terms of ndn+n.
6.slot: the table from which to draw the object (if [object vnum] not used).
7.slot: the vnum of the specific object (if [table vnum] not used).
Examples:
0 35 2 5 1d1+0 0 70 0 20 2 10 1d2+0 63 0 0 15 1 2 1d1+0 :92:13 0
The first example has a 35% chance of creating an object from the area file (70). If two of that object already exist in the room, however, no others will be made there. Similarly, if five objects of the same vnum already exist in the area, no others will appear.
The second example is similar to the first except it draws an object from an encounter table within the area file (table 63).
The third example is similar to the other two except it draws an object from an encounter table in a different area file. Yes, you can create objects that exist in one area and place them in another.
Note: Limits on items are respected, so by creating that powerful (and limited) breastplate, you run the risk of that item not appearing because the limit of the object has been reached.
Note: if used in a sub-table for give, equip, and put commands, the object will not load into the room, but onto the mobile or into the object, respectively. By default objects load into rooms.
P put an object in an objectThe format for putting objects in objects into your area is as follows:
P [copies] [table vnum] [item vnum]
1.slot: P signifies that an object is being put into another object.
2.slot: the number of copies of the object put into the object.
3.slot: the table from which to draw the object (if [item vnum] not used).
4.slot: the vnum of the object (if [table vnum] not used).
Examples:
P 2d1+0 0 48 P 1d1+1 7 0 P 1d2+0 :121:6 0
The first example puts two copies of an object from the area file (48) into another object.
The second example puts one to two copies of an object, and uses a table from the area file (table 7).
The third example does much the same as the second object, but uses a table from a different area file (table :121:6).
Note: Limits on items are respected, so by placing that wondrous (and limited) wand into a dresser full of clothes, you run the risk of that item not appearing because the limit of the object has been reached.
D execute a mobprog after the player enters the roomThe format for executing an encounter mobprog in your area is as follows:
D [chance] [mobprog]
1.slot: D signifies that a mobprog will execute after the new room is displayed to the character.
2.slot: the chance the mud will call the mobprog.
3.slot: the name of the mobprog itself.
Example:
D 10 mShamrockCafeEncounters02
The mobprog above has a ten percent chance of calling the mobprog named "mShamrockCafeEncounters02". This mobprog will activate after the player's new room is displayed. This is very useful for atmospheric programs (like animals running at the approach of a player). These kinds of mobprogs will activate only for the player entering the room with the encounter.
X execute a mobprog before the player enters the roomThe format for executing an encounter mobprog in your area is as follows:
X [chance] [mobprog]
1.slot: X signifies that a mobprog will execute before the new room is displayed to the character.
2.slot: the chance the mud will call the mobprog.
3.slot: the name of the mobprog itself.
Example:
X 20 mHaonDorEncounters01
The mobprog above has a twenty percent chance of calling the mobprog named "mHaonDorEncounters01". This mobprog will activate before the player's new room is displayed. This is very useful for atmospheric programs (like telling a player the new smells she's coming into as she enters the room.) These kinds of mobprogs will activate only for the player entering the room with the encounter.
Note: Keep in mind the mobprog will execute whether the player scans or enters the room - it executes before the room is displayed, whether she enters the room or not. A tricky detail, but one you should keep in mind nonetheless (the "D" command will not execute until after the player has moved into the room.)
T choose from another encounter tableThe format for choosing from another encounter table is as follows:
T [chance] [copies] [table vnum]
1.slot: T signifies a call to a new table.
2.slot: the chance a new table will be called.
3.slot: calls made to the new table.
4.slot: the vnum of the new table.
Examples:
T 15 3 12 T 35 2 :34:5
Both examples are set up the same, differing only to where they make their call. The first example, which has a fifteen percent chance of making three calls out to a new table, if successful will make the call to an encounter table in the area file. The second example, if successful, will make its call to a table in a different area file.
A choose from another encounter table - all entries checked onceThis way of choosing from another encounter table follows the exact format of the "T" encounter table command:
A [chance] [copies] [table vnum]
1.slot: A signifies a call to a new table.
2.slot: the chance a new table will be called.
3.slot: calls made to the new table.
4.slot: the vnum of the new table.
Examples:
A 20 2 8 A 25 4 :162:10
The setup of the examples above is the same as the setup of the examples found under the "T" encounter table command. The difference is if a call is made to the new table via the "A" command, every entry in that new table will be checked at least once, as opposed to the "T" command, which will check entries only so far as it fulfills its structure. Also, the "A" command allows you to create a table whose sum of chances can exceed 100. There's more on this below.
Hints for using encounter tables
#1 D 10 mShamrockCafeEncounters01 * mobprog D 10 mShamrockCafeEncounters02 * mobprog O 5 1 3 1d1+0 0 201 * clump of purple flowers O 5 1 3 1d1+0 0 202 * handful of white flowers O 5 1 3 1d1+0 0 203 * a small mushroom O 5 1 5 1d1+0 3 0 * choose a random object M 20 1 4 1d1+0 4 0 * choose a mobile
Even though the chances of each executable, object, and mob may differ from one to the next, the sum of all of them add up to 60, less than the 100 allowed.
EXCEPTION: If the "A" command is used, the table it calls to may have the sum of its chances exceed 100. This is because every thing in that table is checked at least once, and Dawn does not compare the chances of any one thing in the table against the other. See below for a further explanation.
Encounter tables are checked in terms of calls and chances. When a call is made by an encounter or a populator to an encounter table, or by an encounter table to another encounter table, the mud generates a number between 1 and 100. Whatever line that number corresponds to, that is the line returned. Let's take another example from Shamrock's Cafe:#6 O 35 1 2 1d1+0 0 205 <--------------- (1 through 35) O 35 1 2 1d1+0 0 206 <--------------- (36 through 70) R 30 1d1+0 N 1 <--------------- (71 through 100)
Suppose Dawn rolled up a "67". This means the second line of the encounter table is the one returned as the encounter. It works very much like encounter tables you will find in some RPGs. Note, however, two very important things about this: first, the mud always respects the limits given by the tables, that is, if a mobile wanders into a room that has not had an encounter yet, and a player walks into that room setting off the encounter, and the mud generates an encounter for the room, but the encounter generates a mobile of the same vnum, and the room is at its maximum number of vnums, then no mobile will be generated. The same is true of objects. Long winded? I think so. ;)
Second, if the sum of the chances is less than 100, and the number the mud generates exceeds the sum, no encounter will occur. In the first example given above, the sum of the chances is 60 - any number greater than 60 will return no encounter (which may or may not be what you intend.)
EXCEPTION: encounter tables called by the "A" command do not follow this convention. Instead, each entry in the table is checked, and a number is generated to see if that entry succeeds. In other words, by using the "A" command, it is possible to have several lines returned per encounter (perhaps a genie and his lamp appear in the same room at the same time.)
If a call is made by a command to an encounter table rather than to a specific mobile or object vnum, the "copies" in that command become "calls". So when asking for three copies from a new table, you are actually making calls to that table. The "G", "E", and "P" commands are considered to be "children" of the "M" and "O" commands, and are to be called only if their "parent" commands are called and chosen. The "R" command should be called only in "G" and "E" subtables. The "M", "O", and "R" commands will not be chosen if the room has reached its maximum number of encounters since the last area reset. Subtables of "O", "P", "G", and "E" commands may contain only "O" commands (and corresponding "P" commands, if any) and "R" commands. Subtables of "M" commands may contain only other "M" commands (and corresponding "G" and "E" commands, if any). Everything after the last field of a command is considered a comment. Conventionally, however, we use asterisks (*).