QuArK FAQ
Updated 1999-04-05

Go to:
- Main page
- Explorer
- Configuration
- Map editor
- Model editor
- Plug-ins
- Map tutorial
- Model tutorial
- FAQ
- Glossary

FAQ - Index


You got a question? Send it to quark@egroups.com.

QuArK related:

Game related:

Quake-2 related:

BSP compiling:


FAQ - QuArK related

Duplicator/Copy-one
When should I not use the copy/paste routine but the duplicator/copy-one functionality? - and how should i use it?

The difference between simple copy/paste and an advanced feature like the Duplicator is that the copied object remain "attached" in some way to the original objects. The copied objects are displayed in blue and you cannot edit them at all. Whenever you change anything in the source object, the original object changes accordingly. You can think about the copied objects as a mirror image; you cannot grip it, it remains all the time an image of the original object.

You cannot edit the copies at all. They are 100% a mirror of the original. However, if you like, you can dissociate them from the original and turn them into normal editable objects. To do so, right-click on the Duplicator and choose "Dissociate images".

For example, to make a stair, you design a cube as a single stairstep, and then instead of making normal copies of the stairstep, you put the stairstep in a group along with a Duplicator that you configure (by double-clicking on it) so that the stairstep is copied n times to form the whole stair. This makes it easy to change the texture on the steps later, for example, because you don't have to change it on all steps.

Another use of Duplicators is as a real mirror: If you want to make a map with two symetrical parts (e.g. for CTF or TeamFortress), you make only one half of the map, and let a Duplicator make the other part. This way, you don't have to constantly copy parts of the map from one half to the other while you improve it. Of course, the map is not 100% symmetrical; everything that should change between the two parts should not be duplicated, but made directly at the correct location. For example, for CTF, some walls need textures with a different color; in this case, you have to make the wall once in each part. In the mirror part, it will be totally surrounded by Duplicator images, but this doesn't matter.

Advanced Duplicators can apply a linear mapping, too.

Mirror (x,y,z)
Can i make a mirrored copy of a (group of) polys or does it always take the whole map? - how do i use it right?

Mirrors, like all Duplicators, copy everything in the group they are in. In fact, you must always put Duplicators inside groups. Simply make a new group with the objects to be duplicated, and move the Duplicator inside this group. (This is all done by dragging items around with the mouse in the tree-list of polyhedrons and entities).

Digger/Negative poly
When do i use this one instead of, for example, the brush subtraction command? - and what would be the advantage of doing so?
And what is the meaning of a 'negative poly' - when is it wise to use it instead of just creating a hole with the brush subtracion command?

Diggers and Negative polys have the same advantages as Duplicators; you can later make changes that wouldn't be possible if you had actually done the subtraction long time ago. This includes changing the shape of the hole, or working with the original polyhedrons - if you had actually subtracted, these original polyhedrons would be broken in a lot of parts, thus if you'd want, for example, to change the texture or make the thing thinner, you would have to do so on all the parts.

A Digger is just something you can drag/place into a group (which you should create to keep the digger from affecting all of the polys in your map) and which then turns every single poly that you put into the Digger into a negative one - so it is more like a group-wise negative-maker, whereas the negative poly button on the polyphedron-page is more useful for turning one or two poly's into negative ones. Negative polyhedrons, BTW, only dig within the group where they are, just like Diggers.

Shared faces
A word about "shared faces" and other ways of digging

Starting from QuArK 5.3 there is a new set of four buttons; rectangular selection of polyhedrons, rectangular selection of entities, quick cube maker, and cut polyhedrons and groups in two. The latter is a good alternative to using brush subtraction to make holes. Click on this button, select the polyhedron(s) to cut, and draw a line on the map through the polyhedron(s). This cuts the polyhedron(s) in two along the line. Cut a few times to make a door shape, and then all that remains to do is to delete the small polyhedron part inside the door shape to make the hole. If you selected a group instead of polyhedrons before, QuArK will ask you if it must activate a special feature, called "shared faces". If you answer Yes, you will get two groups, one for each half of the group, cut in two along the line you drew. This line is a single polyhedron face, shared by all polyhedrons in the group. If you select this face, you will see that it selects all polyhedrons; and if you move it, you will see all polyhedrons reshaped!

"Face sharing" is a powerful feature of QuArK. Polyhedron faces, that usually appear inside polyhedron in the tree-list of entities, can be dragged outside polyhedron. If you do so, the face will be shared by all polyhedrons in the group where you've put the face. This lets you edit the face as you like (move, rotate, change texture, scroll texture, etc.) and the changes are immediately visible on all polyhedrons that use the face.

Cutting a group in two is the easiest way to use this feature. For example, start a new map, select the group "border wall", click on the button "cut polyhedrons and groups in two", and draw a line through the group. Answer Yes to the question. You will get two groups "border wall". For this example, delete one of them. Then see what's remaining. If you open the remaining group, you will see a face called "cut" directly in the group. Click on it. Several polyhedrons turn blue, and several handles appear, but it is really a single face. Use any handle to move or rotate the face, and you will that it modifies polyhedrons together. If we didn't use a shared face, it would be tedious to make some changes on all faces, one by one. Now go to the "faces" page by double-click on the face "cut" in the tree-list : the image that usually shows the current face as only one polygon now shows it as several polygons! This is the rather strange shape of this shared face.

More generally, face sharing is useful to make a lot of polys with a common face, so that you can later move, rotate, scroll the texture, etc, without having to worry doing it on all polyhedrons.

There is a case where you really need a shared face : with Duplicators. If you move a face of a duplicated polyhedron out of the Duplicator's view, it will not be duplicated and all the images will share this single face. This is useful if you don't want that face to be moved by the Duplicator.

Shared faces - part II
If I have a wall that is composed of more than one polyphedrons, for example as a result of me using the substract-polyphedron command to make a passage through this wall, is it possible to assign one single texture to this whole wall as if it were just one polyphedron(-face)?

Yes, thanks to shared faces. A possible way to use them is to use the command "face-sharing subtraction" instead of "subtract polyhedron". This command keeps each face of the original polyhedron as a unique, shared face. Another solution is to use diggers or negative polyhedrons to prevent the wall from being splitted immediately, as described above, too.

If you already splitted your wall, and want to align the texture between all the parts, you can follow these steps:

  1. Select a face and align the texture correctly on it
  2. Remember the value in the "texture origin" field (you can copy it to the clipboard)
  3. Select all the faces together, either using the "Extended selection" command, or one by one in the tree view while holding down the Ctrl key
  4. Come back to the "faces" page by clicking on the 4th button, bottom left.
  5. Enter the remembered value in the "texture origin" field (or paste from clipboard)
However, this will not let you visually align the texture on all the faces. When several faces are selected, you don't see them in the small box where single faces are displayed. The best solution is to turn all your faces into a single, shared one, as follows. A not-so-good solution is to do texture alignment in a 3D view instead.

The shared face solution; let's say we want to align the face called "south" in a set of polyhedrons.

  1. Put all the polyhedrons in a group of their own
  2. In the tree view, locate one of the "south" faces
  3. Drag this face outside the polyhedron, into the group
  4. Delete the remaining "south" face in all other polyhedrons
  5. The "south" face in the group is now shared by all polyhedrons. Double-click on it and see!


Hollow maker
Is this just a way of selecting a lot of polys and making them hollow all at the same time? - and if so, when does this come in handy?

No, for this purpose, there is a command "Make hollow" in the menu. The difference between the menu command "Make hollow" and the Hollow Maker is the same as the difference between the menu command "Brush subtraction" and the Digger; the (ir)reversibility.

One problem with the Hollow maker is that the resulting polyhedron is hollow but it is completely closed; there is no way to see or walk inside. You have to use a negative brush or a Digger to make a hole in the walls around the hollow polyhedron.

Linear mapping
What the hell is meant by linear mapping(s)?

"Linear mapping" actually means any transformation like rotation, enlarging/shrinking, symmetry, or a combination of them all. When you use the rotate, enlarge, shrink, and symmetry buttons of the movement tool palette, you actually apply a linear mapping on the selected objects. This is only interesting to know for a special kind of Duplicators, the one that can apply linear mappings. It means that this kind of Duplicator can create images with any of the previous movement commands applied.

For example, to make a round stair, with steps that rotate while they go up, you would use such a Duplicator. First make the stair straight as you'd do with a normal Duplicator; then, select the Duplicator object and click on one of the "rotate" buttons of the movement tool palette -- that is, try to "rotate" the Duplicator. This actually makes the Duplicator rotate all its copies.

Duplicator specifics/args
In the specifics of the duplicator I saw a few things that I wanted to know the meaning of; "macro", "out", "angle", "origin", "offset".

"macro" - Specifies what the Duplicator does. You should usually not change it; to create Duplicator doing other things, directly insert them from the New Items window. (Countrary to Quake, which relies on the name of the entity to know what it does, QuArK relies on the "macro" specific for Duplicators, which means you can freely rename the Duplicators and call them, e.g. "stairmaker".)

"out" - All kinds of Duplicators work like this: You can put objects both inside them (as you do with Diggers, for the shape of the hole), and besides them, in the same group. Objects inside are not included in the final map (e.g. the hole shape), while objects besides are (e.g. the first step of a stair). You can, if you want, put objects inside a Duplicator that makes n copies; these original objects will not be present in the final map, but their copies will be. The meaning of the "out" Specific is as follows: If set to "1", the Duplicator works with objects both inside and besides it, and if not set, the Duipicator works only with objects inside it. A digger, for example, works by turning every polyhedron negative. That's why it should only work on the polyhedrons inside them, not besides.

"angle" - Is only useful for non-linear copy Duplicators. It lets the Duplicator rotate each copy by the given amount of degrees around the z axis. It is not very useful, because a linear Duplicator can do this and more, but it's a remaining of some very old versions of QuArK.

"origin" - Like for entities, this is the point where the Duplicator is. This is generally only used to know where the Duplicator should be displayed on the map, and has no influence on the Duplicator's behaviour. Linear Duplicators, however, use this point as the center for rotations, zooming, etc.

"offset" - This position the duplicates. The best way to do it, however, is to do it visually on the map, by dragging one of the blue squares that appear with each copy made by the Duplicator. Use the same grid for the object to copy (e.g. the stairstep) and to position the blue handles.

Register QuArK
How many [money name] are needed to register QuArK?

I don't know, just the equivalent of 20 US$... You can pay in whatever money you like (incl. Euros ;-)

Note that QuArK is no longer Shareware, but this still applies. For more information, see this page.

Prefabs
I was wondering if I could add my own prefabs to this new list/menu and how I could do that.

In the New Items window, go in the menu Folders and select 'New Main Folder'. This lets you create a new folder in this window where you can drop your own prefabs. In the dialog box that pops up, I recommend you to select the 3rd choice; "in a new add-on". This will let you create a new add-on file, and what you put in your new folder in the New Items window will actually be saved in this new file. This means that you can share your prefabs with other QuArK users simply by sending them this new file. (If you make nice prefabs, send them to Gryphon, the QuArK home page manager!)

To actually put your prefabs from the map editor to your new folder in the New Items window, use copy and paste, or drag and drop.

In recent versions of QuArK, you can also drop prefabs directly to the prefabs panel (top left), where they appear as a button; clicking on this button inserts the prefab in the map. This is simpler but it won't let you easily distribute your prefabs to others. (drag buttons to the trash icon to remove them.)

Compass
I see you have removed the degree-indications around the compass.

I did not REMOVE anything from QuArK 4.07 to QuArK 5.x, I just didn't rewrote everything... Because QuArK 5.x is a complete rewrite, not just an enhancement. But you are right, I'll put these numbers back, as an option (it is done in 5.4).

Coordinates
I also see that you removed the three-dimensional coordinates of the cursor that were next to the editing windows.

I also re-introduced them for QuArK 5.4, along with a basic contextual help system. You can again press F1 when the mouse is over a button or a menu command to get a complete description.

Units in pixels/meters/foots
I think that in a lot of cases it would be a very nice thing if QuArK could be set from the pixel-based system to for example a millimeter/centimeter based system.

This is not possible, because of entities that use all around pixel numbers. I couldn't for example let you enter centimeters in the "height" field of a func_plat, because I just don't know for sure which are exactly the fields that contain distances to be converted, and which ones don't. It would create a lot of confusion. However, you can get a simple mapping between Quake pixels and the way it looks. I heard that a pixel is actually an inch (grr.. why not use centimeters?) so that to get the expected feeling you should multiply numbers by 2.5, or consider 40 pixels as one meter. I know it seems strange, if the player is only 49 pixels in size, but it is really the way it looks in Quake; the player is strangely small and wide.

BTW, you can set also use the grid to help you, e.g. by setting it to a size you admit is one meter or 10 centimeters (you can set any value for the grid size, even non-integer ones).

Resizing polyhedrons
Sometimes it would be very nice if you could just resize a polyphedron by typing the (height-/depth-/width-)dimensions into a pop-up window or another menu.

I dislike features like this because they work well for cubes but not for any other shape. And I want QuArK to work with absolutely any shape. Anyway, it could be done. Ask in the QuArK-Python (mailinglist) forum if someone wants to do this, it could be a nice Python plug-in.

Polyhedron names
If I use the "subtract polyphedron" command, for example subtracting a rather round shape from a square shape, the name that I have given the square, for example "square", is not the same name that is being used for the "splinter-polyphedrons" that are the result of the polyphedron substraction. They (as far as i recall) tend to use the same name as the polyphedron that I have used as the substractor. Is this right?

This has been fixed in recent versions of QuArK. The small resulting polyhedrons have the same name as the "mother-polyhedron". But the added faces inside the polyhedrons have names that come from the corresponding cutting face of the subtractor. In fact, they share everything with the faces of the subtractor, including texture.

Leak/hole finding
Sometimes when I make QuArK search for holes in my map, it seems to find one and it draws an arrow that DOES NOT EVEN LEAVE MY ROOM(S). It does not cross a line anywhere! This appears a little strange to me; isn't this red line is supposed to represent the escaping route of an entity in my map THROUGH a leak in one of my walls INTO the virtual vacuum outside the rooms i created? Sometimes it also draws a line STRAIGHT THROUGH A SOLID POLY-WALL. That should be completely impossible if you ask me; shouldn't it?

Yes, you are perfectly right. I can only suspect a bug in QuArK. Can you please send me a small sample map that makes this bug appear? I'd appreciate it.

Drag and drop in tree-view
I see that it is no longer possible in QuArK 5.4 to just select a poly, drag it over a group and drop it into that group without opening it first.

What actually changed is the default behaviour: If the group is closed, the dropped objects are put besides the group by default. But in all versions there has been the possibility of dragging with the right mouse button to get a menu with all possible actions; moving or coping, inside or besides the group.

Entity specifics/args lists
Is there some place on your site where i can get a complete list of all usable specifics in QuArK with their SYNTAX, PARAMETERS, POSSIBLE VALUES, EFFECT (what does it do), AND WHICH ENTITIES CAN THEY BE COMBINED WITH?

Not on my web site. There are such lists available here and there, but I'm afraid nothing complete (please tell me if you find one!). Search for more information at http://www.planetquake.com, or from the Links page of my (well... Gryphon's) site.

Entity specifics/args lists - part II
I sure would like to have some kind of quick reference list of all the possible specifics so i can stop wasting time with the trial and error method.

The list of specifics is based on id Software comments, and thus are certainly not complete. The help texts that appear when you leave the mouse over the "help book" button sometimes help.

FAQ - Game related

To .PAK or not to .PAK, that is the question
If I built a level and I use my own textures and my own recorded sounds in it, can I distribute the BSP-file of my level without having to worry about that or do I have to include the textures and WAV-files that I home-created in the ZIP-file along with a manual for placing them correctly in the right directories as I have done on my computer? I mean; are they automatically included in the .BSP during creation, or does the .BSP merely point to those files, so that they have to be placed in the Quake-2 directories of the people who want to play my level?

The Quake-2 .BSP files don't store the textures. You have to distribute them together with it. The same is true for .WAV files. You can make a .ZIP file with the directory structure intact if you want to spare the trouble of putting the files in their correct directories from other users.

To .PAK or not to .PAK, that is the question - part II
I also saw a few examples of guys distributing home-made PAK#.PAK-files.

Yes, you can do that with QuArK, too. In the main window's Games menu, select 'Output directories', and check 'Always create .pak files'. Then QuArK will build a .PAK file in the 'TmpQuArK' directory, and the created .PAK file will contain the .WAV files too if you store them in the .QRK file, in a 'Files for the game' entry (see the New Files toolbox).

Note however that your custom textures will not be stored in the .PAK file. QuArK doesn't try to determine which textures are custom and which ones are not. You will have to add them to the .PAK yourself, by editing the .PAK with QuArK, for example.

The advantage of using a .PAK file is that you don't have to explain the map users all they must do with the files in your .ZIP. Once the .QRK file containing your map stores all necessary files, every time you press GO (menu Games), QuArK builds a brand new .PAK file, ready to be distributed. The file is called PAK0.PAK in the "TmpQuArK" directory under your Quake directory.

To store files in a .QRK, follow these steps: Open the .QRK file, open the "New Files" toolbox from the Toolboxes menu, double-click on "Files for the game". Then come back to the .QRK and select your new "Files for the game". There is a "new folder" button that appears in the toolbar above. Click on it to make a new folder, and rename it (e.g. "sounds" for .WAV files). The files you put inside this folder will be found by Quake as if you had put them in a "sounds" directory on the disk.

Usually, custom .WAV files should be put in a sub-directory of "sounds", e.g. "sounds/yourname/", and your map should refer to them as "yourname/filename.wav". In this case, you need a sub-folder in the "sounds" folder, called "yourname".

To actually put files inside these folders, one possible way is to drop them from Windows' Explorer to QuArK. QuArK will ask you if you'd like the files to be actually copied inside the .QRK file (it will make the .QRK file bigger, but you don't need the original files any more), or just make links; in the latter case, the files should be put in the same directory as the .QRK file itself, or QuArK will not find them again later. Either way, it does not change the way QuArK writes the .PAK file. The files are always really included inside the .PAK.

FAQ - Quake-2 related

Func_areaportal entities
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 if this func_eareaportal is not used. But how do i place it?

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

Thanks to Robert van der Schoot for this information.

Turret entities
I am working on a huge turret.

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.

Turret entities - part II
Can I use other entities in conjunction with this turret?

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.

Func_train entitiy
I am experimenting with a func_train and I seem to be unable to predict the exact course that this thing will follow after I put down the path_corners for it.

The general path it will follow is set by the chain of target/targetname that tie the path_corner entities together. When you click on one of the path_corners, QuArK should display the whole path with arrows; if it doesn't, there is something wrong in your target/targetnames, or show indirect 'target' links isn't checked. Now to know exactly where the func_train will go: Its lower-left corner is the point that follows the path_corners.

Spotlights
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?

It seems that only the light's "_cone" works. It must be a mistake to have a "_cone" field in the info_null. I removed them. 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.

Security-/locked doors with keys
How do I use keys and doors in Quake-2?

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.

Note that in QuArK 5.4 and below the "trigger_key" misses the "targetname" specific. You will have to add it yourself with the "+" button. It is fixed in version 5.5.

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

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

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

Explanation from Decker

FAQ - BSP compiling

Texture alignment/misplacement
A lot of times when I have placed textures on polyphedrons exactly the way I want them, after compiling my map into a BSP-file, those textures somehow seem to be completely misplaced.

The standard QBSP or QBSP3 programs can't place texture in any position; there are restrictions. Use TXQBSP or TXQBSP3 instead, available from http://www.planetquake.com/quark. You should download the full Build Pack of build tools for the game you are using. Besides TXQBSP, it contains enhanced versions of the other building utilities. IT IS IMPORTANT TO HAVE THESE VERSIONS OF THE UTILITIES! YOU SHOULD REALLY USE THE WHOLE BUILD PACK UNLESS YOU KNOW WHAT YOU ARE DOING!

Brush alignment/misplacement
Something similar [as above] also occurs with shapes.

Small distortions occur if you are using QBSP3 instead of TXQBSP3. I am not sure you are speaking about this, because the distortions should not be too important, but try using TXQBSP3

_minlight
I noticed that there was a specific in the turret_base of the floorturret supplied in the QuArK prefabs file called "_minlight" with a value of ".2". What the hell is this one all about?

I am not sure, but I think this is related to extra specifics that ARGHRAD knows about. If you use ARGHRAD instead of QRAD3, you have such additional specifics that control the minimum light level of the world or of an object, directionnal sun in the sky, lights that emit shadow instead of light (!) and so on. See http://www.planetquake.com/arghrad.

Ghost brushes
Sometimes when I am working on a very complex thing in QuArK (for example the diafragm-based door that i worked on for days in a row) I let QuArK create a full BSP; and it places a HUGE poly somewhere in my map! A poly that i NEVER EVER PLACED THERE myself. The strange thing is that this poly does not stop fired discharges from my gun, nor does it stop me from walking through.

I never saw this strange effect. Maybe it has something to do with the numerous and (I suppose) small polyhedrons. In fact, I suspect the problem to come from the fact you are using QBSP instead of TXQBSP; a very small poly may get slightly distorted and as a result one of its side gets very large. One more time, try using TXQBSP3!

Brush subtracting creates many small polyhedrons
Suppose I create a rather round pipe and I want to connect it to a room. I now have several options; if i just make it stick into this room and then use it as a subtractor with the brush subtraction command, a lot of very small "splinters" will be the result. In other words; a lot of polyhedrons.

All these extra poly's will not make the level run much slower. There is not a lot of difference in speed, because there is still the same area to be drawn with the texture. Anyway, QBSP3 also likes to cut polygon faces into small pieces.

It is right that a lot of small polys require more computations than just a few large ones, but on the other hand, a large poly is longer to display than a small one. I don't know how much it really compensate the increase in time, but it is certainly not twice as long to draw twice as much polys for the same surface.

If the tons of polyhedrons make it harder to work with the map, use a Digger or a negative poly instead. You can even put a single polyhedron with a lot of sides for the pipe, and another negative polyhedron a bit smaller inside. This polyhedron will both make the hole through the pipe and through the walls if it is long enough. This lets you make a whole pipe connecting two rooms with only two polyhedrons and no additional breaking of the walls.

Brush overlapping
I know that in many cases, I can prevent a lot of splinters to be created by making poly's overlap (sharing the same three-dimensional space). How bad is that?

Theoretically, it is not bad at all. In practice, I've noticed that it tends to make QBSP3 generate errors about "portals cutted away", and these errors tend to generate void grey visual artefacts. This is particularly true if you have, say, a slope with another horizontal polyhedron going inside. In this case, I'd rather have the horizontal polyhedron end exactly on the slope instead. But if you have no slope, I guess you can make the polyhedrons overlap without trouble. It helps keeping some constructs simpler.

Brush overlapping - part II
For example; cutting a hole into a wall, using a six-sided prism for a substractor, to make a passage for a tunnel which has 20 sides on its outside. If I make the size (diameter) of this six-sided prism fall within the thick wall of this tunnel, there won't be a leak, but there WILL be a lot of overlapping. Is that a problem?

I think it will not be a problem. Be careful, however, that if two polyhedrons with different textures overlap in such a way that their visible faces overlap, too (the extreme example is if the two polyhedrons are just the same, at the same location) then I guess there is no way to tell which texture will be visible.