The only Quake Live cvars+commands you'll ever need to know!
Q. There's already a console guide at http://www.regurge.at/ql/ , why make this one?
There are ~1400 commands/cvars, this takes only the most important 197
cvars and gives recommendations and often times extra info not
included in the basic list. It also includes explanations for the 63
most important commands sometimes with more in-depth info.
isn't saying anything against Muffin's guide, in fact his work
made my job with this guide easier! Some of the descriptions were
copied from there although most were typed from memory.
With this guide you should have everything you need to make a config.
Q. Recommendations huh? I've never heard of you, you probably suck! Why should I listen to you?
A. Granted I'm not a cypher or a rapha, but I've been at this a very long time and I've had a chance to run countless tests on
each cvar. I'm a cvar and setting maniac and have been since long
before QL came out. I care about the truth of these options and the
last thing I want is to spread misinformation.
I've decided that I trust your advice, however I'm very lazy, can you
just provide a config that uses all your recommendations?
Yes, however many cvars are personal preference, so you'll have to
adjust those. Here's a template I made:
Q. I bet your personal config is a horrendous tweaked out mess! What does it look like?
Like this here: http://pastebin.com/rfwnEVn4
Making your own config is kind of like a Jedi making his/her own lightsaber. It's like a right of passage.
There are a few ways to handle this:
from scratch, make a blank text file with a .cfg extension. Type
everything out yourself and save it as yourname.cfg. I don't recommend
this as it is a lot of typing and it takes plenty of experience to know
all the commands and such by heart.
Use the game's built in config writing system, writeconfig. Set the game up how you like, then writeconfig yourname.cfg
edit yourname.cfg and take out the defaults/ineffectual cvars and
organize it nice and neat. This works pretty well and is worth
third way (which I recommend) is to take an already made config and
modify it until it suits your needs. The configs of noctis and stermy
make excellent templates, and again the template I made is at:
There are four files of importance to configs in home/baseq3:
qzconfig.cfg and repconfig.cfg, the only time I ever touch these is to delete them as part of a reset process.
autoexec.cfg, this does not exist by default. It can be created with \writeconfig autoexec. When it is present, any cvars that are changed will not
be saved when Quake Live is exited. The only way to save them is with
another \writeconfig autoexec, by manually editing the files, or by renaming/deleting autoexec and then making changes.
using autoexec as it allows you to go
hog wild with testing things and you never have to remember all what
changed to change it back because you can always just restart the game
and everything will be back to normal. I love this behavior and make
great use of it. The only cvar you really have to worry
about is handicap because it saves anyways. Make sure to put handicap
back to 100 if
you've been using it at some other value.
..and yourname.cfg, this is your light saber, untouched by the clutter of the other files and only ever edited manually.
I do often is reset configs by deleting (or move into a backup
directory) qzconfig.cfg, repconfig.cfg, and autoexec.cfg,
then load a practice game, exec yourname.cfg, do a vid_restart and
writeconfig autoexec. That way all cvars not in yourname.cfg get set to
Given the above there are two ways to handle configs:
Erase the contents of autoexec.cfg, and put in one line: exec yourname.cfg
Then make autoexec.cfg read-only just in case an accidental writeconfig autoexec is issued.
allows you to test cvars and reset the game to get them back to normal.
However, if you want to keep them longer for extended testing you have
to edit yourname.cfg. So there are two levels, cvars you are testing in
the current session, and cvars that have made it in to your config.
This method has a drawback that any settings to be saved beyond the current session must be inputted manually into yourname.cfg.
Leave autoexec.cfg as it is.
If you wish to test cvars only for the current session, just change what you like and restart the game to go back to normal.
you wish to test them for a longer period of time, do \writeconfig
autoexec. That way they will load when the game loads, however they
aren't part of yourname.cfg yet.
If you decide you want to keep
using them, edit yourname.cfg with the new cvars/values. So you have
three levels of testing this way. You can also reload your configs
without the extra step of editing autoexec.cfg. I recommend using this
Anyways, on to the cvars!
When set to 1 taunt sounds will be played when a player hits their taunt key (+button3).
strongly recommend setting this to 0. Although theoretically the enemy
could give away their position by hitting their taunt key, I find that
the annoyance players can cause with this far outweighs any potential
advantage of leaving it at 1. Some players really enjoy hearing their
own taunts and so leave this at 1. Personally I was overjoyed when this
cvar was implemented and made it 0 the second I heard about it.
Selects which voice is used for the announcer.
1 - Default: Sounds like a generic male announcer.
2 - Vadrigar: Original Q3A announcer, male announcer that has much more energy and character than setting 1.
3 - Daemia: Generic female announcer.
preference, however I still find it approrpriate for this guide since
you will likely be hearing a lot of whichever announcer you choose
unless you turn it off completely with s_announcerVolume 0.
When set to 1, the announcer voices rewards such as 'impressive' and 'excellent'.
I recommend setting this to 0 as it is unnecessary aural clutter.
0 - Do nothing
1 - Automatically record a demo when the game starts or if it is already in progress.
2 - Automatically take a screenshot when the game is over.
3 - Automatically record a demo when the game starts or it it is already in progress and also
take a screenshot when the game is over.
recommend using 1 so that you can always go back and review your games.
I don't have much use for screenshots but if you are in an official
competition you may wish to use setting 3. Also the screenshots can serve as a nice 'index' of your own demos.
set to 1, holding the jump button down will produce repeated jumps. If
forward is held while doing this some speed can be gained.
you were accustomed to the behavior before this cvar was added and made
default, you very well may wish to turn this off as it might mess up
your jump timing.
Theoretically though all jumps that could be performed with autoHop off could be performed with it on, and in long distances or on stairs it takes less energy to simply hold the jump button down.
good to be able to lessen energy expenditure from typical in-game
operations because it means that you can play for longer, and have more
energy to concentrate during the time you do play. Nonetheless I have
personally never played an FPS game with such a setting and cannot
bring myself to trust it, so I leave it at 0. So I will say this is
The amount of time in milliseconds for the shell casings to be shown as they fly out of the machine gun and shotgun.
I strongly recommend setting this to 0 as it is visual clutter.
This sets how much the player's view bobs from side to side while in motion.
highly recommend setting this to 0. The effect is unpleasant and
unnecessary. The bobbing up and down of quake1 and doom2 was far more
palletable although it was still something that you'd usually want to turn off.
When set to 1 projectiles such as rockets will show a small trail of bubbles behind them when underwater.
I recommend setting this to 0 to make it easier to see when shooting underwater.
When set to 1, a loud buzzer sound will play when the match ends.
I recommend 0 as it is noisy and completely unnecessary.
When set to 1, regular chat messages typed in messagemode1 will beep as they are shown.
Completely personal preference, it's nice to know that the option is there.
The brightness of the crosshair, 0 being black, 1.0 being normal (brightest).
leave this at default, but it's very interesting to try 0. One strategy
is to set your brightness settings high, like mapoverbrightbits 10 and
gamma 1, and then set crosshairbrightness to 0 for a black crosshair.
That way you have a bright screen and a dark crosshair, as opposed to a
bright crosshair and a relatively dark screen.
Theoretically this works just as well, if not better. As to which
is definitely better I have no idea, and likely depends on the person among various other variables.
Values between 0 and 1 can also be used, but so far I haven't found much use for them.
The color of the crosshair. Uses the 26 color scheme.
Notable values include:
1 - bright red
5 - bright yellow (popular)
9 - bright green
13 - Cyan
15 - bright blue
21 - Magenta (what I might call pink)
25 - White (default)
26 - Off white
The only way to set it to black is to use cg_crosshairBrightness 0.
Which color works best depends on the person, the brightness settings, enemy model settings, resolution and more.
Controls crosshair color as applicable to the appropriate hit style controlled by cg_crosshairHitStyle. Uses the
26 color scheme like cg_crosshairColor and color1/color2.
I've never had a problem with the default of bright red.
Allows the crosshair to indicate the damage dealt to other players.
0 = Off
1 = Colorize the crosshair based on damage dealt.
2 = Colorize the crosshair to the color designated by cg_crosshairHitColor.
3 = Pulse the crosshair (exaggerated/scaled pulse)
4 = Colorize by damage and Pulse the crosshair.
5 = Colorize by cg_crosshairHitColor and Pulse the crosshair.
6 = Pulse the crosshair with a smaller pulse. (same size as the cg_crosshairPulse uses when picking items up)
7 = Colorize by damage and pulse with a smaller pulse.
8 = Colorize by cg_crosshairHitColor and pulse with a smaller pulse.
default of 2 is fine. I experimented with the other values and found most of them unnecessary and/or distracting.
0 also works well, as the effect of the crosshair changing color can be
seen as distracting. So, in my opinion values 2 and 0 are the most
Styles 1, 4 and 7 could work as an accessibility feature for the hearing impaired.
Sets the amount of time in milliseconds the crosshair hit effect is displayed for.
run many experiments with this cvar, and I've come to the conclusion
that the default is fine, although a value of 100 is certainly
idea I tried was setting it to 50 ms which is the reload time of the
LG. A cell is fired every 50 ms, and if the beam hits it will blink
crosshairHitcolor for 50 ms. That way the crosshair will only stay the
hitcolor as long as I am hitting, and it will blink if I miss at all.
While it sounds good on paper, in practice it felt absolutely horrible.
It made me feel like the LG wasn't hitting, and I'd immediately start
to make corrections that weren't necessary.
it to a value greater than 200 caused the opposite
effect, where I'd feel like I was hitting a great deal even when I
wasn't. Eventually I settled on 100, but I'm very hesitant to say that
this is at all advantageous. It very well might be the case that the
brain is simply adapting to what it is presented with in this regard,
and there is nothing to be gained outside of 'reasonable' values that
are probably close to the default.
The crosshair will become larger for a split second when an item is picked up.
It's a very minor effect and completely personal preference.
Size of the crosshair in pixels.
much personal preference, and also depends on the crosshair being used.
Some would say that a smaller crosshair is more precise, others would
say that a large crosshair helps you to chunk the geometry of the
screen better. The default is somewhere in-between.
Some crosshairs are quite interesting at large sizes, for example the dot crosshair (6) becomes a square.
cg_damagePlum "g mg sg gl rl lg rg pg bfg gh cg ng pl hmg"
which weapons will draw damage plumes. These are small numbers that fly
out from an enemy player on hit indicating the damage they
Largely personal preference.
the one hand they give potentially valuable hit information, on the
other they can be distracting, especially with the LG which due to its
fast hit rate causes the enemy player to shoot out numbers like popcorn.
idea is to set it only for Area of Effect weapons: cg_damagePlum "sg gl
rl pl bfg". That way you have a better idea of how much damage a
partial hit actually did as sometimes this can be unclear.
players have stated that the damagePlum effect has improved their
lightning gun accuracy due to the extra feedback from hits.
have found that damagePlums can be used to acquire information about an
enemy's position that wouldn't otherwise be possible. For example if I
throw a grenade into a room, but I cannot tell where it bounced, yet it
still hits the player somewhere I normally wouldn't know where the
player was when they were hit. With damagePlums I will see a tiny
number eminate from their position. So I definitely recommend leaving
it on for the RL and GL. This effect would also happen with proximity
I also recommend using it for the SG as it is often difficult to tell how much damage you have done with it.
the time of writing I have it set to "mg sg gl rl bfg ng pl". I found it
distracting on the weapons I didn't include, but potentially useful on
the rest. I left the machine gun in since I often ignore machine gun
damage that I do, expecting it to either just harass the enemy or
outright frag them instead of carefully measuring the damage it does
and potentially acting accordingly.
Controls the colors used for the damage numbers.
setting of 1 colors each number based on its value. The lowest value is
white, and gradually changes to red for the maximum value of 100.
A setting of 2 colors each number based on its value,
similar to crosshairHitStyle 1. From 1-25 will be blue, 26 to
50 yellow, 51 to 75 orange, 76 and greater red.
A setting of 3 will color each number based on the weapon used:
gt - light blue
mg - yellow
sg - orange
gl - dark green
rl - red
lg - white
rg - bright green
pg - magenta
bfg - dark blue
ng - turquoise
pl - rose
cg - light grey
hmg - dark yellow
2 make more sense than setting 3, as it gives a small bit of extra
information to make it clear what range of damage was dealt. I don't
know why it would be important to know which weapon of yours damaged
another player, as this is usually pretty obvious.
2 might be slightly easier to see than setting 1, even if 1 has more
granularity. Nonetheless, the default of 1 is perfectly fine.
whether or not damage plumes are drawn for any weapons. A setting of 0
will be off for all, 1 will be on for the weapons chosen in
I recommend leaving this at 1 and instead controlling its behavior with cg_Damageplum.
Displays ‘low ammo’ and ‘out of ammo’ warnings.
0 - Off
1 - Normal-Sized Text Warning
2 - Small-Sized Text Warning
I recommend setting this to 0 as it is distracting. It should be obvious from the hud when you are low on ammo.
Displays the name and face model of the last player who attacked you in the upper right hand corner.
personally didn't notice this for many years, so I think it is a pretty
minor issue. I don't know why this information would be ncessary, so I
suppose it is visual clutter, albeit very minor visual clutter. So
personal preference I guess.
Displays the specified crosshair image. Values range from 0 to 20.
0 - No crosshair
1 - Thin circle with a dot in the middle
2 - Cross
3 - larger cross with a gap in the center
4 - Semi-transparent circle with a dot in the middle
5 - Similar to 1 except the circle is semi-transparent
6 - Small dot
7 - Similar to 2, except with a semi-transparent circle around it
8 - cross formed by four lines bent at right angles, the inside is lined with black trim
9 - Similar to 3 except the crosshair and its gap are even larger, with a dot in the middle
10 - Dot surrounded by two semi-transparent paranthesis-shaped figures
11 - Black circle filled in with cg_crosshaircolor.
- A circle that runs through the center of 4 short lines with a dot in
the middle. A combination of crosshairs 9 and 1 but with black
trim on the inside.
13 - Small thick circle, lined on the inside by black trim.
14 - A large circle with 4 gaps in it (north,south, east and west) and fins on each side
15 - A circle slightly smaller than 14, with 4 gaps (NSEW) in it, lined with black trim on the inside, and a dot in the middle.
16 - Two capital D's, one backwards and placed back to back with a small gap between them, both missing their "back" lines.
17 - A larger version of crosshair 12 with an additional semi-transparent circle around it.
18 - Four small, thin triangles placed on the corners of what would be a box shape, each
pointing towards the center.
- A combination of crosshair 2 and crosshair 9, four lines with a gap
in the middle, yet in this gap is a small cross. At normal size values
this small cross appears as a dot.
- The Q3A version of crosshair 1. Slightly larger than its QL
counterpart. The quality of its image is a bit lower, the circle
gets cut off at the edges some.
21 - The Q3A version of crosshair 2. Slightly larger than its QL counterpart. It lacks a black border around the cross image.
22 - The Q3A version of crosshair 3. Slightly larger than its QL counterpart. It lacks a black border around its "fins".
- The Q3A version of crosshair 4. Slightly larger than its QL
counterpart. It lacks a black border around its center circle. It again
has the edges cut off like in crosshair 21.
24 - The Q3A version of crosshair 5. Slightly larger than its QL counterpart.
- The Q3A version of crosshair 6. Looks virtually identical to its
QL counterpart. There may be a minor size difference, but it is nearly
26 - The Q3A version of crosshair 7. Slightly
larger than its QL counterpart. Again the circle is cut off at the
edges some. It also lacks the black border around the cross image.
27 - Similar to crosshair 21, except ever so slightly transparent.
28 - The Q3A version of crosshair 9. Slightly larger than its QL counterpart. It lacks a black border around the 'fins'.
- The Q3A version of crosshair 10. Slightly larger than its QL
counterpart. Image quality is a bit lower. It gets cut off on the sides
30 - Draws a weird silver box in the center of the screen. Appears as some kind of unsupported crosshair object.
31 - The same as 1 as the crosshair values start over. Useful if using a
hud and wish to use a crosshair value as a cvar test, yet retain
the ability to use the other crosshairs without influence.
Largely personal preference. I think the most popular crosshairs are 2 and 7.
0 - off
1 - Shows a teammate's health and armor under their name when the crosshair is on them
2 - Same as 1, except that when low their health will be shown in a different color.
I just leave at its default of 2. I don't even really notice the team health information.
The size of the crosshair team health information. The Min 0.10f, and Max 0.26f.
haven't had a reason to change this, although admittedly the default is
a bit small for serious TDM where this information may be vital.
a box during demo playback with keys for pausing and fast forwarding.
It also allows you to hide the demo hud during playback.
When set to 1, the current frames per second is displayed in the top right-hand corner.
leave this at 0 unless I am diagnosing framerate problems (which
luckily I haven't had). Very useful and important cvar though.
should be noted that when com_maxfps has been changed from its default, the value given
by cg_drawFPS can be misleading. For example, if you set com_maxfps to
120, cg_drawFPS will display 120. However in reality it is 125, since
only integer values of 1000/x are accepted by com_maxfps. To be sure of the actual FPS value
being shown, I recommend a third party utility.
Displays the "you fragged suchandsuch" text across the screen when getting a frag.
recommend setting this to 0, as the frag text is unnecessary visual
clutter that takes up a lot of space in the center of the screen.
0 = Draw only currently held weapons on the weapon bar.
1 = Draw all weapons available that can be found on the map in the weapon bar.
recommend using a value of 1, so that the weaponbar image remains
consistent and therefore easier for your brain to chunk the geometry of
I can see some appeal in using 0 in that it gives
peripheral visual information about what weapons you have and do not
have. However imo this would work better with different behavior.
for example you just spawned and have only the MG, then when you pickup
the rocket launcher, the RL icon/ammo will be displayed under the MG.
There won't be spaces between the MG and the RL so that you could
peripherally interpret the position of the entries as to which weapons
you have. You could do this if spaces remained for the SG and GL.
Granted it is less visually cluttering to bunch the weapons together
like this, but without the spaces I find it inferior to
Controls the displaying of weapons in 1st person view.
0 = hidden
1 = normal (bobs when moving)
2 = Stays still when moving
3 = Stays still when moving, but is also drawn transparent.
the LG I recommend using cg_drawgun 2, gunZ -8, gunX -10, and gunY 2.7.
For the other weapons I think it is entirely personal preference.
I suppose showing the gun does cover up part of the screen but it helps some people to aim so it's a tough call.
drawgun 2 is recommended for the thin LG setup, even though with
drawgun 1 and the cg_gun variables the gun is also hidden. This is
because walking will actually make the beam eminate from different
places on the screen which could potentially throw off your aim.
Drawgun 2 prevents this.
Using drawgun 3 instead of drawgun 2 when gunZ/X/Y are -8, -10, and 2.7
respectively hides most guns still, however with drawgun 2 the red
"laser" on the shot gun is shown just a tiny bit at the bottom of the
screen. This doesn't bother me at all and I don't even notice it so I
leave it that way, however using drawgun 3 increases the effect as it
is drawn with colors that are actually less transparent than the red
picking up an item, a notification message appears near the bottom
left-hand corner of the screen. The options are as follows:
0 - off
1 - Item's icon only
2 - Item's text only
3 - Item's icon and text
4 - Time stamp only
5 - Time stamp and icon
6 - Time stamp and text
7 - Time stamp, icon, and text
recommend either using 0, or using 5 6 or 7. Since 4 doesn't tell you
which item was picked up you could get misleading information if you
picked up more than one item at close to the same time.
1, 2, and 3 don't give you any information you really need, unless you
are completely new to the game and don't know what the items actually
Values 5, 6 and 7 give you both a time stamp which you might use for item timing, and also an identifier for the item picked up.
personally use 0, since I am accustomed to checking the game timer when
I pick up an item I wish to time, so having an extra time stamp on the
screen isn't useful to me and becomes visual clutter.
set to 1, during warmup above the "Press F3 to ready yourself" message
the following will be written "the match will begin when more players
I recommend setting this
to 0. Since I and most people end up playing a lot of warmup, it's
helpful to be able to turn off this extra text to make for less screen
reward symbols such as a yellow skull for excellents (two frags in two
seconds), and a rail symbol for impressives (two rails in a row).
I recommend setting this to 0 as it is visual clutter.
is actually the number of columns the rewards will be shown in, to
which there is always only one row. If set to 9 for example, 9 symbols
will be displayed across the screen, after which only a single symbol
for a given award will be shown with a number at its top indicating the
total count for that particular reward.
recommend leaving this at 1 so that rewards take up the least amount of
space on the screen. That's assuming you have drawRewards set to 1, if
you have it at 0 then they won't be displayed anyways.
set to 1 and spectating, you will see "Press ESC and join button to
enter game" and "SPECTATOR MODE press attack key to cycle through
I recommend setting this to 0 to make for clearer spectating.
When set to 1 a small box is drawn in the top right hand corner that lists teammates and their locations.
When set to 2 the same small box is drawn but closer to the bottom right.
I've never had a reason to turn this off, and its information can be quite useful. So far I find the position of the default
value of 1 less "cluttering" than 2. Others find the '2' position easier to read.
The opacity/transparency of the team overlay box background.
never felt the need to change this, but it's a great feature to have.
Using 0 is an interesting idea as it cuts down on the clutter as its
background box is not shown. However the background box adds contrast
to the text, so it's a tradeoff.
The size of the teamOverlay font. It has a minimum of 0.12, and a maximum of 0.22.
on your particular hud setup, resolution, and personal preference. Also
larger team games will have more players and therefore take up more
space, so a balance will have to be struck between readability and
The X coordinate of the team overlay box.
had a reason to change the position of the team overlay box. I noticed
that it's based on some odd values. The hud is based on a 640x480
layout, so the Y cvar is upper bounded at 480, and lower bounded at
-480. The x cvar is upper bounded at 640, and lower bounded at -640.
Both default to 0. This is a little strange since the team overlay by
default is in the top right hand corner, perhaps its box starts at
something like (500, 238) if the center of the cartesian coordinates
was in the center of the screen. Instead the center used appears to be
where the box appears by default. Not a problem, just unusual.
Of course this all changes for cg_drawTeamOverlay "2" at which point a completely different center value is used.
The Y coordinate of the team overlay box.
had a reason to change the position of the team overlay, although it's
nice to have the option. I can see a hardcore TDM player wanting to
adjust its position.
Displays another player's name above their heads when the crosshair is pointed at them.
recommend leaving this at 1. It can be useful information during the
game to know who is behaving in what way. Also if this isn't set to 1
crosshairteamHealth will not be shown.There are some moments in the
game where I haven't seen the enemy, yet I see their name flash on the
screen momentarily, indicating that they were there, but had just moved
out of my visual range. In this
case the crosshairname information could be invaluable.
opacity/transparency of the name of the player shown when placing the
crosshair over them. Obviously requires cg_drawCrosshairNames to be set
I always thought the default was
fine. This value also determines the opacity/transparency of the
These three are the hex color code for bright modeled enemies.
recommend using 0x00ff00ff (as green as it gets) for all of them.
Although I can see that many different values and combinations would
work just as well.
The format is 0xRRGGBB and the last two characters are for the brightness. FF should be as bright as it gets.
Strangely, 0x000000FF is black, while 0x00000000 is white.
This is a strange one. Someone on an ET|QW forum had this to say about it:
controls how fast a prediction error is decayed off to smooth out any
jerkiness. A prediction error is, very basically, what occurs when the
client and server disagree on the location you're in. Unfortunately,
there are many problems with the prediction code several of which
carried over into ET btw) that make it easy to cause prediction errors,
so by setting cg_errordecay really high and exploiting any of the
prediction errors, you can effectively move your camera away from
yourself far enough to see through walls. It doesn't really seem to be
possible to generate enough error within 500ms to give yourself any
advantage. In other words, setting this cvar to high values produces a
Another clue was given by this post here in regards to CPM:
cheat protected cg_errordecay cvarPlease don't, set an upper bound
instead. Players should be allowed to use 0 and anything from 0 to 200
is surely fair. This is important, your view of the gamestate should,
if desired, be as accurate as possible, even if it's not smooth;
separating the player's view from the actual body position is not good
for high-level play.
For those who do not know what this does -
when your position that the server tells your client differs from the
one predicted by the client it has to be corrected. The actual player
position is corrected instantly but your in eyes view is smoothly
transferred over a number of milliseconds equal to the value of
cg_errordecay. This means you're not seeing an accurate crosshair nor
information that you base movements on. Try this in baseq3 (prevented
in CPMA) to get a feel for it - load a map with a teleporter. Set
cg_errordecay 5000. Enter the teleporter and watch your view travel
through the level, try moving while this happens, your player is
already at the tele dest while your view goes on its tour.
I ran the test suggested above in Q3A, and I did not experience what
they mentioned. What I did experience was that when I rocket jumped
every time I landed it sunk my view deeper into the floor. On
pro-q3tourney4 at one point my view was so deep on the top ledge that
it was like my view was hanging under it, and of course I could see
anything that would be obstructed normally by the ledge. At a value of
10000 I could see the view correcting, slowly rising me upwards to
where my view was supposed to be. I was unable to produce any other
artifacts, not by rj'ing into walls, going through teleporters, making
high speed jumps or maneuvering on jump pads.
locked between 0 and 100 in QL, and defaults to 100. As far as I know
no one has ever gotten a "wallhack" effect. Perhaps a setting of 0 will
keep your view as true as possible during an error.
piece of evidence was acquired by using an obscure cvar not mentioned
in this guide: cg_showmiss 1. Just moving around on the server produced
many "prediction errors". I have trouble believing that a 100 ms
correction is going on during each of these times, but if so I'd rather
have it be 0 ms.
did some testing, playing with 0 for some time on various servers with
different latencies. So far I've come to the conclusion that 0 produces
undesirable effects. With ~75 ms I would often experience a stuttering
effect when being hit by enemy players, especially with the LG (as if actually being electrocuted!). This
effect is jarring and unpleasant. It happens less with 50 ms, and I
assume even less with a lower ping. For now I've raised it to values
like 40 which lessens the stuttering effect.
If anyone has more information on this cvar let me know.
how the player’s view camera changes in relation to aim position
changes. When it is set to a value higher than 0, the view camera lags
behind the player’s aim position, turning to it slowly and smoothing
the frames in-between causing a mouse smoothing effect.
don't recommend using this cvar as it shows you some incorrect
information. If you do choose to use it, keep it at low values such as
less than 1. I know that at one point, Stermy used settings of it like
0.02 or 0.03 which already has a noticeable effect. Set it to 300 for a
laugh (drunken mouse).
Changes the appearance of the flag.
1 - Classic Flag
2 - Holographic Flag
When enabled: In spectator mode, when a player scores a frag, the spectator view automatically switches to that player.
Personal preference. Useful for casters.
Force enemy team player models to be displayed as a specific model.
default is absolutely fine. Keel fills in the hit cylinder nicely and
the /bright keeps him bright. His hitsounds and footsteps are fairly
easy to hear. I use keel/bright and have no complaints.
is another common choice though, as he is easier to see being slightly
larger. The robotic hitsounds Tank makes can be difficult to discern
Since all models feature a /bright or /sport option now,
many models are now candidates for use instead of the most popular
ones, tankJR and keel. One radical idea is to use bones, who is arguably
the most difficult character to see as he takes up the least of the hit cylinder.
That way if your crosshair is on or near him you'll be getting a hit for sure since he is a smaller target.
Other models that work alright are visor, sarge and sorlag.
Here is a screenshot
of some of the models in the hit cylinder. The cylinder size may have
been adjusted slightly since this screenshot was taken though:
forceEnemyModel is not set, this cvar will force other players to use a
specific version of their model, such as "bright" or "sport". Use blank
"" to turn off.
Since I recommend
forcing enemy models, it isn't important what value this is set to. If
you don't use forceEnemyModel, at least forcing them to their
bright or sport versions will make for easier to see enemies.
Force enemies' grenades and rails to use 'Enemy Upper Color' (cg_enemyUpperColor).
I recommend using 1, the reasoning behind it is that it
will enable you to determine which grenades are teammates and which are
enemy grenades. Since most players use a /bright enemy model, the enemyUpperColor will affect both the model and the grenade.
Force teammate player models to be displayed as a specific model.
criteria to look for in a team model would be that they would be fairly
quiet as it is more important to hear enemies than teammates, and show
up as noticeably different than enemies so that you do not confuse the
What tends to happen is that a wide variety of team models
work fine, whereas fewer enemy models seem comfortable. So it is hard
to give a recommendation other than what I use, which is bitterman/red.
As long as the above criteria are satisfied you could use just about
forceTeamModel is not set, this cvar will force other players to use a
specific version of their model, such as "bright" or "sport". Use blank
"" to turn off.
Since I recommend
forcing team models, it isn't important what value this is set to. It's
personal preference whether you wish for your teammates to be bright or
Force teammates’ grenades and rails to use 'Team Upper Color' (cg_teamUpperColor).
Since I do not force bright skins for teammates, I am free to change
cg_teamUpperColor to whichever color I wish and have it not affect my
team models. So, I use 0xFFFFFFFF (white) making my teammate's grenades
The field of view in degrees.
recommend using a value between 90 and 105. The famous arq0n who is the
lead developer of cpma said that 102 was the "best" fov. However he
never stated why and I cannot think of any reason for this.
X direction of the gunmodel when cg_drawGun is set to 1 or 2. However
the coordinate system for the gun model is such that the X axis behaves
like a normal Z-axis. Higher values move the gun forward, lower values
move it backward.
I recommend that at least for the lightning gun, set this to -10 (minimum) for thin LG
For a laugh, set it to a maximum of 10 with cg_drawgun 1 and run around for a disturbing rocket gunmodel.
Y direction of the gunmodel when cg_drawGun is set to 1 or 2. However
the coordinate system for the gun model is such that the Y axis behaves
like a backwards x axis. Positive values move the gun model to the
right, negative values move it to the left.
At least for the lightning gun I recommend setting this to 2.7 (centered) for thin and centered LG purposes.
Z direction of the gunmodel when cg_drawGun is set to 1 or 2. However
the coordinate system for the gun model is such that the Z axis behaves
like a normal Y axis. Higher values move the gun upwards, lower values
move it downwards.
I recommend setting this to -8 (minimum) on at least the lightning gun for thin LG purposes.
0 - No hit beeps
1 - Singular hit beep when a shot lands
2 - High pitched beep when a small amount of damage is done, low-pitch for larger amounts.
3 - Low pitched beep when a small amount of damage is done, high pitch for larger amounts.
At first I thought that only 2 and 3 were worth considering, and which of those was personal preference.
it is possible to get a consistent beep sound for the GT/MG/LG/RG/NG/CG
by having these use 1. After all with a little experience you already
know what damage these weapons do per hit, so it is slightly less
distracting in my opinion to have them all make the same beep.
definitely should be bad to use values other than 2 or 3 for the
SG/GL/RL/BFG/PM since they have variable damage and you could lose
valuable game information this way. Of course crosshairhitStyle could
also be used to display this information.
the directory of which heads up display (hud) to use. Huds are always
in ui/, which looks for them either in the pak file, or in the
home/baseq3/ui directory. Three huds are included:
ui/hud.txt - default hud
ui/hud2.txt - Smaller more uniform hud with the timer in the top left
ui/hud3.txt - Large hud
largely personal preference, however there are a lot of cool huds out
there. Visit http://qlhud.eu/ to see a great many of them. Better yet,
the site that qlhud.eu was based off of just recently returned, visit
pro configs come with their huds so you can check those out too. A
custom hud is not needed and plenty of top players use the default or
large huds, but they can be fun to try out.
option is to make your own, either by modifying a hud that you like, or
using a utility such as the online one at http://visualhud.pk69.com
When set to 1 hitting a player will cause spark-like graphics to eminate from them.
Personal preference. On the one hand it can help with intuiting damage, on the other it can be distracting.
One good use for it is in TDM: to tell if the enemy is being hit by a teammate's machine gun fire and you'll therefore
have a better idea on what their health is.
Time in milliseconds before impact sparks fade out.
Size of each spark when cg_impactSparks is set to 1.
Personal preference. Increasing
their size can make them easier to see at the tradeoff of becoming
speed and direction of impact sparks when cg_impactSparks is set to 1.
Values range from -128 to 128. Values less than 0 will feature impact
sparks travelling downwards. Setting this to 0 means that the sparks
will stay at the point of damage.
this to 0 has the effect of making them less distracting, while being
more difficult to see at a distance. Also in an up close battle, using
a SparksVelocity different from 0 allows you to discern which damage
sparks are older than others by their height, potentially providing information about enemy dodge motion as well.
When cg_simpleItems is 0, this controls how the items behave.
0 = static
1 = bounce
2 = rotate
3 = bounce and rotate
4 = static (balloon spawn)
5 = bounce (balloon spawn)
6 = rotate (balloon spawn)
7 = bounce and rotate (balloon spawn)
Mostly personal preference, and in my opinion isn't a big deal.
under 4 appear immediately on spawn, and do not "balloon" up. It
should be noted that the "ballooning" does not start until the weapon
idea is that the enemy can pick up the weapon while it was ballooning
providing less visual information than if it had appeared suddenly such
that one can miss the fact that they did pick up the item. Therefore
the "competitive" options may be to use values 0,1,2,3. Since I'm
accustomed to the 'bounce and rotate' behavior I settled on setting 3.
Determines how much the screen shakes when hit, values range from 0 to 1.
_strongly_ recommend setting this to 0 as it makes getting hit much
less jarring. Depends on having cg_screendamage set to a non-zero
value. So, you can set cg_screendamage to 0 and get this effectively
made 0 as well.
Plays a distinct sound when you score a kill in any mode. This cvar is premium/pro only.
Values are as follows:
0 = Off
1 = Ting, sounds like a ball bearing hitting a teapot
2 = Tink, lowered pitched than 1, sounds like two teapots being tapped together
3 = Dramatic, sounds just like a horror movie trailer when the title is displayed, DUN!
4 = Woosh, sounds like a very fast flyby from a missle
5 = Drum, sounds like a drumstick striking a very thin tin bucket
6 = Bang, sounds like Sorlag dropping onto some bleachers
7 = Ding, sounds synthetic and very generic, like the fasten your seatbelt sign on a plane
8 = ChaChing, old timey cash register sound
It's a pretty minor issue, but I recommend just using 0. It is unneeded information.
1 = Show netgraph
2 = Show netgraph + client ping estimation.
How to interpret the graph from Yakumo:
Top bar is prediction
Blue is interpolation between two valid frames
Yellow is extrapolation since the last frame (waiting for another)
Yellow is bad, it will increase a lot if using timenudge.
On the top, green is ping for a properly received snapshot
Yellow is a properly received snapshot, but the previous one was suppressed to stay under the client set rate.
Red is packet loss
So.. if the top line is all blue, and the bottom line is completely flat and green then your connection is in great shape.
Unless you are diagnosing lag problems, I recommend setting this to 0.
Determines which direction the game timer counts. 1 counts down, 0 counts up.
recommend setting this to 0 so that the timer counts up to the time
limit, as it is generally easier to add than to subtract when timing
items. Also this is the more common setting so you are much more likely
to hear players giving out times in public team games that are derived
from the timer counting up.
Enables the lightning impact effect on surfaces by the lightning beam.
recommend setting this to 0, although I can see that leaving it at 1
gives some feedback about the distance between you and the target. In
practice I haven't found this feedback to be particularly useful, but
others might. Something to test for yourself.
Ranges from 0 to 768. Determines the size of the lightning impact effect when impact is closer
than x units.
I use lightningimpact 0 I just leave this at default. Players that use
1 might try experimenting with this to see if the distance to target
information can be heightened by adjusting this value.
Controls the lightning stream effect.
1. Blue twisty double beam
2. White jagged zappy single beam
3. Large blue/white zig zaggy rolling bolt beam from q3test
4. Thin blue/white single beam
5. Semi-Transparent picmip'd style triangular beam from Q3
personally recommend Style 4 as it is the thinnest. Plenty of strong
players use setting 5, setting 2, and even setting 1. I have never seen setting 3 in a config, and I've read a lot of configs.
you have cg_drawgun set to 1 or 2, and then hide it with cg_gunZ -8,
cg_gunX -10, and center it with cg_gunY 2.7 your beam will be slightly
thinner than normal. I think this works well in combination with
percentile level of ammo available before issuing a low ammo warning,
for both the lowammoWarning sound and the "low" message on the weapon
Min: 0.01 (1%)
Max: 1.00 (100%)
I recommend leaving this at default since I also recommend turning off low ammo warning sounds.
Controls what sound is played when low on ammo.
0 = Disabled
1 = Low Ammo Clip Reload Sound played for Low Ammo, "No Ammo" Click Sound played when out of ammo
2 "No Ammo" Click Sound played for both Low and No Ammo
I recommend setting
this to 0 as it should be clear from the heads up display what your
ammo is and adding this sound to it is unnecessary and potentially
Controls the weapon bar ammo warning display.
1 = Draw weapon bar ammo value in red when empty
2 = Draw weapon bar ammo value in yellow when low and red when empty
The default value is fine as the effect is barely noticeable.
set to 1, burn marks and bullet holes and such will be shown on the
walls for a short time after weaponsfire. Setting this to 0 turns off
In general I
recommend using 0 as it is extemporaneous information. I personally only turn it
on when someone is drawing on the walls to see their "art" :-)
does however give some potentially useful information, as enemy
prediction/rockets that hit a wall will leave the mark showing for 10
seconds. This information could be used to interpret their location and
where they might be headed. Probably duel is the game type where this
would be most useful. Something to consider.(Thanks TIE for reminding me of this important detail).
Every time a gun fires a small flash will be shown on the screen.
Also controls the "blazing" aura on the lightning gun when the model is shown.
I _strongly_ recommend setting this to 0 as it is a very distracting effect.
Values between 0 and 1 are possible. They determine how far play models lean from side to side when strafing.
personal preference. It could be argued that the player lean is vital
information about their direction, it could also be argued that this is
distracting. I use a value of 0.7 to strike a middle road between the
two, erring on the side of the lean.
Allows a client to disable some of the team related VO
I recommend 0 to cut down on the announcer.
There are two explanations, one:
A value of 0 will feel less responsive in high ping environments but may prevent wrongly predicted rail shots and/or impacts.
set to 1 the rail graphic is drawn instantly as if there were no
latency at all. When set to 0, the rail graphic is drawn when the
server sees the shot, so there is a latency shown.
at least trying 0 as it gives a better clue as to what
sort of lag is actually experienced and so adaptations can be made.
Still some players swear by 1. Either way every player owes it to
experiment with this cvar.
Client prediction for picking up items.
Since this sometimes results in hearing the pickup sound yet not actually picking up the item, I recommend using 0.
1 = Rail core rail trail
2 = Spiral rail trail
personal preference, however the spiral rail trail is slightly more
centered as you can test by turning on cg_marks, railing a wall at eye
level and then walking up to it and seeing where the mark lines up with
the crosshair. At close range style 2 will be more centered, at the
cost of this extra spiral graphic that cannot be removed or adjusted (other than color).
The time in milliseconds that the rail beam remains on the screen.
Very personal preference, however there are some interesting settings:
0 - Off, never shows the rail beam. Useful if you believe that the beam is distracting you.
1500 - This is the duration of the railgun's reload time, so when the beam has faded it means
you can shoot again.
- Since you must still react to the rail beam fading, one idea is to
subtract your would-be reaction time from 1500. So if your reaction
time was estimated to be 150 ms, you could use 1350 and shoot as soon
as you see the beam fade. (Thanks aeoL for this idea).
200 - Fades twice as fast, gives it a "snappy" feeling.
500 - One-third the reload time
- I don't recommend doing this online, but in devmap you can make some
neat railgun art as the beams will stay for as long as you like.
They are also color unique, so if you change rail colors and fire again
it will not affect the color of the previous beam. EDIT: This was
recently capped at 2000 in Quake Live because the developers are
anti-fun. It is still possible in Q3A I believe.
set to 1, small numbers will float out of enemy bodies or nearby during
game events notifying you of points or frags gained.
leave this at 1. It is very minor visual clutter, and helps me to
understand the scoring in some game types. Technically this is
extemporaneous information since I either don't need the scoring
information, or know it well enough that I don't need these numbers. So
I can see the reasoning behind setting it to 0. It is a very very minor
This is the hex color value of the color flash shown when receiving damage in general.
information is given about the direction of enemy fire, I find this
vague and difficult to interpret on the fly, even with many adjustments
to the below screendamage cvars. It is also rare that you do not hear
an enemy shot, or have a strong idea where the enemy is shooting from.
With this in mind I recommend using 0, as I find it to be more of a distraction/screen clutter than useful information.
Setting this to 0 also renders cg_kickScale
ineffectual. So if you use screendamage 0, and prefer kickscale to be 0 as well, you do not need to set kickscale to 0.
This is the hex color value of the color flash shown when receiving damage from yourself such as during rocket jumps.
I recommend leaving this at the default.
This is the hex color value of the color flash shown when receiving damage from teammates.
recommend turning off screendamage with cg_screenDamage 0 which renders
the other screendamage cvars ineffectual so they can be left at default.
The opacity of the color flash when receiving damage from enemies or yourself.
recommend turning off screendamage with cg_screenDamage 0 which renders
the other screendamage cvars ineffectual so they can be left at default.
The opacity of the color flash when receiving damage from teammates.
recommend turning off screendamage with cg_screenDamage 0 which renders
the other screendamage cvars ineffectual so they can be left at default.
Displays the player's own name on the team overlay.
is useful if you wish to see what your teammates see on the overlay,
and learn what the various locations are called. Otherwise leave it at
0 because it is extemporaneous information.
Draws a shadow under the feet of players.
recommend leaving this at its default of 1. It seems to be useful
visual information in predicting shots, and there are some
rare cases when the player's shadow can be seen, but their model
Draws the items as flat symbols instead of 3d objects when set to 1.
preference. It is easier to see around simple items, but more difficult
to see the items themselves from certain angles/distances.
When simpleitems is on, this controls whether or not they bob up and down.
A value of 0 turns off this behavior.
A value of 1 makes all items bob.
A value of 2 makes only major items bob, such as armors and the megahealth.
recommend setting this to 0 if you use simpleItems. The bobbing effect
looks incredibly strange on simpleItems, the way that bobbing icons
might in any user interface.
When simpleitems is on, this number controls their size.
default is absolutely fine. I feel that increasing their
size defeats the purpose of simple items, which is to make it
easier to see around them (and they are somewhat less visually
the default size of simple items is substantially smaller than the
the non-simple items such that the items cannot be seen at certain
angles (the red armor on blood run is a typical example). Increasing
the size mitigates this.
Alternatively, simpleItemsBob would be another way of mitigating it, if you could stomach the weirdness.
This is the shotgun smoke shown while firing.
I recommend using 0 (off), as this smoke is distracting.
This controls the size of the smoke trail on grenades.
recommend setting this to 0 as with many grenades comes many trails
making it difficult to see. Since the grenade flies at an awkward
trajectory however, one idea is to temporarily set a low value for this
such as 8 to get a feel for how grenades fall/bounce. Ultimately though
it is just a visual distraction.
Smoke trail for the Nail gun projectile.
you never play on maps that feature the nail gun, you can leave this at
its default. Otherwise it is easier to see with this at 0.
This determines the size of the smoke trail for the rocket projectile.
I strongly recomnend setting this to 0, as the smoke trails are highly distracting/obscuring.
When spectating a player, displays any changes they make to their fov, such as when zooming.
preference. I have it off because I prefer to see the game with my
personal fov setting even when spectating. It is interesting however to
see what fov strong players might use when spectating them live and
when they zoom. Unfortunately I don't believe there is any way to
extract the exact value of the fov in use, although one could
theoretically switch between specFov 1/0 and adjust their fov until the
Displays a meter for the player’s horizontal velocity.
Values are: [0|1|2|3]
0 = Off
1 = lag-o-meter style graph
2 = value and graph under crosshair
3 = value under crosshair
I recommend leaving this at 0 unless you are training strafe jumps.
set to 1, trying to shoot a weapon that has run out of ammo will
automatically switch to a weapon that does have ammo, or to the
gauntlet if there are no others with ammo.
Either 1 or 0 is ok.
0 is superior since you have control over which weapon to switch to
instead of a weapon that is automatically decided for you. In this case
though you need to train yourself to switch manually when the last shot
has been fired, or you will end up shooting nothing.
I've managed to use 1 without issue for pretty much my entire time in
QL, as have many other players, so I feel that it is not terribly
When set to 1, switching to a weapon that is out of ammo is permitted.
recommend leaving this at default. There are cases when you are
anticipating picking up ammo and don't want to take the extra time to
switch to the weapon _after_ you pick up the ammo. Also less noise is
made without unnecessary switching.
Determines whether or not the "beep" sound will be played when receiving a team chat.
personal preference. I can see that if someone regularly played with a
large team and they relied heavily on team binds that were constantly
in use during the game that turning this off might be a good idea.
Otherwise it is an incredibly minor issue.
When set to 1, only chats in messagemode2 will be displayed. Handy as a "mute" function as many games do not feature team chat.
this at 0 unless you have a strong need to mute other players on the
server and would rather not mess with the block command.
three cvars determine the torso color, "pants" color, and head color
respectively of the teammate's model when they are set to a /bright
model. After the 0x, each color channel gets two characters and the
last two are for brightnessl: RRGGBB FF.
personally do not force a bright model for teammates as I am used to
shooting at bright models. I use bitterman/red for teammates.
The brightness channel seems to have no effect on player model color unless
using all 0's, so I recommend just leaving it at FF. Some examples
on how to use the hex color system:
0xFF0000FF = As red as it gets
0x00FF00FF = As green as it gets
0x0000FFFF = As blue as it gets
0xFFFFFFFF = As white as it gets
0x000000FF = As black as it gets
0x00FFFFFF = Turquoise
I set teamuppercolor to white (0xFFFFFFFF) and use cg_forceTeamWeaponColor so that grenades from teammates become white.
Flexibility factor for lightning gun shaft, 0 being the most flexible and 1 being the most rigid.
remember reading somewhere that truelightning 1 is supposed to turn on
a special client side prediction (up to 80 ms) which should make it so
that if the beam is on the player it will count as a hit. In this case
the beam is snapped to the crosshair, therefore aiming with the beam or
the crosshair is just personal preference.
In practice I am not
sure that truelightning 1 actually does this, but the substantial
difference between 1 and say 0.98 might be an indicator that this is so.
you turn on marks (cg_marks 1) and go to a laggy server say with 200
ms, set truelighting to 1 and shoot the LG at a wall while strafing you
will see the marks lag behind the LG beams position substantially.
Setting truelightning to 0 however matches them up perfectly.
thought this may be an indicator of the lg's behavior in-game, but
someone mentioned that the wall marks do not operate under the same
guidelines as enemy players. Anecdotal evidence seems to suggest this
is true as LG'ing at even very high pings doesn't seem to behave this
poorly at values > 0, although it could just be me because my
previous game was QW in which I had to put up with a lot of LG wagging
so I might be unconsciously making adapting motions despite the way the
beam is being drawn.
When you couple this with the netcode's
other issues, such as the hit cylinder sometimes lagging behind/in front of where
the enemy player is displayed, it becomes rather difficult to determine
much of anything for sure.
Rather than enter into this technical
mess without any developer confirmations I don't concern myself with
the beam or the crosshair really. Instead I aim by patterns: I know
what good LG'ing is supposed to look like from experiencing times when
the LG hits well (hitbeep), and seeing good players LG. So, I am always comparing the geometry of the
whole screen to what I think it should be and try to make the patterns
match using a balance of movement keying and mouse work.
A value of 0 is interesting as it teaches you some of the motions that may be needed for good LG'ing.
are many players claiming a "best" value for truelightning. I have
heard 0.5, 0.75, 0.77, 0.95 and 1. An interesting thing about 0.75 is
that it used to be the default value, which was later changed to 1.
I think the best recommendation I can give is to pick a value between 0.5 and 1 and stick to it.
set to 0, the shot gun spread will appear slightly random, more like a
real shotgun.When set to 1, the spread graphic will appear as the game
actually uses it, in concentric rings.
I recommend using 1 as it is truer to the way the pellets are actually behaving.
When set to 1 this will display "Used suchandsuch" when using an item such as the Medkit.
Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.
When set to 1 this will display "No item to use" upon pressing the use key (+button2) when the player has no item.
Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.
Literally the size of the view on the screen. Using lower than 100 shrinks the screen and applies a grey border on what's left.
is some appeal to using values like 90 or 95 as they can help you focus
on the screen in some cases, but really just using the default of 100
is the only thing I can recommend.
When under water the player's view will be distorted by a wavy undulating visual effect.
I recommend setting this to 0 so that you can see more clearly when under water.
is the display of the "weapon bar", which shows which weapons you have
and what ammo you have for each one. It has 4 values:
4 - Large Q3 style weapon bar that shows only upon changing weapons
3 - Horizontal weapon bar shown in the lower center
2 - Vertical weapon bar shown on the right side
1 - Vertical weapon bar shown on the left side
0 - off
only value I don't recommend is 0, as currently there is no other way
to display this important information. Otherwise it is entirely personal
This is the hex color value of the small band around grenades.
set this to the same value as cg_teamUpperColor (0xFFFFFFFF), and use
cg_forceTeamWeaponColor 1. That makes my own grenades the same color
as those of my team.
This is the field of view (fov) in degrees that will be taken when zooming.
recommend a higher value than the default of 22.5, which is very low.
When the zoom fov is set very low it becomes disorienting as the
difference between zooming and one's normal fov is so large. A value of
60 seems quite reasonable to me, and I wouldn't go lower than say 37.
what works best for you with this value will depend somewhat on what
fov you use when not zooming. Also if you play a lot of SpaceCTF you
may find that the lowest possible value is best since the ranges
are so far on that particular map.
Zoomscaling 1, zooming in will not happen instantly, but over a small
time frame over which the fov will be moved between your current fov
and the zoom fov. Similar to pressing the zoom-in button on a camera
and having it zoom in quickly.
When set to 0 the fov changes instantly from the normal fov to the zoom fov.
I recommend using 0 as it is faster. However some players find the
effect of an instantaneous fov change unpleasant and so leave this at
1. It isn't terribly critical and is mostly personal preference, as
even with zoomscaling 1 it zooms in fairly quickly.
zoom is active the mouse sensitivity is run through an algorithm, and the
result is multiplied by this number, except in the case of 0, in which
case a different algorithm is used.
When cg_zoomSensitivity > 0, the sensitivity is multiplied by zoomsens which is then multiplied by k, where
k = arctan[ 0.75 * tan[cg_zoomfov°/2] ] / arctan[ 0.75 * tan[cg_fov°/2] ]
Remember that both fov and zoomfov are in _degrees_ and not radians.
When cg_zoomSensitivity = 0, the sensitivity is multiplied by k, where
k = arctan(tan(zoomfov * (pi/360)) * height/width ) * (360/pi) / 75
In this case do not specify degrees for zoomfov.
recommend using zoomsensitivity 1 as it uses the more correct
algorithm, and most do not need to change it.
idea is to use a value of 0.864713, as the formula that makes the most
sense to me personally is sens * k where k = tan[ cg_zoomfov°/2 ] /
tan[cg_fov°/2 ], and the value of 0.864713 adjusts the result to what
it would be with this other algorithm.
set to 1, pressing the zoom key remains zoomed in until it is pressed
again, as opposed to zooming while the key is held down.
recommend using 0 as it is extra work (and time) pressing and releasing
the zoom key. Some find holding down a key unpleasant and benefit from
setting this to 1.
set to 1 and something is typed into the console, upon pressing enter
it will be chatted in messagemode1. Commands and cvars have to be
preceded by a \ to work. This will be added automatically by the
autocomplete if you press [tab] after typing part of a command or cvar.
Unless you do a lot of chatting, leave this at 0.
set to 1, supposedly sets the value of cl_timenudge based on ping. It
will also override any value of cl_timenudge including 0. Values lower
than -20 will not be used.
At the pings
I play at such as 50 and 70, it seems to me that the timenudge just
gets set to -20, so isn't much different than if I simply used
timenudge -20. I don't have any way of knowing this for certain since
the values it has set are not made available to the client, but judging
by the side effects it must be near the limit. Since this is case I
prefer to set timenudge manually.
0 - No record message
1 - Message appears in the bottom center of the screen that says "recording" and states the
current file size of the demo.
2 - A small text is shown at the bottom left corner that says "REC".
recommend 0 unless you aren't used to demos and want to make sure it is
recording, then I would use 2 to keep it out of the way.
set to a value > 0 the mouse sensitivity will increase as the
velocity increases. Values < 0 are supposed to exhibit negative
acceleration, however the behavior is buggy and not recommended.
The formula used by the game is as follows:
B + (A(v-c))^(P-1)
B = sensitivity
A = cl_MouseAccel
v = velocity (lower bounded at 0)
c = cl_MouseAccelOffset
P = cl_MouseAccelPower (lower bounded at 1)
When m_cpi is at its default of 0 both v and c are measured in counts per millisecond.
When m_cpi is set to the CPI of the mouse, v and c are measured in cm/second.
Like sensitivity, this is about as "personal preference" as it gets.
idea is to join an empty map and find an area where you can easily
recognize two points that are directly in front of you and directly to
the left or right at a 90 degree angle. Then with mouseaccel 0 make a
comfortable motion with the mouse to the right. Adjust your sensitivity
until the comfortable motion makes a 90 degree turn to the right. Then
do the same for left and use a value in-between the two in an attempt
to satisfy both directions.
Do the same for a 360 degree turn,
taking note of the sensitivity value you arrived at. Don't worry that
they aren't exactly multiples of one another, your mind expects your
arm/hand to move the mouse more for a greater turn.
I got something like:
3.84 90 degrees
9.75 360 degrees
Note: this was with a 400 cpi mouse.
Set cl_MouseSensCap to the 360 degree sens. Set the base sensitivity to the 90 degree sens.
go back to whichever position you were using to do the tests, and
practice 180 degree turns. Increase cl_mouseAccel in increments of 0.05
until a 180 is comfortable.
The values you are left with should
provide a nice "template" for adjustments and reflect some underlying
physical truth about what mouse motions your hand is comfortable with making.
If you wish to know for sure how much sensitivity is being added per unit of velocity, you can use the following formula:
Sensitivity = Sensitivity + (cl_MouseAccel * V)
Where V = [(Velocity)(CPI / 2.54)] / 1000
Velocity is in centimeters/second.
Note: this formula assumes: cl_mouseacceloffset 0, cl_mouseaccelPower 2, and m_cpi 0.
CPI = 400
Sensitivity = 4
cl_mouseaccel = 0.1
Velocity = 50 cm / second (so if you had accel 0 and a base sens of 25 cm/360 that'd be two 360s in one sec!)
Sensitivity_at_this_speed = 4 + (0.1 * V)
V = [(50)(400 / 2.54)] / 1000
V = 7.87402
Sensitivity_at_this_speed = 4 + (0.1 * 7.87402)
Sensitivity_at_this_speed = 4 + 0.787402
Sensitivity_at_this_speed = ~ 4.78
velocity at which mouse acceleration starts.
Using positive values has the effect of delaying the application of acceleration until a given velocity is reached when
mouseaccel is > 0.
counts/millisecond when m_cpi = 0 which it is by default.
When m_cpi =
the cpi of your mouse, it is measured in cm/second.
permitted, in which case the accel behaves as if the velocity started
at a higher speed, however this is silly when cl_MouseAccelPower is at
its default of 2 because it is identical in effect to raising the
recommend leaving this at 0 unless you know that what you're getting is
what you want. To convert an offset velocity to m/s run the value
[(v * 1000) / (CPI / 2.54)] / 100 = m/s
So for example cl_MouseAccelOffset 5, at 400 CPI is 0.3175 m/s.
If you prefer centimeters per second you can use this instead:
[(v * 1000) / (CPI / 2.54)] = cm/s
power curve of the mouse acceleration. In the code it is subtracted by
1, so power 2 is actually taking mouse accel to a power of 1,
which is the same as multiplying it by 1. This results in a linear
acceleration (a straight line).
Personal preference. I would leave this at default unless you are sure that this is something you want.
I have tried many times over the years to derive some advantage from
this cvar, experimenting with both higher (greater than 2) and lower
curves (between 1 and 2). I did not succeed in acquiring anything of
When using mouse accel, the sensitivity will not become greater than this value.
highly on the mouse settings you use. With MouseAccelPower set greater than 2 using senscap becomes important as the
sensitivity can skyrocket.
Determines how many duplicate packets you send to the server to avoid packet loss.
Appears to make very little difference. I posted a thread about it here:
a value of 0 is recommended if you have a clean connection, assuming
that 0 is accepted by the code. Using 0 is a placebo risk.
tests were run by Flashsoul and myself using wireshark. No extra
packets were sent regardless of the packetdup value. Some still report
a clear change in bandwidth usage using different values, so perhaps
its mechanism is less obvious than sending more, or less packets.
The time for player interpolation, values range from -20 to 0.
idea is to use different timenudge values for different weapons. For example using -9 for most weapons, and 0 for the LG/RG.
As I understand it timenudge sets the time
allowed for interpolation (adding images between two points for
smoothness). At -20 this time is low or none resulting in other players
appearing choppier while being displayed sooner. I also suspect that
lower values of timenudge are truer to the player's actual position as
opposed to a predicted one, although it's very difficult to know for
The lower framerate can make prediction more difficult.
Just imagine trying to catch a baseball that you can only see at 0.5
FPS, vs. one that you can see at 120 fps. At 0.5 FPS its trajectory
would look choppy and unpredictable.
Now imagine that the
smooth 120 fps baseball came at a price of a large latency, say 500 ms.
It would also be harder to predict, but not as difficult as in the
previous example because you could guess where it was in the future
based on its easily seen trajectory in the past, just get ready to
catch it earlier than you would normally.
None of the timenudge
values are this extreme, but since quake is so fast and things occur in
tens of milliseconds, being 20 ms off on a shot can mean the difference
between a hit and a miss.
As for what to use I really can't say. I know players who have excellent aim with -20, and others who have excellent aim with 0.
me personally using -20 ends up throwing off my aim since enemies
appear less smooth. I eventually settled on using -9 as it is between
the two 'extremes'. I probably had some convoluded mathematical
reason for using -9 instead of -10, but I cannot recall anymore what it
was, and it's very likely placebo anyways.
Everyone's brain works a little differently when it comes to hand eye coordination/prediction so use what works for you.
Color of the rail beam/core. <1-26>
preference. I will say though that color 17 for both makes for a blue
rail that stands out very little if that's something you'd like.
Color of rail disc/swirl effect. <1-26>
Use sleep frames to reduce CPU usage.
Description from the changelog:
cvar to disable idle sleep, to prevent FPS issues that may be caused by
low resolution timers in Windows XP or on-demand CPU scaling. Setting
com_idleSleep to 0 will restore the previous behavior of using up an
entire CPU to wait until the next frame. Unless disabling com_idleSleep
has a direct effect, it is highly recommended that com_idleSleep is
If you are having trouble
reaching your desired framerate, you might try com_IdleSleep 0. I
personally get 200 fps if I set maxfps 250 with com_idleSleep 1, I have
to change it to 0 to get the full 250.
Maximum rendered frames per second.
The default of 125 is absolutely fine, as is the maximum of 250.
integer values of 1000/x are taken, to a max of 125 and a minimum of
30. Maxfps values are always rounded up, so if you input com_maxfps
112, it will really be 125. If you put in 105 it will really be 111.
cg_drawFPS has a cap to prevent it from displaying a number that is
higher than com_maxFPS. So the values shown by drawFPS can be
incorrect, as for example com_maxfps 120 will show up as 120, even
though it is actually 125.
your computer can handle a stable 250 fps, it's definitely worth using.
Of course maxpackets maxes out at 125, so you'll be sending a packet
once every other frame. I find this to be a minor issue though, and
prefer the extra smoothness of 250. Of course you will need a display
capable of such a refresh to see this value, but even if you do not, it
is possible that using a greater maxfps reduces latency of part of the
process between input and frame draw.
set to 1 the console will have a background like snow on a television.
When set to 0 the console background will completely black, or
transparent as determined by con_opacity.
Personal preference, however I do find 0 easier to read.
This is how far down the console goes, the default value of 0.5 going half way down the screen.
have yet to find a need to change this. I suppose I am used to the
console going half way down since the earliest versions of quake 1.
When con_background is 0, this value determines how transparent/opaque the console is.
Determines the size of the console text, a range between 0.5 and 1 can be used.
I think the default of 0.5 is too small, so I use the maximum value, 1.
This value determines the speed at which the console comes down when "toggleconsole" is issued.
strongly recommend setting this to a very high value, such as 999 such
that the console comes down instantly. As someone who uses the console
often waiting for it to go up and down is a waste of time.
a time for each console entry. Time is given in M:ss:hhh where m is
minutes, s is seconds, and h are hundredths. Works only when a game is
I haven't had much use for this other than for some technical stuff. However it can be useful to give information
about when something happened, like that you died 1 second after
picking up the LG, or what the game time was when the mercy limit was
Unless you really want the information, I recommend leaving it at 0 for a less cluttered console.
Sets your player handicap.
With handicap 100, you can have a maximum of 200 health and 200 armor, which will tick down to 100. Shots do normal damage.
handicap 50, you have a maximum of 100 health and 100 armor, which will
tick down to 50. If you already have 100 armor, you will be unable to
pick up more armor, until it ticks down to at least 99. Shots will do
half of their damage.
I usually only use this in the following circumstances:
practicing LG with a friend, on for example hellsgate. Using a value
like handicap 75 prevents the other player from dying so quickly and so
more practice time is available. Setting it much lower than this makes
it so that players run out of ammo before anyone has died. If both
players lg at rather low accuracies they may find that a higher value
* When playing in say a Clan Arena game with much
lower skilled friends, I have set up to handicap 50. The effect is very
powerful and can make it extremely difficult to get good scores.
the 'pushback' of weapons is tied to damage, so if you set handicap 50
your LG for example will have less of a pushback and so can render LG
practice with it unrealistic to normal gameplay.
The method that Quake Live will use for mouse input.
-1 - Windows cursor input, subject to cursor ballistics
0 - No mouse input
1 - Dinput (direct input)
2 - WM_INPUT (raw)
most recommended value is 2. Some like the slightly different feel of
dinput. I would only use -1 if you've made sure that the windows cursor
ballistics haven't added any unwanted acceleration or other such
enabled the game will not "grab" the mouse, that is to say that it will
not confine the mouse pointer to the center of the screen.
A known bug sometimes
occurs where it is not reset back to 0, which causes the sensitivity to
increase 100 fold and fixes the players view towards looking at the
ground. Setting in_nograb back to 0 usually fixes the problem.
Appears not to require an in_restart after a change in its value.
Leave this at 0.
This changes the units used by sensitivity and the cl_MouseAccel formula to more familiar ones.
There are a couple requirements:
1. That m_cpi is set to the CPI value of the mouse.
In order to set m_cpi correctly, it should take into account any
driver-level sensitivity setting that affects the game. For example,
you have a 1000cpi mouse with a driver setting of x0.6 - you would set
m_cpi to 600, not 1000. Many driver-level settings do not affect the
game when in_mouse is 2. If not sure a quick test should clear things
2. That m_yaw is set to 0.022
After that, sensitivity
changes from a dimensionless multiplier, to degrees per centimeter, and
cl_MouseAccelOffset changes from counts per millisecond to centimeters
In order to convert your existing sens and accel
settings to the new scheme with m_cpi, there are some existing
calculators out there that will do the conversion. If you want to do
this manually, you can use the following formula for conversion from
old to new.
new_sens = old_sens * (old_yaw * m_cpi / 2.54)
new_sensCap = old_sensCap * (old_yaw * m_cpi / 2.54)
new_accel = old_accel * (old_yaw * (m_cpi/2.54)^2 ) / 1000
new_pitch = old_pitch * (0.022 / old_yaw)
new_yaw = 0.022
nice feature of this is that when changing the mouse CPI, the only
value you have to change is m_cpi. So if you were using a 400 CPI mouse
and had all your m_cpi values set, then switched to a mouse with 800
CPI, you wouldn't have to adjust your sensitivity any. Just set m_cpi
to 800 and you're all done.
preference. I have however found that a lot of mice do not seem to have
the exact CPI value stated which throws off the calculations when
trying to convert from m_cpi 0 to m_cpi >0.
Values >0 turn on mouse interpolation which makes mouse movement smoother. Values range from 0 to 33.
recommend m_filter 0. This is because interpolation adds frames
in-between counts, and these wouldn't normally be shown as they aren't
true to the actual counts that came in. It also adds a tiny bit of
latency, which is negligible at values like 1 but becomes significant
at values like 8+. It may also add what feels like positive
acceleration, albeit this would be extremely tiny.
adore the feeling m_filter 1 gives them and swear by it. Even top
players have used it with great success. It's the kind of cvar that
technically should be bad, but in practice the issue is not so simple.
So you can give 1 a try to see if you like it. However I cannot
recommend using >0.
vertical mouse sensitivity. When m_cpi = 0, this is in degrees per
mouse count but is multiplied by sensitivity to produce the final x
Highly personal preference, however here are some ideas:
m_yaw at 0.022, and use m_pitch 0.022 as well. That way the horizontal
sensitivity remains identical to the vertical sensitivity for a
consistent feel on both axis.
Increase m_pitch somewhat such
that it is higher than m_yaw, to reflect the notion that it is more
difficult to move the mouse up and down than it is side to side. This
makes rocket jumps easier, turning while aiming downwards easier, and
makes the horizontal sensitivity feel less sensitive in a way that may
Decrease m_pitch somewhat, such that it is
lower than m_yaw. This will make it less likely that 180s result in
some unwanted pitch movement. Most of the precision mouse motion needed
appears to be in the horizontal movement, whereas the pitch is needed
just to set up. For example if an enemy is on a high ledge and you wish
to lg him, you set the pitch position so that the crosshair is level to
him, then use the horizontal mouse motion to do the aiming. The pitch
is no longer needed, and much of the game is this way.
what works for you.
horizontal mouse sensitivity. When m_cpi = 0, this is in degrees per
mouse count but is multiplied by sensitivity to produce the final x
As a rule of thumb I
try to get by without ever changing this value as it makes it easier to
read other people's configs and get an idea of what sensitivity they
are using if I myself am using 0.022 yaw.
minimum number of degrees the quake guy can turn is 360/65536 or
roughly 0.005493164 degrees. This is about 1/4 of 0.022.
Input algorithm looks like this:
dy = M (B + (A(v-c))^(P-1)) dx
dx is counts, dy is degrees. M is m_yaw.
increasing m_yaw increases both the base sensitivity _and_ the accel,
as they are multiplied by it. So doubling m_yaw doubles the base
sensitivity and the accel.
Also it should be noted that cl_MouseSensCap is ignored when cl_MouseAccel is 0.
Using accel 0 bypasses this input algorithm and appears to use something like this:
dy = M (B) dx
So that m_yaw * base sens = degrees per count. (dy/dx = M(B))
The same technical stuff that applies to m_yaw also applies to m_pitch.
Sets your player model.
important difference between models is the sounds they make, since most
players force models and won't see which model you have selected.
Ideally you want sounds that are quiet as not to obscure important
Ranger, Bitterman, Anarki and Xaero are all fairly quiet.
Doom, Bones, and Biker are ok too but are slightly louder.
Crash and Sarge are louder still, but remain popular.
Razor has nice jumping sounds, bad hit sounds.
is somewhere in-between. Sounds aren't great, but not bad either. One
nice thing is that her sounds are always short in duration.
Uriel is also in-between. The sounds are quieter than Slash's, however last for a longer duration.
while her jump sound and high health hit sound is fairly benign, her
lower health hit sounds are quite loud. Mynx sounds almost the exact
Lucy is similar to Janet in this regard, but worse. Jump
sound fine, hit sounds aren't particularly loud but they are invasive
and disturbing imo.
Klesk is also in the same boat, but worse
still. The jump sounds are fine, however all the hit sounds are
terrible. Arguably worse than Janets/Lucy.
Grunt is noisy, and it sounds like he's snoring or snarling with every jump.
Hunter is rather noisy, and terrible jump sound "oooah oooah oooah".
James is loud, and his jumping sound sounds like a robot is choking.
is certainly loud. He makes a great enemy model since his sounds are
fairly distinct. There is some bent appeal to using him as a player
model in addition to an enemy model since then you make the same sounds
as your opponent, and if your opponent is using enemy model keel you
can get an idea of what they hear.
TankJR is loud as well. The hit sounds are less distinct than keel imo.
Major is loud is unnerving. Same with Sorlag.
Orbb is the worst sound wise. High pitched shrieking for every action.
This is the cvar the client uses to enter password protected servers.
Quake Live prompts you for the password when connecting to a password
protected server from the website so you usually don't have to mess
with this cvar.
the bloom threshold when r_enableBloom 1 and r_enablePostProcess 1. The
lower the threshold, the more bloom drawn. <0-1>
value of 1 simply turns bloom off. A value of 0.25 as the default
wasn't a bad choice as it enables you to see all the bloom effects just
fine. Using very low values causes bloom to simply take over the screen
in an effect that looks like every near death experience ever portrayed
The bloom menu can be found under
game settings --> advanced --> post process. It features built-in
presets where it says "Bloom Settings". These are quite useful for
exploring the features of bloom. The "selective greyscale" option is
quite interesting. I personally needed to turn down the sceneIntensity
for it to be useable though.
the bloom intensity when r_enableBloom 1 and r_enablePostProcess 1. The
higher the value, the more intensive and bright the bloom effect will
Either the default, or a
value that is not much higher than the default works. High values cause
the bloom "spheres" to get totally out of hand to the point that it
feels like looking at a brightly lit christmas tree through a very
foggy window. Using zero simply turns off blooms completely.
Sets the number of rendering passes for bloom effect.
0 - off
1 - one pass
2 - two passes
I have tested bloom I have always needed to set this to 2. Otherwise
the effect is too subtle. I would consider using 1 if I was to use
bloom on a regular basis however.
the degree of color saturation applied to the bloom effect when
r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the
more colorful the bloom effect will appear to be. <0-10>
personal preferency. When set to its maximum blooms will be very
colorful, and for example the green keel/bright model is enveloped in a
very bright green halo. When it's 0 keel's "jacket" glows white as if
it were made of white LEDs.
Probably a value somewhere between the two, erring on the saturated side is best as it takes
advantage of bloom's ability to make player's and objects stand out
while not making the contrast so high as to be hard on the eyes.
the intensity of brightness applied to the non-bloomed world when
r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the
brighter the non-bloomed world will appear to be. <0-10>
greater than 1 tend to cause walls that are as bright as the sun.
Unlike r_contrast (see below) there are no dark surfaces at all.
less than 1 are more interesting. While the default is fine, a value of
0.5 can offset the brightening effect of colorcorrect. That and r_gamma
the degree of color saturation applied to the non-bloomed world when
r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the
more colorful the non-bloomed world will appear to be. <0-10>
have no problem with the default. Values greater than 1 do exactly what
the saturation button does on a television. Turns the colors up to the
point that they look downright weird.
As with sceneIntensity,
lowering the value has much more interesting results. A setting of 0
causes a world rendered in grey scale. Yet explosions, the LG beam,
players and some objects retain their color. So one setup that is
geared towards visibility of important objects such as weapons fire and
player models could try using 0 and cranking up the settings for the
When r_enablePostProcess is set to 1, this controls the contrast.
A setting of 0.5 makes the screen appear as if it has a grey haze on it.
A setting of 2 gives everything a very bright and colorful look in an unpleasant way. Colors
become very sharp and hard on the eyes.
A setting of 10 renders everything bright orange, bright white, and dark black. Dark surfaces
appear as sun spots on the surface of the sun. Good for a laugh.
recommend leaving this cvar at default. The only thing that can be
gained from changing it in my opinion is using a value less than 1 such
as 0.5, which makes the rocket explosions appear much more transparent.
It comes at a terrible cost of making the rest of the game difficult to
The height in pixels when r_mode is set to -1.
Leave at default unless you are setting a custom resolution.
The width in pixels when r_mode is set to -1.
Leave at default unless you are setting a custom resolution.
Monitor refresh rate (in Hertz), useful for CRT monitors.
This depends on the display you have. First, try to get away with using the default of 0, which should use
whichever value you have set in windows. However when you load the
game, check your display's OSD to make sure it is using the desired
value, if not you may have to set it manually. This is made more likely
if you are not using your display's native resolution to play the game.
you are using a CRT, you may have to try different values near your
target value to get the desired effect. I recall that my CRT was set to
154 Hz, but Quake Live would only load at 154 Hz if I set
displayRefresh to 150. Values it didn't 'like' would set the refresh
rate to 60 Hz. So it may take some fiddling to get Quake Live to load
at the desired refresh rate, and the older your hardware the more
finnicky it is likely to be.
Dynamic Lights. (eg: rockets emitting light onto nearby scenery)
In general I
recommend using 0 as the lights can be very distracting, especially in
up close rocket battles. However I can see a lot of reasoning behind
using 1 as the lights could give information away about an enemy
position that wouldn't be available when using 0.
powerups can glow, and flags can glow which means they could sometimes
be seen with dynamiclight 1 when they could not with dynamiclight 0.
It should also be noted that there are cases when this glow can be seen through walls.
for duel/CA/Instagib I'd definitely recommend 0, but for CTF/TDM/FFA
you might find that 1 gives you important information at the cost of
some screen clutter.
Enables light bloom effects when r_enablePostProcess 1.
personally recommend against using bloom, so if you have postprocess
set to 1 then set r_enablebloom to 0. When bloom is enabled
anti-aliasing doesn't work.
With some tinkering there are some interesting bloom setups available
but in general I find its effects distracting.
color correction when r_enablePostProcess 1. At the time of writing
this seems to only activate when chosen from the menu. Even
when colorcorrectactive shows 1 it still isn't active.
I mess with bloom I always have to turn this option off otherwise the
display becomes too bright and colors become washed out.
Enable post processing. A setting of 1 is needed for bloom and r_contrast, but renders r_intensity ineffectual.
you're low on FPS, setting this to 0 can help tremendously. Otherwise
this is one of the main cvars that affects brightness and the overall
look of the game, and so this is falls under personal preference.
When set to 1, the skybox will be replaced with a solid color.
personal preference. I personally have a toggle set, so that on maps
that have a particularly bright sky such as Thunderstruck of Sacellum,
or even Almost Lost I can turn it off, but leave it on for other maps.
It's important to note that with r_fastSky 1, you cannot see through portals.
When r_fastSky is set to 1, the sky will be this color described in hex color code. The default is black.
leave this at black, however I did try some other values and thought
the effect was quite nice. If I used fastsky all the time I would
seriously consider setting a value other than black.
Note: The hex color code used for this is only 6 characters which is different from the 8 character code used by
team/enemy colors. If you add the extra characters you will get unpredictable effects.
Renders all textures on the map at full brightness when set to 1.
default value of 0 is absolutely fine. With 1 and vertexlight 1, the
map becomes shockingly bright, even with mapoverBrightBits 1 although I
thought this was at least playable, but very, very strange looking. I
think it boils down to that if you use vertexlight 0 it has very little
effect, but with vertexlight 1 it takes off like a wild animal. On some
maps it will be nearly impossible to get a playable setup with vertexlight 1.
0 - Windowed
1 - Fullscreen
strongly recommend playing in fullscreen. However fullscreen is not
default in case there are problems, so this cvar is a must for every
Amount of image luminance applied to the in-game display. The higher the number, the stronger luminance present.
This is one of the main cvars for controlling brightness. I find that there are two main approaches to brightness:
High r_mapoverBrightBits, low gamma such as 1 (default).
Low r_mapoverBrightBits such as 1, and high r_gamma, such as 1.75. Perhaps r_overbrightbits
can also be lowered to 0 in this case.
The r_gamma default of 1, with the default mapoverBrightBits of 2 tends to be a bit too dark.
A nice quick fix is just r_gamma 1.3 or so.
Setting this to 1 enables the ignoring of hardware gamma settings.
usually has the effect of simply making everything dark and having to
crank up the other brightness settings to compensate. Nonetheless the
results might be desirable, and is largely personal preference similar
circumstances I see no reason to use 1. I can see that if you play on
different systems often, that it may be useful to use 1 in an effort to
secure a more consistent brightness level across systems. I think in
practice though this isn't really so realistic as the display is more
likely to have a larger effect on brightness than the driver settings,
which are usually at default. I wouldn't be surprised if the default
brightness of AMD drivers vs. Nvidia drivers is the same.
the level of brightness added to textures and model skins. Doesn't seem
to work when r_enablepostprocess is set to 1.
r_enablePostProcess is 0 this cranks up the brightness in a very
unpleasant way. Colors will quickly wash out. It basically turns all
normal map lights into white hot nuclear reactions, and/or each surface
seems to reflect light more brightly than it normally would such as
that a little bit of light turns them into the sun's corona. Values
lower than 1 are not allowed. I recommend leaving it at its default of 1.
When set to 1 it enables the light data lighting model. Is only effectual when r_vertexlight is set to 0.
to r_fullbright, this is kind of an "extreme" setting. It's tricky to
get it to where the maps aren't simply too bright. It takes all the
textures of the walls, rendering them in greys and bright whites. I
find it easier to get a playable game with it than with vertex +
fullbright. Perhaps it is comparable to drawflat in other games. Maybe
it is better used only for mappers who wish to see their light sources
more clearly. I recommend leaving it at 0 unless you're willing to
tinker a lot and suffer through some maps being too bright.
how other player models reduce in complexity by distance. The values
range from -2 to 2. When set to 2, the enemy model will remain at
lowest detail in all instances. When set to -2 it will remain at
highest detail. When set to 0 it will oscillate between the two
depending on the distance.
Also effects the appearance of some weapons when the gun is shown (drawgun 1 or 2 with sufficient gunXYZ values).
I recommend using -2 with enemymodel keel so that he will remain at highest detail.
who have the gun shown dislike the high detail appearance of the gun
models and so use lodbias 2. The RL is perhaps the most significant of
these. It seems like a minor issue to me but may not be for someone
lodbias 2 is recommended for TankJR since he better fits the hit cylinder this way.
Level of detail scale adjustment.
A setting of 0 will keep the player model at lowest detail until they are very close, and then use medium detail.
A setting of 50 (maximum) will keep the player model at highest detail until they are very far away.
A setting of 10 is between the above two.
Setting r_lodbias to -2 kept the player at highest detail more often than r_lodbias 0 and r_lodscale 50 in a test though.
recommend setting r_lodbias to -2 or 2 and forgetting about r_lodscale
(leave at default).That way the model's appearance stays as consistent
Ambient lighting and radiance of the map. Along with r_gamma this is one of the "main" brightness cvars.
Behaves differently depending on r_vertexLight, r_enablePostProcess, and r_ignoreHWgamma.
There are many values that work great, and they depend on a variety of factors.
Here are some example brightness setups:
a laugh you can try r_mapoverBrightBits 0, which basically "turns out
the lights". Or, 20 which causes the walls to be covered in psychedelic
colors. 25 makes everything mostly red and black, as if you're in a
futuristic palace of the devil.
you to cap the brightness of surfaces brightened by r_mapOverbrightBits
(Most useful when using high values of r_mapOverBrightBits; vid_restart
required after a value change).
Values range from 0 to 255.
you use high mapoverbrightbits like 10, try a value of maybe 125 or 150
to tone down the bright white textures on the map. Players managed for
over a decade to play q3 (and QL for a couple of years) without this
cvar though so it's not really needed but sure is great to have.
Sets the resolution the game will use when full screen. The values are as follows:
Mode -2: Use whichever resolution is currently in use, ie. what the desktop is using.
Mode -1: Use the resolution specified by r_customwidth and r_customheight
Mode 0: 320x240
Mode 1: 400x300
Mode 2: 512x384
Mode 3: 640x360
Mode 4: 640x400
Mode 5: 640x480
Mode 6: 800x450
Mode 7: 852x480
Mode 8: 800x500
Mode 9: 800x600
Mode 10: 1024x640
Mode 11: 1024x576
Mode 12: 1024x768
Mode 13: 1152x864
Mode 14: 1280x720
Mode 15: 1280x768
Mode 16: 1280x800
Mode 17: 1280x1024
Mode 18: 1440x900
Mode 19: 1600x900
Mode 20: 1600x1000
Mode 21: 1680x1050
Mode 22: 1600x1200
Mode 23: 1920x1080
Mode 24: 1920x1200
Mode 25: 1920x1440
Mode 26: 2048x1536
Mode 27: 2560x1600
Very personal preference, and not a simple issue. Will certainly depend a lot on what display is being used.
of all, you should try to use a resolution that you can get 125 fps on,
and also one that your display can run at at least 120 Hz. If not, get
as close as you can.
For CRT users this almost invariably means
using a resolution at or under 1280x1024.
Newer gaming displays might support 1080p or 4k at 360 Hz or greater. If you can get 125 fps at those
resolutions and like the effect, go for it.
Ambient lighting applied to in-game entities or objects. The range is from 0 to 4.
I think that most setups will leave this at 1. Other values have more tempremental effects.
are two interesting options, one is to use r_overBrightBits 0, and a
high gamma. It tends to make small crosshairs look a little dampened
but with an adiquately sized crosshair it can look great. Yellows and
greens stand out while the map remains predominantely dull colors. It
is very easy on the eyes to play this way.
Vertexlight off +
overbrightbits 0 makes for rocket explosions that are slightly more
transparent than normal. With overbrightbits 0, r_mapoverbrightBits and
r_enablePostprocess seem to have very little effect if any.
interesting, albeit extreme option is to use overbrightbits 2. This
covers the display in a kind of bright grey haze, however rocket
explosions become the most transparent that I've seen them. Plasma
balls are slightly transparent and smaller tha normal, and even the LG
appears thinner than normal. These benefits come at hefty cost though
since the grey haze makes some items such as armor shards very hard to
see. Player models are ok.
For example: r_overbrightbits 2,
r_mapoverBrightbits 2, r_gamma 1.3, r_vertexLight 1, and
r_enablePostprocess 0 make the transparent effect on rocket explosions
very strong. Lowering r_gamma gives the map a lot more contrast while
maintaining much of the transparencies.
and/or r_mapoverBrightBits has the effect of amplifying the "grey
haze", although it gets rid of the really dark areas.
I think the effect is too strong so I recommend sticking to either
r_overbrightbits 1 or 0. I think the majority of players leave it at 1
and only change r_gamma and/or r_mapoverBrightbits, and probably their
display's brightness as well. This works pretty well but it is
interesting to consider these other more obscure options.
color average/level of detail. Lower values will manipulate and blend
the colors of themap textures. Textures at the highest value, ‘10’
appear nearly as solid colors. A vid_restart or map load is required
before changes will come into affect.
personal preference. A value of 5 is popular as a happy medium. Setting
it to 0 results in high quality, however a level that is complicated by
quality textures may be visually distracting. Setting it to 10 solves
this problem, however the
textures become so simple that depth
perception may be difficult. Still many great players use either 0 or
10, and just about any value in-between.
Rail trail core effect diameter (in pixels). The color is controlled by color1.
Very personal preference. One
person told me that using 1 for corewidth helped their rail aim, others
like the really thick look of segmentlength 1. Some have had
all the r_rail settings at default for a long time and don't have any
issue with them.
Rail trail section length (in pixels). The color is controlled by color2.
Does not effect the 'spiral' when using cg_railstyle 2.
are largely personal preference. There are some interesting quirks
though. If you set segmentlength to 1 or 0.5 you can get a thick
looking rail beam. You can even choose to hide the core with corewidth
If you're on a machine that is very fast, but want to help
diagnose FPS problems for a friend, yet are having trouble doing
anything that turns down your framerate, just set cg_railtrailtime to a
very high number such that the beams stay. Then set segmentlength to
maybe 0.5, and shoot a bunch of rails. When in the field of rails your
FPS will be greatly taxed. I used this method once when I was trying to
get the FPS to under 1 frame per second so I could see if the frames
were being drawn or just popped onto the screen (they were). Increasing
railwidth should amplify this effect still further.
Diameter of the segments in pixels.
preference. If you like the effect of segmentlength 0.5 or 1, and turn
off corewidth you may like to adjust the width of the beam with this
Enables simple MIP mapping, boosts performance.
one is a tough call. Certainly the default value of 1 is fine. The
question is whether or not there is something to be gained from using
0. With 0 the walls look smoother, and certain far away textures seem
better preserved. Some say the player models tend to look less sharp.
The effect is very subtle and comparing them side by side in a photo
editor I definitely see a difference but it isn't a big one. I really
cannot tell which is better so I'll have to call this one personal
preference for now.
set to 1, going through a teleporter makes the screen go entirely white
for a split second. It is no longer than this unless the player is
undergoing much lag.
To see what this
effect actually looks like, try devmap verticalvengeance duel and set
timescale to 0.25 and go through the teleporter. Events will be taking
place slow enough for you to see the flash.
teleporterFlash 0 the flash is not white, but black. Since this happens
so quickly in the actual game it probably doesn't matter what value
it's set to. Just because I thought it was neat to make the game
potentially easier on my eyes by adjusting something that I'm not
consciously aware of I set this to 0 though.
rather tenuous reason to use 0 is that if you're playing in the same
room as your opponents, and the room happens to be dark,
teleporterflash 1 will momentarily "flash" which could inform your
opponents that you have gone through a teleporter. Keep in mind that
the corner of the eye can better pick up these subtle changes. (Thanks
aeoL for this idea)
With this idea in mind, it could be possible
to make a bind that produces a bright flash, such as : "r_gamma 10 ;
wait ; r_gamma 1" in order to be really devious and fake a teleport
flash. (Thanks ybl for mentioning this).
Sets texture filter.
X is the method for rendering textures, and Y is the method used to mip them.
A setting of GL_X, will render all textures with method X, and no mip mapping will be done.
The options for X and Y are, NEAREST and LINEAR.
So the following combinations are possible:
= The default setting. It shows up close textures at normal quality,
and far away textures are only slightly mipped to prevent moire
GL_LINEAR_MIPMAP_NEAREST = Up close textures are
at normal quality, far away textures are mipped much more than with
GL_LINEAR = All textures are at normal quality
and no mipping is done for far away textures.This causes plenty of
annoying moire patterns. However, if you use a higher resolution, using this setting can result in a thinner tip to the LG.
GL_NEAREST = Gives everything an old
school grainy look, almost exactly like d_mipcap 0 in quake1. This is
with r_picmip 0, if r_picmip is 5 for example, it looks more like
d_mipcap 3. It currently has a bug with crosshairs below a certain size
where it will render them black. Some people like the look of
gl_nearest or gl_nearest_mipmap_nearest, and they are nice options to
GL_NEAREST_MIPMAP_NEAREST = Similar to
gl_linear_mipmap_linear, in that it mips just enough to prevent the
moire patterning. It also doesn't suffer the small crosshair bug that
GL_NEAREST_MIPMAP_LINEAR = Up close textures
are nearest, far away textures are mipped with linear. Looks almost
identical to gl_nearest_mipmap_nearest.
I recommend using the default. Although it's fun to try gl_nearest_mipmap_nearest.
set to 1 it enables vertex lighting, 0 is lightmap.
actually recommend using 1. There's something about the way the
textures look that alters the way the game feels. It feels slower in a
way that seems more conducive to aiming. It tends to be brighter than
lightmap with less image quality. Pairing it with r_fullbright 1 has
If you're low on FPS, using 1 can help tremendously.
Sets the resolution of the game when windowed (as opposed to fullscreen). Uses the same mode list as r_mode.
you normally play in fullscreen, use a lower resolution than your
screen resolution, so that when you go windowed you can see other
applications that you may wish to use.
nice use for this is if you wish to play at lower resolutions despite
having a newer display that features a high resolution, as you don't
have to worry about scaling or changes in refresh rate by simply
playing in windowed. It also allows for quite a range of aspect ratios.
I even tried a 1:1 aspect and it loaded without issue.
Controls packets so that your downstream connection bandwidth does not get saturated. (Max bytes per second)
recommend leaving this at its default value of 25000. However with some
testing it appears that the rate cvar does very little and does not
make the difference for incoming data rates that it indicates, so it
may make little or no difference what value is used. Leaving it at maximum puts
you on the safe side though.
sound effects. Things like wind blowing, rain falling, humming of
machines, torches burning. An s_restart, vid_restart, map change or
reload of the game is required for the change to take effect.
recommend setting this to 0. There is one downside however, and that's
that with 0 set you cannot hear proximity mines beeping. I personally
find this to be a minor issue compared to the substantial reduction in
ambient noise, but it's something to be aware of.
Controls the volume of the announcer.
Personal preference, however since the announcer plays often, what its volume should be is something worth considering imo.
Volume of Quake Live's background music.
I strongly recommend setting this to 0 as it is unneeded and distracting.
Controls the volume of the in-game voice chat.
preference. During team games it may be expected of you to at least
listen to voice chats from teammates, and they may be giving out
valuable information there. Otherwise whether you wish to listen to the
often times unpredictable voice chats of random players on a public
server is completely up to you. It might be a good idea to at least use
a value that is lower than in-game sounds to prevent voice chats from
drowning out important game information, but this also depends on the
volume of the voices present.
The game's volume. Highly dependent on the computer, speakers/headphones, the operating system's audio settings, and the person.
Not too quiet, not too loud. All things in moderation.
say that if you keep your volume low it forces your brain to
concentrate more on the visual aspect of the game and in turn can
Others say having it up slightly louder helps them concentrate.
Obviously to prevent damage to your hearing you should not set this value too high.
mouse sensitivity, which is then multiplied by m_yaw and m_pitch to
determine the final amount of degrees to turn per mouse count.
This is about as personal preference as it gets.
idea is to get an empty map such that you can find two easy points of
reference that are directly in front and directly behind you. Then make
a comfortable motion with the mouse to the right. Usually my
hand/wrist/arm wants to stop at a certain spot. Adjust your sensitivity
so that at that spot you make a 180 degree turn. Do the same for the
left, which will usually yield a slightly different number. Use a value
in-between the two in an attempt to satisfy the needs of each direction.
For me this number was ~6.25 on a 400 cpi mouse (roughly 16.6 cm/360).
wacky idea is to set your sensitivity in such a way that one mouse
count changes the screen by one center pixel. To do that use this
S = (360 /M) / ((360 / F) * H)
M = m_yaw
F = cg_fov
H = Horizontal resolution in pixels (for example 800 for 800x600)
S = sensitivity
Unfortunately at high CPI values, the sensitivity goes through the roof at lower resolutions.
These are just silly ideas anyways. Nothing beats the old fashioned play and adjust.
timedemo = "0"
set to 1, the next demo played will be run as fast as it can go, and
when it is finished an FPS value is reported. If using the same demo
across different systems, this can be used as a performance benchmark.
this at 0 unless you are doing benchmarking. Otherwise you may be
confused as to why your demos seem to be stuck on fast forward playback
thing you can do is in tandem with a utility like fraps, start a
practice game with cheats enabled (devmap), and set timedemo to 1. It
will then render as fast as it possibly can, and you will be able to
see what fps values can actually be rendered on your hardware.
timescale = "1"
speed of game events. This can only be adjusted on localhost or during
demo playback. Use of this cvar for demos is no longer necessary since
cg_DrawDemoHud was added, but it still has other uses..
For demos, setting
values greater than 1 acts like a fast forward button, and values lower
than 1 are like slow-mo. A value of 0 does not result in a pause during
demo playback, and setting it to 0 on localhost or when on the
disconnection screen causes the game to freeze. The closest thing to
pause is timescale 0.000000000001 or a similar value.
keys being pressed during demo playback ends the demo, so it is common
to bind keys for use during demo playback elsewhere. For example:
bind pgdn "timescale 1" // Normal
bind pgup "timescale 10" // Fast forward
bind ins "timescale 0.5" // Half speed
bind del "timescale 0.25" // Quarter speed
Use of cg_DrawDemoHud should eliminate the need for timescale binds, however you may wish to still bind +acc and +scores.
tell people all the time who wish to improve their Lightning Gun
accuracy to lightning battle with a friend, and record the game. Then
play back the demo at timescale 0.25. You'd be surprised what you can
learn from this.
Since timescale also works on localhost (devmap), another idea if you're really bored is to put
on some tunes, add some bots on say Vertical Vengeance or Eye to Eye in
a devmap FFA or CA game. Do a give all ; god, set timescale to 10 and
run around shooting all the different weapons. Very awesome if you
haven't tried it before. Do not do this if you are prone to seizures :-)
can also set a low timescale value, record a game against a bot, and
then play it back at normal speed. This will result in god-like aim,
however I recommend against doing this often as it can make the normal
game seem very fast and difficult to aim in. I have also noticed a
strange phenomenon when doing this, in that when bots are being hit at
a very high accuracy, for example with 95% lightning gun they can have
dodging anomalies, appearing to "give up" and stand more or less still.
winkey_disable = "0"
When set to 1 the windows key will be ignored by the OS when the game is running.
I recommend setting this to 1 to prevent accidental pressing of the windows key at a critical moment in the game.
alias makes up a command of the name you specify, and it does what you specified it to do.
alias <aliasname> "[commands]"
For example: alias greet "say hello there"
Creates a command called "greet", and when activated invokes the say command for the words "hello there".
It can be activated with the console:
player: hello there
It can also be activated when it is bound to a key:
\bind h "greet"
Now pressing h will activate the alias "greet".
More than one command can be issued by a single alias, just separate each instruction with a semicolon. For example:
alias greet2 "cg_chatbeep 0 ; say hello there"
This can be bound to a key in exactly the same way as above.
especially important feature of alias is its ability to be bound to a
key for an on and off action by prefixing your aliasname with a + and -
respectively. For example:
alias +greeting "cg_chatbeep 0 ; say hello there"
alias -greeting "cg_chatbeep 1"
bind h "+greeting"
the 'h' key is held down, the alias for +greeting will be activated,
when it is released the alias -greeting will be activated.
is rare (if ever) that you would not want your -alias to undo the commands of
your +alias, and in the example here cg_chatbeep is temporarily changed
to 0 while the button is held down, and returned to 1 when the button
In the scenario of this alias:
alias +lgFire "sensitivity 2 ; +attack"
alias -lgFire "sensitivity 4 ; -attack"
sensitivity is changed to 2 when whichever button +lgFire is bound to
is pressed, as well as the attack command issued. When the button is
released the sensitivity is changed to 4 and the attack command is
a single alias takes a maximum of 255 characters. If for some reason
you need to use an alias larger than this, split it up into multiple
aliases. For example: alias blah0 "blah1 ; blah2" (Thanks andy17null for this info)
Assign an action to a key.
bind <key> "command/cvar1 ; command/cvar2 ; ...command/cvarN"
Multiple command/cvars can be added to a bind by separating them with a semicolon.
For example, bind g "weapon 3 ; cg_zoomfov 80 ; cl_timenudge -10"
that start with a + will be activated while the key is pressed down,
and deactivated when the key is released. For example bind mouse1
"+attack", +attack will continue to be issued while mouse1 is held down
and will not stop until mouse1 is released.
Some keys have special names, these are:
scroll Lock is "0x00"
aux1 - 17 (I assume these are for a game pad of some sort)
When in_joystick is 1:
Joy1 - 32
keys are identified with a scan code in hexadecimal. Quake uses
different keyboard scan codes than the OS, making it tricky to
determine what they are. For example, 0x97 is F7 for me, and scroll
Lock is 0x00. These are different for different keyboards. Probably
some experimenting will be required to be able to bind odd keys on your
of the keys appear to be ignored by QL. For example I could not get
print screen to work (I tried multiple hex codes), or the windows key (with winkey_disable 0 obviously),
or the menu key.
callvote <command> <variable>
Can also be abbreviated 'cv' for faster typing. Calls a vote for the players on the server to vote on. Some examples:
callvote kick annoyingtroll
callvote teamsize 2
callvote map FuriousHeights
Commands used in conjunction with callvote wiill autocomplete by hitting the Tab key.
Clears all the text from the console. I use this often.
Lists the game's commands.
You can also search for a command by typing cmdlist *searchstring.
Lists the vast majority of the game's cvars, their flags and their values.
can also search for a cvar by typing cvarlist *searchstring. Very very
useful when you cannot remember the full name of a cvar.
Plays a demo that's in home/baseq3/demos
rarely used as autorecorded demos usually have long names that are
difficult to remember. Instead the user interface allows one to browse their demos, under Statistics -> Replays.
Enters a map with cheats on. Extremely useful for testing things on localhost. I often do the following for example:
a practice game and enter the console, type devmap verticalvengeance
duel (I hit tab to auto-complete and save on keystrokes).
there I have a key bound to "give all ; god" which gives me all the
weapons and renders me invincible. Now I can run around the map and try
out all the weapons. If I want something to shoot at I will add a bot
by typing "addbot anarki 4". Since the bot is feeble against someone
who is invincible and with all the weapons, I exec a config with the following cvars:
This makes the bot as strong as possible, and gives it a lot of health resulting in long fight times.
from the current server and takes you back to the server browser.
carrying the flag in a CTF style game type, issuing this command
releases the flag. This can be extremely important as it enables you to
transfer the flag to a more stacked teammate to improve the chances of
this command drops the current powerup such as the quad, the
battlesuit, invisibility and regen. Useful for when you wish to
give your powerup to a better stacked teammate who may be able to rack
up more frags.
this command drops the current when in certain team based game types.
Very important to TDM as it enables you to give weapons to a teammate
that needs them.
a config file. The file itself must have the extension of .cfg or it
will not work. Files are assumed to be located in home/baseq3.
The .cfg part can be omitted and it will be assumed.
Config files can be exec'd in other directories within home/baseq3 by specifying them:
Will look in home/baseq3/backups/ for lorfabackup.cfg
the game in a duel, giving the player who entered it a loss and not a
quit. It is also available to the losing player in team gametypes, when
one player is left remaining.
Gives a specific item/weapon to the player in devmap (cheats enabled).
List of gives I know (the spaces are important):
give machine gun
give grenade launcher
give rocket launcher
give lightning gun
give plasma gun
give grappling hook
give prox launcher
give red armor
give yellow armor
give green armor
give quad damage
give battle suit
give mega health
give armor shard
give personal teleporter
give health (changes health to the maximum non-tick value allowed by handicap, which is 100 by
give shells (shotgun)
give cells (this actually the plasma ammo, even though this would be lg ammo in other games)
give lightning (ammo for the LG)
give slugs (railgun)
give ammo (gives 999 ammo for all weapons)
If anyone knows the rest of these let me know!
god mode on/off when in devmap (cheats enabled). Very useful for
testing things when you wish to play against a bot but don't want to be
I have a bind to "give all ; god" which lets me play with all the weapons in localhost.
Restarts mouse input. Required after a change to in_mouse, and can also be useful if the mouse input crashes for some reason.
Loads the hud.
useful for when testing different huds, as you can simply change
cg_hudFiles to the new hud, and then type in loadhud to load it. No
need to save the config and restart QL. Also saves time in making a
hud, as you can run windowed, make some changes to the hud file, and
then simply type in loadhud to see the effect of the changes.
Kills oneself. Commits suicide. Jisatsu. Självmord.
Incurs an extra 1 second spawn delay.
useful for race since you always spawn near the starting point. So when
you complete a run you can suicide and immediately go again.
was recently (August 2014) enabled on public servers, which quite
possibly introduces certain tactics based on the "teleporting" nature
of dying and spawning elsewhere.
a chat prompt, in which a message can be typed and upon pressing enter
will be seen by everyone on the server with the exception of certain
game types that prevent spectator chat being seen by players when a
game is in progress.
Enter a chat prompt; chats typed here will go to teammates only. Useful for team communication.
the players on the server and which number they are. Required for admin
actions on a spawned server which usually use the player's number to
identify them instead of their name, and their name may be difficult or even impossible to type out.
Exits the game. Other players will see "suchandsuch disconnected"
Also exits the game, however other players will see "suchandsuch ragequits" with the 'rage' part colored in red letters.
Sets the player status to ready. By default this is bound to F3.
from the server, and then automatically connect again. Useful if there was
a timeout due to lag. Instead of exiting the program and rejoining from
the website, a reconnect can be issued instead.
Starts recording a demo.
If no demoname is provided, a file name of demo0000 will be used. If demo0000 exists, demo0001 will be used instead.
Demo files are placed in home/baseq3/demos
Chats in messagemode1. Useful for chatting from the console, or for automatic binds.
Chats in messagemode2 which is team chat. Useful for creating team chat binds.
Takes a screenshot in .tga format. This is recommended with lower resolutions as the text shows up more clearly.
a screenshot in JPG format. Saves a lot of space at the cost of some
quality. Not recommended for low resolutions as the text can come out
slightly blurry and difficult to read.
Lists all the information about the server, including the infamous skillrating value. Sample output:
Server info settings:
QuakeLive 0.1.0.591 linux-i386 Jul 10 2012 16:56:49
is very similar to alias, except that it does not support + and -
commands, and it must be activated with an extra command called vstr
which tells the game to do the stuff in the specified set.
So for the "hello there" example given above for alias this could be done instead:
\set greet "say hello there"
player: hello there
It can also be bound to a key:
bind h "vstr greet"
It also supports multiple commands:
set greet2 "cg_chatbeep 0 ; say hello there"
a personal preference I choose to use set/vstr whenever possible as
opposed to alias because I trust it more.
set also assigns a value to an existing cvar, for example:
set sensitivity "5"
almost exactly like set, except that it is more likely to be stored in
the relevant config files. Recommended for use in config files for
robustness. So when making a config, instead of just typing sensitivity
"5", or set sensitivity "5", it is recommended that you use seta
practice mode, this transfers your current position to the position
given. It takes positions in the format of the position and orientation
numbers provided by "viewpos". See its entry below in this list.
A sample output of viewpos is:
(674 82 498) : -90
So to "teleport" there:
setviewpos 674 82 498 -90
Very useful for trick jump training as you can bind a key to a location for example:
bind [key] "setviewpos 674 82 498 -90"
practice your trick move from that position over and over again simply
hitting the key after each iteration to return the exact same spot.
Stop recording a demo.
Used to set team. The valid teams are:
These can be abbreviated with just their first letter:
Gives a person a message in-game that only they can see. Player must be on the server.
tell <playernumber> <message>
To get a player's number, type \players to see a list of who is on the server and what their numbers are.
This is a function that will switch a function between 1 and 0 by pressing a key.
bind pause "toggle r_fastsky"
pressing pause, if r_fastsky is set to 0, it will be changed to 1. If
it is 1 it will be changed to 0. Its new value will be echoed in the
console. Saves space in one's personal config since a toggle doesn't
have to be created manually with alias or set/vstr.
all aliases, or rather after this command is issued, typing them in
will say "alias suchandsuch not found". This is different from typing
in a command/cvar the game is unfamiliar with, as this will report
"command suchandsuch not found". So the game is still aware of their
existence, but prevents them from working.
This is usually found
after the bindings list in a config. To truly remove all aliases game
settings must be reset via the website (game settings --> reset
now this command is buggy, as it cancels out the use of aliases, but
does not allow them to be realiased under the same name. I don't
recommend keeping it in yourconfig.cfg.
all key bindings. Usually found at the beginning of a config to clear
all keys before binding them. I recommend using this only at the top of
a config and nowhere else.
Displays player coordinates in map, in the form of: (X Y Z) : Angle
useful for manual sensitivity testing, as it can tell you almost
exactly when you've made a full 180 or 360 rotation, which reduces the
margin of just eye-balling it. The last number is your orientation in
degrees relative to some point on the map, so a 360 degree turn should
land back at exactly this orientation.
Restarts the renderer. Required for many r_ cvars to take effect.
Used to issue a vote of yes or no. Normally vote yes is bound to F1 and vote no is bound to F2.
I personally changed it so that F1 remains vote yes, but vote no is F4 so that I do not accidentally hit the wrong vote key.
Executes the commands in a specified set. See the description of 'set' for more info.
vstr <cvarname that originated from set>
a gametic. There are two gametics per frame, so at 125 fps there are
250 gametics/sec. Useful to time commands precisely as the number of
waits can be specified by adding a number after the wait command. For
example, wait 1000 will wait 4 seconds at 125 fps. However while a wait
is in progress, no commands can be issued which means no moving or
shooting. This may have been done to prevent scripts that would time
Selects a specific weapon.Usage: weapon #
1 = gauntlet
2 = machine gun
3 = shotgun
4 = grenade launcher
5 = rocket launcher
6 = lightning gun
7 = railgun
8 = plasmagun
9 = BFG10K
10 = grappling hook
11 = nailgun
12 = proximity mine launcher
13 = chaingun
14 = heavy machine gun
the next weapon in the weapon cycle. Weapons without ammo, including
the gauntlet are skipped, even when cg_SwitchToEmpty is set to 1.
the previous weapon in the weapon cycle. Weapons without ammo,
including the gauntlet are skipped, even when cg_SwitchToEmpty is set
Writes a config with all the relevant cvars in it. Vital if an autoexec is present, because then the only way to save settings
is with: writeconfig autoexec
These activate when the key is pressed down, and deactivate when released. They are for use with the bind command.
Shows your weapon accuracies.
Different weapons have different accuracy values that are considered good. The vast majority of concern is given
the accuracy values of the lightning gun and the railgun. Excellent
accuracy values for these would be 40 % and 50 % respectively.
stronger the player the better their dodging tends to be, and so
accuracies are likely lower than normal against such players.
This term "+back" is also used to describe a very defensive style, for example:
"It was a very slow game with a low score, very +back".
item. Makes the "click" sound when there is no item to use. Bind to
mwheeldown or mwheelup (scroll wheel) to make a velcro sound. Warning: This can become a bad habit.
The taunt key. Do not use this ever.
The term "+forward" is also used to describe a very aggressive/offensive style. For example:
"All that guy does is rush and attack, never slows down, he is very +forward".
Crouches, or swims down.
While crouching the player will travel at 1/4th the speed of running, and half the speed of walking (80 ups).
No footstep sounds will be made while crouching, and also the hit cylinder will be slightly smaller which comes at the
cost of mobility.
Jumps, or swims up in the water.
Displays the scoreboard.
this key is held down no footstep sounds will be made by the player,
however will travel at roughly half the speed (161 ups vs. 320 ups).
The voice chat key, hold down to talk.
Zooms in when activated, zooms out when deactivated.
Muffin's console guide:
Worthless information about your worthless mouse:
Guide by Lorfa: firstname.lastname@example.org
Last Update: August 12, 2022