Overlapping InfoLoc Areas

[grayman]

When two location areas overlap (missing separator between them), we get the warning:

 

WARNING: location entity 'AAA' overlaps 'BBB' in area 53.

 

How do I find out where area 53 is?

 

Solving these has been pretty trivial in the past, w/o knowing where the area is, but a current WIP has multiple touch points and I'm tired of trying to figure out where the overlap is.

[stgatilov]

5 hours ago, grayman said:

When two location areas overlap (missing separator between them), we get the warning:

WARNING: location entity 'AAA' overlaps 'BBB' in area 53.

How do I find out where area 53 is?

Looking at the code:

1. Look at the "origin" spawnarg of 'AAA' --- this point belongs to the area 53.
2. Search for "_area53" in the .proc file, it gives you the surfaces of the area. You can use the coordinates or materials to see where it is.
3. Use r_showSurfaceInfo 1 to see which surface it in front of you. It should say "_area53" when you find the proper one.

There is also cvar to draw only one entity, but it accepts a renderEntity id, so it becomes a bit complicated.

[demagogue]

I thought overlap meant the two areas either have an internal leak into each other or a portal without a separator, so both areas are treated as one area and it just picks one of the location_entities. So as to the question where is the overlap, I thought the entire space of both locations overlap as if they were one location, and it's just a matter of finding the leak or portal without a separator and separating them.

Edit: Sorry I may have just misread your post and think it's saying something it's not. If you just want to know which two locations are getting combined, then I see your issue.

Also (this is maybe an aside & I'm going by very old memory here), but I seem to recall the area number is set during the dmap, so it's possible the number might change between dmaps.  I guess the theory would be easy to test in your case though, if you dmap and then got the warning with a new area number. But anyway that's not a big issue in this case.

I guess another way to do it is just put different ambient sounds on the location_entity, and eventually you'll hear that one isn't playing in the location like it's supposed to. Not sure if that's so much faster though.

[stgatilov]

On latest dev build, we have dedicated dmap diagnostic for this type of problem: 5354