> 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...
SPECIAL(foo);
...
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...
<pseudocode>
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)))
break;
if (VALID_SHP_RNUM(srn))
return ((SPEC_FUN *)SHOP_FUNC(srn));
return GET_MOB_SPEC(character);
}
</pseudocode>
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:>
-Mysid
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST