Re: Retirement

From: Mysidia (
Date: 07/03/01

> An 'rnum' should fit in the same space as a 'vnum' otherwise you have a
> rather useless batch of real numbers.

   Well yeah.. i'm rather meaning there ought to be explicit typecasts
to type (room_vnum) or (obj_vnum) for example when a vnum variable is
being used to hold a rnum and an (obj_rnum) cast when the rnum is being
extracted, so it's obvious that that's what's happening --- perhaps there
should be a gen_vnum type to indicate the largest datatype used for vnums,
so that a single variable can be used to hold all different kinds of
vnums, and similarly a gen_rnum (generic rnum) type, being the largest
sort of int used on rnums...

in many cases where a vnum is put into an int, different kinds of
vnums/rnums are also put into that int

> A lot of that is historical and the patchlevel sizes aren't exactly small
> already to go make sweeping changes.  People like to throw fits when we
> make a lot of small changes too so I'm expecting another round of groans
> shortly.

   Well, ignore 'em!  Worst-case scenario, they run patch and manually
sort out the rejects -- which is nothing to give them reason for groaning
unless the patch changes aren't altering function parameters; if they
have real complaints, that's another matter.. but patches of small changes
is trivial; perhaps they're doing something they shouldn't necessarily
be doing, attempting to integrate all the stock changes into their custom
codebase a thing bound to give them a few headaches

   I'm not suggesting that an extroardinary amount of sweeping changes
are neededin a single patchlevel -- but I think some things in stock
aren't quite as they ought to be.

The way shop functions are implemented is annoying..

Suppose you want to check if a mob has a certain proc as a condition
for some hook from the command parser or some other place.. what you
want to do is...

if (GET_MOB_SPEC(char) == foo)
    ... do stuff ...

What you are instead forced to do is execute a search of the shop database
something evil, something resembling...

typedef int SPEC_FUN (struct char_data *, void *me, CMDTYPE *, char *);

SPEC_FUN * get_proc(struct char_data *character, SPEC_FUN *func) {
    shop_rnum srn;

    if (GET_MOB_SPEC(character) != SPEC(shop_keeper))

    for(srn = bottom_shop; VALID_SHP_RNUM(srn); srn = NEXT_SHOP(srn))
        if (SHOP_KEEPER(srn) == GET_MOB_RNUM(character)))
    if (VALID_SHP_RNUM(srn))
        return ((SPEC_FUN *)SHOP_FUNC(srn));
    return GET_MOB_SPEC(character);

Now it doesn't seem that bad, I guess -- I just don't like that a search
is necessary, it makes the GET_MOB_SPEC() macro seem a little misleading
if it doesn't always report the place where the spec_assign.c proc has
been assigned.

Having a MOB_SHOP NPC flag set by the system and then used by the command
interpreter in special case fashion would be better than that.

Just some ideas:>


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST