quake2 - Areaportals - Common Problems

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. If you have any questions or problems, then you can contact me via jcaesar@mediaone.net or http://www.digitalos.com/ Copyright © 1998 Joel Caesar Permission granted to R U S T to publish this doc. Return to Tutorials Page...