On Sat, 20 Sep 1997, Chris Proctor wrote:
> > Has anyone ever considered changing some of the spec_procs to being
> > simple MOB_FLAGS? For example, changing the spec_thief to being a
> > MOB_THIEF flag, so that mobs can have easier, and more settable
> > characteristics? I am wondering what other features people suggest to
> > make mobs seems more 'realistic' besides custom spec_procs. Something
> > more 'generic' that can be applied to more than one mob.
>
Ive dome some code that works off of MOB_FLAGS as you suggest. But for
the bulk of the fancy code, I.E. do more the pick up trash or be
aggresive, or anything simplistic like thatk, Ive always just written new
mob SPECIALS
What I did do however though was to add a new field to the mob files,
basically an INDEX number.
When the mud is booted and the mob_special line is hit in the mob file, a
switch/case looks at the INDEX number and does an ASSIGNMOB call right
then and there.
I removed all ASSIGNMOB calls from spec_assign.c and added to OASIS a
menu of mob speical programs we have, so builders can add them.
This is really incredible, as most builders never even KNEW what mob
special were available, and now that they have them laid out, they get
used.
One other neat thing is in the stat mob call where it used to say
mob special: exists
I save that mob index on the mb in memory now, and use that with an array
on strings so that i can show:
mob special: healer
or whatever, and actually see what code is on a mob with a simple stat
The only mob specials still in spec_assign are those that are not generic
enough to be used on just any mob.
One thing id like to see change in the stock code, is what was somewhat
discussed by someone the other day, a better ordering of the one_argument
etc calls.
As it is now we have ONE function * to work with and can ony use one mob
special, or room speical for that matter, per thing.
Ive noticed that some speicals code, trash the argument list passed into
them. Like if you assign a mob to be a shop keeper and also try to
MOB_ASSIGN it, youll see that the shop code obliterates the argument list
before your special gets called.
If all specials left the original arguments unmolested, we could use a
linked list of function pointers instead of just one, and thuse put as
many sets of code per mob/roon/etc as we wanted...
my 2 cents for the day
*******************************************************************
* Ron Hensley ron@dmv.com *
* Network Administrator http://www.dmv.com/~ron *
* PGP Key at WWW Page *
* DelMarVa OnLine 749-7898 Ext. 403 *
*******************************************************************
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST