Submitted by
Miniwood on Tue, 2004-04-20 21:38.
Areaportals - Common Problems
By Joel Caesar
Areaportals (or APs) tend to be one of the more problematic elements of
Quake2. I've found that time after time, people are reading the previous
tutorials and are STILL not able to get them working correctly. I
almost couldn't believe it, thinking these other people were doing
something wrong. Until I was working on a tower in an outdoor area map, I
didn't realize that many of the terms related to APs are understood
differently. This addendum is a brief recap of some of the previous
tutorials, but is not meant as a replacement for all of them.
I will cover the following items:
1. A proper AP door (building)
2. What is an area? ( and placing the AP)
3. The Hall of Mirrors (HOM) error
4. The Grey Door Problem. (Updated 4/19/98)
1. A proper AP door.
A proper AP door is a func_door surrounded on all sides by a frame
(required because otherwise the entity touches the void causing a
leak--this will be more clear in placement). The func_door then has a
target of a func_areaportal. In fig. 1, you can see the frame brushes
outlined in white (filled gray). The outline of the func_door is in
yellow. The func_areaportal can be seen in fuscia. In my
working with APs, I've found it actually is OK to allow the areaportal
to touch the void.
2. What is an area?
An areaportal door needs to be sandwiched between two different areas.
Like a slice of cheese between bread. In fig. 2 below, you can see where
I've drawn two rooms, and a room and a hallway--I've also drawn the
entire AP entity in yellow (func_door and func_areaportal). The door
must be BETWEEN, and NOT IN, any of the rooms involved, or hallways
(henceforth, areas)--and each area, must be sealed with no leaks or
openings, or the area must be terminated by another AP.
Sometimes, the two rooms can touch the door entity. Sometimes it
cannot. Why? I can't tell you, suffice it to say, try pushing the two
areas together until
they touch the AP door and its frame. If this causes problems, you might
need to extend the frame to meet the two areas. Usually the first way
does work, so read on to see if you have other problems before changing
this, as changing frame size is usually a minor problem.
Ah hah... there's more. The above fig. 2 is an easy example to see two
completely seperate areas. In fig 3. below, there is a room within a
room. A common configuration of an outdoor room, or a room within a
room. You might think that the two areas here are completely seperate.
Quite WRONG. The problem lies in the inner room (red arrow). It's not
seperate. It has the same floor and ceiling
(and if it didn't it wouldn't matter--it's not enough of a difference.
The problem
is actually the walls.
While not entirely incorrect, this configuration may work as is,
albeit with some trouble. Seperating the ceiling and floors of the inner
room and making them different brushes of the outer room might work,
but not if you need another entrance to
the inner room, other than teleporters.
Here is how to correctly build this type of room for an AP (fig. 4
below). Different walls, different ceilings, and so on (different floors
and ceilings, green and blue). Trust me.. If you don't build your rooms
like this, you're gonna rebuild them later.
Okay.. you say.. I get it, I get it.. But do you? Do you know WHY? Here's
the answer:
1. An area is a completely sealed room (or container if you will) from which, all of
it's interior faces can ONLY be seen from within that area.
2. An area is a completely sealed room from which all of it's exterior faces, can only
be seen by the void (or nothing).
This of course doesn't include looking through where doors would be.
Below, you will find two examples, based on my map "Atmospheric
Processor" (terraform2.bsp). I discovered in fig.5 below, my APs weren't
working, yet I followed all the other tutorials (obviously). It
ultimately came down to "What is an area?" The red outlined brushes
represent sky, so this is an outdoor area. The above examples of a room
in a room, are basically the box at the bottom of
the figure, with the tower on top. Most of the brushes, more or less
were very similar to what you see here. Large, solid brushes. They broke
rule 2. above. BSP did not see them as entirely seperate areas (in the
tower and outside the tower), even though both ends of the openings (as
seen) are terminated with APs.
What I had to do is add a small room within the opening (actually I
wound up rebuilding the entire tower to learn this--so do what you need
to do). I basically wound up with an inner-lower room, and inner-tower
room (both connected). The large outer room, was made of the "skybox"
and floor room, and the outer shell of the tower, and outer shell
of the lower room (outer shell or lower room not shown below).
3. The Hall of Mirrors Effect (HOM)
The Hall of Mirrors Effect is an error caused by an areaportal, which
causes an area of the map to constantly display the contents of the
screen without clearing. It's sort of like giant smudging, and sort of
cool lookin I suppose, but.. still.. it's an error to be killed. What
causes it? I don't know... But usually, it's not a bad areaportal. HOM
usually appears after adding two or more APs to your map and usually
it's because they connect the same areas... Can I help you fix it?
Maybe.. Here's what I recommend. In the figure below, you will see the
typical OK-side, and HOM-side. On the HOM-side you need to make the
opening smaller (as
indicated by the red arrows). I'm talking about 2 grid points (pixels)
here folks.. If you chose the right textures, you may not even have to
realign them.
If you have HOM on BOTH sides of a door, then you have the problem on
more than one areaportal. Do the above steps to each areaportal to see
if this fixes it. If none of this works for you, I've usually found that
having very symmetrical rooms (or groups of rooms) are the cause of
this error (but not always), so try repositioning where the door is.
4. The Grey Door Problem
NOTE: I knew I'd figure this out after emailing J. Carmack and all
the level designers at Id, and before getting a response... ARGH.
I've usually found the grey door problem when testing my level in
software mode. Hardware accelerated graphics boards (3Dfx, Permedia2)
don't usually show the problem. I have found that this happens under two
possible conditions. Check your areaportals by the numbered list
below:
- Be sure your areaportal has the Clip texture on ALL sides, or, you can use the trigger texture.
NOT the Skip, Hint, or other textures.
- Make sure the texture properties (again on ALL sides) have
NoDraw ON, PlayerClip OFF, and MonsterClip OFF!
Try compiling at this point.
- If you still have the grey areaportal, check to see if the frame
of the door (you do have one right) completely touches the
outer edges of the door.
If the above doesn't work, then the area opposite the grey side may
have too many
polygons to be drawn for software mode and this is just a result. You
may have to remove the AP door, or change it to a regular door, and then
perhaps use a U or L shaped hallway, or some other type of vis-blocker
to make this part or your level work.
Area Portals set for DM and Single Player
When using Area Portals in both DM and Single Player, you might find
some problems. In the typical single player game, doors are closed. In
DM most, if not all doors, are open. You'll get the good ol' HOM.
Also, you won't get any errors related to areaportals and the number of
areas they touch.
Sure you can take the cheap way (read, "easy") and make doors open real
fast and close real fast (I personally like this, cause I don't think
there is
any real place where doors are always open). The hard way, is to have
your DM areaportal doors not appear in deathmatch. Sadly enough, I
didn't have
an answer for the HOM portal problem. Phil Daniels figured it out
though, so he gets the credit for the info., cause I'd never have
figured it out.
Most entities in most editors have spawnflags for whether they appear in
single player, deathmatch, or under a particular difficulty level. The
logical thing to do, would be to set the door to have a spawnflag "not
in deathmatch" and the same for the areaportal (after all there is no
more
door). Nope.
The areaportals cannot be set this way. They have to be operated, not
flagged out (i.e. they will still be loaded). Set a trigger_always
targeted
to the ap's name and set it's spawnflags to "not in easy", "not in
normal", and "not in hard". The AP should have NO flags set, the door
has "not in
deathmatch" set.
The level loads in DM and at load point, the areaportal is triggered (stays open) so there is no HOM.
Copyright © 1998 Joel Caesar
Permission granted to R U S T to publish this doc.
Func_areaportal - 2 - Problems
Entity Properties