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