VBSP error with decompiled map file

Micnax

Back from the dead (again)
aa
Apr 25, 2009
2,109
1,585
Hi all, I was trying to fix up an old map I had made by decompiling the BSP file I had on hand of it (I had lost the original VMF), but I'm encountering issues when trying to compile it.

First I had areaportal issues which required replacing them all again (not too bad), but now I'm encountering a weird bug with info_overlays.
Overlay touching too many faces (touching 221, max 64)
Overlay overlays/logo_red_white at 2175.0 -64.0 1072.0
This happens for every overlay in the map unless it's deleted (it then jumps to another overlay error), and replacing the overlay on that surface causes the error to appear again. The overlays themselves are well within the max faces too (most 1-2 faces, the largest being 8 faces).

Any ideas on how to fix it?
 

obodobear

L4: Comfortable Member
Mar 15, 2016
172
32
Overlay touching too many faces (touching [number], max 64) Overlay [texture] at [x] [y] [z]
Description:
You have an overlay (info_overlay) entity that is touching too many brushes, or parts of a brush. The error message tells you also how much you have and allowed (touching [number], max 64)

Solution:
You can find the overlay using the coordinates. View -> go to coordinates( [x] [y] [z] ) You can delete, move or resize the overlay.


This error will cause your map to fail compiling completely

I tried looking on a compile checker, and this is what came up, sounds like you already tried the solution though and it didn't work. In that case I'm not really sure what you should do.
 

killohurtz

Distinction in Applied Carving
aa
Feb 22, 2014
1,016
1,277
I doubt a decompiler would affect these, but there are a couple other causes of this error that might be worth checking. Are any of the overlays' brush faces too big, or do they have a low lightmap scale? I'm not sure what it could be otherwise.
 

Micnax

Back from the dead (again)
aa
Apr 25, 2009
2,109
1,585
I doubt a decompiler would affect these, but there are a couple other causes of this error that might be worth checking. Are any of the overlays' brush faces too big, or do they have a low lightmap scale? I'm not sure what it could be otherwise.
The brushes vary in size but the largest is 900 by 768. Lightmap scale is the default (16).
I could try removing all the overlays and doing a compile test then, then add them back in one by one again...
 

Micnax

Back from the dead (again)
aa
Apr 25, 2009
2,109
1,585
Okay, I've fixed those issues with the overlays by just simply removing them. The error might return when I add them back in, but the map at least compiles now!

Which brings me to another issue, areaportals linked to doors get screwed over when they're openly viewed. How can I fix this?

20170216203429_1.jpg
 

henke37

aa
Sep 23, 2011
2,075
515
Areaportals linked to doors must be placed so that the door completely covers the areaportal. From both sides.
 

Micnax

Back from the dead (again)
aa
Apr 25, 2009
2,109
1,585
Areaportals linked to doors must be placed so that the door completely covers the areaportal. From both sides.
Yeah, it does. It looks fine with the door closed (areaportal closed) but glitches like the pic when the door is opened (areaportal open).
In Hammer, it's 1 unit wide placed inside the door. If it wasn't the areaportal would just hide the door (not this case)
 

henke37

aa
Sep 23, 2011
2,075
515
The areaportal is probably wedged closed for some reason. Try r_portalsopenall 1 to check if area portal data is corrupt. It is usually corrupted by leaks and area portal leaks.
 

obodobear

L4: Comfortable Member
Mar 15, 2016
172
32
Not as bad as the time I had the resupply cabinets of my map assigned to the wrong team