Re: Retirement

From: Mysidia (
Date: 07/02/01

> +    case ITEM_KEY:
> +      min_val = 0;
> +      max_val = 32099;
> +      break;

shouldn't that assign 'max_val' to a structs.h value that determines
the size of a vnum? or at least.. 'max_val = SHRT_MAX;'

One of the irritating things about OasisOLC/stock circle is that it likes
assuming things like the sizes of these vnums or (in some cases)
that NOWHERE == -1, for example, interchanging those constants with -1
doing a >= 0 to exclude the NO**** condition, or using a standard
integer (or a sh_int) as a rnum/vnum

other annoying thing i've seen is the use of those macros for multiple
meanings: example, using 'NOWHERE' to mean both a Null room and a Null
zone... there ought to be a separate 'NO***' for each kind of item;
should be a NOZONE for zones, a NOSHOP for shops, a WEAR_NONE for wear
location -1, NOPLAYER for -1 on the ptable, etc.

The bootup code shouldn't assume -1 either, currently it does, but it does
even worse than that -- it assumes that a 'rnum' can fit in the same
place that a vnum does (the renum_world and renum_zone_table functions
come to mind immediately as major perpetrators)

And while i'm ranting I'll go on!  The shop, mail, and board thingies are
all evil pieces of code [to exagerate a little] (why are they implemented
as spec procs?.. the special casing just to make ordinary specprocs work
on shopkeepers is nasty IMO); and why oh why can't the thing group
same objects (not containing stuff) in a list under one structure (using
an obj->count to indicate quanity) -- and combining multiple copies of the
same when showing that list to players?

-- Why are the rent and player files stored in a binary format; player/obj
files should be stored as text; that may seem a trivial thing, but it
certainly matters, perhaps a series of text files (1 file per player) and
a single binary index file (that can be manually rebuilt easily) to store
simply the list of players and any data needed to search players by would
be better than what exists in stock circle.

The stock codebase [IMO] ought to contain at least all those features that
the vast majority of MUD implementors find the most useful+appropriate
and are going to have implemented on their system if they're serious
about running a production mud; not vanity features like colors so
players can give you headaches through their creative use of channel
aliases or additional skills/tidbits that can be tossed in at the rate of
two seconds -- but the functional, helpful kind that aren't that trivial
to otherwise implement without high chances of nasty side-effects.

Heh, what a way to change the subject in the middle of a
message... weird:>


   | FAQ: |
   | Archives: |

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