> + 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:> -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