![]() |
QuArK FAQ Updated 1999-04-05
|
Go to:
|
FAQ - Index |
FAQ - QuArK related |
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.
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).
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.
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.
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:
The shared face solution; let's say we want to align the face called "south" in a set of polyhedrons.
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" 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.
"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.
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.
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.)
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).
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.
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).
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.
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.
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.
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.
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.
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 |
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.
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 |
<< 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.
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.
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.
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.
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.
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.
<< 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 |
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!
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
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.
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!
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.
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.
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.