Re: vnums vs rnums

From: Patrick Dughi (
Date: 08/31/00

> 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.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/11/01 PDT