Re: SYSTEM: Increasing the number of rooms (sh_int -> ??)

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

>     I've found that if i have a zone, say zone 400.zon (40000->40099, say),
> then i cannot goto that zone, even though it is created. I've figured it was
> becuase of the room vnums being an sh_int.

        This is correct, and mob and item, and rnums, and everything.
> Is there any way I could increase the vnum number type?

> What type should i increase it to AND will it take SERIOUS changes?
        See below.
> Lastly, what about memory? If i currently have 15,000 rooms, and I change it
> from sh_int to <what you folks suggest>, then what??
        Well, from sh_int to int, your size will double - but only for
integer space. By and large, this is neither large nor noticable.
However, if you fill each room, it could be quite large.  Letsee...

        Well, sh_int is 2 bytes on most systems I know of.  2 bytes = 2*8
= 16 bits.  That makes for a maximum of 15 + 1 for a sign bits to hold
your number.  That means you have for your vnums (which are sh_int's), a
range of -32768 to 32767 for use in your rooms.  Any access outside of
this is the negative rollover compliment.  If you just go ahead and make
the vnums unsigned, that gives you from 0 to 65535 rooms with no extra
space requirements. If you take it a step further and make them unsigned
(normal) ints, you got about 4.3 billion rooms.

        These can both be done, as far as I know, without any serious
changes, or modifications to the code itself.  Make vnums & rnums ints,
and you shouldn't have to worry about it again.

        But in actuality, you will.  No matter how fast the computer your
system is on, if you use incredibly large zones or a large number of
zones, you're going to slow down your system.  You're still doing work on
a linear array - and in alot of cases that means you'll have to walk along
a good portion of the array in alot of standard situations.  For those of
you with wildneress maps, I hope you haven't lost your mind and made them
real rooms - aside from the memory concerns, this array continuance will
cause severe issues!  Even dynamically sized arrays are a pain in the ass
to deal with when they get too large.

        I have seen only one other way to deal with room structures, and
that was a decently complicated AVL tree.  Not that I'm adverse to
complicated structures, but surely someone else out there has met this
problem with some variety of solutions. I'm curious to know what else has
anyone else done?


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

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