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

Question:
I have my own custom md2 models I would like to add and use in QuArK and Quake 2. How would I do that?

Answer:
I do nothing but map for Q2, the original version was fairly limited compared to what has been made available with Lazarus for added entity features.

Not to long ago I did some updating to it to work better with QuArK. If you have a recent version of QuArK 6.4alpha you may already have it in the addons\Quake_2 folder (it should be dated about 5-9-03). If so, you just need to register it in QuArK.

To do that start QuArK and click on Options -> Configuration -> Quake2 -> Installed Add-ons. This will show all the addons available.

Click on Q2_Lazarus.qrk, click OK then close all the window popups.

Then in QuArK's main menu, click on Toolboxes -> New map items, there you will see listings for Quake2 Entities and Entities for QuArK_Lazarus. You can use either one as Lazarus updates the original as well. Look under model_*entities (in the Lazarus listing) for what you need. I believe I put in some flyover help tags as well.

1) With Lazarus you can use md2 models that you export out of MilkShape, That's your first step.

2) Next, go to this link on this site to download the QuArK Lazarus v3 zip file and extract it to your QuArK folder. General instructions on how to set your models up come with it.

3) Now go to the Lazarus site on planetquake and download it from there. This is a very good page to download for off line viewing as it gives detailed descriptions of Quake2 features, entities and how to use them. I believe instruction on how to install Lazarus for Q2 comes with it. The real difference is its gamex86.dll file that has all the added features built into it. Quake2 comes with its own gamex86.dll file for the original features of the game, so you might want to rename it (like ORGgamex86.dll) if you want to save it.

Basically, once you have done these 3 steps, you're pretty well set to go. Just play with the misc_actor and model_spawn entities that you use to insert your custom models with and get a feel on how they work.

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
...

Question:
When using FreeImage as the loading library, why do certain PCX file don't load correctly as seem to have a randomized color palette?

Answer:
This is a known issue with some Quake 2 .PCX files; technically, they are corrupt. Both QuArK and DevIL compensate for it, but FreeImage doesn't, resulting in a corrupt palette. In other words: don't use FreeImage for loading PCX files if you encounter this issue.