On Wed, 30 Jul 1997, Desmond Daignault wrote:
> Another thing I want to do is eliminate the need for rnum values. I find
> it rather confusing to have to keep track of 2 sets of values (rnum and
> vnum). So, what I will probably do is use a tree of some sort for the
> objs and mobs, and a graph for the rooms (with a tree index for zones)
Sounds like a good idea. I think I would offset speed hits when doing
searches by organizing everything into hashed arrays by vnum and using
pointers to prototypes in place of rnums. The downside is it'd require
constant maintenance to keep an efficient hash.
> The only thing I can see that might cause a problem is rooms that have no
> exits, and cannot be entered from another room. (ie. an island) Why a
> builder would want to waste space with such a room is beyond me, but it
> could possably happen. (axiom to keep in mind: end users never do what you
> expect.)
Good point. When you're coding for builders, flexibility is very
important.
> The main advantage I can see to this system is that you don't have to
> worry about exceeding the 10, 100, 1000, or whatever limit you set per
> zone, limit for room vnums. Each zone can be given a range of vnums, so
> that a small zone can have vnums 1-20, and not waste the other 80 vnums
> that could possably be used by another zone.
Actually this is already possible in stock circle. It'd be real
confusing, but technically you can make zone 1 rooms 0-20, zone 2 rooms
21-500, and zone 21 rooms 501-32000. All you have to do is tell the zones
they're number 1, 2, and 21 with tops of 20, 500, and 32000. Don't try to
do this with stock olc though. I'm pretty sure it won't work with either
oasis or obuild.
I see what you're getting at, though. If your rooms are numbered
sequentially from 1 regardless of zone, it'd be better organized.
> So... while you are hacking around with db.c to make the files all conform
> to a set standard... You might want to consider something similiar to
> this. (although... get the parser working first.. would be hell trying to
> do both at the same time.)
Yeah I can see advantages to shuffling the internals around, but it's a
bit lower on my list than organizing the db, so I'd be inclined to keep
the two seperate.
> Another advantage to losing the arrays for objs/mobs/etc. is the notorious
> bugs being discovered with zedit... no need to do the top_of_zone_table +
> 3 crap... Arrays do provide some ease of use... but when you start
> needing to expand them they start to suck.
No kidding. I had similar problems with the obuild zone editor. I'm
addicted to linked lists and hash arrays now.
Sam
+------------------------------------------------------------+
| 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