Re: Zone limits

From: William Karp (
Date: 11/23/95

On Thu, 23 Nov 1995, William L. Garces wrote:

> On Wed, 22 Nov 1995, Wilfinger Paul SrA 786CS/SCNNH wrote:
>  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. 

Well, your on the right track, a signed int will give you a little over 
32000 above and below zero.  if you change it to an unsigned int, then 
you can go up to a little over 65000 (positive only).  but as long as the 
compiler and such will handle it, (and as long as your doing the work) 
why not change it to something like a long (+-)2 billion, 147 million, or 
if ou wanted to get really crazy, a unsigned long(+) 4 billion 294 million.

I've never tried to change the max size of the rooms, so I don't know 
what difficulties you'd be getting into, but if you go over 32000, then 
65000 doesn't seem like it gives you that much more room.  But be 
careful, because using a long is going to let you eat much more memory 
(twice as much wherever you declare any values) versus using an int.

Just to let you know, an int, and unsigned int is both 16 bit 
and the long is the 32bit number you were referring to.

 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)

The only problem should be that you have to delete the player file, and 
recreate a new one.


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