Resets
From dodWiki
Making Reset Lists
By
Tank the Life Bringer at Dawn of Demise
(tdod.org port 4000)
Without a reset list, an area wouldn't refill itself when it came time for "repop". The reset list is the file the MUD uses to set everything in the area back to where it should be, restocks the mobs, and resets all the doors.
Every area MUST have a reset list. There are three ways to do this online:
Any time you make a new mob, object, or exit with a door, you must add a reset for it or it will not repop when the area resets itself.
Contents |
Instazone or Instaz
Syntax: instazone
Syntax: instazone nodoors
Instazone will write (or rewrite) the resets for the entire area based on the current positions of your mobs and objects. All you have to do is place each mob in its proper room, wearing what it should be wearing, carrying what it should be carrying, and objects in their proper places, or in their proper containers, and doors in their proper states, (open, closed, locked). It's kind of like taking a "snapshot" of your proto area; everything will be set on the reset list as it appears in the area.
If you've left a door open, it will always repop as open. If you've forgotten to add a mob, it won't appear unless you either manually add it, or do another Instazone.
The option of "nodoors" means no door resets will be created.
NOTE: This command will wipe out ALL existing resets! Do not use this command after you have added your own resets with 'reset add'. The recommended procedure is to use instazone, then use the 'RESET' command to add any special resets, and NOT use instazone again.
Instaroom or Instar
Syntax: instaroom
This command is the same as instazone, but is room-based instead of area-based, this command will write (or rewrite) the resets for the room you are in. This command is most useful for making small modifications to an existing reset list.
WARNING: Both "Instazone" and "Instaroom" have a problem when it comes to handling nesting objects.
I.e.: Objects that repop within objects on the ground.
The best way to handle these objects is to add them manually with RESET.
Reset
Syntax: reset <primary command> [secondary command] [parameters]
This command is used to display, edit, delete, add, insert, and perform resets in an area.
Valid primary commands are; list, edit, delete, add, insert, place, area, remove, mobile, object, hide, trap, bit, and random.
WARNING: When adding resets using reset, the order that resets are put in is VERY important. You cannot equip a mobile with an object before putting the mobile into a room. Likewise, you cannot put an object into a container until the container is put into a room.
Primary Reset Commands and Parameters
List
Syntax: reset list [start number] [end number]
This will display the list of resets currently set in the area that is assigned to you or the area you are in currently (in that order). If a starting number and an ending number are not specified, all resets will be shown.
Example:
reset list 1 10 1) (object) stone pale blue (5426) -> Main Street (5402) [1] 2) lamia beast (5401) -> A Garden Path (5403) [20] 3) long dagger slim (5438) -> lamia beast (wield) [150] 4) lamia beast (5401) -> A Garden Path (5404) [20] 5) long dagger slim (5438) -> lamia beast (wield) [150] 6) lamia beast (5401) -> A Garden Path (5405) [20] 7) long dagger slim (5438) -> lamia beast (wield) [150] 8) (object) stone scarlet blue (5427) -> A Garden Path (5405) [1] 9) lamia beast (5401) -> A Garden Path (5406) [20] 10) long dagger slim (5438) -> lamia beast (wield) [150]
Edit
Syntax: reset edit <number> <secondary command> <parameters>
Allows you to edit one line of resets, if you know the reset number. The reset number can be found using the ‘reset list’(see above.)
In the above example reset 3 is:
3) long dagger slim (5438) -> lamia beast (wield) [150]
Valid <secondary command> and their related <parameters> will follow in the section 'Secondary Reset Commands'.
Insert
Syntax: reset insert <number> <secondary command> <parameters>
Allows you to insert a reset before the reset number specified. The inserted reset becomes reset <number>. All following reset numbers are increased by 1.
Ex. reset insert 3 <secondary command> <parameters>
3) inserted reset info would be here
4) long dagger slim (5438) -> lamia beast (wield) [150]
Valid <secondary command> and related <parameters> will follow in the section 'Secondary Reset Commands'.
Add
Syntax: reset add <secondary command> <parameters>
Allows you to add a reset to the END of the reset list.
Valid <secondary command> and related <parameters> will follow in the section 'Secondary Reset Commands'.
Delete
Syntax: reset delete <start number> [end number]
Allows you to delete one or more resets. If <start number> is stated without [end number] only <start number> reset will be deleted.
Area
Syntax: reset area
This will reset: The area that is assigned to you or The area you are in currently (in that order).
Secondary Reset Commands
I'm going to do a little something different here. I'm going to insert this section here since insert, add, and edit all use this information. More primary commands follow this section.
MOB
mob <mobile vnum> <room vnum> [limit]
This loads a mobile into a room. The limit is how many of this mob vnum can exist at any one time in the mud. No more copies of this mob will repop until the number of copies drops below the [limit].
OBJ
obj <object vnum> <room vnum> [limit]
This loads an object into a room. The limit is how many of this object vnum can exist at any one time in the room vnum. No more copies of this object will repop until the number of copies drops below the [limit].
GIVE
give <object vnum> [limit]
This reset gives the object vnum to last loaded mobile. (not sure about [limit] here though)
EQUIP
equip <object vnum> <wear position> [limit]
This will equip object vnum in <position> (see wear position below) on last loaded mobile.
Wear positions for equip (use number):
| No. | Location | No. | Location | No. | Location |
|---|---|---|---|---|---|
| 1 | light | 2 | finger1 | 3 | finger2 |
| 4 | neck1 | 5 | neck2 | 6 | body |
| 7 | head | 8 | legs | 9 | feet |
| 10 | hands | 11 | arms | 12 | shield |
| 13 | about | 14 | waist | 15 | wrist1 |
| 16 | wrist2 | 17 | wield | 18 | hold |
| 19 | dual_wield | 20 | ears | 21 | eyes |
| 22 | missile wield |
Note: These are offset by +1 from the object wear locations
PUT
put <object vnum1> <object vnum2>
This puts <object vnum1> into <object vnum2>
DOOR
door <room vnum> <door dir> <state>
This resets a door, located in <room vnum> leading in <door dir> (see door directions below) to a certain state (see state below).
Door direction: (use number)
| Direction | Value |
|---|---|
| NORTH | 0 |
| EAST | 1 |
| SOUTH | 2 |
| WEST | 3 |
| UP | 4 |
| DOWN | 5 |
| NORTHEAST | 6 |
| NORTHWEST | 7 |
| SOUTHEAST | 8 |
| SOUTHWEST | 9 |
| SOMEWHERE | 10 |
State:
- 0 - open and unlocked
- 1 - closed and unlocked
- 2 - closed and locked
RAND
rand <room vnum> <last door dir>
This randomizes a range of exits
TRAP
trap <vnum> <type> <charges> <flags>
This sets a trap.
VNUM - The vnum of either the room or object to be trapped.
TYPE - The type of trap.
| No. | Type | No. | Type |
|---|---|---|---|
| 1 | Poison gas | 8 | Flame |
| 2 | Poison dart | 9 | Explosion |
| 3 | Poison needle | 10 | Acid spray |
| 4 | Poison dagger | 11 | Electric shock |
| 5 | Poison arrow | 12 | Blade |
| 6 | Blindness gas | 13 | Sex change |
| 7 | Sleeping sickness | 14 | Ice blast trap |
| 15 | Paralysis trap |
CHARGES - The number of charges this trap should contain.
FLAGS- Flags specifying the characteristics of the trap:
| Flag | Description |
| ROOM | Trap is in a room |
| OBJ | Trap is on an object |
| ENTER | Trap is triggered by entering the room |
| LEAVE | Trap is triggered by leaving the room |
| OPEN | Trap is triggered by opening |
| CLOSE | Trap is triggered by closing |
| GET | Trap is triggered by getting the object |
| PUT | Trap is triggered by putting the object |
| EXAMINE | Trap is triggered by examining the object |
| PICK | Trap is triggered by picking the object |
| UNLOCK | Trap is triggered by unlocking the object |
| NORTH | Trap is triggered by moving north |
| SOUTH | Trap is triggered by moving south |
| EAST | Trap is triggered by moving east |
| WEST | Trap is triggered by moving west |
| UP | Trap is triggered by moving up |
| DOWN | Trap is triggered by moving down |
HIDE
hide <object vnum>
This hides an object
Examples
reset add mob 1000 1000 1 (Loads mob 1000 into room 1000, limit 1)
reset add obj 1200 1000 5 (Loads obj 1200 into room 1000, limit 5)
reset add give 1000 (Gives obj 1000 to the last mob loaded)
reset add equip 1000 7 (Gives obj 1000 to the last mob loaded and forces it to wear object on legs)
reset add put 1000 1200 (Puts obj 1000 into obj 1200 - Obj 1200 must already exist as last obj loaded)
reset add door 0 1 (Close the north door - door must exist)
reset add rand 3 (Randomize exits n, s, e, w)
reset add hide 1000 (Hide object 1000 - defaults to last obj loaded if object not specified)
Primary Reset Commands Continued
(This section still under construction)
My understanding of these resets is shaky at best so take them with a grain of salt.
REMOVE
Syntax: reset remove <#>
Similar to delete except it only allows you to delete one reset by number.
MOBILE
Syntax: reset mobile <mob vnum> [limit] [room vnum]
Same as secondary command MOB. If [room vnum] is not specified current room will have the reset.
OBJECT
Syntax: reset object <object vnum> [limit [room [room vnum]]]
Syntax: reset object <object vnum> give <mob name> [limit]
Syntax: reset object <object vnum> equip <mob name> <location> [limit]
Syntax: reset object <object vnum> put <to_obj name> [limit]
Same as secondary commands OBJ, GIVE, EQUIP, and PUT respectively.
If [room vnum] is not specified current room will have the reset.
HIDE
Syntax: reset hide <object vnum>
Same as secondary command HIDE.
TRAP
Syntax: reset trap <object vnum> <type> <charges> <flags>
Syntax: reset trap room <type> <charges> <flags>
BIT
Syntax: reset bit <set|toggle|remove> door [room vnum] <dir> <exit flags>
Syntax: reset bit <set|toggle|remove> object <obj name> <extra flags>
Syntax: reset bit <set|toggle|remove> mobile <mob name> <affect flags>
Syntax: reset bit <set|toggle|remove> room [room vnum] <room flags>
If [room vnum] is not specified current room will have the reset.
RANDOM
Syntax: reset random <last dir> [room vnum]
If [room vnum] is not specified current room will have the reset.
The #RESETS section
For the #RESETS section of the area file, the syntax is:
#RESETS * <comment:to_eol> M <:number> <mob-vnum:number> <limit:number> <room-vnum:number>\ <comment:to_eol> O <:number> <obj-vnum:number> <:number> <room-vnum:number> \ <comment:to_eol> P <:number> <obj-vnum:number> <:number> <obj-vnum:number> \ <comment:to_eol> G <:number> <obj-vnum:number> <:number> \ <comment:to_eol> E <:number> <obj-vnum:number> <:number> <wear_loc:number> \ <comment:to_eol> D <:number> <room-vnum:number> <door:number> <state:number> \ <comment:to_eol> R <:number> <room-vnum:number> <last-door:number> \ <comment:to_eol> S
To reset an area, the server executes each command in the list of reset commands once. Each area is reset once when the server loads, and again periodically as it ages. By default, an area is reset if it is at least 3 area-minutes old and is empty of players, or if it is 15 area-minutes old. At the 14 area-minute mark, each (awake) player in the area is warned of the impending reset. These values are coded into the function 'reset_area' in 'db.c'.
An 'area-minute' varies between 30 and 90 seconds of real time, with an average of 60 seconds. The variation defeats area timekeepers. (See also: tick.)
The #Resets section contains a series of single lines. The backslashes and line splitting above are for readability; they are not part of the file format.
Because of the end-of-line comments, this section is not as free-format as other sections.
The reset commands are:
* comment M read a mobile O read an object P put object in object G give object to mobile E equip object to mobile D set state of door R randomize room exits S stop (end of list)
The * lines contain comments.
The 'S' line is the last line of the section.
Every other command contains four numbers (three for the 'G' command). The first number is ignored. The next three (or two) numbers are interpreted as follows:
For the 'M' command:
- The second number is the vnum of a mobile to load.
- The third number is the limit of how many of this mobile may be present in the world.
- The fourth number is the vnum of the room where the mobile is loaded.
For the 'O', 'P', 'G', and 'E' commands:
- The second number is the vnum of an object to load.
- The third number is ignored.
- For the 'O' command, the fourth number is the vnum of the room where the object is loaded. The object is not loaded if the target room already contains any objects with this vnum. The object is also not loaded if any players are present in the area.
- For the 'P' command, the fourth number is the vnum of a container object where the object will be loaded. The actual container used is the most recently loaded object with the right vnum; for best results, there should be only one such container in the world. The object is not loaded if no container object exists, or if someone is carrying it, or if it already contains one of the to-be-loaded object.
- For the 'G' command, there is no fourth number. If the most recent 'M' command succeeded (e.g. the mobile limit wasn't exceeded), the object is given to that mobile. If the most recent 'M' command failed (due to hitting mobile limit), then the object is not loaded.
- For the 'E' command, the fourth number is an equipment location. If the most recent 'M' command succeeded, that mobile is equipped with the object. If the most recent 'M' command failed, then the object is not loaded. All objects have a level limit, which is computed by inheritance from the most recently read 'M' command (whether it succeeded or not) in 'area_update' in 'db.c'. As distributed, an object's level equals the mobile level minus 2, clipped to the range 0 to 35.
For the 'D' command:
- The second number is the vnum of a room.
- The third number is a door number from 0 to 5.
- The fourth number indicates how to set the door: 0 for open and unlocked; 1 for closed and unlocked; 2 for closed and locked.
- Room exits must be coherent: if room 1 has an exit to room 2, and room 2 has an exit in the reverse direction, that exit must go back to room 1. This doesn't prevent one-way exits; room 2 doesn't NEED to have an exit in the reverse direction.
For the 'R' command:
- The second number is the vnum of a room.
- The third number is a door number.
- When this command is invoked, the doors from 0 to the indicated door number are shuffled. The room will still have the same exits leading to the same other rooms as before, but the directions will be different. Thus, a door number of 4 makes a two-dimensional maze room; a door number of 6 makes a three-dimensional maze room.
- Use of both the 'D' and 'R' commands on the same room will yield unpredicatable results.
Any line (except an 'S' line) may have a comment at the end.
CREDITS
I really thank Herne the Hunter for the original help files that I used to create my own help. Special thanks to Tank, the original author of this document.
All samples and tips have been provided by myself, and other members of the mudding community..
If you would like credit please state the name you want credited, a link to a webpage , email, a mud where you build, and/or its telnet address. You may use any combination you desire. Samples and tips without this information will be listed as anonymous.
