Lorfa's 258

The only Quake Live cvars+commands you'll ever need to know!


Q. There's already a console guide at http://www.regurge.at/ql/ , why make this one?   

A. There are ~1400 commands/cvars, this takes only the most important 197 cvars and gives recommendations and often times extra info not included in the basic list. It also includes explanations for the 63 most important commands sometimes with more in-depth info.

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:


Q. I bet your personal config is a horrendous tweaked out mess! What does it look like?

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


Making your own config is kind of like a Jedi making his/her own lightsaber. It's like a right of passage.

There are a few ways to handle this:

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:



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

qzconfig.cfg and repconfig.cfg, the only time I ever touch these is to delete them as part of a reset process.

autoexec.cfg, this does not exist by default. It can be created with \writeconfig autoexec. When it is present, any cvars that are changed will not be saved when Quake Live is exited. The only way to save them is with another \writeconfig autoexec, by manually editing the files, or by renaming/deleting autoexec and then making changes.

I recommend using autoexec 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 is handicap because it saves anyways. Make sure to put handicap back to 100 if you've been using it at some other value.

..and yourname.cfg, this is your light saber, untouched by the clutter of the other files and only ever edited manually.

What I do often is reset configs by deleting (or move into a backup directory) qzconfig.cfg, repconfig.cfg, and autoexec.cfg, then load a practice game, exec yourname.cfg, do a vid_restart and writeconfig autoexec. That way all cvars not in yourname.cfg get set to their defaults.

Given the above there are two ways to 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!


    cg_allowTaunt   "1"


When set to 1 taunt sounds will be played when a player hits their taunt key (+button3).


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_announcer   "1"


Selects which voice is used for the announcer.


1 - Default: Sounds like a generic male announcer. 
2 - Vadrigar: Original Q3A announcer, male announcer that has much more energy and character than setting 1.
3 - Daemia: Generic female announcer.


Personal preference, however I still find it approrpriate for this guide since you will likely be hearing a lot of whichever announcer you choose unless you turn it off completely with s_announcerVolume 0.

    cg_announcerRewardsVO   "1"


When set to 1, the announcer voices rewards such as 'impressive' and 'excellent'.


I recommend setting this to 0 as it is unnecessary aural clutter.

    cg_autoAction   ""



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.


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"


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.


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.

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. Nonetheless I have personally never played an FPS game with such a setting and cannot bring myself to trust it, so I leave it at 0. So I will say this is personal preference.

    cg_brassTime   "2500"


The amount of time in milliseconds for the shell casings to be shown as they fly out of the machine gun and shotgun.


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

    cg_bob   "0.5"


This sets how much the player's view bobs from side to side while in motion.


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 it was still something that you'd usually want to turn off.

    cg_bubbleTrail   "1"


When set to 1 projectiles such as rockets will show a small trail of bubbles behind them when underwater.


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

    cg_buzzerSound   "1"


When set to 1, a loud buzzer sound will play when the match ends.


I recommend 0 as it is noisy and completely unnecessary.

    cg_chatbeep   "1"


When set to 1, regular chat messages typed in messagemode1 will beep as they are shown.


Completely personal preference, it's nice to know that the option is there.

    cg_crosshairBrightness   "1.0"


The brightness of the crosshair, 0 being black, 1.0 being normal (brightest).


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 among various other variables.

Values between 0 and 1 can also be used, but so far I haven't found much use for them.

    cg_crosshairColor   "25"


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


Notable values include:

1 - bright red
5 - bright yellow (popular)
9 - bright green
13 - Cyan
15 - bright blue
21 - Magenta (what I might call pink)
25 - White (default)
26 - Off white

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

Which color works best depends on the person, the brightness settings, enemy model settings, resolution and more.

    cg_crosshairHitColor   "1"


Controls crosshair color as applicable to the appropriate hit style controlled by cg_crosshairHitStyle. Uses the
26 color scheme like cg_crosshairColor and color1/color2.


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

    cg_crosshairHitStyle   "2"


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

0 = Off

1 = Colorize the crosshair based on damage dealt.

2 = Colorize the crosshair to the color designated by cg_crosshairHitColor.

3 = Pulse the crosshair (exaggerated/scaled pulse)

4 = Colorize by damage and Pulse the crosshair.

5 = Colorize by cg_crosshairHitColor and Pulse the crosshair.

6 = Pulse the crosshair with a smaller pulse. (same size as the cg_crosshairPulse uses when picking items up)

7 = Colorize by damage and pulse with a smaller pulse.

8 = Colorize by cg_crosshairHitColor and pulse with a smaller pulse.


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, in my opinion 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"


Sets the amount of time in milliseconds the crosshair hit effect is displayed for.


I've run many experiments with this cvar, and I've come to the conclusion that the default is fine, although a value of 100 is certainly compelling.

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.

Setting it to a value greater than 200 caused the opposite effect, where I'd feel like I was hitting a great deal even when I wasn't. Eventually I settled on 100, but I'm very hesitant to say that this is at all advantageous. It very well might be the case that the brain is simply adapting to what it is presented with in this regard, and there is nothing to be gained outside of 'reasonable' values that are probably close to the default.

    cg_crosshairPulse   "1"


The crosshair will become larger for a split second when an item is picked up.


It's a very minor effect and completely personal preference.

    cg_crosshairSize   "32"


Size of the crosshair in pixels.


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"


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.


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.

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"


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


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. Nonetheless, the default of 1 is perfectly fine.

    cg_damagePlums   "1"


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.


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

    cg_drawAmmoWarning   "1"


Displays ‘low ammo’ and ‘out of ammo’ warnings.

0 - Off
1 - Normal-Sized Text Warning
2 - Small-Sized Text Warning


I recommend setting this to 0 as it is distracting. It should be obvious from the hud when you are low on ammo.

    cg_drawAttacker   "1"


Displays the name and face model of the last player who attacked you in the upper right hand corner.


I personally didn't notice this for many years, so I think it is a pretty minor issue. I don't know why this information would be ncessary, so I suppose it is visual clutter, albeit very minor visual clutter. So personal preference I guess.

    cg_drawCrosshair   "4"


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.
22 - The Q3A version of crosshair 3. Slightly larger than its QL counterpart. It lacks a black border around its "fins".
23 - The Q3A version of crosshair 4. Slightly larger than its QL counterpart. It lacks a black border around its center circle. It again has the edges cut off like in crosshair 21.
24 - The Q3A version of crosshair 5. Slightly larger than its QL counterpart. 
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.
28 - The Q3A version of crosshair 9. Slightly larger than its QL counterpart. It 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.


Largely personal preference. I think the most popular crosshairs are 2 and 7.

    cg_drawCrosshairTeamHealth   "2"


0 - off
1 - Shows a teammate's health and armor under their name when the crosshair is on them
2 - Same as 1, except that when low their health will be shown in a different color.


I just leave at its default of 2. I don't even really notice the team health information.
    cg_drawCrosshairTeamHealthSize   "0.12f"


The size of the crosshair team health information. The Min 0.10f, and Max 0.26f.


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_drawDemoHud   "1"


Shows a box during demo playback with keys for pausing and fast forwarding. It also allows you to hide the demo hud during playback.


Personal preference.

    cg_drawFPS   "0"


When set to 1, the current frames per second is displayed in the top right-hand corner.


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 a third party utility.

    cg_drawFragMessages   "1"


Displays the "you fragged suchandsuch" text across the screen when getting a frag.


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_drawFullWeaponBar   "0"


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.


I recommend using a value of 1, 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"


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.


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"


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


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"


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


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"


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


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

    cg_drawRewardsRowSize   "1"


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.


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"


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


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

    cg_drawTeamOverlay   "1"


When set to 1 a small box is drawn in the top right hand corner that lists teammates and their locations.
When set to 2 the same small box is drawn but closer to the bottom right.


I've never had a reason to turn this off, and its information can be quite useful. So far I find the position of the default
value of 1 less "cluttering" than 2. Others find the '2' position easier to read.

    cg_drawTeamOverlayOpacity   "0.75"


The opacity/transparency of the team overlay box background.


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_drawTeamOverlaySize   "0.16"


The size of the teamOverlay font. It has a minimum of 0.12, and a maximum of 0.22.


Depends on your particular hud setup, resolution, and personal preference. Also larger team games will have more players and therefore take up more space, so a balance will have to be struck between readability and screen real-estate.

    cg_drawTeamOverlayX   "0"


The X coordinate of the team overlay box.


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"


The Y coordinate of the team overlay box.


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_enemyCrosshairNames   "1"


Displays another player's name above their heads when the crosshair is pointed at them.


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_enemyCrosshairNamesOpacity   "0.75"


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.


I always thought the default was fine. This value also determines the opacity/transparency of the drawcrosshairTeamHealth information.

    cg_enemyHeadColor   "0x2a8000FF"
    cg_enemyLowerColor   "0x2a8000FF"
    cg_enemyUpperColor   "0x2a8000FF"


These three are the hex color code for bright modeled enemies.


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"


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


I ran the test suggested above in Q3A, and I did not experience what they mentioned. What I did experience was that when I rocket jumped every time I landed it sunk my view deeper into the floor. On pro-q3tourney4 at one point my view was so deep on the top ledge that it was like my view was hanging under it, and of course I could see anything that would be obstructed normally by the ledge. At a value of 10000 I could see the view correcting, slowly rising me upwards to where my view was supposed to be. I was unable to produce any other artifacts, not by rj'ing into walls, going through teleporters, making high speed jumps or maneuvering on jump pads.

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"


Alters how the player’s view camera changes in relation to aim position changes. When it is set to a value higher than 0, the view camera lags behind the player’s aim position, turning to it slowly and smoothing the frames in-between causing a mouse smoothing effect.


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"


Changes the appearance of the flag.

1 - Classic Flag
2 - Holographic Flag


Personal preference.

    cg_followKiller   "0"


When enabled: In spectator mode, when a player scores a frag, the spectator view automatically switches to that player.


Personal preference. Useful for casters.

    cg_forceEnemyModel   "keel/bright"


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


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:


    cg_forceEnemySkin   "bright"


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.


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"


Force enemies' grenades and rails to use 'Enemy Upper Color' (cg_enemyUpperColor).


I recommend using 1, the reasoning behind it is that it will enable you to determine which grenades are teammates and which are enemy grenades. Since most players use a /bright enemy model, the enemyUpperColor will affect both the model and the grenade.

    cg_forceTeamModel   ""


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


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


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.


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"


Force teammates’ grenades and rails to use 'Team Upper Color' (cg_teamUpperColor).


Since I do not force bright skins for teammates, I am free to change cg_teamUpperColor to whichever color I wish and have it not affect my team models. So, I use 0xFFFFFFFF (white) making my teammate's grenades white.

    cg_fov   "100"


The field of view in degrees.


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_gunX   "0"


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.


I recommend that at least for the lightning gun, set this to -10 (minimum) for thin LG

For a laugh, set it to a maximum of 10 with cg_drawgun 1 and run around for a disturbing rocket gunmodel.

    cg_gunY   "0"


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.


At least for the lightning gun I recommend setting this to 2.7 (centered) for thin and centered LG purposes.

    cg_gunZ   "0"


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.


I recommend setting this to -8 (minimum) on at least the lightning gun for thin LG purposes.

    cg_hitBeep   "2"



0 - No hit beeps
1 - Singular hit beep when a shot lands
2 - High pitched beep when a small amount of damage is done, low-pitch for larger amounts.
3 - Low pitched beep when a small amount of damage is done, high pitch for larger amounts.


At first I thought that only 2 and 3 were worth considering, and which of those was personal preference.

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"


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


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"


When set to 1 hitting a player will cause spark-like graphics to eminate from them.


Personal preference. On the one hand it can help with intuiting damage, on the other it can be distracting.

One good use for it is in TDM: to tell if the enemy is being hit by a teammate's machine gun fire and you'll therefore
have a better idea on what their health is.

    cg_impactSparksLifetime   "250"


Time in milliseconds before impact sparks fade out.


Personal preference.

    cg_impactSparksSize   "8"


Size of each spark when cg_impactSparks is set to 1.


Personal preference. Increasing their size can make them easier to see at the tradeoff of becoming distracting.

    cg_impactSparksVelocity   "128"


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.


Personal preference.

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, potentially providing information about enemy dodge motion as well.

    cg_itemFx   "7"


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)


Mostly personal preference, and in my opinion isn't a big deal.

Values under 4 appear immediately on spawn, and do not "balloon" up. It should be noted that the "ballooning" does not start until the weapon spawns. 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 values 0,1,2,3. Since I'm accustomed to the 'bounce and rotate' behavior I settled on setting 3.

    cg_kickScale   "0.5"


Determines how much the screen shakes when hit, values range from 0 to 1.


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"


Plays a distinct sound when you score a kill in any mode. This cvar is premium/pro only.

Values are as follows:

0 = Off
1 = Ting, sounds like a ball bearing hitting a teapot
2 = Tink, lowered pitched than 1, sounds like two teapots being tapped together
3 = Dramatic, sounds just like a horror movie trailer when the title is displayed, DUN!
4 = Woosh, sounds like a very fast flyby from a missle
5 = Drum, sounds like a drumstick striking a very thin tin bucket
6 = Bang, sounds like Sorlag dropping onto some bleachers
7 = Ding, sounds synthetic and very generic, like the fasten your seatbelt sign on a plane
8 = ChaChing, old timey cash register sound


It's a pretty minor issue, but I recommend just using 0. It is unneeded information.

    cg_lagometer   "0"


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.


Unless you are diagnosing lag problems, I recommend setting this to 0.

    cg_levelTimerDirection   "1"


Determines which direction the game timer counts. 1 counts down, 0 counts up.


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"


Enables the lightning impact effect on surfaces by the lightning beam.


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"


Ranges from 0 to 768. Determines the size of the lightning impact effect when impact is closer
than x units.


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"


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


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"


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%)


I recommend leaving this at default since I also recommend turning off low ammo warning sounds.

    cg_lowAmmoWarningSound   "1"


Controls what sound is played when low on ammo.

0 = Disabled

1 = Low Ammo Clip Reload Sound played for Low Ammo, "No Ammo" Click Sound played when out of ammo

2   "No Ammo" Click Sound played for both Low and No Ammo


I recommend setting this to 0 as it should be clear from the heads up display what your ammo is and adding this sound to it is unnecessary and potentially unnerving.

    cg_lowAmmoWeaponBarWarning   "2"


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


The default value is fine as the effect is barely noticeable.

    cg_marks   "1"


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.


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"


Every time a gun fires a small flash will be shown on the screen.

Also controls the "blazing" aura on the lightning gun when the model is shown.


I _strongly_ recommend setting this to 0 as it is a very distracting effect.

    cg_playerLean   "1"


Values between 0 and 1 are possible. They determine how far play models lean from side to side when strafing.


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"


Allows a client to disable some of the team related VO


I recommend 0 to cut down on the announcer.

    cg_predictLocalRailshots   "1"


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.


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.


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. Still some players swear by 1. Either way every player owes it to themselves to experiment with this cvar.

    cg_predictItems   "1"


Client prediction for picking up items.


Since this sometimes results in hearing the pickup sound yet not actually picking up the item, I recommend using 0.

    cg_railStyle   "1"


cg_railStyle [1|2]
1 = Rail core rail trail
2 = Spiral rail trail


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"


The time in milliseconds that the rail beam remains on the screen.


Very personal preference, however there are some interesting settings:

0 - Off, never shows the rail beam. Useful if you believe that the beam is distracting you.
1500 - This is the duration of the railgun's reload time, so when the beam has faded it means
you can shoot again.
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. EDIT: This was recently capped at 2000 in Quake Live because the developers are anti-fun. It is still possible in Q3A I believe.

    cg_scorePlums   "1"


When set to 1, small numbers will float out of enemy bodies or nearby during game events notifying you of points or frags gained.


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"


This is the hex color value of the color flash shown when receiving damage in general.


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"


This is the hex color value of the color flash shown when receiving damage from yourself such as during rocket jumps.


I recommend leaving this at the default.

    cg_screenDamage_Team   "0x700000C8"


This is the hex color value of the color flash shown when receiving damage from teammates.


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"


The opacity of the color flash when receiving damage from enemies or yourself.


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_Team   "200"


The opacity of the color flash when receiving damage from teammates.


I recommend turning off screendamage with cg_screenDamage 0 which renders the other screendamage cvars ineffectual so they can be left at default.

    cg_selfOnTeamOverlay   "0"


Displays the player's own name on the team overlay.


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"


Draws a shadow under the feet of players.


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"


Draws the items as flat symbols instead of 3d objects when set to 1.


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"


When simpleitems is on, this controls whether or not they bob up and down.

A value of 0 turns off this behavior.

A value of 1 makes all items bob.

A value of 2 makes only major items bob, such as armors and the megahealth.


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"


When simpleitems is on, this number controls their size.


The default is absolutely fine. I feel that increasing their size defeats the purpose of simple items, which is to make it easier to see around them (and they are somewhat less visually cluttering).

However the default size of simple items is substantially smaller than the size of the non-simple items such that the items cannot be seen at certain angles (the red armor on blood run is a typical example). Increasing the size mitigates this.

Alternatively, simpleItemsBob would be another way of mitigating it, if you could stomach the weirdness.

    cg_smoke_SG   "1"


This is the shotgun smoke shown while firing.


I recommend using 0 (off), as this smoke is distracting.

    cg_smokeRadius_GL   "64"


This controls the size of the smoke trail on grenades.


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"


Smoke trail for the Nail gun projectile.


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"


This determines the size of the smoke trail for the rocket projectile.


I strongly recomnend setting this to 0, as the smoke trails are highly distracting/obscuring.

    cg_specFov   "1"


When spectating a player, displays any changes they make to their fov, such as when zooming.


Personal preference. I have it off because I prefer to see the game with my personal fov setting even when spectating. It is interesting however to see what fov strong players might use when spectating them live and when they zoom. Unfortunately I don't believe there is any way to extract the exact value of the fov in use, although one could theoretically switch between specFov 1/0 and adjust their fov until the view matches.

    cg_speedometer   "0"


Displays a meter for the player’s horizontal velocity.

Values are: [0|1|2|3]

0 = Off
1 = lag-o-meter style graph
2 = value and graph under crosshair
3 = value under crosshair


I recommend leaving this at 0 unless you are training strafe jumps.

    cg_switchOnEmpty   "1"


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.


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"


When set to 1, switching to a weapon that is out of ammo is permitted.


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"


Determines whether or not the "beep" sound will be played when receiving a team chat.


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"


When set to 1, only chats in messagemode2 will be displayed. Handy as a "mute" function as many games do not feature team chat.


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" 


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.


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"


Flexibility factor for lightning gun shaft, 0 being the most flexible and 1 being the most rigid.


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), and seeing good players LG. So, I am always comparing the geometry of the whole screen to what I think it should be and try to make the patterns match using a balance of movement keying and mouse work.

A value of 0 is interesting as it teaches you some of the motions that may be needed for good LG'ing.

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"


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.


I recommend using 1 as it is truer to the way the pellets are actually behaving.

    cg_useItemMessage   "1"


When set to 1 this will display "Used suchandsuch" when using an item such as the Medkit.


Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.

    cg_useItemWarning   "1"


When set to 1 this will display "No item to use" upon pressing the use key (+button2) when the player has no item.


Either 1 or 0 is fine, it's a very minor issue as items aren't used very often.

    cg_viewsize   "100"


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.


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"


When under water the player's view will be distorted by a wavy undulating visual effect.


I recommend setting this to 0 so that you can see more clearly when under water.

    cg_weaponBar   "1"


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


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"


This is the hex color value of the small band around grenades.


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"


This is the field of view (fov) in degrees that will be taken when zooming.


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"


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"


When zoom is active the mouse sensitivity is run through an algorithm, and the result is multiplied by this number, except in the case of 0, in which case a different algorithm is used.

When cg_zoomSensitivity > 0, the sensitivity is multiplied by zoomsens which is then multiplied by k, where

k = arctan[ 0.75 * tan[cg_zoomfov°/2] ] / arctan[ 0.75 * tan[cg_fov°/2] ]

Remember that both fov and zoomfov are in _degrees_ and not radians.

When cg_zoomSensitivity = 0, the sensitivity is multiplied by k, where

k = arctan(tan(zoomfov * (pi/360)) * height/width ) * (360/pi) / 75

In this case do not specify degrees for zoomfov.


I recommend using zoomsensitivity 1 as it uses the more correct algorithm, and most do not need to change it.

One idea is to use a value of 0.864713, as the formula that makes the most sense to me personally is sens * k where k = tan[ cg_zoomfov°/2 ] / tan[cg_fov°/2 ], and the value of 0.864713 adjusts the result to what it would be with this other algorithm.

    cg_zoomToggle   "0"


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.


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"


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.


Unless you do a lot of chatting, leave this at 0.

    cl_autoTimeNudge   "0"


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.


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"



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


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"


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.


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 of one another, your mind expects your arm/hand to move the mouse more for a greater turn.

I got something like:

3.84 90 degrees
9.75 360 degrees
Note: this was with a 400 cpi mouse.

Set cl_MouseSensCap to the 360 degree sens. Set the base sensitivity to the 90 degree sens.

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"


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.


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"


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


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"


When using mouse accel, the sensitivity will not become greater than this value.


Depends highly on the mouse settings you use. With MouseAccelPower set greater than 2 using senscap becomes important as the sensitivity can skyrocket.

    cl_packetdup   "1"


Determines how many duplicate packets you send to the server to avoid packet loss.


Appears to make very little difference. I posted a thread about it here:


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"


The time for player interpolation, values range from -20 to 0.


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 enemies appear less smooth. I eventually settled on using -9 as it is between the two 'extremes'.  I probably had some convoluded mathematical reason for using -9 instead of -10, but I cannot recall anymore what it was, and it's very likely placebo anyways.

Everyone's brain works a little differently when it comes to hand eye coordination/prediction so use what works for you.

    color1   "7"


Color of the rail beam/core. <1-26>


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"


Color of rail disc/swirl effect. <1-26>


Personal preference.

     com_idleSleep   "1"


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.


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"


Maximum rendered frames per second.


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. Of course you will need a display capable of such a refresh to see this value, but even if you do not, it is possible that using a greater maxfps reduces latency of part of the process between input and frame draw.

    con_background   "0"


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.


Personal preference, however I do find 0 easier to read.

    con_height   "0.5"


This is how far down the console goes, the default value of 0.5 going half way down the screen.


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"


When con_background is 0, this value determines how transparent/opaque the console is.


Personal preference.

    con_scale   "0.5"


Determines the size of the console text, a range between 0.5 and 1 can be used.


I think the default of 0.5 is too small, so I use the maximum value, 1.

    con_speed   "3"


This value determines the speed at which the console comes down when "toggleconsole" is issued.


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"


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.


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"


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.


I usually only use this in the following circumstances:

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

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

Note, the 'pushback' of weapons is tied to damage, so if you set handicap 50 your LG for example will have less of a pushback and so can render LG practice with it unrealistic to normal gameplay.

    in_mouse   "2"


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)


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"


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.


Leave this at 0.

    m_cpi   "0"


This changes the units used by sensitivity and the cl_MouseAccel formula to more familiar ones.

There are a couple requirements:

1. That m_cpi is set to the CPI value of the mouse.

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.


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"


Values >0 turn on mouse interpolation which makes mouse movement smoother. Values range from 0 to 33.


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"


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.


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"


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.


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"


Sets your player model.


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


This is the cvar the client uses to enter password protected servers.


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"


Sets the bloom threshold when r_enableBloom 1 and r_enablePostProcess 1. The lower the threshold, the more bloom drawn. <0-1>


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.


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"


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>


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"


Sets the number of rendering passes for bloom effect.

0 - off
1 - one pass
2 - two passes


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"


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>


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 were made of white LEDs.

Probably a value somewhere between the two, erring on the saturated side is best as it takes advantage of bloom's ability to make player's and objects stand out while not making the contrast so high as to be hard on the eyes.

    r_BloomSceneIntensity   "1.000"


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>


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"


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>


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"


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.


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"


The height in pixels when r_mode is set to -1.


Leave at default unless you are setting a custom resolution.

    r_customwidth   "1600"


The width in pixels when r_mode is set to -1.


Leave at default unless you are setting a custom resolution.

    r_displayRefresh   "0"


Monitor refresh rate (in Hertz), useful for CRT monitors.


This depends on the display you have. First, try to get away with using the default of 0, which should use whichever value you have set in windows. However when you load the game, check your display's OSD to make sure it is using the desired value, if not you may have to set it manually. This is made more likely if you are not using your display's native resolution to play the game.

If you are using a CRT, you may have to try different values near your target value to get the desired effect. I recall that my CRT was set to 154 Hz, but Quake Live would only load at 154 Hz if I set displayRefresh to 150. Values it didn't 'like' would set the refresh rate to 60 Hz. So it may take some fiddling to get Quake Live to load at the desired refresh rate, and the older your hardware the more finnicky it is likely to be.

    r_dynamiclight   "1"


Dynamic Lights. (eg: rockets emitting light onto nearby scenery)


In general I recommend using 0 as the lights can be very distracting, especially in up close rocket battles. However I can see a lot of reasoning behind using 1 as the lights could give information away about an enemy position that wouldn't be available when using 0.

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"


Enables light bloom effects when r_enablePostProcess 1.


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"


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.


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"


Enable post processing. A setting of 1 is needed for bloom and r_contrast, but renders r_intensity ineffectual.


If you're low on FPS, setting this to 0 can help tremendously. Otherwise this is one of the main cvars that affects brightness and the overall look of the game, and so this is falls under personal preference.

    r_fastsky   "0"


When set to 1, the skybox will be replaced with a solid color.


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"


When r_fastSky is set to 1, the sky will be this color described in hex color code. The default is black.


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"


Renders all textures on the map at full brightness when set to 1.


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"


0 - Windowed
1 - Fullscreen


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"


Amount of image luminance applied to the in-game display. The higher the number, the stronger luminance present.


This is one of the main cvars for controlling brightness. I find that there are two main approaches to brightness:

High r_mapoverBrightBits, low gamma such as 1 (default).

Low r_mapoverBrightBits such as 1, and high r_gamma, such as 1.75. Perhaps r_overbrightbits
can also be lowered to 0 in this case.

The r_gamma default of 1, with the default mapoverBrightBits of 2 tends to be a bit too dark.
A nice quick fix is just r_gamma 1.3 or so.

    r_ignorehwgamma   "0"


Setting this to 1 enables the ignoring of hardware gamma settings.


This usually has the effect of simply making everything dark and having to crank up the other brightness settings to compensate. Nonetheless the results might be desirable, and is largely personal preference similar to r_enablePostProcess.

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 larger effect on brightness than the driver settings, which are usually at default. I wouldn't be surprised if the default brightness of AMD drivers vs. Nvidia drivers is the same.

    r_intensity   "1"


Intensifies the level of brightness added to textures and model skins. Doesn't seem to work when r_enablepostprocess is set to 1.


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"


When set to 1 it enables the light data lighting model. Is only effectual when r_vertexlight is set to 0.


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"


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


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"


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.


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"


Ambient lighting and radiance of the map. Along with r_gamma this is one of the "main" brightness cvars.

Behaves differently depending on r_vertexLight, r_enablePostProcess, and r_ignoreHWgamma.


There are many values that work great, and they depend on a variety of factors.

Here are some example brightness setups:

r_mapoverBrightBits 1
r_overBrightBits 1
r_mapoverBrightCap 255
r_gamma 1.75

r_mapoverBrightBits 10
r_overBrightBits 1
r_mapoverBrightCap 160
r_gamma 1.3

r_mapoverBrightBits 5
r_overBrightBits 1
r_mapoverBrightCap 255
r_gamma 1

r_mapoverBrightBits 1
r_overBrightBits 0
r_mapoverBrightCap 255
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"


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.


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 but sure is great to have.

    r_mode   "-2"


Sets the resolution the game will use when full screen. The values are as follows:

Mode -2: Use whichever resolution is currently in use, ie. what the desktop is using.
Mode -1: Use the resolution specified by r_customwidth and r_customheight
Mode  0: 320x240
Mode  1: 400x300
Mode  2: 512x384
Mode  3: 640x360
Mode  4: 640x400
Mode  5: 640x480
Mode  6: 800x450
Mode  7: 852x480
Mode  8: 800x500
Mode  9: 800x600
Mode  10: 1024x640
Mode  11: 1024x576
Mode  12: 1024x768
Mode  13: 1152x864
Mode  14: 1280x720
Mode  15: 1280x768
Mode  16: 1280x800
Mode  17: 1280x1024
Mode  18: 1440x900
Mode  19: 1600x900
Mode  20: 1600x1000
Mode  21: 1680x1050
Mode  22: 1600x1200
Mode  23: 1920x1080
Mode  24: 1920x1200
Mode  25: 1920x1440
Mode  26: 2048x1536
Mode  27: 2560x1600


Very personal preference, and not a simple issue. Will certainly depend a lot on what display is being used.

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.

Newer gaming displays might support 1080p or 4k at 360 Hz or greater. If you can get 125 fps at those resolutions and like the effect, go for it.

    r_overBrightBits   "1"


Ambient lighting applied to in-game entities or objects. The range is from 0 to 4.


I think that most setups will leave this at 1. Other values have more tempremental effects.

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"


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.


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.

    r_railCoreWidth   "6"


Rail trail core effect diameter (in pixels). The color is controlled by color1.


Very personal preference. One person told me that using 1 for corewidth helped their rail aim, others like the really thick look of segmentlength 1. Some have had all the r_rail settings at default for a long time and don't have any issue with them.

    r_railSegmentLength   "32"


Rail trail section length (in pixels). The color is controlled by color2.

Does not effect the 'spiral' when using cg_railstyle 2.


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"


Diameter of the segments in pixels.


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"


Enables simple MIP mapping, boosts performance.


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_teleporterFlash   "1"


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.


To see what this effect actually looks like, try devmap verticalvengeance duel and set timescale to 0.25 and go through the teleporter. Events will be taking place slow enough for you to see the flash.

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"


Sets texture filter.


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.


I recommend using the default. Although it's fun to try gl_nearest_mipmap_nearest.

    r_vertexlight   "0"


When set to 1 it enables vertex lighting, 0 is lightmap.


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"


Sets the resolution of the game when windowed (as opposed to fullscreen). Uses the same mode list as r_mode.


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.

Another nice use for this is if you wish to play at lower resolutions despite having a newer display that features a high resolution, as you don't have to worry about scaling or changes in refresh rate by simply playing in windowed. It also allows for quite a range of aspect ratios. I even tried a 1:1 aspect and it loaded without issue.

    rate   "25000"


Controls packets so that your downstream connection bandwidth does not get saturated. (Max bytes per second)


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"


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.


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_announcerVolume "1"


Controls the volume of the announcer.


Personal preference, however since the announcer plays often, what its volume should be is something worth considering imo.

    s_musicvolume   "0.25"


Volume of Quake Live's background music.


I strongly recommend setting this to 0 as it is unneeded and distracting.

    s_voiceVolume   "0.8"


Controls the volume of the in-game voice chat.


Personal preference. During team games it may be expected of you to at least listen to voice chats from teammates, and they may be giving out valuable information there. Otherwise whether you wish to listen to the often times unpredictable voice chats of random players on a public server is completely up to you. It might be a good idea to at least use a value that is lower than in-game sounds to prevent voice chats from drowning out important game information, but this also depends on the volume of the voices present.

    s_volume   "0.8"


The game's volume. Highly dependent on the computer, speakers/headphones, the operating system's audio settings, and the person.


Not too quiet, not too loud. All things in moderation.

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"


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.


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"


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.


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"


The speed of game events. This can only be adjusted on localhost or during demo playback. Use of this cvar for demos is no longer necessary since cg_DrawDemoHud was added, but it still has other uses..

For demos, setting values greater than 1 acts like a fast forward button, and values lower than 1 are like slow-mo. A value of 0 does not result in a pause during demo playback, and setting it to 0 on localhost or when on the disconnection screen causes the game to freeze. The closest thing to pause is timescale 0.000000000001 or a similar value.


Normal keys being pressed during demo playback ends the demo, so it is common to bind keys for use during demo playback elsewhere. For example:

bind 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

Use of cg_DrawDemoHud should eliminate the need for timescale binds, however you may wish to still bind +acc and +scores.

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.

Since timescale also works on localhost (devmap), another idea if you're really bored is to put on some tunes, add some bots on say Vertical Vengeance or Eye to Eye in a devmap FFA or CA game. Do a give all ; god, set timescale to 10 and run around shooting all the different weapons. Very awesome if you haven't tried it before. Do not do this if you are prone to seizures :-)

You can also set a low timescale value, record a game against a bot, and then play it back at normal speed. This will result in god-like aim, however I recommend against doing this often as it can make the normal game seem very fast and difficult to aim in. I have also noticed a strange phenomenon when doing this, in that when bots are being hit at a very high accuracy, for example with 95% lightning gun they can have dodging anomalies, appearing to "give up" and stand more or less still.

    winkey_disable = "0"


When set to 1 the windows key will be ignored by the OS when the game is running.


I recommend setting this to 1 to prevent accidental pressing of the windows key at a critical moment in the game.




alias makes up a command of the name you specify, and it does what you specified it to do.


alias <aliasname> "[commands]"

For example: alias greet "say hello there"

Creates a command called "greet", and when activated invokes the say command for the words "hello there".

It can be activated with the console:


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)



Assign an action to a key.


bind <key> "command/cvar1 ; command/cvar2 ; ...command/cvarN"

Multiple command/cvars can be added to a bind by separating them with a semicolon.

For example, bind g "weapon 3 ; cg_zoomfov 80 ; cl_timenudge -10"

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:

scroll Lock is "0x00"
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.



callvote <command> <variable>


Can also be abbreviated 'cv' for faster typing. Calls a vote for the players on the server to vote on. Some examples:

callvote kick annoyingtroll
callvote teamsize 2
callvote map FuriousHeights

Commands used in conjunction with callvote wiill autocomplete by hitting the Tab key.



Clears all the text from the console. I use this often.



Lists the game's commands.

You can also search for a command by typing cmdlist *searchstring.



Lists the vast majority of the game's cvars, their flags and their values.

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


Plays a demo that's in home/baseq3/demos

Gets rarely used as autorecorded demos usually have long names that are difficult to remember. Instead the user interface allows one to browse their demos, under Statistics -> Replays.



Enters a map with cheats on. Extremely useful for testing things on localhost. I often do the following for example:

Open a practice game and enter the console, type devmap verticalvengeance duel (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 exec a config with the following cvars:

g_startinghealthBonus "0"
g_startinghealth "999"
g_startingarmor "999"
bot_nochat "1"
bot_challenge "1"
bot_thinktime "0"

This makes the bot as strong as possible, and gives it a lot of health resulting in long fight times.



Disconnects from the current server and takes you back to the server browser.



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.



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.



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.



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.


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



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.



Gives a specific item/weapon to the player in devmap (cheats enabled).


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

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!



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.



Restarts mouse input. Required after a change to in_mouse, and can also be useful if the mouse input crashes for some reason.



Loads the hud.


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.



Kills oneself. Commits suicide. Jisatsu. Självmord.

Incurs an extra 1 second spawn delay.


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.



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.



Enter a chat prompt; chats typed here will go to teammates only. Useful for team communication.



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, and their name may be difficult or even impossible to type out.



Exits the game. Other players will see "suchandsuch disconnected"



Also exits the game, however other players will see "suchandsuch ragequits" with the 'rage' part colored in red letters.



Sets the player status to ready. By default this is bound to F3.



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.



Starts recording a demo.


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



Chats in messagemode1. Useful for chatting from the console, or for automatic binds.


say <message>



Chats in messagemode2 which is team chat. Useful for creating team chat binds.


say_team <message>



Takes a screenshot in .tga format. This is recommended with lower resolutions as the text shows up more clearly.



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.



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 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_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
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 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"



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



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.


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.



Stop recording a demo.



Used to set team. The valid teams are:


These can be abbreviated with just their first letter:



team <team>



Gives a person a message in-game that only they can see. Player must be on the server.


tell <playernumber> <message>

To get a player's number, type \players to see a list of who is on the server and what their numbers are.



This is a function that will switch a function between 1 and 0 by pressing a key.


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.


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.



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.   



Displays player coordinates in map, in the form of: (X Y Z) : Angle


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.



Restarts the renderer. Required for many r_ cvars to take effect.



Used to issue a vote of yes or no. Normally vote yes is bound to F1 and vote no is bound to F2.

I personally changed it so that F1 remains vote yes, but vote no is F4 so that I do not accidentally hit the wrong vote key.


vote yes
vote no



Executes the commands in a specified set. See the description of 'set' for more info.


vstr <cvarname that originated from set>



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.



Selects a specific weapon.Usage: weapon #


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



Selects the next weapon in the weapon cycle. Weapons without ammo, including the gauntlet are skipped, even when cg_SwitchToEmpty is set to 1.



Selects the previous weapon in the weapon cycle. Weapons without ammo, including the gauntlet are skipped, even when cg_SwitchToEmpty is set to 1.



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


writeconfig <filename>

Button Commands:

These activate when the key is pressed down, and deactivate when released. They are for use with the bind command.



Shows your weapon accuracies.

Different weapons have different accuracy values that are considered good. The vast majority of concern is given
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.



Fires weapon.



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



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.


The taunt key. Do not use this ever.



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



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.



Strafes left.



Strafes right.



Jumps, or swims up in the water.



Displays the scoreboard.



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


The voice chat key, hold down to talk.



Zooms in when activated, zooms out when deactivated.


Muffin's console guide:


Worthless information about your worthless mouse:


Special Thanks:


Guide by Lorfa: mklabyrinth@gmail.com

Last Update: August 12, 2022