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.