F.A.K.K2
Frequently Asked Questions (FAQ)
Last Updated: September 17, 2000
This is a list
of questions and answers to explain how to do things in different systems in
the game.
Q: How do I create a
Particle System?
A:
Read the document titled “Ghost Particle System” and then read the document
title “Client Side Commands.” Both of
these documents explain how to use the particle/beam system.
Q: How do I use the
letterbox command?
A: The letterbox command is used to
create solid bars on the top and bottom of the screen. The syntax for the command is: letterbox <speed> [fraction]. The speed specifies how fast the bars should
appear on the screen from the edges.
fraction is an optional parameter which specifies the amount of the
screen is covered.
Q:
How do I render a model on the screen
from the UI?
A: Currently in FAKK, we use the UI and the Inventory System to draw the models. The Inventory System sets up the model name and it’s properties.
First, use the
Inventory System Commands (see the Inventory System Commands document) to set
up a model that you want to render on the screen. Second, create a Label widget
in a menu that you want to display an item.
In FAKK we set the invmodelrender
index to correspond to the item stat that is sent over in the playerstate. This itemstat is used to look up a
configstring for the name of the item.
The UI then asks the Inventory System for the model that corresponds to
that name. The UI then calls CL_Draw3Dmodel to render the model in
that widget.
If you want to
create a special model renderer on the screen, then take a look at the code
that is in file cl_ui.cpp in the
function UIFakkLabel::Draw
Q:
What do the numbers represent in the FPS
command?
A: The number to the right of the abbreviations is the corresponding value. Here are the abbreviations and their meanings:
|
FPS |
Frames Per Second |
|
wt |
# of World Triangles |
|
wv |
# of World Vertices |
|
t |
Total # of Triangles |
|
v |
Total # of Vertices |
|
Mtex |
Texture Usage (in Megabytes) |
This entity is used to simulate levers, sea saws and teeter totters. Simply build a brush model and then make it into a func_fulcrum entity. The brush will automatically pivot about its center unless an origin brush is used. The origin brush can be used to redefine the point about which the fulcrum pivots. By default, fulcrums can pivot on either axis and have a bunch of default parameters. By clicking on X_AXIS_ONLY or Y_AXIS_ONLY you can isolate the behavior of the fulcrum. Look at fulcrum.bsp for an example. The following are a list of additional parameters fulcrums can use:
speed - set the speed at which the fulcrum will operate (default is 48)
resetspeed - speed at whcih fulcrum resets, (default speed * 0.002)
dampening - dampen constant (default 0.95)
limit - limit the movement of the fulcrum (default 90 degrees)
The in-game camera system is accessed through the “camera” menu that can be seen by issuing: togglemenu camera. I recommend that you bind this command to a key so that you can easily bring the menu up and down. The menu was designed with letter boxing in mind, and you can see that if you have letter boxing on, no portion of the actual screen will be obscured. If you click in the middle of the screen, your cursor will go away and you will return to the game. Another handy trick is to bind one of your mouse buttons to: ui_showmouse which will bring the mouse cursor up and take away mouse control from the game. There is a reciprocal command you can use called: ui_hidemouse.
The camera system allows you to create camera paths that can be controlled from script. Simply add as many nodes as you would like for your camera path and then type a name for your camera path in the gray box on the bottom of the screen. Once you have named your path you can save it or load another one. To cycle between multiple camera paths use the ß and à at the bottom of the screen.
Once you are done creating paths, you can utilize those paths from script using the cam load <path name> function. Once the path has been loaded into memory it can be executed by using the $cameraname follow $pathname command. For an explanation of all camera functions please refer to the Camera Documentation Document.
There is an in-game sound system that allows you to place TriggerSpeaker’s, TriggerRandomSpeaker’s and MusicTrigger’s. These entities are saved out in a separate file which has the same name as the current map but a different extension, “.snd”. When a level is loaded the .snd file is automatically loaded and executed. The nice thing about this, is that it doesn’t matter if the map changes, the sound file need only be updated if the geometry or gameplay call for it. To access the in game sound system issue this command: togglemenu zound. I recommend that you bind this command to a key so you can easily bring the menu up and down.
MusicTrigger’s allow you to dynamically change the mood of the music at key moments in the game. The standard defined moods are:
· none
· normal
· action
· suspense
· mystery
· success
· failure
· surprise
· special
· aux1
· aux2
· aux3
· aux4
· aux5
· aux6
· aux7
commands
available from script
------------------------------
soundtrack <soundtrack name>
restoresoundtrack
music <current mood>
<fallback mood>
forcemusic <current mood>
<fallback mood>
musicvolume <volume>
restoremusicvolume
ex. soundtrack file format (same as sin's)
------------------------------------------
path music/test
action ram.mp3
normal garbage.mp3
!action loop
!action interrupt
!action restart
!normal volume .7
!normal fadetime 2
-----------------------------------
Where
the music moods can have the following effects, effects are denoted by
prepending the ‘!’ character:
Loop- music loops until another mood is triggered. Without this modifier, the mood plays only once
Interrupt - music interrupts whatever music is currently playing
restart - music will start from the beginning of the file when triggered. Without this modifier, music will pick up where it left off playing during its last triggering
volume <0 through 1> - Music volume for the mood
fadetime <seconds> - How long the mood will take to transition (crossfade) with another non-interrupted mood
Note:
restore script commands just restore the
soundtrack (or volume)
that is saved. The soundtrack and musicvolume commands both save the
current value before changing it.
For Example this would mean:
soundtrack test1.mus
soundtrack test2.mus
restoresoundtrack
You would be back to using the test1 soundtrack.
A portal sky is simply another room or set of geometry that is always drawn a fixed distance from the viewer. This geometry can be seen through sky brushes and is defined simply by creating an entity with the “skyorigin” render effect, to do this simply issue this script command:
$entityname rendereffects +skyorigin
This entity can be fully scripted. The origin and orientation of the portal sky
will be determined based off the origin and orientation of that entity.
From the editor, the following key-value pairs
can be added to the worldspawn
entity to control the far clipping plane:
“farplane”
“<farplane distance in pixels>”
“farplane_color”
“<r g b>”
“farplane_cull”
“<boolean pertaining to whether or not the far plane should cull far data.
“ambientlight”
“<r g b> ambient light for all entities and the world itself.”
“suncolor”
“<r g b> the color of sunlight”
“sunlight”
“<intensity of the sunlight>”
“sundirection”
“<x y z> direction of incoming sun rays”
“lightmapdensity”
“default lightmap density override”
From the script, the farplane can be modified as
follows:
The world now has a reserved targetname of “world”.
The farplane can be manipulated using the following commands:
farplane <distance>
farplane_color “r g b”
farplane_cull <boolean>
This can be used on levels where you want the farplane to change depending on the location you are currently in. For example to turn on green fog at a distance of 1000, you would use:
world farplane 1000
world farplane_color “0 1 0”
$thing
rendereffects +viewlensflare
and
$thing
rendereffects +lensflare
lensflare is the
regular type lensflare that doesn't fade out.
viewlensflare is
the one that is dependent on your view how visible it is.
All models
that do not have to animate (frame not shader) and do not have to move should
be tagged with the MAKE_STATIC flag
in the editor. This will allow them to
be properly lit by q3map and also cast shadows.
Q3map always assumes 2 bits of overbrightening when lighting the map. This means that instead of lighting going from 0-255 it only goes from 0-63 and then allows you to overbrighten the map past that point. The renderer in turn determines if the display and accelerator are capable of overbrightening and then does one of three things:
1. If the display cannot overbrighten, or it is turned off, than all incoming lightmaps are multiplied by 4 (to compensate for the lost two bits).
2. If the display can overbrighten but is only running in 16 bit color mode, than all incoming lightmaps are multiplied by 2 (to compensate for 1 lost bit). In this case you only have one bit of overbrightening. The gamma table is adjusted accordingly for 1 bit of overbrightening.
3. If the display can overbrighten and it is running in 24/32 bit color mode, than incoming lightmaps are read in as is. The gamma table is adjusted accordingly for 1 bit of overbrightening.
This also means that all non-game related art, interfaces, 2D art etc. Has to be multiplied by either 63, 127, or 255 depending on the overbrightening. This is accomplished through the internal rendering variable, tr.identityLightByte and tr.identityLight.
Our version of Q3RADIANT now has lighting preview. To access this feature look at the Lighting menu under View on the main menu. There are only so many lightmaps setup in the editor, if you’re level does not seem to be looking right (from a lighting perspective) this could be caused by running out of lightmap space. In order to prevent this you can adjust the Real Lighting Scale under Preferences.