Lorfa's 263 (QL Console Guide)

Lorfa's 263
The only Quake Live cvars+commands you'll ever need to know!
Faq:
Q. There's already a console guide at http://www.regurge.at/ql/ , why make this

one?
A. There are ~1400 commands/cvars, this takes only the most important 193 cvars and
gives recommendations and often times extra info not included in the basic list. It
also includes explanations for the 70 most important commands sometimes with more
in-depth info.
This 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.
Q. I've decided that I trust your advice, however I'm very lazy, can you just
provide a config that uses all your recommendations?
A. Yes, however many cvars are personal preference, so you'll have to adjust those.
Here's a template I made:
http://pastebin.com/EQTVHbXR
Alternatively you can look at a verbose version of the same config with small notes
on each entry here:
http://pastebin.com/Z997JHps
Q. I bet your personal config is a horrendous tweaked out mess! What does it look
like?
Like this here: http://pastebin.com/rfwnEVn4
Lern2Cfg:
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:
Start 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
Then edit yourname.cfg and take out the defaults/ineffectual cvars and organize it
nice and neat. This works pretty well and is worth considering.
The 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:
http://pastebin.com/EQTVHbXR.
Alternatively you can look at a verbose version of the same config with small notes
explaining each cvar here:
http://pastebin.com/Z997JHps
Lern2CfgFiles:
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.
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 or by manually editing the files.
I recommend using this as it allows you to go hog wild with testing things and you
never have to remember all what was 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
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.
The file repconfig.cfg is uploaded to the website automatically and stored there,
and will be downloaded if you login from another machine. It does not contain a
complete set of variables which can have unpredictable effects, so I often clear
this out. There is only one way to clear this out to start with a completely
default setup from which to exec yourname.cfg, that is:
1. Delete (or move into a backup directory) qzconfig.cfg, repconfig.cfg, and

autoexec.cfg.
2. Login and click on "Settings" in the top right corner. Under the table of models
there is a button that says "Reset settings defaults". Click on this and the
website will reload.
What I usually do after this is load a practice game, exec yourname.cfg, do a

vid_restart and writeconfig autoexec.
I recommend reloading configs after each update.
Given the above there are two ways to do handle configs:
Method 1:
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.
This 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.
Method 2:
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.
If 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
method.
Anyways, on to the cvars!
Cvars:
cg_allowTaunt "1"
Description:
When set to 1 taunt sounds will be played when a player hits their taunt key
(+button3).
Recommendation:
I 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.
cg_autoAction ""
Description:
0/1/2/3
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.
Recommendation:
I 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.
cg_autoHop "1"
Description:
When set to 1, holding the jump button down will produce repeated jumps. If forward
is held while doing this some speed can be gained.
Recommendation:
If 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. At
the time of writing I am still using 0.
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.
It's 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.
cg_brassTime "2500"
Description:
The amount of time in milliseconds for the shell casings to be shown as they fly
out of the machine gun and shotgun.
Recommendation:
I strongly recommend setting this to 0 as it is visual clutter.
cg_bob "0.5"
Description:
This sets how much the player's view bobs from side to side while in motion.
Recommendation:
I 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 still
something that you'd usually want to turn off.
cg_bubbleTrail "1"
Description:
When set to 1 projectiles such as rockets will show a small trail of bubbles behind
them when underwater.
Recommendation:
I recommend setting this to 0 to make it easier to see when shooting underwater.
cg_buzzerSound "1"
Description:
When set to 1, an loud buzzer sound will play when the match ends.
Recommendation:
I recommend 0 as it is noisy and completely unnecessary.
cg_chatbeep "1"
Description:
When set to 1, regular chat messages typed in messagemode1 will beep as they are
shown.
Recommendation:
Completely personal preference, it's nice to know that the option is there.
cg_crosshairBrightness "1.0"
Description:
The brightness of the crosshair, 0 being black, 1.0 being normal (brightest).
Recommendation:
I 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.
Values between 0 and 1 can also be used, but so far I haven't found much use for
them.
cg_crosshairColor "25"
Description:
The color of the crosshair. Uses the 26 color scheme.
Recommendation:
I personally use 25 (white). 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.
cg_crosshairHitColor "1"
Description:
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.
Recommendation:
I've never had a problem with the default of bright red.
cg_crosshairHitStyle "2"
Description:
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 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 smaller pulse.
8 = Colorize by cg_crosshairHitColor and pulse with smaller pulse.
Recommendation:
The default of 2 is fine. I experimented with the other values and found most of
them unnecessary and/or distracting.
Setting 0 also works well, as the effect of the crosshair changing color can be
seen as distracting. So, probably the values 2 and 0 are the most circumspect.
Styles 1, 4 and 7 could work as an accessibility feature for the hearing impaired.
cg_crosshairHitTime "200.0"
Description:
Sets the amount of time in milliseconds the crosshair hit effect is displayed for.
Recommendation:
I've run many experiments with this cvar, and I've come to the conclusion that the
default is fine.
One 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.
Conversely setting it to a value greater than 200 resulting in the opposite effect.
Where I'd feel like I was hitting a great deal even when I wasn't. Probably most of
this is due to just not being used to a different value than 200, but I think 200
is quite reasonable. That if during an LG battle 4 cells are off, I know I'm
definitely off track and 200 ms gives me enough time to see it and react.
cg_crosshairPulse "1"
Description:
The crosshair will become larger for a split second when an item is picked up.
Recommendation:
It's a very minor effect so I have no problem leaving it at 1. It may be more

bothersome to others.
cg_crosshairSize "32"
Description:
Size of the crosshair in pixels.
Recommendation:
Very 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"
Description:
Controls which weapons will draw damage plumes. These are small numbers that fly
out from an enemy player on hit indicating the damage they have taken.
Recommendation:
Largely personal preference.

On 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.
One 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.
Some players have stated that the damagePlum effect has improved their lightning
gun accuracy due to the extra feedback from hits.
I 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
mines, but this weapon was made rare on maps in the last update.
I also recommend using it for the SG as it is often difficult to tell how much
damage you have done with it.
At 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.
cg_damagePlumColorStyle "1"
Description:
Controls the colors used for the damage numbers.
A 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
Recommendation:
Settings 1 and 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.
Setting 2 might be slightly easier to see than setting 1, even if 1 has more
granularity.
cg_damagePlums "1"
Description:
Controls 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 cg_damagePlum.
Recommendation:
I recommend leaving this at 1 and controlling its behavior with cg_Damageplum.
cg_drawAmmoWarning "1"
Description:
Displays low ammo and out of ammo warnings.
0 - Off
1 - Normal-Sized Text Warning
2 - Small-Sized Text Warning
Recommendation:
I recommend setting this to 0 as it is distracting. It should be obvious from the

hud when you are low on ammo.
cg_drawCrosshair "4"
Description:
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.
12 - 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.
19 - 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.
20 - 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.
lacks a black border around its "fins".
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.
25 - The Q3A version of crosshair 6. Looks virtually identical to its QL
counterpart. There may be a minor size difference, but it is nearly imperceptible.
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.
lacks a black border around the 'fins'.
29 - 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 a bit.
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.
Recommendation:
Largely personal preference. I think the most popular crosshairs are 2 and 7.
cg_drawCrosshairNames "1"
Description:
Displays another player's name above their heads when the crosshair is pointed at
them.
Recommendation:
I 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.
cg_drawCrosshairNamesOpacity "0.75"
Description:
The opacity/transparency of the name of the player shown when placing the crosshair
over them. Obviously requires cg_drawCrosshairNames to be set to 1.
Recommendation:
I always thought the default was fine. This value also determines the
opacity/transparency of the drawcrosshairTeamHealth information.
cg_drawCrosshairTeamHealth "2"
Description:
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.
Recommendation:
I just leave at its default of 2. I don't even really notice the team health
information.
cg_drawCrosshairTeamHealthSize "0.12f"
Description:
The size of the crosshair team health information. The Min 0.10f, and Max 0.26f.
Recommendation:
I 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.
cg_drawFPS "0"
Description:
When set to 1, the current frames per second is displayed in the top right-hand
corner.
Recommendation:
I leave this at 0 unless I am diagnosing framerate problems (which luckily I

haven't had). Very useful and important cvar though.
It 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 using a utility like Fraps.
cg_drawFragMessages "1"
Description:
Displays the "you fragged suchandsuch" text across the screen when getting a frag.
Recommendation:
I 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.
cg_drawFriend "1"
Description:
Draws a yellow triangle over teammates' heads that can be seen through the walls in
team based game types.
Recommendation:
I highly recommend keeping this at 1 as it is vital information.
cg_drawFullWeaponBar "1"
Description:
cg_drawFullWeaponBar [0|1]
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.
Recommendation:
I recommend leaving this at default, so that the weaponbar image remains consistent
and therefore easier for your brain to chunk the geometry of the screen.
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.
Say 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
cg_drawFullWeaponBar 1.
cg_drawGun "1"
Description:
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.
Recommendation:
For 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.
Note: 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.
Note2: 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 laser.
cg_drawItemPickups "3"
Description:
Upon picking up an item, a notification message appears near the bottom left-hand
corner of the screen. The options are as follows:
cg_drawItemPickups [0|1|2|3|4|5|6|7]
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
Recommendation:
I 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.
Values 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 are.
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.
I 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.
cg_drawPregameMessages "1"
Description:
When 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 are ready".
Recommendation:
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
clutter.
cg_drawRewards "1"
Description:
Draws 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).
Recommendation:
I recommend setting this to 0 as it is visual clutter.
cg_drawRewardsRowSize "1"
Description:
This 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.
Recommendation:
I 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.
cg_drawSpecMessages "1"
Description:
When 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 players".
Recommendation:
I recommend setting this to 0 to make for clearer spectating.
cg_drawTeamOverlay "1"
Description:
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.
Recommendation:
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.
cg_drawTeamOverlayOpacity "0.75"
Description:
The opacity/transparency of the team overlay box background.
Recommendation:
I've 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.
cg_drawTeamOverlayX "0"
Description:
The X coordinate of the team overlay box.
Recommendation:
Never 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.
cg_drawTeamOverlayY "0"
Description:
The Y coordinate of the team overlay box.
Recommendation:
Never 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.
cg_enemyHeadColor "0x2a8000FF"
cg_enemyLowerColor "0x2a8000FF"
cg_enemyUpperColor "0x2a8000FF"
Description:
These three are the hex color code for bright modeled enemies.
Recommendation:
I 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.

cg_errordecay "100"
Description:
This is a strange one. Someone on an ET|QW forum had this to say about it:
cg_errordecay 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 wallhack effect.
Source: http://www.urbanterror.info/forums/topic/1613-kicked-for-cg-errordecay/
Another clue was given by this post here in regards to CPM:
chg: 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.
Source: http://promode.ru/?q=node/1127
Recommendation:
I ran the test suggested above in q3, 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.
It's 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.
One 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.
I 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.
cg_filter_angles "0"
Description:
Alters how the players 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 players
aim position, turning to it slowly and smoothing the frames in-between causing a
mouse smoothing effect.
Recommendation:
I 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).
cg_flagStyle "1"
Description:
Changes the appearance of the flag.
1 - Classic Flag
2 - Holographic Flag
Recommendation:
Personal preference. This cvar is Premium only.
cg_followKiller "0"
Description:
When enabled: In spectator mode, when a player scores a frag, the spectator view
automatically switches to that player.
Recommendation:
Personal preference. Useful for casters.
cg_forceEnemyModel "keel/bright"
Description:
Force enemy team player models to be displayed as a specific model.
Recommendation:
The 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.
TankJR is another common choice though, as he is easier to see being slightly

larger. The robotic hitsounds Tank makes can be difficult to discern though.
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:
http://xdcclan.com/screenshots/ql_new_hitbox.jpg
cg_forceEnemySkin "bright"
Description:
When 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.
Recommendation:
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.
cg_forceEnemyWeaponColor "0"
Description:
Force enemies' grenades and rails to use 'Enemy Upper Color' (cg_enemyUpperColor).
Description:
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.
cg_forceTeamModel ""
Description:
Force teammate player models to be displayed as a specific model.
Recommendation:
The 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 two.
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 any model.
cg_forceTeamSkin ""
Description:
When 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.
Recommendation:
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
not.
cg_forceTeamWeaponColor "0"
Description:
Force teammates grenades and rails to use 'Team Upper Color' (cg_teamUpperColor).
Recommendation:
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 white.
cg_fov "100"
Description:
The field of view in degrees.
Recommendation:
I 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.
cg_gibs "10"
Description:
When the player is killed beyond a certain amount of health they will be "gibbed",
that is explode into sparks.
Recommendation:
I strongly recommend 0. For one gibbing a player will make a terrible scratching
noise, and second the sparks effect makes for visual clutter.
cg_gunX "0"
Description:
The 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.
Recommendation:
I recommend that at least for the lightning gun, set this to -10 (minimum) for thin
LG
purposes.
Set it to a maximum of 10 with cg_drawgun 1 and run around for a disturbing rocket
gunmodel.
cg_gunY "0"
Description:
The 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.
Recommendation:
At least for the lightning gun I recommend setting this to 2.7 (centered) for thin
and centered LG purposes.
cg_gunZ "0"
Description:
The 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.
Recommendation:
I recommend setting this to -8 (minimum) on at least the lightning gun for thin LG
purposes.
cg_hitBeep "2"
Description:
0/1/2/3
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.
Recommendation:
At first I thought that only 2 and 3 were worth considering, and which of those was
personal preference.
However, 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.
It 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.
cg_hudFiles "ui/hud.txt"
Description:
Sets 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
Recommendation:
It's 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 here: http://qlhud.net/
Many 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.
Another 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
cg_impactSparks "1"
Description:
When set to 1 hitting a player will cause spark-like graphics to eminate from them.
Recommendation:
I recommend 0, although I understand that some players prefer to use 1 for damage
information
purposes.
For example in TDM it becomes easy 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.
cg_impactSparksLifetime "250"
Description:
Time in milliseconds before impact sparks fade out.
Recommendation:
I leave this at default since I usually turn impactsparks off.
cg_impactSparksSize "8"
Description:
Size of each spark when cg_impactSparks is set to 1.
Recommendation:
I leave this at default since I usually turn impactsparks off. Increasing their
size can make them easier to see at the tradeoff of becoming distracting.
cg_impactSparksVelocity "128"
Description:
The 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.
Recommendation:
I leave this at default since I usually turn impactsparks off.
Setting 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.
cg_itemFx "7"
Description:
When cg_simpleItems is 0, this controls how the items behave.
cg_itemFx [0|1|2|3|4|5|6|7]
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)
Recommendation:
Mostly personal preference, and in my opinion isn't a big deal.
Values under 4 appear immediately on spawn, and do not "balloon" up. One 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 under
4.
It should be noted that the "ballooning" does not start until the weapon spawns.
Personally I don't mind the ballooning of the default value (7).
cg_kickScale "0.5"
Description:
Determines how much the screen shakes when hit, values range from 0 to 1.
Recommendation:
I _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.
cg_killBeep "7"
Description:
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
Recommendation:
It's a pretty minor issue, but I recommend just using 0. It is unneeded

information.
cg_lagometer "0"
Description:
cg_lagometer [0|1|2]
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.
Recommendation:
Unless you are diagnosing lag problems, I recommend setting this to 0.
cg_levelTimerDirection "1"
Description:
Determines which direction the game timer counts. 1 counts down, 0 counts up.
Recommendation:
I 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.
cg_lightningImpact "1"
Description:
Enables the lightning impact effect on surfaces by the lightning beam.
Recommendation:
I 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.
cg_lightningImpactCap "192"
Description:
Ranges from 0 to 768. Determines the size of the lightning impact effect when
impact is closer
than x units.
Recommendation:
Since 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.
cg_lightningStyle "1"
Description:
Controls the lightning stream effect.
cg_lightningStyle [1|2|3|4|5]
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
Recommendation:
I 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.
If 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 lightningstyle 4.
cg_lowAmmoWarningPercentile "0.20"
Description:
Controls percentile level of ammo available before issuing a low ammo warning, for
both the lowammoWarning sound and the "low" message on the weapon bar.
Min: 0.01 (1%)

Max: 1.00 (100%)
Recommendation:
I recommend leaving this at default since I also recommend turning off low ammo
warning
sounds.
cg_lowAmmoWarningSound "1"
Description:
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
Recommendation:
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 unnerving.
cg_lowAmmoWeaponBarWarning "2"
Description:
Controls the weapon bar ammo warning display.
cg_lowAmmoWeaponBarWarning [0|1|2]
1 = Draw weapon bar ammo value in red when empty
2 = Draw weapon bar ammo value in yellow when low and red when empty
Recommendation:
The default value is fine as the effect is barely noticeable.
cg_marks "1"
Description:
When 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 the effect.
Recommendation:
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" :-)
It 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).
cg_muzzleFlash "1"
Description:
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.
Recommendation:
I _strongly_ recommend setting this to 0 as it is a very distracting effect.
cg_playerLean "1"
Description:
Values between 0 and 1 are possible. They determine how far play models lean from
side to side when strafing.
Recommendation:
Largely 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.
cg_playTeamVO "1"
Description:
Allows a client to disable some of the team related VO
Recommendation:
I recommend 0 to cut down on the announcer.
cg_predictLocalRailshots "1"
Description:
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.
Two:
When 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.
Recommendation:
I recommend 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. If I am playing with the
railbeam being drawn, using 1 tends to make railing more difficult for me. For
others the opposite is true. Either way every player owes it to themselves to
experiment with this cvar.
cg_predictItems "1"
Description:
Client prediction for picking up items.
Recommendation:
Since this sometimes results in hearing the pickup sound yet not actually picking
up the item, I recommend using 0.
cg_projectileNudge "0"
Description:
Turns on or off projectile nudging, accepted values are from 0 to 80.
Recommendation:
When it was first added to the list of cvars there were no range limits. Setting it
to a value of maybe 2000 or -2000, I forget which made it so that plasma balls
would appear to hit their target immediately after firing even if they hadn't made
it to the target yet. Same with rockets: the explosion would appear where the
crosshair pointed immediately after firing, even if it hadn't really made it there
yet.
The idea behind this is that when the player is on a laggy server there is a firing
delay, so this cvar was designed to offset that delay by drawing the projectile so
many ms ahead as if it had been fired earlier. This would apply to the rocket
launcher and the plasma gun for sure, but perhaps the grenade launcher and BFG as
well.
The effect (assuming it's there) is virtually undetectable. Use at your own placebo
risk.
EDIT: February 2014, apparently its effect has been disabled for some time.
cg_railStyle "1"
Description:
cg_railStyle [1|2]
1 = Rail core rail trail
2 = Spiral rail trail
Recommendation:
Mostly 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).
cg_railTrailTime "400"
Description:
The time in milliseconds that the rail beam remains on the screen.
Recommendation:
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.
1300 - 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
999999 - 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.
cg_rewardsVO "1"
Description:
When set to 1 voice chats related to awards will be played. These include
"Excellent!" and "Impressive!".
Recommendation:
I recommend using 0 as it is extemporaneous aural information.
cg_scorePlums "1"
Description:
When set to 1, small numbers will float out of enemy bodies or nearby during game
events notifying you of points or frags gained.
Recommendation:
I 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 issue though.
cg_screenDamage "0x700000C8"
Description:
This is the hex color value of the color flash shown when receiving damage in
general.
Recommendation:
Although 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.
cg_screenDamage_Self "0x00000000"
Description:
This is the hex color value of the color flash shown when receiving damage from
yourself such as during rocket jumps.
Recommendation:
I recommend leaving this at the default.
cg_screenDamage_Team "0x700000C8"
Description:
This is the hex color value of the color flash shown when receiving damage from
teammates.
Recommendation:
I recommend turning off screendamage with cg_screenDamage 0 which renders the other
screendamage cvars ineffectual so they can be left at default.
cg_screenDamageAlpha "200"
Description:
The opacify of the color flash when receiving damage from enemies or yourself.
Recommendation:
cg_screenDamageAlpha_Team "200"
Description:
The opacity of the color flash when receiving damage from teammates.
Recommendation:
cg_selfOnTeamOverlay "0"
Description:
Displays the player's own name on the team overlay.
Recommendation:
This 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.
cg_shadows "1"
Description:
Draws a shadow under the feet of players.
Recommendation:
I 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 cannot.
cg_simpleItems "0"
Description:
Draws the items as flat symbols instead of 3d objects when set to 1.
Recommendation:
Personal preference. It is easier to see around simple items, but more difficult to
see the items themselves from certain angles/distances.
cg_simpleItemsBob "2"
Description:
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 to bob.
A value of 2 makes only major items bob, such as armors and the megahealth.
Recommendation:
I 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.
cg_simpleItemsRadius "15"
Description:
When simpleitems is on, this number controls their size.
Recommendation:
The default is absolutely fine. A lot of players seem to be cranking up the value
to the maximum or near its maximum these days, which makes for hilarious looking
items. To me this defeats the purpose of simple items though, which is to make it
easier to see around them.
However the size of the simple items is substantially smaller than the size of the
non-simple items which might seem a bit strange to players not used to it and so
could raise this value for a more "normal" feeling.
cg_smoke_SG "1"
Description:
This is the shotgun smoke shown while firing.
Recommendation:
I recommend using 0 (off), as this smoke is distracting.
cg_smokeRadius_GL "64"
Description:
This controls the size of the smoke trail on grenades.
Recommendation:
I 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.
cg_smokeRadius_NG "16"
Description:
Smoke trail for the Nail gun projectile.
Recommendation:
If 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.
cg_smokeRadius_RL "32"
Description:
This determines the size of the smoke trail for the rocket projectile.
Recommendation:
I strongly recomnend setting this to 0, as the smoke trails are highly

distracting/obscuring.
cg_speedometer "0"
Description:
Displays a meter for the players 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
Recommendation:
I recommend leaving this at 0 unless you are training strafe jumps.
cg_switchOnEmpty "1"
Description:
When 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.
Recommendation:
Either 1 or 0 is ok.
Technically 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.
However 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 critical.
cg_switchToEmpty "1"
Description:
When set to 1, switching to a weapon that is out of ammo is permitted.
Recommendation:
I 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.
cg_teamChatBeep "1"
Description:
Determines whether or not the "beep" sound will be played when receiving a team
chat.
Recommendation:
Completely 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.
cg_teamChatsOnly "0"
Description:
When set to 1, only chats in messagemode2 will be displayed. Handy as a "mute"

function as many games do not feature team chat.
Recommendation:
Leave 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.
cg_teamHeadColor "0x808080FF"
cg_teamLowerColor "0x808080FF"
cg_teamUpperColor "0x808080FF"
Description:
These 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.
Recommendation:
I 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.
cg_trueLightning "1"
Description:
Flexibility factor for lightning gun shaft, 0 being the most flexible and 1 being
the most rigid.
Recommendation:
I 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.
If 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.
I 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), watching good players and even observing the
occasional aimbot. 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.
There 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.
cg_trueShotgun "0"
Description:
When 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.
Recommendation:
I recommend using 1 as it is truer to the way the pellets are actually behaving.
cg_useItemMessage "1"
Description:
When set to 1 this will display "Used suchandsuch" when using an item such as the
Medkit.
Recommendation:
Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.
cg_useItemWarning "1"
Description:
When set to 1 this will display "No item to use" upon pressing the use key
(+button2) when the player has no item.
Recommendation:
Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.
cg_viewsize "100"
Description:
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.
Recommendation:
There 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.
cg_waterWarp "1"
Description:
When under water the player's view will be distorted by a wavy undulating visual
effect.
Recommendation:
I recommend setting this to 0 so that you can see more clearly when under water.
cg_weaponBar "1"
Description:
This 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
Recommendation:
The 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 preference.
cg_weaponColor_grenade "0x007000FF"
Description:
This is the hex color value of the small band around grenades.
Recommendation:
I 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.
cg_zoomfov "22.5"
Description:
This is the field of view (fov) in degrees that will be taken when zooming.
Recommendation:
I 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.
Obviously 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.
cg_zoomScaling "1"
Description:
With 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.
Recommendation: 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.
cg_zoomSensitivity "1"
Description:
When zoomed 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.
Recommendation:
I recommend using zoomsensitivity 1 as it uses the more correct algorithm, and most
do not need to change it. There's some appeal to lowering it just a tad for some
added slow down during long distance rails, but it isn't really necessary.
cg_zoomToggle "0"
Description:
When 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.
Recommendation:
I 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.
cl_allowConsoleChat "0"
Description:
When 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.
Recommendation:
Unless you do a lot of chatting, leave this at 0.
cl_autoTimeNudge "0"
Description:
When 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.
Recommendation:
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.
cl_demoRecordMessage "2"
Description:
0/1/2
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".
Recommendation:
I 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.
cl_mouseAccel "0"
Description:
When 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.
Recommendation:
Like sensitivity, this is about as "personal preference" as it gets.
One 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 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.
Then 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.
For example:
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
cl_mouseAccelOffset "0"
Description:
The 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.
Measured in 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.
Negative values are 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 base sensitivity.
Recommendation:
I 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 through this:
[(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
cl_mouseAccelPower "2"
Description:
The 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).
Recommendation:
Personal preference. I would leave this at default unless you are sure that this is
something you want.
Personally 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 merit.
cl_mouseSensCap "0"
Description:
When using mouse accel, the sensitivity will not become greater than this value.
Recommendation:
Depends highly on the mouse settings you use. Currently I am using 7.5 as this is
the highest sens I can tolerate with my mouse accel at this time. With
MouseAccelPower set greater than 2 using senscap becomes important as the
sensitivity can skyrocket.
cl_packetdup "1"
Description:
Determines how many duplicate packets you send to the server to avoid packet loss.
Recommendation:
Appears to make very little difference. I posted a thread about it here:
http://www.esreality.com/index.php?a=post&id=2111747
Perhaps 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.
Recently 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.
cl_timeNudge "0"
Description:
The time for player interpolation, values range from -20 to 0.
Recommendation:
One 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 sure.
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.
For me personally using -20 ends up throwing off my aim since it reminds me of my
quakeworld days which has a very responsive feel to it. QL isn't as responsive so I
found myself taking less time to aim and just shooting as fast as possible, often
missing quite a bit.
Everyone's brain works a little differently when it comes to hand eye

coordination/prediction so use what works for you.
color1 "7"
Description:
Color of the rail beam/core. <1-26>
Recommendation:
Personal 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.
color2 "25"
Description:
Color of rail disc/swirl effect. <1-26>
Recommendation:
Personal preference.
com_idleSleep "1"
Description:
Use sleep frames to reduce CPU usage.
Description from the changelog:
Added 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 kept ON.
Recommendation:
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.
com_maxfps "125"
Description:
Maximum rendered frames per second.
Recommendation:
The default of 125 is absolutely fine, as is the maximum of 250.
Only 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.
Currently 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.
If 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, even though my display refresh of 154 Hz only allows me to see an extra 29
fps. I long for the day that I might look upon 250 fps at 250 Hz.
con_background "0"
Description:
When 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.
Recommendation:
When using 0, I find that setting con_opacity 0 as well seems to be easiest on the
eyes. I still personally prefer 1, as the console text is easier to read.
con_height "0.5"
Description:
This is how far down the console goes, the default value of 0.5 going half way down
the screen.
Recommendation:
I 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.
con_opacity "0.75"
Description:
When con_background is 0, this value determines how transparent/opaque the console

is.
Recommendation:
If I happened to be using con_background 0, I like to set this to 0 as it seems to

make for the easiest reading.
con_scale "0.5"
Description:
Determines the size of the console text, a range between 0.5 and 1 can be used.
Recommendation:
I think the default of 0.5 is too small, so I use the maximum value, 1.
con_speed "3"
Description:
This value determines the speed at which the console comes down when
"toggleconsole" is issued.
Recommendation:
I 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.
con_timestamps "0"
Description:
Adds 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 in progress.
Recommendation:
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
hit.
Unless you really want the information, I recommend leaving it at 0 for a less
cluttered console.
handicap "100"
Description:
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.
With 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.
Recommendation:
I usually only use this in the following circumstances:
1. When warming up with a bot. I use handicap 50 to prevent the bot from dying too
quickly from my shots, therefore I get more aim practice time before the bot dies
and I have to go and find him again.
2. When 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 works better.
3. 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.
in_mouse "2"
Description:
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)
Recommendation:
The 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 anomalies.
in_nograb "0"
Description:
When 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.
Recommendation:
Leave this at 0.
m_cpi "0"
Description:
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.
Note: 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 up.
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 per second.
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
One 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.
Recommendation:
Personal 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.
m_filter "0"
Description:
Values >0 turn on mouse interpolation which makes mouse movement smoother. Values
range from 0 to 33.
Recommendation:
I 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.
Some players 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.
m_pitch "0.022"
Description:
The vertical mouse sensitivity. When m_cpi = 0, this is in degrees per mouse count
but is multiplied by sensitivity to produce the final x degrees/count value.
Recommendation:
Highly personal preference, however here are some ideas:
Leave 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 benefit hitscans.
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.
Use what works for you.
m_yaw "0.022"
Description:
The horizontal mouse sensitivity. When m_cpi = 0, this is in degrees per mouse
count but is multiplied by sensitivity to produce the final x degrees/count value.
Recommendation:
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.
Random info:
The 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.
Therefore 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.
model "sarge/default"
Description:
Sets your player model.
Recommendation:
The 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 gaming sounds.
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.
Slash 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.
Janet 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 same.
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.
Keel 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.
password ""
Description:
This is the cvar the client uses to enter password protected servers.
Recommendation:
None. 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.
r_BloomBrightThreshold "0.25"
Description:
Sets the bloom threshold when r_enableBloom 1 and r_enablePostProcess 1. The lower
the threshold, the more bloom drawn. <0-1>
Recommendation:
A 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 on television.
Note:
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.
r_BloomIntensity "0.50"
Description:
Sets the bloom intensity when r_enableBloom 1 and r_enablePostProcess 1. The higher
the value, the more intensive and bright the bloom effect will be. <0-10>
Recommendation:
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.
r_BloomPasses "1"
Description:
Sets the number of rendering passes for bloom effect.
0 - off
1 - one pass
2 - two passes
Recommendation:
Whenever 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.
r_BloomSaturation "0.800"
Description:
Sets 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>
Recommendation:
Very 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 where 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.
r_BloomSceneIntensity "1.000"
Description:
Sets 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>
Recommendation:
Values 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.
Values 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 of course.
r_BloomSceneSaturation "1.000"
Description:
Sets 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>
Recommendation:
I 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 objects.
r_contrast "1.0"
Description:
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.
Description:
I 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 see though.
r_customheight "1024"
Description:
The height in pixels when r_mode is set to -1.
Recommendation:
Leave at default unless you are setting a custom resolution.
r_customwidth "1600"
Description:
The width in pixels when r_mode is set to -1.
Recommendation:
Leave at default unless you are setting a custom resolution.
r_displayRefresh "0"
Description:
Monitor refresh rate (in Hertz), useful for CRT monitors.
Recommendation:
Use at least 120 Hz if possible. If not, try to get it as high as you can. Many
LCDs are stuck at 60 Hz, or 75 Hz. CRTs can go much higher, provided the resolution
stays fairly low. I recommend a utility like powerstrip to pencil your refresh
rates. The game will not override them unless they are far from the value of
displayrefresh. For example I use 154 Hz at 800x600, and set r_displayRefresh to
150, since it doesn't take a value like 154. My refresh rate remains at 154
regardless. However if I set r_displayrefresh to 75, I'll get 75 Hz. If I put in a
value it doesn't like, it defaults to 60 Hz. Check your display's OSD to find out
what refresh rate is actually being displayed. You may have to use an odd refresh
rate value to eliminate tearing when using a CRT. I get tearing at both 120 and 125
Hz at 1024x768. I have
no idea what value to use to eliminate it, luckily I prefer 800x600. Probably this
kind of behavior varies with the display.
r_dynamiclight "1"
Description:
Dynamic Lights. (eg: rockets emitting light onto nearby scenery)
Recommendation:
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.
Also, 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.
So 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.
r_enableBloom "1"
Description:
Enables light bloom effects when r_enablePostProcess 1.
Recommendation:
I 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.
r_enableColorCorrect "1"
Description:
Enables 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.
Recommendation:
Whenever I mess with bloom I always have to turn this option off otherwise the
display becomes too bright and colors become washed out.
r_enablePostProcess "1"
Description:
Enable post processing. A setting of 1 is needed for bloom and r_contrast, but
renders r_intensity ineffectual.
Recommendation:
If you're low on FPS, setting this to 0 can help tremendously. I actually recommend
setting this to 0 anyways. It changes the brightness a bit but I like the effect,
and it's nice to know that my machine is having an easier time running the game.
r_fastsky "0"
Description:
When set to 1, the skybox will be replaced with a solid color.
Recommendation:
Largely 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.
r_fastSkyColor "0x000000"
Description:
When r_fastSky is set to 1, the sky will be this color described in hex color code.
The default is black.
Recommendation:
I 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.
r_fullbright "0"
Description:
Renders all textures on the map at full brightness when set to 1.
Recommendation:
The 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.
r_fullscreen "0"
Description:
0 - Windowed
1 - Fullscreen
Recommendation:
I strongly recommend playing in fullscreen. However fullscreen is not default in

case there are problems, so this cvar is a must for every config.
r_gamma "1"
Description:
Amount of image luminance applied to the in-game display. The higher the number,
the stronger luminance present.
Recommendation:
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.
r_ignorehwgamma "0"
Description:
Setting this to 1 enables the ignoring of hardware gamma settings.
Recommendation:
This usually has the effect of simply making everything dark and having to crank up
the other brightness settings to compensate. Under normal 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 large effect on brightness than the driver settings, which
are usually at default. I wouldn't be surprised if the default brightness of ATI
drivers vs. Nvidia drivers is the same. So I suppose I recommend just leaving this
at 0.
r_intensity "1"
Description:
Intensifies the level of brightness added to textures and model skins. Doesn't seem
to work when r_enablepostprocess is set to 1.
Recommendation:
When 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.
r_lightmap "0"
Description:
When set to 1 it enables the light data lighting model. Is only effectual when
r_vertexlight is set to 0.
Recommendation:
Similar 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.
r_lodbias "0"
Description:
Controls 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).
Recommendation:
I recommend using -2 with enemymodel keel so that he will remain at highest detail.
Some 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 else.
lodbias 2 is recommended for TankJR since he better fits the hit cylinder this way.
r_lodscale "10"
Description:
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.
Recommendation:
I 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 as possible.
r_mapOverBrightBits "2"
Description:
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.
Recommendation:
There are many values that work great, and they depend on a variety of factors.
Here are some example brightness setups:
r_mapoverBrightBits 1
r_overBrightBits 1
r_mapoverBrightCap 255
r_gamma 1.75
r_overBrightBits 1
r_gamma 1.3
r_overBrightBits 1
r_gamma 1
r_overBrightBits 0
r_gamma 1.7
For 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.
r_mapOverBrightCap "255"
Description:
Allows 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.
Recommendation:
If 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, just a convenience.
r_mode "-2"
Description:
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
Recommendation:
Very personal preference, and not a simple issue.
First 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. With some of the new LCDs they run 120 Hz at their native resolution.
This could be resolutions like 1920x1080 or 1680x1050. If you can get 125 fps at
those resolutions and like the effect, go for it.
There is some controversy over what aspect ratio is best, be it 4:3 or the wider
16:9 and 16:10. Probably you can adapt to using either and play just fine.
I personally suspect that 4:3 makes it easier for the human mind to "chunk" the
screen and take note of its geometry. Perhaps 5:4 is even better since it is
slightly more square than 4:3. Maybe it depends completely on the person. It's hard
to tell. Here are some example pro players that use low resolution:
Cypher (640x480) (may have changed to 800x600 recently)

Cooller (640x480)
avek (640x480)
Stermy (800x600)
Dahang (800x600)
czm (800x600)
k1llsen (800x600)
Spart1e (1024x768)
Evil (1024x768)
r_overBrightBits "1"
Description:
Ambient lighting applied to in-game entities or objects. The range is from 0 to 4.
Recommendation:
I think that most setups will leave this at 1. Other values have more tempremental
effects.
There 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.
Another 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.
Increasing r_gamma and/or r_mapoverBrightBits has the effect of amplifying the

"grey haze", although it gets rid of the really dark areas.
Ultimately 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.
r_picmip "0"
Description:
Texture 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.
Recommendation:
Largely 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. I personally use
5.
r_railCoreWidth "6"
Description:
Rail trail core effect diameter (in pixels). The color is controlled by color1.
Recommendation:
One person told me that using 1 for corewidth helped their rail aim, others like
the really thick look of segmentlength 1. Some like me have had all the r_rail
settings at default for a long time and don't have any issue with them.
In an old cypher config (he's since changed settings) I found railstyle 2 with
corewidth 20. So yeah, just use whatever you like :-)
r_railSegmentLength "32"
Description:
Rail trail section length (in pixels). The color is controlled by color2.
Does not effect the 'spiral' when using cg_railstyle 2.
Recommendation:
These 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 0.
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.
r_railWidth "16"
Description:
Diameter of the segments in pixels.
Recommendation:
Personal 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 number.
r_simpleMipMaps "1"
Description:
Enables simple MIP mapping, boosts performance.
Recommendation:
This 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.
r_subdivisions "4"
Description:
Patch mesh/curve sub divisions. A value of 80 will replace curved surfaces with
angled surfaces to give a performance boost. Only values of 4 and 80 are allowed in
Quake Live.
Recommendation:
This one is controversial. Here are some pros/cons/information.

Pros of using 80:
In some cases the curve takes up part of a doorway in which case something may be
seen with 80 that would not be seen with 4.
It results in more consistent map features, as far away curves will lower in
quality. This happens much less with 80 since the quality is already low.
It is useful for learning to do some movement tricks consistently. For example on

Campgrounds doing the rail to bridge jump from various points along the curve is
easier since the curve is broken up into points to start from. (Thanks aeoL for
this idea).
It might be the case that you can see something with 4 that you cannot see with 80,
however you cannot shoot through that area, in which it would be better to use 80
such that if you can see it you can always shoot at it.
Cons of using 80:
Some maps may be rendered more correctly with 4, than with 80, such that perhaps
something could be seen with 4 that could not be seen with 80.
Using 4 is much better looking in my opinion.
Important pictures illustrating the different effects:
Aerowalk: http://imageshack.us/a/img831/7135/kwgjgjr.gif
Campgrounds: http://imageshack.us/a/img692/9822/dxpn7xzc.gif
Campgrounds: http://imageshack.us/a/img24/4703/iomxigr.gif
FuriousHeights: http://imageshack.us/a/img542/669/j8pmjk7.gif
FuriousHeights: http://imageshack.us/a/img209/5472/tdbr9w3.gif
Bloodrun: http://imageshack.us/a/img89/1117/j1oyki9.gif <----- omg!

Bloodrun: http://imageshack.us/a/img694/5450/l9tjtjs.gif
Thanks FFT for these gifs.
r_teleporterFlash "1"
Description:
When 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.
Recommendation:
To see what this effect actually looks like, try devmap verticalvengeance and set
timescale to 0.25 and go through the teleporter. Events will be taking place
significantly slow for you to see the flash.
With 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.
Another 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).
r_textureMode "GL_LINEAR_MIPMAP_LINEAR"
Description:
Sets texture filter.
Usage:
r_texturemode "GL_X_MIPMAP_Y"
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:
GL_LINEAR_MIPMAP_LINEAR = The default setting. It shows up close textures at normal

quality, and far away textures are only slightly mipped to prevent moire
patterning.
GL_LINEAR_MIPMAP_NEAREST = Up close textures are at normal quality, far away

textures are mipped much more than with mipmap_linear.
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 have.
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 does.
GL_NEAREST_MIPMAP_LINEAR = Up close textures are nearest, far away textures are

mipped with linear. Looks almost identical to gl_nearest_mipmap_nearest.
Recommendation:
I recommend using the default. Although it's fun to try gl_nearest_mipmap_nearest.
r_vertexlight "0"
Description:
When set to 1 it enables vertex lighting, 0 is lightmap.
Recommendation:
I 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 wild results.
If you're low on FPS, using 1 can help tremendously.
r_windowedmode "12"
Description:
Sets the resolution of the game when windowed (as opposed to fullscreen). Uses the
same mode list as r_mode.
Recommendation:
If 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. For me a value of 5 (640x480) works perfectly for this.
rate "25000"
Description:
Controls packets so that your downstream connection bandwidth does not get
saturated. (Max bytes per second)
Recommendation:
I 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.
s_ambient "1"
Description:
Ambient 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.
Recommendation:
I 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.
s_musicvolume "0.25"
Description:
Volume of Quake Live's background music.

Reccommendation:
I strongly recommend setting this to 0 as it is unneeded and distracting.
s_volume "0.8"
Description:
The game's volume. Highly dependent on the computer, speakers/headphones, the

operating system's audio settings, and the person.
Recommendation:
Not too quiet, not too loud. All things in moderation.
Some 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 improve aim.
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.
sensitivity "4"
Description:
Sets mouse sensitivity, which is then multiplied by m_yaw and m_pitch to determine
the final amount of degrees to turn per mouse count.
Recommendation:
This is about as personal preference as it gets.
One 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).
Another 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 formula:
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"
Description:
When 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.
Recommendation:
Leave 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
One 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"
Description:
The speed of game events. This can only be adjusted on localhost or during demo
playback.
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.
Recommendation:
Since any normal key being pressed during demo playback ends the demo, I recommend
binding keys for use during demo playback elsewhere. From my own config:
bind F6 "+acc" // Accuracy

bind F5 "+scores" // Scoreboard
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
I 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.
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 :-)
winkey_disable = "0"
Description:
When set to 1 the windows key will be ignored by the OS when the game is running.
Recommendation:
I recommend setting this to 1 to prevent accidental pressing of the windows key at
a critical moment in the game.
Commands:
alias
Description:
alias makes up a command of the name you specify, and it does what you specified it
to do.
Usage:
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:
\greet
Results in:
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.
An 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"
When the 'h' key is held down, the alias for +greeting will be activated, when it
is released the alias -greeting will be activated.
It 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 is released.
In the scenario of this alias:

alias +lgFire "sensitivity 2 ; +attack"
alias -lgFire "sensitivity 4 ; -attack"
The 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 cancelled.
Note, 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)
bind
Description:
Assign an action to a key.
Usage:
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"
Commands 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:
semicolon
capslock
rightarrow
uparrow
downarrow
leftarrow
scroll Lock is "0x00"
kp_numlock
kp_slash
kp_star
kp_minus
kp_plus
kp_enter
kp_home
kp_uparrow
kp_pgup
kp_leftarrow
kp_5
kp_rightarrow
kp_end
kp_downarrow
kp_pgdn
kp_ins
kp_del
Mouse1
mwheelup
mwheeldown
aux1 - 17 (I assume these are for a game pad of some sort)
When in_joystick is 1:
Joy1 - 32
Unusual 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 particular keyboard.
Some 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.
block
Syntax:
block <playername>
Description:
Hides all chats coming from a player. Useful for trolls.
blocklist
Description:
Lists all players that are currently in your blocklist.
callvote
Syntax:
callvote <command> <variable>
Description:
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.
clear
Description:
Clears all the text from the console. I use this often.
cmdlist
Description:
Lists the game's commands.
You can also search for a command by typing cmdlist *searchstring.
cvarlist
Description:
Lists the vast majority of the game's cvars, their flags and their values.
You can also search for a cvar by typing cvarlist *searchstring. Very very useful
when you cannot remember the full name of a cvar.
demo
Syntax:
demo <demoname>
Description:
Plays a demo that's in home/baseq3/demos
Gets rarely used as autorecorded demos usually have long names that are difficult
to remember, in which case automated demo player tools such as QLDP are used
instead.
devmap
Description:
Enters a map with cheats on. Extremely useful for testing things on localhost. I
often do the following for example:
Open a practice game and enter the console, type devmap verticalvengeance (I hit
tab to auto-complete and save on keystrokes).
From 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 usually set a handicap of 50 or
less which let's me shoot plenty without killing the bot and gives me an excellent
chance to get a feel for whatever it is I happen to be testing.
disconnect
Description:
Disconnects from the current server and takes you back to the server browser.
dropflag
Description:
When 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 a cap.
droppowerup
Description:
Issuing 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.
dropweapon
Description:
Issuing 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.
exec
Description:
Executes 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.
Usage:
exec <filename>
exec lorf.cfg
exec lorf
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:
exec backups/lorfabackup.cfg
Will look in home/baseq3/backups/ for lorfabackup.cfg
forfeit
Description:
Ends 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.
give
Description:
Gives a specific item/weapon to the player in devmap (cheats enabled).
Usage:
give <item>
List of gives I know (the spaces are important):

give gauntlet
give machine gun
give shotgun
give grenade launcher
give rocket launcher
give lightning gun
give railgun
give plasma gun
give bfg10k
give grappling hook
give nailgun
give prox launcher
give chaingun
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 regeneration
give invisibility
give haste
give flight
give health (changes health to the maximum non-tick value allowed by handicap,
which is 100 by
default)
give bullets
give shells (shotgun)
give grenades
give rockets
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)

give all
If anyone knows the rest of these let me know!
god
Description:
Toggles 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 killed.
I have a bind to "give all ; god" which lets me play with all the weapons in
localhost.
in_restart
Description:
Restarts mouse input. Required after a change to in_mouse, and can also be useful
if the mouse input crashes for some reason.
loadhud
Description:
Loads the hud.
Comment:
Very 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.
kill
Description:
Kills oneself. Commits suicide. Jisatsu. Sjlvmord.
Incurs an extra 1 second spawn delay.
Comment:
Very useful for race since you always spawn near the starting point. So when you
complete a run you can suicide and immediately go again.
It was recently (August 2014) enabled on public servers, which quite possibly
introduces certain tactics based on the "teleporting" nature of dying and spawning
elsewhere.
messagemode
Description:
Enters 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.
messagemode2
Description:
Enter a chat prompt; chats typed here will go to teammates only. Useful for team
communication.
messagemode5
Enter a chat prompt; chats typed here will go to the last person who messaged from
QL's online buddy chat. I recommend binding the backspace key for this one.
name
Description:
The player's name. Can be styled in colors using the carot symbol (^).
Usage:
name "playername"
The colors are:
^1 = red
^2 = green
^3 = yellow
^4 = blue
^5 = cyan
^6 = Magenta
^7 = white
^8 = black (not supported for names but still works for chat)
So a 7 lettered name with all different colors would look like this:
name "^1p^2l^3a^4y^5e^6r^71"
Will make for a very colorful "player1" name.
While colors can be added, the name cannot be changed from its original lettering.
If there is an error the name will simply be reset back to white in all lowercase
letters.
Colors can also be used in chat.
players
Description:
Lists 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. Also useful when you are going to \block someone, as you do
not have to view their name, remember exactly how it is written, and then enter the
console and \block <thatname>. Instead you can just enter the console, type
players, and then \block from that player's name shown on the list.
quit
Description:
Exits the game. Other players will see "suchandsuch disconnected"
ragequit
Description:
Also exits the game, however other players will see "suchandsuch ragequits" with
the 'rage' part colored in red letters.
readyup
Description:
Sets the player status to ready. By default this is bound to F3.
reconnect
Description:
Disconnect 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.
record
Description:
Starts recording a demo.
Usage:
record <demoname>
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
reply
Description:
Replies the last person who messaged via the quake live buddy chat. Very useful if
watching a demo and someone is messaging as you can reply them through the console
because hitting your messagemode5 key will not work or will stop the demo.
Usage:
reply <message>
say
Description:
Chats in messagemode1. Useful for chatting from the console, or for automatic
binds.
Usage:
say <message>
say_team
Description:
Chats in messagemode2 which is team chat. Useful for creating team chat binds.
Usage:
say_team <message>
screenshot
Description:
Takes a screenshot in .tga format. This is recommended with lower resolutions as

the text shows up more clearly.
screenshotJPEG
Description:
Takes 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.
serverinfo
Description:
Lists all the information about the server, including the infamous skillrating
value. Sample output:
Server info settings:

teamsize 8
g_gametype 0
gt_realm quakelive
g_voteFlags 2250
sv_ranked 1
sv_maxclients 16
sv_hostname FFA
timelimit 15
g_teamSizeMin 2
sv_advertising 1
fraglimit 50
g_overtime 0
sv_location TX
sv_allowDownload 1
version QuakeLive 0.1.0.591 linux-i386 Jul 10 2012 16:56:49
dmflags 0
protocol 73
mapname limbus
sv_privateClients 0
sv_gtid 326591
sv_adXmitDelay 300000
sv_skillRating 510
gamename baseqz
g_adCaptureScoreBonus2
g_adElimScoreBonus 2
g_adTouchScoreBonus 1
g_aspectEnable 0
capturelimit 8
g_compmode 0
g_customSettings 0
g_freezeRoundDelay 4000
g_gameState PRE_GAME
g_gravity 800
g_holiday 0
g_instaGib 0
g_maxDeferredSpawns 4
g_maxGameClients 0
g_maxSkillTier 0
g_maxStandardClients0
mercylimit 0
g_needpass 0
g_quadDamageFactor 3
roundlimit 5
roundtimelimit 180
ruleset 1
scorelimit 150
g_startingHealth 100
g_teamForceBalance 1
g_timeoutCount 3
g_weaponrespawn 5
g_levelStartTime 1345295043
set
Description:
set 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"

\vstr greet
Results in:
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"
As 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"
seta
Description:
Behaves 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 sensitivity "5".
setviewpos
Description:
In 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.
Usage:
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"
..and practice your trick move from that position over and over again simply
hitting the key after each iteration to return the exact same spot.
stoprecord
Description:
Stop recording a demo.
team
Description:
Used to set team. The valid teams are:
red
blue
spectator
auto
These can be abbreviated with just their first letter:
r
b
s
a
Usage:
team <team>
tell
Description:
Gives a person a message in-game that only they can see. Player must be on the
server.
Usage:
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.
tell_buddy
Description:
Talks to a friend via the quake live buddy chat.
Usage:
tell_buddy <name> <message>
toggle
Description:
This is a function that will switch a function between 1 and 0 by pressing a key.
Usage:
toggle <cvar>
For example,
bind pause "toggle r_fastsky"
Upon 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.
unaliasall
Description:
Removes 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
defaults).
For 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.
unbindall
Description:
Removes 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.
unblock
Usage: unblock <playername>

Description:
Removes a particular player from the block list.
viewpos
Description:
Displays player coordinates in map, in the form of: (X Y Z) : Angle
Comments:
Very 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.
vid_restart
Description:
Restarts the renderer. Required for many r_ cvars to take effect.
vote
Description:
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.
Usage:
vote yes
vote no
vstr
Description:
Executes the commands in a specified set. See the description of 'set' for more
info.
Usage:
vstr <cvarname that originated from set>
wait
Description:
Waits 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 items.
weapon
Description:
Selects a specific weapon.Usage: weapon #
List:
weapon [1-14]
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
weapnext
Description:
Selects the next weapon in the weapon cycle. Weapons without ammo, including the
gauntlet are skipped, even when cg_SwitchToEmpty is set to 1.
weapprev
Description:
Selects the previous weapon in the weapon cycle. Weapons without ammo, including
the gauntlet are skipped, even when cg_SwitchToEmpty is set to 1.
writeconfig
Description:
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
Usage:
writeconfig <filename>
Button Commands:
These activate when the key is pressed down, and deactivate when released. They are
for use with the bind command.
+acc
Description:
Shows your weapon accuracies.
Different weapons have different accuracy values that are considered good. The vast
majority of concern is given
to the accuracy values of the lightning gun and the railgun. Excellent accuracy
values for these would be 40 % and 50 % respectively.
The stronger the player the better their dodging tends to be, and so accuracies are
likely lower than normal against such players.
+attack
Description:
Fires weapon.
+back
Description:
Moves backward.
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".
+button0
Description:
Fires weapon. Identical to +attack. Impress your friends by binding this for fire
instead of attack :-P
+button2
Description:
Use 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.
+button3
Description:
The taunt key. Do not use this ever.
+forward
Description:
Moves forward.
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".
+movedown
Description:
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.
+moveleft
Description:
Strafes left.
+moveright
Description:
Strafes right.
+moveup
Description:
Jumps, or swims up in the water.
+scores
Description:
Displays the scoreboard.
+speed
Description:
Run/Walk toggle.
While 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).
+zoom
Description:
Zooms in when activated, zooms out when deactivated.
Links:
Muffin's console guide:
http://www.regurge.at/ql/
Worthless information about your worthless mouse:
http://www.funender.com/quake/mouse/index.html
Special Thanks:
TheMuffinMan86
Lam
Injx
SyncError
Regurge
govn0r
Yakumo
EmSixTeen
Wrl
Windex
aeoL
ybl
TIE
andy17null
pvh
FFT
Flashsoul
Guide by Lorfa: mklabyrinth@gmail.com
Last Update: September 1, 2014

Lorfa&#39;s 263 (QL Console Guide)

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Lorfa&#39;s 263 (QL Console Guide)

Caricato da

Copyright:

Formati disponibili

Lorfa's 263

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

Like this here: http://pastebin.com/rfwnEVn4

There are a few ways to handle this:

There are four files of importance to configs in home/baseq3:

1. Delete (or move into a backup directory) qzconfig.cfg, repconfig.cfg, and

What I usually do after this is load a practice game, exec yourname.cfg, do a

Given the above there are two ways to do handle configs:

Then make autoexec.cfg read-only just in case an accidental writeconfig autoexec is

Leave autoexec.cfg as it is.

Anyways, on to the cvars!

I strongly recommend setting this to 0 as it is visual clutter.

I recommend setting this to 0 to make it easier to see when shooting underwater.

I recommend 0 as it is noisy and completely unnecessary.

The color of the crosshair. Uses the 26 color scheme.

I personally use 25 (white). Notable values include:

The only way to set it to black is to use cg_crosshairBrightness 0.

Controls crosshair color as applicable to the appropriate hit style controlled by

I've never had a problem with the default of bright red.

Allows the crosshair to indicate the damage dealt to other players.

1 = Colorize the crosshair based on damage dealt.

2 = Colorize the crosshair to 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.

7 = Colorize by damage and pulse with smaller pulse.

8 = Colorize by cg_crosshairHitColor and pulse with smaller pulse.

It's a very minor effect so I have no problem leaving it at 1. It may be more

Size of the crosshair in pixels.

cg_damagePlum "g mg sg gl rl lg rg pg bfg gh cg ng pl hmg"

Largely personal preference.

At the time of writing I have it set to "mg sg gl rl bfg ng pl". I found it

Controls the colors used for the damage numbers.

A setting of 2 colors each number based on its value, similar to crosshairHitStyle

A setting of 3 will color each number based on the weapon used:

I recommend leaving this at 1 and controlling its behavior with cg_Damageplum.

Displays low ammo and out of ammo warnings.

I recommend setting this to 0 as it is distracting. It should be obvious from the

Displays the specified crosshair image. Values range from 0 to 20.

I leave this at 0 unless I am diagnosing framerate problems (which luckily I

I highly recommend keeping this at 1 as it is vital information.

0 = Draw only currently held weapons on the weapon bar.

Controls the displaying of weapons in 1st person view.

I recommend setting this to 0 as it is visual clutter.

I recommend setting this to 0 to make for clearer spectating.

The opacity/transparency of the team overlay box background.

The X coordinate of the team overlay box.

The Y coordinate of the team overlay box.

Strangely, 0x000000FF is black, while 0x00000000 is white.

Another clue was given by this post here in regards to CPM:

If anyone has more information on this cvar let me know.

Changes the appearance of the flag.

Personal preference. This cvar is Premium only.

Personal preference. Useful for casters.

Force enemy team player models to be displayed as a specific model.

TankJR is another common choice though, as he is easier to see being slightly

I recommend using 1, the reasoning behind it is that it will enable you to

Force teammate player models to be displayed as a specific model.

Since I do not force bright skins for teammates, I am free to change

The field of view in degrees.

The X direction of the gunmodel when cg_drawGun is set to 1 or 2. However the

The Y direction of the gunmodel when cg_drawGun is set to 1 or 2. However the

Lorfa's 263 (QL Console Guide)

Lorfa's 263 (QL Console Guide)