Area Portal Map Bug

Avatar
Gemarakup
1,183 Posts
Posted Jan 18, 2013
When I run my map, it closes down Portal 2 and shows a dialogue saying something like: engineerror> numportals or whatever similar. I tried deleting area portals but it doesn't help.
Advertisement
Registered users don’t see ads! Register now!
Avatar
josepezdj
2,386 Posts
Posted Jan 18, 2013
Replied 2 hours later
What exactly is the engine error? Numportals > areportals or what? If so, you should be having yellow warning messages in the compile too, telling you that your areaportals don't touch 2 faces. Maybe you haven't sealed the rooms properly and your areaportals are leaking. Bare in mind that a func_brush or a func_detail don't seal an area, and areaportals need sealed areas to do their work... Are you sure you have deleted all areaportals and the problem is still there?
Avatar
ChickenMobile
2,460 Posts
Posted Jan 19, 2013
Replied 19 hours later
This is a problem to do with leaking of your area portals. Area portals should be closed off to each other otherwise it will leak and cause errors like the one you have.

This error could also be caused by you tying a displacement to an entity, however technically the map shouldn't even compile if this is the case.

Fix 1: visgroup2.pngHide everything but "world geometry" inside the visgroups -> auto tab and add a spawn point. Compile your map.

If it leaks, this is the problem.

Fix 2: visgroup1.pngHide all your area portals inside the visgroups -> auto tab and try to compile.

If it doesn't leak, it is an areaportal problem.

Images 2
Post image 1
Post image 2
Avatar
Gemarakup
1,183 Posts
Posted Jan 19, 2013
Replied 4 hours later
Well the rooms are sealed properly because this map is already released, and I am fixing nothing to do with the sealing walls. I only deleted some areaportals because I still need the optimization, but if I need to completely recreate them I will. What I need is that the areaportals need to be touching each other or should I just do this visgroup thing?
Avatar
josepezdj
2,386 Posts
Posted Jan 19, 2013
Replied 2 hours later
What about posting the vmf? quicker and easier :wink:
Avatar
Gemarakup
1,183 Posts
Posted Jan 20, 2013
Replied 17 hours later
Here.
Avatar
ChickenMobile
2,460 Posts
Posted Jan 20, 2013
Replied 2 hours later
Ok, you are an idiot.
Your whole chamber is made out of func_detail. Of course you are getting areaportal leaks and crashes.
What I find funny is what should be func_detail are not (like the door frames).

whatareyouthinking.png

Please read the wiki article on func_detail and this nifty tutorial about areaportals.

Area portals must be sealed to one area otherwise they will leak. Loading the pointfile when it leaks will draw a red line from the area-portal to the other side of the same area portal.

Images 1
Post image 1
Avatar
Gemarakup
1,183 Posts
Posted Jan 20, 2013
Replied 3 minutes later
Not the whole thing, the walls that outside walls are regular brushes. If you're saying that areaportals should be between non brush entities fine. It worked before. That's all I needed to know.
Avatar
FelixGriffin
2,680 Posts
Posted Jan 20, 2013
Replied 13 minutes later
She's also trying to tell you that that's your optimization problem, since almost everything will be in one really big leaf, and that you need to FULLY seal leaves if you want areaportals to work. Just making the frames areound the areaportals into world brushes isn't going to help anything.
Avatar
ChickenMobile
2,460 Posts
Posted Jan 20, 2013
Replied 20 minutes later

FelixGriffin wrote:
She's also trying to tell you that that's your optimization problem, since almost everything will be in one really big leaf, and that you need to FULLY seal leaves if you want areaportals to work. Just making the frames areound the areaportals into world brushes isn't going to help anything.

Incorrect about the big leaf, your map would be split up into multiple small leafs for absolutely no reason, decreasing performance and making compile times extremely longer. Probably for your map, a big box around everything might increase performance.

VVIS should always take around 0-4 seconds max - even for large maps.
4 threads reading e:\program files (x86)\steam\steamapps\common\portal 2\sdk_content\maps\tc_vitrified.bsp reading e:\program files (x86)\steam\steamapps\common\portal 2\sdk_content\maps\tc_vitrified.prt 277 portalclusters 691 numportals 0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10 Optimized: 66 visible clusters (0.00%) Total clusters visible: 25162 Average clusters visible: 90 Building PAS... Average clusters audible: 180 visdatasize:18864  compressed from 22160 writing e:\program files (x86)\steam\steamapps\common\portal 2\sdk_content\maps\tc_vitrified.bsp 1 second elapsedThe code above is from a compile log from my map tc_vitrified which is 10x (+) bigger than your map and 99x more complex.

But honestly your map would probably benefit more from no area portals whatsoever because it seems that you lack the concept of areaportals in the first place.

Read up on func_details and optimisation. There are probably a heap of tutorials on it.

Avatar
FelixGriffin
2,680 Posts
Posted Jan 20, 2013
Replied 13 minutes later

ChickenMobile wrote:
Incorrect about the big leaf, your map would be split up into multiple small leafs for absolutely no reason, decreasing performance and making compile times extremely longer. Probably for your map, a big box around everything might increase performance.

But wouldn't it only have one leaf, because everything that could block visibility would be func_detailed? (I'm probably wrong, I'm not very good at optimizing maps. I just try to func_detail any crazy shapes and leave the rest as world geometry.)

Avatar
ChickenMobile
2,460 Posts
Posted Jan 20, 2013
Replied 10 hours later

FelixGriffin wrote:
But wouldn't it only have one leaf, because everything that could block visibility would be func_detailed? (I'm probably wrong, I'm not very good at optimizing maps. I just try to func_detail any crazy shapes and leave the rest as world geometry.)

You would be able to nearly see all the leaves at once, but vvis will still try to figure out what visleafs can't see each other when it compiles. Hence the in-game lag and large compile times.

In order to manually set what leafs can see each other, create a big trigger and change it to a func_viscluster in the spot you want it to be.

Here's a simple comic for you simple minded people to understand the leaf concept.
img

Avatar
Lpfreaky90
2,842 Posts
Posted Jan 20, 2013
Replied 1 hour later

ChickenMobile wrote:
FelixGriffin wrote:

But wouldn't it only have one leaf, because everything that could block visibility would be func_detailed? (I'm probably wrong, I'm not very good at optimizing maps. I just try to func_detail any crazy shapes and leave the rest as world geometry.)

You would be able to nearly see all the leaves at once, but vvis will still try to figure out what visleafs can't see each other when it compiles. Hence the in-game lag and large compile times.

In order to manually set what leafs can see each other, create a big trigger and change it to a func_viscluster in the spot you want it to be.

Here's a simple comic for you simple minded people to understand the leaf concept.
img

:potd: :potd: :potd: :potd:

Avatar
Gemarakup
1,183 Posts
Posted Jan 21, 2013
Replied 1 hour later
A comic for the hell of areaportals...
Avatar
josepezdj
2,386 Posts
Posted Jan 21, 2013
Replied 3 hours later

Chicken wrote:
AWESOMESAUCE SELF-EXPLANATORY AWESOME DRAWINGS!

FUCK :potd: YEAH!

@yishbarr. your map is truly a mess, sorry. Bare in mind the simplest areaportal construction in order to understand how it must be made and how it works: a simple square room with a door hollow size 256x128 (h x w); the areaportal can be 1-2 units thick and covering that door hollow (256x128 units); you can introduce its edges some units into the walls brushes or ceiling/floor because they are world brushes... if for example you would have a func_detailed brush at one edge of the door frame, like one pillar size 256x32 units (h x w), this areaportal should be necessarily 256x160 unit (h x w) at least to make sure your areaportal is sealed, understand? Imagine that room is all your whole map and it cannot have any leaks to can be compiled, ok?

In your map there are areaportals NOT TIED to a func_areaportal entity but textured like so, avoid this kind of stuff. Also you made areaportal brushes with their edges floating in the air, not touching world brushes with ALL their edges... this is not the way.

Just by closing the external area of your map with huge brushes you won't make it to work properly. You must seal it properly before.

There is a terrible bad habit you have (dunno if this was a map previously made in PTI and later editted with hammer but it looks like so at certain parts...): I discovered many of your walls are 1 unit thick. Try to make them at least 32 units, and try that all props and entities are inside your walls in order to seal your map: there are squarebeams almost outside the map and a lot of leaks where you have gel droppers or tractor beams.

I'd suggest you to give it a look to the basic hammer tutorials by Solarchronus. Apart from explain how to do the basic stuff in hammer, he is so neat when sealing the map and making the holes to embed the props and such, I think you'll appreciate these tutorials.

By now, just forget about areaportals, you don't really need them at all for such a small map like this. When you are more skilled in hammer, give a carefully check to this optimisation guide.

Cheer up!

Advertisement
Registered users don’t see ads! Register now!
Avatar
Gemarakup
1,183 Posts
Posted Jan 21, 2013
Replied 5 hours later
Thanks.