If you have any questions, problems or find solutions regarding this topic, please post them in the QuArK forum/mailing-list.

Question:
I know that that is some kind of a barrier for Quake-2 used by the map-designer (me) to tell Quake-2 to ignore anything that is behind it, so that the framerate will not suffer from parts of the map that are not essential yet, but will be taken into account (and therefore use precious processing power) by Quake-2 if this func_areaportal is not used. But how do i place it?

Answer:
Quake-2 tends to (re)draw the whole map during gameplay all the time, even the (numerous) parts of it that are not visible to the player (yet). This of course puts a lot of "stress" on your system (pc), resulting in a slower gameplay, more than necessary.

The func_areaportal entity tells Quake-2 to ignore anything that's behind the brush belonging to the func_areaportal.

This brush can be resized just like all the others and should be placed in a way that it covers the passage that you want to "close off" completely. Putting the brush of the func_areaportal in the same place as the brush of, for example, the func_door that you use to close off the corridor visibly (from the player's point of view) is the only wise choice of positioning.

Take care not to make it visible for the player; making it a little "thinner" than the door-brush prevents that. Making it wider and/or higher than the door-brush is not bad (most of the times).

You can use the func_areaportal in conjunction with any "passage-covering-entity" like; func_train, func_plat, func_explosive, etc.

Make sure that the TARGET specific of the entity you chose as a "passage-blocker" is pointing to the TARGETNAME specific of the func_areaportal. This will make the brush of the func_areaportal dissapear when the entity (func_door for instance) gets triggered (and reappear if the door slams shut again. Nifty).

Don't just give the passage-blocking-entity and the func_areaportal the same TARGETNAME. It will result in a func_areaportal that DOES dissapear when you trigger (for example) the button that opens the door, but that DOES NOT reappear automatically when the door slams shut again. Even worse, it will reappear when you open the door once again, showing its ugly black looks to the confused player.

You can of course check the "relationship" between the trigger-entity, the passage-blocking-entity and the func_areaportal by selecting one of them in QuArK.

Question:
I am working on a huge turret.

Answer:
Turrets are a bit hard to design.

The turret_base and turret_breach must have the same "team" specific.
The turret_driver's "target" must match the turret_breach's "targetname".
The turret_breach's "target" must match the "target" of yet another entity, "info_notnull".

You must design and place all three turret_xxx entities as if the turret where looking to the direction 0 (east). If you want the turret to begin facing another direction, you must set it in the "angle" specific of both turret_breach and turret_base (not in turret_driver).

Finally, place the "info_notnull" entity at the point from which rockets are to be thrown. Unlike the other entities, it seems that you must place this one at the correct position for the turret's starting angle, not for the angle 0. I mean, you must place it at the place where it WOULD BE if the turret already rotated to its starting angle.

Question:
Can I use other entities in conjunction with this turret?

Answer:
I don't think so. Maybe you can try putting other monsters over the rotating objects; but they would still behave as normal monsters. I think the turret_driver cannot be changed into something else. I don't think you can have other func_xxx objects work together with the turret at all.

Question:
When creating a spotlight, using the "info_null" entity, it is possible to set a "cone"-value in the specifics of the light_entity as well as in the specifics of the info_null-entity?

Answer:
It seems that only the light's "_cone" works. It must be a mistake to have a "_cone" field in the info_null.

For your question; yes, this is the size of the cone of light that is emitted when the light's "target" points to an "info_null" entity. The light is emitted in the direction of the "info_null" entity. The "_cone" field is the angle, in degrees.

Question:
How do I use keys and doors in Quake-2?

Answer:
The keys are the "key_xxx " entities. Countrary to the good old Quake-1, you cannot simply tell a door it must not open unless the player carries some key.

The entity that knows whether the player carries a key or not is "trigger_key". This entity is a 'relay trigger', which means that it must be fired by something else, and it will then fire its own targets if the triggering player carries the correct key.

You can use it between a button and a door, for example. When the button is pressed, it doesn't directly fire the door, but the trigger_key, which in turn fires the door if the player has the correct key.

If you don't want a button, you can replace it with a trigger_multiple just in front of the door, so that the door opens when the player approaches.

Question:
How do I measure the "framerate", i.e. how fast my maps are displayed by Quake-2?

Answer:
[explanation from Robert]
... use the following Quake-2 console-command, or you might find yourself spending loads of time making a visually stunning map, only to find out that it cannot be played for another 5 years until Intel and their competitors invent a processor that can speed this level up to a playable framerate.

While playing your map in Quake-2, go and stand in the spot that you would like to "check" and pull down the console with the tilde (~) key. Then type  timerefresh  and hit the enter-key.

The computer will now draw 180 frames while making a 360 degree pirouette with the "camera" and will measure the time which it needs to do that in seconds. Dividing 180 through the number of seconds of course leads to the desired value. The "Frames Per Second" or shortly "fps". This value should preferably NOT be lower as 24 to 30 (which is considered to be the number of frames that the human eye can "read" in a second)
...

[explanation from Decker]
... however the  timerefresh  command, isn't the best way to determine framerates, since that only gives a value on the spot where its executed.

To get a more precise fps-value, you must record a demo, running around everywhere in your level, and then playback the demo with  timedemo 1  enabled.

This will give an overall fps-value of your entire level, and not just in one spot
...