low_obj conflict vs. imaginary vnum

Posted by Sylaer on Wed 10 May 2006 04:11 PM — 12 posts, 38,648 views.

Sylaer Wed 10 May 2006 04:11 PM #0

I noticed that my objects weren't saving after reboot (or crash, in this case).
After looking into it I found that the hi_obj and low_obj for the zone I'm working on are both set to 0. I tried asetting them to the vnums that fall withing my vassign range, but it says that it "conflicts with another area." However, using checkvnums Object AND checking the zones command there are no other objects with vnums in this range. Any idea what's going on?
Worse case scenario is that I go into the area's file and write the hi and low_obj manually, but I don't know where this file is kept :P So my second question is where the vnum ranges for areas are located. Any help would be appreciated!

Zeno USA Wed 10 May 2006 04:27 PM #1

Make sure to check the 'vnums' and 'zones' command. Are you using SmaugFUSS? If not, maybe there was a bug related to this.

Could you give us exactly what you are typing for aset?

Sylaer Wed 10 May 2006 04:56 PM #2

Using SmaugFUSS,
vnums doesn't display my area because it's already installed, and zones lists no objects with vnums 10500 to 10599. The area that I'm editing (100 rooms, mobs and objects- used vassign to get vnums for all of these between 10500 and 10599) displays 0-0 for low_obj and hi_obj. Repeat: "zones" command lists 0-0 for hi and low obj.
I was using this command to set the obj vnums:
aset MyArea.are low_obj 10500
aset MyArea.are hi_obj 10599

I wonder if it's because I can only set one of these values at a time- so if I set hi_obj to 10599, the obj range is 0 to 10599, which covers other areas.

Zeno USA Wed 10 May 2006 05:02 PM #3

Hm. Well the function doing that would be check_for_area_conflicts.

So I would suggest going into that function, and under the true path put a bug message (for debugging) printing the area name that is conflicting.

Sylaer Wed 10 May 2006 05:40 PM #4

Zeno-
I copied the function check_for_area_conflicts, renamed it and changed the return type so that I can output the area name when the obj vnum error occurs.
*cry* But I don't know how to return and output a pointer :P It's something I learned this semester but this is finals week and my brain is fried. Here's my code:


char return_fault_area_name( AREA_DATA * carea, int lo, int hi )
{
   AREA_DATA *area;

   for( area = first_area; area; area = area->next )
      if( area != carea && check_area_conflict( area, lo, hi ) )
         return carea->name;
   for( area = first_build; area; area = area->next )
      if( area != carea && check_area_conflict( area, lo, hi ) )
         return carea->name;

   return FALSE;
}

Then I output the function directly.
It's a pointer to interger blah blah cast problem. And I ran across it dozens of times in the past few weeks but can't remember how to fix it. Can a return type be *char ?

Zeno USA Wed 10 May 2006 05:55 PM #5

You don't have to do that, it's pretty simple.

In the original function, before the function returns true, just add something like this:

bug( "check_for_area_conflicts: %s", carea->name );

Sylaer Wed 10 May 2006 06:47 PM #6

Ah, great! That worked.
It outputs that it conflicts with itself, though..

I did:
aset MyArea.are low_obj 10500

and got:
Log: [*****] BUG: check_for_area_conflicts: MyArea

I am baffled.

Zeno USA Wed 10 May 2006 07:02 PM #7

Are you sure you are printing the correct AREA_DATA? There are probably two, one being passed into the function that is the area you're setting, and the other would be looping through all areas. Make sure you have the one looping through all areas.

If it is correct, then the function is checking all installed areas including the one you're setting. I don't know if that's intended or not, but it probably is.

Sylaer Wed 10 May 2006 07:42 PM #8

Erm so I took your code and changed it,


bug( "check_for_area_conflicts: %s", area->name );

"area" is the variable in the for loop for the current area, so it outputs correctly the conflicting area. It was almost always Gods.are, which is vnums 1200-1201. ..and being that my area is 10500-10599 with buffers of zones all around both of them, I'm not quite sure what's up with that.

I may have discovered the issue- when I aset ANYTHING to my area, then foldarea, then hotboot or shutdown/restart, the changes aren't being saved. I am aassigned and bestowed the area. Erm, I'm guessing this is related to the vnum problem.

[EDIT]: I'm pulling my hair out, best to just walk away from it for a few hours and come back

David Haley USA Wed 10 May 2006 08:36 PM #9

This is more likely to be a problem with how you're using the online construction commands than with the code. This has been a somewhat finnicky process for me as well and I've found that missing a silly step somewhere can make strange things happen.

One thing is to try aassigning yourself the area, then vassigning yourself the ranges, not forgetting to assign room, object and mob vnums to yourself, and then asetting the area's vnums.

Sylaer Wed 10 May 2006 11:13 PM #10

For the time being I've erased what I had and started over in the same vnum range. The only things I had built were rooms, and I have the backup file for reference. I guess I'll just be much more careful meddling with areas that are already installed in the future :P

Conner USA Thu 11 May 2006 08:06 AM #11

I think the problem you're running into is that this area is already installed so it's getting it's vnum ranges for the area by reading the first and last object vnums in the .are file.