===========================================================================
This snippet was written by Erwin S. Andreasen, erwin@pip.dknet.dk. You may
use this code freely, as long as you retain my name in all of the files. You
also have to mail me telling that you are using it. I am giving this,
hopefully useful, piece of source code to you for free, and all I require
from you is some feedback.
Please mail me if you find any bugs or have any new ideas or just comments.
All my snippets are publically available at:
http://pip.dknet.dk/~pip1773/
If you do not have WWW access, try ftp'ing to pip.dknet.dk and examine
the /pub/pip1773 directory.
===========================================================================
CHANGES SINCE LAST RELEASE:
I have added redit-ilab.c, which is the reset editting package tailored to
ILAB olc, which has a seperate reset list for each room.
Note that although do_rdoor and do_rrandom are included, you should not
added those functions to the command table: rdoor is obsolete with ILAB OLC,
and rrandom is not much use, as ILAB OLC disables random doors.
Also, free_reset/new_reset were fixed: they used malloc, which is very bad,
as those resets are not necessarily allocated with malloc.
Also note that you will need to change reset_area() to take but one
parameter. Other than that, there is no much change compared to stock ILAB
OLC.
Room-based reset editting package
---------------------------------
Basically, description of syntax is listed in the rhelp.txt file, which is
in standard MERC help-file format.
"findlock" does not REALLY belong there, but it kinda got there anyway ..
you may find it useful though :)
"rkill" might be a bit buggy... play with it :)
"rlook" does not show correct levels for items in shops.
Limits: I use -1 to signify that the item should be only loaded at reboot in
the unused arg2 of most resets (e.g. M 0 1234 -1 1234 will load mob 1234
into room 1234, but only at reboot). The commands assume a default limit 0.
Standard MERC ignores this value for objects, but it is significant for
mobiles. Note that you can put any value there. A useful thing to do is to
let this value be a random chance of loading the item, if bigger than 0.
E.g. if this value is 5, the item loads one out of 5 times.
There are some small changes required other places in the code:
merc.h
======
1. obj_index_data and mob_index_data need an AREA_DATA* area field
AREA_DATA *area;
2. prototypes:
DECLARE_DO_FUN( do_rlook );
DECLARE_DO_FUN( do_rmob );
DECLARE_DO_FUN( do_rkill );
DECLARE_DO_FUN( do_rdrop );
DECLARE_DO_FUN( do_rput );
DECLARE_DO_FUN( do_rrandom );
DECLARE_DO_FUN( do_rgive );
DECLARE_DO_FUN( do_rwear );
DECLARE_DO_FUN( do_rfind );
DECLARE_DO_FUN( do_rwhere );
DECLARE_DO_FUN( do_rview );
DECLARE_DO_FUN( do_rdoor );
DECLARE_DO_FUN( do_findlock );
DECLARE_DO_FUN( do_freset );
db.c
====
3. This field needs to be initialized at boot; add this in load_objects:
pObjIndex->area = area_last;
4. And in load_mobiles:
pMobIndex->area = area_last;
area_last is a db.c global containing the pointer to the last area.
interp.c
========
5. Well, the command themselves. adjust level as you see fit :)
{ "rlook", do_rlook, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rfind", do_rfind, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rwhere", do_rwhere, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rrandom", do_rrandom, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rmob", do_rmob, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rput", do_rput, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rgive", do_rgive, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rwear", do_rwear, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rdrop", do_rdrop, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rkill", do_rkill, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rview", do_rview, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "rdoor", do_rdoor, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "findlock", do_findlock, POS_DEAD, L_SUP, LOG_ALWAYS },
{ "freset", do_freset, POS_DEAD, L_SUP, LOG_ALWAYS },
redit.c
=======
6. Extra wear locations
If you have any other wear locations, you will need to add them to the
wear_locations table. This table contains three entries: one containg the
ITEM_ bit and the other two containing the 2 WEAR_ locations for the items
that have the ITEM_ bit set. The first one must ALWAYS be there, but the
second of them can be WEAR_NONE if there is only one location for the item
bit.
7. IS_BUILDER_HERE
You need to change this macro if you have builder permissions in your MUD.
It should return non-zero if the character may change on the current area he
is standing in.
Note that all characters that have the commands can use rview, rlook, rfind
and rwhere.
8. Door states
If you have any special door states used in reset, you need to change
door_state_desc() and parse_door_state() functions.
9. rm *.o;make
Be SURE to make a clean make, as you added fields to the mob_index/obj_index
structure.
EXAMPLE SESSION:
You decide to add a few extra cityguard in Midgaard. You find the room you
want them to start in and type "rlook" to check what is already here. You
think the room is OK, so check on what guards are available in Midgaard:
> rfind guard
There are 4 kinds of cityguard. You decide on just the first.
> rmob guard 15
This will cause the first guard to reset in the room you are in. 15 is the
mud-wide limit of number of those guards, if there are more than 15, the
reset will NOT be executed.
You decide to give him some standard issue equipment. Now.. what are the
vnums for that ? You use rfind to find some pieces you want:
> rfind sword
You notice that the standard issue sword you want is the second on the list,
so you make your new guard reset with it:
> rwear guard 2.sword
rwear automatically finds out if the mob can use the weapon and if it
already has one.
You continue using rfind to find equipment in the current area, and adding
it by using rwear. You also decide that the guard should carry a bottle of
ale:
> rgive guard ale
After some further consideration, you decide that he should not have the ale
after all... You type rlook to see what reset number the ale has and find
out it is number 8.
> rkill 8
You remove the ale reset.
Then, a split second later, you decide you really do not need another guard
reset after all. You discovered the "rwhere guard" output and found that
there are plenty of them already! Typing rlook you see that the mob reset
is number 1.
> rkill 1
This gives you an error message though: this mob resets with some equipment,
and just removing the mob reset will produce strange results. You decide to
remove the mob AND all of its equipment.
> rkill 1 CONFIRM ALL
Just typing "rkill confirm" would remove the guard - but NOT his objects.