Re: Zone limits

From: William L. Garces (wlgarces@sprint.uccs.edu)
Date: 11/23/95


On Wed, 22 Nov 1995, Wilfinger Paul SrA 786CS/SCNNH wrote:

>     I was wondering if any exp. this problem that we are having.  When 
> trying to create a new zone 608 the zone loads but can't find the wld 
> numbers to load mobs and objs.
> When trying to goto a room in this zone we receive no such room.  I can't 
> find any limitations to cause this.  Any advice would be deeply appreciated.

Well I'm a newbie here (I just started exploring the code today) but
I believe I know what might be causing this.  (All you experts feel
free to correct me).  I believe the problem may be that your room # is
too large. I was trying to create rooms with virtual numbers that were
in the 6 digit range.  When I ran the MUD, I saw no errors when it 
loaded the zon and wld files.  And when I logged onto the MUD 
"show zone" listed my zone.  But "goto" told me that the rooms didn't
exist. Well I looked in structs.h and found that there is a typedef
called "room_num" that is used wherever a room number needs to be
stored.  This number has a type of signed short which I found is a 16bit
 value in limits.h. That means that room numbers can only go up
to a little over 32000.  I assume that your room numbers for zone 608
start at 60800 if you use the numbering convention stated in building.doc
which would put you over the limit.

Now a question for you guys that have been coding Circle for a while.
I would like to change this value to a signed int which would be a 32
bit value.  I looked through structs.h and found places where room_num
was used.  The only place that appeared to have a problem was a structure
that appears to define player info that gets saved to disk (it was called
"player_save_struct" or something to that effect. Sorry I don't remember
the exact name. I am writing this under DOS and can't access my Linux
partition to check. I'm sure you know which one I'm talking about. 
There is a big comment saying not to change the variables as it will
ruin the player file. It also defines a lot of extra variables that
coders can use to add new player information to the player file)
If the only problem is that it will change the size of the structure
saved to the player file then I would like to just delete my player file
, change room_num to a signed int, and then recompile. (I can nuke
my player file because I am just running Circle on my own personal
computer. No player base to worry about) Would this work?
Or is there code that depends on the size/displacement in this struct?
I don't expect this to be a problem if the members are all accessed
with struct_name.room_num or struct_name->room_num. Or are there 
other problems?

Well if that won't work I was hoping that I could just move the room
variable from that structure down into one of the blank variables
that are available for expansion. Of course that would also require
that the variable always be accessed through "." or "->" operators.

Are either of these feasible? I don't know enough about the code yet
to know.  If neither of these would work, could you point out 
where the offending code is so that I can check it out?
By the way I have v3.0 bpl8 installed if it matters.

-Will 



This archive was generated by hypermail 2b30 : 12/07/00 PST