> Rnums are sequentialy ordered...1, 2, 3, etc. this is the number that they
> are in the structure arrays world, mob_index, and obj_index.
> They must be dynamic, if a room is inserted in the first zone, all of the
> rnums change. This makes it impractical to use rnums (think about going
> through and changing all the SPECASSIGNs everytime something new is added,
> or having to figure out the rnums for goto everytime you wanted to do one).
> So there are vnums. Vnums stay the same, no matter how many things are
> added, deleted or changed.
>
> I have thought of a way to take out vnums, but it would be very time
> consuming, with little benefit.
>
I did the opposite. I took out rnums. Switched everything into a
large binary tree data structure. Not quite done with it, because I lost
momentum :) It's one of those long boring rewrite the entire way
mob/obj/room/char/zone commands/shops are accessed internally. To date, I
have all rooms working, all zone commands working (but they're all
accessing binary-tree type specifications, so none of the commands do
anything cept door movements, since obj and mob tables seem 'empty').
I'll finish it up and put it up as a neat little thing. It has the fun
side effect that you never have to renumber anything - whether you delete
or insert. This means that you can forget a rigid zone structure, and
load up 1 room, or obj, or mob at a time. Good for memory. :)
I've posted on this before, if you're really interested.
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT