Lorfa's 257

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

Faq:

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

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

This isn't saying anything against Muffin's guide, in fact his work made my job with this guide easier! Some of the descriptions were copied from there although most were typed from memory.

With this guide you should have everything you need to make a config.

Q. Recommendations huh? I've never heard of you, you probably suck! Why should I listen to you?

A. Granted I'm not a cypher or a rapha, but I've been at this a very long time and I've had a chance to run countless tests
on each cvar. I'm a cvar and setting maniac and have been since long before QL came out. I care about the truth of these options and the last thing I want is to spread misinformation.

Q. I've decided that I trust your advice, however I'm very lazy, can you just provide a config that uses all your recommendations?

A. Yes, however many cvars are personal preference, so you'll have to adjust those. Here's a template I made:

http://pastebin.com/EQTVHbXR

Alternatively you can look at a verbose version of the same config with small notes on each entry here:

http://pastebin.com/Z997JHps

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

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

Lern2Cfg:

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

There are a few ways to handle this:

Start from scratch, make a blank text file with a .cfg extension. Type everything out yourself and save it as yourname.cfg. I don't recommend this as it is a lot of typing and it takes plenty of experience to know all the commands and such by heart.

Use the game's built in config writing system, writeconfig. Set the game up how you like, then writeconfig yourname.cfg
Then edit yourname.cfg and take out the defaults/ineffectual cvars and organize it nice and neat. This works pretty well and is worth considering.

The third way (which I recommend) is to take an already made config and modify it until it suits your needs. The configs of noctis and stermy make excellent templates, and again the template I made is at:

http://pastebin.com/EQTVHbXR. 

Alternatively you can look at a verbose version of the same config with small notes explaining each cvar here:

http://pastebin.com/Z997JHps

Lern2CfgFiles:

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

qzconfig.cfg and repconfig.cfg, the only time I ever touch these is to delete them.

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

I recommend using this as it allows you to go hog wild with testing things and you never have to remember all what was changed to change it back because you can always just restart the game and everything will be back to normal. I love this behavior and make great use of it. The only cvar you really have to worry about handicap because it saves anyways. Make sure to put handicap back to 100 if you've been using it at some other value.

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

The file repconfig.cfg is uploaded to the website automatically and stored there, and will be downloaded if you login from another machine. It does not contain a complete set of variables which can have unpredictable effects, so I often clear this out. There is only one way to clear this out to start with a completely default setup from which to exec yourname.cfg, that is:

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

2. Login and click on "Settings" in the top right corner. Under the table of models there is a button that says "Reset settings defaults". Click on this and the website will reload.

What I usually do after this is load a practice game, exec yourname.cfg, do a vid_restart and writeconfig autoexec.
I recommend reloading configs after each update.

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

Method 1:

Erase the contents of autoexec.cfg, and put in one line: exec yourname.cfg

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

This allows you to test cvars and reset the game to get them back to normal. However, if you want to keep them longer for extended testing you have to edit yourname.cfg. So there are two levels, cvars you are testing in the current session, and cvars that have made it in to your config.

This method has a drawback that any settings to be saved beyond the current session must be inputted manually into yourname.cfg.

Method 2:

Leave autoexec.cfg as it is.

If you wish to test cvars only for the current session, just change what you like and restart the game to go back to normal.
If you wish to test them for a longer period of time, do \writeconfig autoexec. That way they will load when the game loads, however they aren't part of yourname.cfg yet.

If you decide you want to keep using them, edit yourname.cfg with the new cvars/values. So you have three levels of testing this way. You can also reload your configs without the extra step of editing autoexec.cfg. I recommend using this method.

Anyways, on to the cvars!

Cvars:

    cg_allowTaunt   "1"

Description:

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

Recommendation:

I strongly recommend setting this to 0. Although theoretically the enemy could give away their position by hitting their taunt key, I find that the annoyance players can cause with this far outweighs any potential advantage of leaving it at 1. Some players really enjoy hearing their own taunts and so leave this at 1. Personally I was overjoyed when this cvar was implemented and made it 0 the second I heard about it.

    cg_autoAction   ""

Description:

0/1/2/3

0 - Do nothing
1 - Automatically record a demo when the game starts or if it is already in progress.
2 - Automatically take a screenshot when the game is over.
3 - Automatically record a demo when the game starts or it it is already in progress and also
    take a screenshot when the game is over.

Recommendation:

I recommend using 1 so that you can always go back and review your games. I don't have much use for screenshots but if you are in an official competition you may wish to use setting 3. Also the screenshots can serve as a nice 'index' of your own demos.

    cg_brassTime   "2500"

Description:

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

Recommendation:

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

    cg_bob   "0.5"

Description:

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

Recommendation:

I highly recommend setting this to 0. The effect is unpleasant and unnecessary. The bobbing up and down of quake1 and doom2 was much more palletable although still something that you'd usually want to turn off.

    cg_bubbleTrail   "1"

Description:

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

Recommendation:

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

    cg_buzzerSound   "1"

Description:

When set to 1, an loud buzzer sound will play at the end of the match.

Recommendation:

I recommend 0 as it is noisy and completely unnecessary.

    cg_chatbeep   "1"

Description:

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

Recommendation:

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

    cg_crosshairBrightness   "1.0"

Description:

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

Recommendation:

I leave this at default, but it's very interesting to try 0. One strategy is to set your brightness settings high, like mapoverbrightbits 10 and gamma 1, and then set crosshairbrightness to 0 for a black crosshair. That way you have a bright screen and a dark crosshair, as opposed to a bright crosshair and a relatively dark screen. Theoretically this works just as well, if not better. As to which is definitely better I have no idea, and likely depends on the person.

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

    cg_crosshairColor   "25"

Description:

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

Recommendation:

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

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

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

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

    cg_crosshairHitColor   "1"

Description:

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

Recommendation:

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

    cg_crosshairHitStyle   "2"

Description:

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

0 = Off

1 = Colorize the crosshair based on damage dealt.

2 = Colorize the crosshair to color designated by cg_crosshairHitColor.

3 = Pulse the crosshair (exaggerated/scaled pulse)

4 = Colorize by damage and Pulse the crosshair.

5 = Colorize by cg_crosshairHitColor and Pulse the crosshair.

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

7 = Colorize by damage and pulse with smaller pulse.

8 = Colorize by cg_crosshairHitColor and pulse with smaller pulse.

Recommendation:

The default of 2 is fine. I experimented with the other values and found most of them unnecessary and/or distracting.

Setting 0 also works well, as the effect of the crosshair changing color can be seen as distracting. So, probably the values 2 and 0 are the most circumspect.

Styles 1, 4 and 7 could work as an accessibility feature for the hearing impaired.

    cg_crosshairHitTime   "200.0"

Description:

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

Recommendation:

I've run many experiments with this cvar, and I've come to the conclusion that the default is fine.

One idea I tried was setting it to 50 ms which is the reload time of the LG. A cell is fired every 50 ms, and if the beam hits it will blink crosshairHitcolor for 50 ms. That way the crosshair will only stay the hitcolor as long as I am hitting, and it will blink if I miss at all. While it sounds good on paper, in practice it felt absolutely horrible. It made me feel like the LG wasn't hitting, and I'd immediately start to make corrections that weren't necessary.

Conversely setting it to a value greater than 200 resulting in the opposite effect. Where I'd feel like I was hitting a great deal even when I wasn't. Probably most of this is due to just not being used to a different value than 200, but I think 200 is quite reasonable. That if during an LG battle 4 cells are off, I know I'm definitely off track and 200 ms gives me enough time to see it and react.

    cg_crosshairPulse   "1"

Description:

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

Recommendation:

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

    cg_crosshairSize   "32"

Description:

Size of the crosshair in pixels.

Recommendation:

Very much personal preference, and also depends on the crosshair being used. Some would say that a smaller crosshair is more precise, others would say that a large crosshair helps you to chunk the geometry of the screen better. The default is somewhere in-between.

Some crosshairs are quite interesting at large sizes, for example the dot crosshair (6) becomes a square.

    cg_drawAmmoWarning   "1"

Description:

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

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

Recommendation:

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

    cg_drawCrosshair   "4"

Description:

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

0 - No crosshair
1 - Thin circle with a dot in the middle
2 - Cross
3 - larger cross with a gap in the center
4 - Semi-transparent circle with a dot in the middle
5 - Similar to 1 except the circle is semi-transparent
6 - Small dot
7 - Similar to 2, except with a semi-transparent circle around it
8 - cross formed by four lines bent at right angles, the inside is lined with black trim
9 - Similar to 3 except the crosshair and its gap are even larger, with a dot in the middle
10 - Dot surrounded by two semi-transparent paranthesis-shaped figures
11 - Black circle filled in with cg_crosshaircolor.
12 - A circle that runs through the center of 4 short lines with a dot in the middle. A combination of crosshairs 9 and 1 but with black trim on the inside.
13 - Small thick circle, lined on the inside by black trim.
14 - A large circle with 4 gaps in it (north,south, east and west) and fins on each side
15 - A circle slightly smaller than 14, with 4 gaps (NSEW) in it, lined with black trim on the inside, and a dot in the middle.
16 - Two capital D's, one backwards and placed back to back with a small gap between them, both missing their "back" lines.
17 - A larger version of crosshair 12 with an additional semi-transparent circle around it.
18 - Four small, thin triangles placed on the corners of what would be a box shape, each
     pointing towards the center.
19 - A combination of crosshair 2 and crosshair 9, four lines with a gap in the middle, yet in this gap is a small cross. At normal size values this small cross appears as a dot.
20 - Draws a weird silver box in the center of the screen. Appears as some kind of unsupported crosshair object.
21 - The same as 1 as the crosshair values start over. Useful if using a hud and wish to use a crosshair value as a cvar test, yet retain the ability to use the other crosshairs without influence.

Recommendation:

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

    cg_drawCrosshairNames   "1"

Description:

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

Recommendation:

I recommend leaving this at 1. It can be useful information during the game to know who is behaving in what way. Also if this isn't set to 1 crosshairteamHealth will not be shown.There are some moments in the game where I haven't seen the enemy, yet I see their name flash on the screen momentarily, indicating that they were there, but had just moved out of my visual range. In this case the crosshairname information could be invaluable.

    cg_drawCrosshairNamesOpacity   "0.75"

Description:

The opacity/transparency of the name of the player shown when placing the crosshair over them. Obviously requires cg_drawCrosshairNames to be set to 1.

Recommendation:

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

    cg_drawCrosshairTeamHealth   "2"

Description:

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

Recommendation:

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

Description:

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

Recommendation:

I haven't had a reason to change this, although admittedly the default is a bit small for serious TDM where this information may be vital.

    cg_drawFPS   "0"

Description:

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

Recommendation:

I leave this at 0 unless I am diagnosing framerate problems (which luckily I haven't had). Very useful and important cvar though.

It should be noted that when com_maxfps has been changed from its default, the value given by cg_drawFPS can be misleading. For example, if you set com_maxfps to 120, cg_drawFPS will display 120. However in reality it is 125, since only integer values of 1000/x are accepted by com_maxfps. To be sure of the actual FPS value being shown, I recommend using a utility like Fraps.

    cg_drawFragMessages   "1"

Description:

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

Recommendation:

I recommend setting this to 0, as the frag text is unnecessary visual clutter that takes up a lot of space in the center of the screen.

    cg_drawFriend   "1"

Description:

Draws a yellow triangle over teammates' heads that can be seen through the walls in team based game types.

Recommendation:

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

    cg_drawFullWeaponBar   "1"

Description:

cg_drawFullWeaponBar [0|1]

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

1 = Draw all weapons available that can be found on the map in the weapon bar.

Recommendation:

I recommend leaving this at default, so that the weaponbar image remains consistent and therefore easier for your brain to chunk the geometry of the screen.

I can see some appeal in using 0 in that it gives peripheral visual information about what weapons you have and do not have. However imo this would work better with different behavior.

Say for example you just spawned and have only the MG, then when you pickup the rocket launcher, the RL icon/ammo will be displayed under the MG. There won't be spaces between the MG and the RL so that you could peripherally interpret the position of the entries as to which weapons you have. You could do this if spaces remained for the SG and GL. Granted it is less visually cluttering to bunch the weapons together like this, but without the spaces I find it inferior to cg_drawFullWeaponBar 1.

    cg_drawGun   "1"

Description:

Controls the displaying of weapons in 1st person view.

0 = hidden
1 = normal (bobs when moving)
2 = Stays still when moving
3 = Stays still when moving, but is also drawn transparent.

Recommendation:

For the LG I recommend using cg_drawgun 2, gunZ -8, gunX -10, and gunY 2.7. For the other weapons I think it is entirely personal preference.

I suppose showing the gun does cover up part of the screen but it helps some people to aim so it's a tough call.

Note: drawgun 2 is recommended for the thin LG setup, even though with drawgun 1 and the cg_gun variables the gun is also hidden. This is because walking will actually make the beam eminate from different places on the screen which could potentially throw off your aim. Drawgun 2 prevents this.

Note2: Using drawgun 3 instead of drawgun 2 when gunZ/X/Y are -8, -10, and 2.7 respectively hides most guns still, however with drawgun 2 the red "laser" on the shot gun is shown just a tiny bit at the bottom of the screen. This doesn't bother me at all and I don't even notice it so I leave it that way, however using drawgun 3 increases the effect as it is drawn with colors that are actually less transparent than the red laser.

    cg_drawItemPickups   "3"

Description:

Upon picking up an item, a notification message appears near the bottom left-hand corner of the screen. The options are as follows:

cg_drawItemPickups [0|1|2|3|4|5|6|7]

0 - off
1 - Item's icon only
2 - Item's text only
3 - Item's icon and text
4 - Time stamp only
5 - Time stamp and icon
6 - Time stamp and text
7 - Time stamp, icon, and text

Recommendation:

I recommend either using 0, or using 5 6 or 7. Since 4 doesn't tell you which item was picked up you could get misleading information if you picked up more than one item at close to the same time.

Values 1, 2, and 3 don't give you any information you really need, unless you are completely new to the game and don't know what the items actually are.

Values 5, 6 and 7 give you both a time stamp which you might use for item timing, and also an identifier for the item picked up.

I personally use 0, since I am accustomed to checking the game timer when I pick up an item I wish to time, so having an extra time stamp on the screen isn't useful to me and becomes visual clutter.

    cg_drawPregameMessages   "1"

Description:

When set to 1, during warmup above the "Press F3 to ready yourself" message the following will be written "the match will begin when more players are ready".

Recommendation:

I recommend setting this to 0. Since I and most people end up playing a lot of warmup, it's helpful to be able to turn off this extra text to make for less screen clutter.

    cg_drawRewards   "1"

Description:

Draws reward symbols such as a yellow skull for excellents (two frags in two seconds), and a rail symbol for impressives (two rails in a row).

Recommendation:

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

    cg_drawRewardsRowSize   "1"

Description:

This is actually the number of columns the rewards will be shown in, to which there is always only one row. If set to 9 for example, 9 symbols will be displayed across the screen, after which only a single symbol for a given award will be shown with a number at its top indicating the total count for that particular award.

Recommendation:

I recommend leaving this at 1 so that rewards take up the least amount of space on the screen. That's assuming you have drawRewards set to 1, if you have it at 0 then they won't be displayed anyways.

    cg_drawSpecMessages   "1"

Description:

When set to 1 and spectating, you will see "Press ESC and join button to enter game" and "SPECTATOR MODE press attack key to cycle through players".

Recommendation:

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

    cg_drawTeamOverlay   "1"

Description:

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

Recommendation:

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

    cg_drawTeamOverlayOpacity   "0.75"

Description:

The opacity/transparency of the team overlay box background.

Recommendation:

I've never felt the need to change this, but it's a great feature to have. Using 0 is an interesting idea as it cuts down on the clutter as its background box is not shown. However the background box adds contrast to the text, so it's a tradeoff.

    cg_drawTeamOverlayX   "0"

Description:

The X coordinate of the team overlay box.

Recommendation:

Never had a reason to change the position of the team overlay box. I noticed that it's based on some odd values. The hud is based on a 640x480 layout, so the Y cvar is upper bounded at 480, and lower bounded at -480. The x cvar is upper bounded at 640, and lower bounded at -640. Both default to 0. This is a little strange since the team overlay by default is in the top right hand corner, perhaps its box starts at something like (500, 238) if the center of the cartesian coordinates was in the center of the screen. Instead the center used appears to be where the box appears by default. Not a problem, just unusual.

Of course this all changes for cg_drawTeamOverlay "2" at which point a completely different center value is used.

    cg_drawTeamOverlayY   "0"

Description:

The Y coordinate of the team overlay box.

Recommendation:

Never had a reason to change the position of the team overlay, although it's nice to have the option. I can see a hardcore TDM player wanting to adjust its position.

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

Description:

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

Recommendation:

I recommend using 0x00ff00ff (as green as it gets) for all of them. Although I can see that many different values and combinations could work just as well.

The format is 0xRRGGBB and the last two characters are for the brightness. FF should be as bright as it gets.

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

    cg_errordecay   "100"

Description:

This is a strange one. Someone on an ET|QW forum had this to say about it:

cg_errordecay controls how fast a prediction error is decayed off to smooth out any jerkiness. A prediction error is, very basically, what occurs when the client and server disagree on the location you're in. Unfortunately, there are many problems with the prediction code several of which carried over into ET btw) that make it easy to cause prediction errors, so by setting cg_errordecay really high and exploiting any of the prediction errors, you can effectively move your camera away from yourself far enough to see through walls. It doesn't really seem to be possible to generate enough error within 500ms to give yourself any advantage. In other words, setting this cvar to high values produces a wallhack effect.

Source: http://www.urbanterror.info/forums/topic/1613-kicked-for-cg-errordecay/

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

chg: cheat protected cg_errordecay cvarPlease don't, set an upper bound instead. Players should be allowed to use 0 and anything from 0 to 200 is surely fair. This is important, your view of the gamestate should, if desired, be as accurate as possible, even if it's not smooth; separating the player's view from the actual body position is not good for high-level play.

For those who do not know what this does - when your position that the server tells your client differs from the one predicted by the client it has to be corrected. The actual player position is corrected instantly but your in eyes view is smoothly transferred over a number of milliseconds equal to the value of cg_errordecay. This means you're not seeing an accurate crosshair nor information that you base movements on. Try this in baseq3 (prevented in CPMA) to get a feel for it - load a map with a teleporter. Set cg_errordecay 5000. Enter the teleporter and watch your view travel through the level, try moving while this happens, your player is already at the tele dest while your view goes on its tour.

Source: http://promode.ru/?q=node/1127

Recommendation:

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

It's locked between 0 and 100 in QL, and defaults to 100. As far as I know no one has ever gotten a "wallhack" effect. Perhaps a setting of 0 will keep your view as true as possible during an error.

One piece of evidence was acquired by using an obscure cvar not mentioned in this guide: cg_showmiss 1. Just moving around on the server produced many "prediction errors". I have trouble believing that a 100 ms correction is going on during each of these times, but if so I'd rather have it be 0 ms.

I did some testing, playing with 0 for some time on various servers with different latencies. So far I've come to the conclusion that 0 produces undesirable effects. With ~75 ms I would often experience a stuttering effect when being hit by enemy players, especially with the LG (as if actually being electrocuted!). This effect is jarring and unpleasant. It happens less with 50 ms, and I assume even less with a lower ping. For now I've raised it to values like 40 which lessens the stuttering effect.

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

    cg_filter_angles   "0"

Description:

Alters how the 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.

Recommendation:

I don't recommend using this cvar as it shows you some incorrect information. If you do choose to use it, keep it at low values such as less than 1. I know that at one point, Stermy used settings of it like 0.02 or 0.03 which already has a noticeable effect. Set it to 300 for a laugh (drunken mouse).

    cg_flagStyle   "1"

Description:

Changes the appearance of the flag.

1 - Classic Flag
2 - Holographic Flag

Recommendation:

Personal preference. This cvar is Premium only.

    cg_followKiller   "0"

Description:

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

Recommendation:

Personal preference. Useful for casters.

    cg_forceEnemyModel   "keel/bright"

Description:

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

Recommendation:

The default is absolutely fine. Keel fills in the hit cylinder nicely and the /bright keeps him bright. His hitsounds and footsteps are fairly easy to hear. I use keel/bright and have no complaints.

TankJR is another common choice though, as he is easier to see being slightly larger. The robotic hitsounds Tank makes can be difficult to discern though.

Since all models feature a /bright or /sport option now, many models are now candidates for use instead of the most popular ones, tankJR and keel. One radical idea is to use bones, who is arguably the most difficult character to see as he takes up the least of the hit cylinder. That way if your crosshair is on or near him you'll be getting a hit for sure since he is a smaller target.

Other models that work alright are visor, sarge and sorlag.

Here is a screenshot of some of the models in the hit cylinder. The cylinder size may have been adjusted slightly since this screenshot was taken though:

http://xdcclan.com/screenshots/ql_new_hitbox.jpg

    cg_forceEnemySkin   "bright"

Description:

When forceEnemyModel is not set, this cvar will force other players to use a specific version of their model, such as "bright" or "sport". Use blank "" to turn off.

Recommendation:

Since I recommend forcing enemy models, it isn't important what value this is set to. If you don't use forceEnemyModel, at least forcing them to their bright or sport versions will make for easier to see enemies.

    cg_forceEnemyWeaponColor   "0"

Description:

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

Description:

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

    cg_forceTeamModel   ""

Description:

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

Recommendation:

The criteria to look for in a team model would be that they would be fairly quiet as it is more important to hear enemies than teammates, and show up as noticeably different than enemies so that you do not confuse the two.

What tends to happen is that a wide variety of team models work fine, whereas fewer enemy models seem comfortable. So it is hard to give a recommendation other than what I use, which is bitterman/red. As long as the above criteria are satisfied you could use just about any model.

    cg_forceTeamSkin   ""

Description:

When forceTeamModel is not set, this cvar will force other players to use a specific version of their model, such as "bright" or "sport". Use blank "" to turn off.

Recommendation:

Since I recommend forcing team models, it isn't important what value this is set to. It's personal preference whether you wish for your teammates to be bright or not.

    cg_forceTeamWeaponColor   "0"

Description:

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

Recommendation:

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

    cg_fov   "100"

Description:

The field of view in degrees.

Recommendation:

I recommend using a value between 90 and 105. The famous arq0n who is the lead developer of cpma said that 102 was the "best" fov. However he never stated why and I cannot think of any reason for this.

   cg_gibs   "10"

Description:

When the player is killed beyond a certain amount of health they will be "gibbed", that is explode into sparks.

Recommendation:

I strongly recommend 0. For one gibbing a player will make a terrible scratching noise, and second the sparks effect makes for visual clutter.

    cg_gunX   "0"

Description:

The X direction of the gunmodel when cg_drawGun is set to 1 or 2. However the coordinate system for the gun model is such that the X axis behaves like a normal Z-axis. Higher values move the gun forward, lower values move it backward.

Recommendation:

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

Set it to a maximum of 10 with cg_drawgun 1 and run around for a disturbing rocket gunmodel.

    cg_gunY   "0"

Description:

The Y direction of the gunmodel when cg_drawGun is set to 1 or 2. However the coordinate system for the gun model is such that the Y axis behaves like a backwards x axis. Positive values move the gun model to the right, negative values move it to the left.

Recommendation:

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

    cg_gunZ   "0"

Description:

The Z direction of the gunmodel when cg_drawGun is set to 1 or 2. However the coordinate system for the gun model is such that the Z axis behaves like a normal Y axis. Higher values move the gun upwards, lower values move it downwards.

Recommendation:

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

    cg_hitBeep   "2"

Description:

0/1/2/3

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

Recommendation:

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

However, it is possible to get a consistent beep sound for the GT/MG/LG/RG/NG/CG by having these use 1. After all with a little experience you already know what damage these weapons do per hit, so it is slightly less distracting in my opinion to have them all make the same beep.

It definitely should be bad to use values other than 2 or 3 for the SG/GL/RL/BFG/PM since they have variable damage and you could lose valuable game information this way. Of course crosshairhitStyle could also be used to display this information.

    cg_hudFiles   "ui/hud.txt"

Description:

Sets the directory of which heads up display (hud) to use. Huds are always in ui/, which looks for them either in the pak file, or in the home/baseq3/ui directory. Three huds are included:

ui/hud.txt - default hud
ui/hud2.txt - Smaller more uniform hud with the timer in the top left
ui/hud3.txt - Large hud

Recommendation:

It's largely personal preference, however there are a lot of cool huds out there. Visit http://qlhud.eu/ to see a great many of them. Better yet, the site that qlhud.eu was based off of just recently returned, visit here: http://qlhud.net/

Many pro configs come with their huds so you can check those out too. A custom hud is not needed and plenty of top players use the default or large huds, but they can be fun to try out.

Another option is to make your own, either by modifying a hud that you like, or using a utility such as the online one at http://visualhud.pk69.com

    cg_impactSparks   "1"

Description:

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

Recommendation:

I recommend 0, although I understand that some players prefer to use 1 for damage information
purposes.

For example in TDM it becomes easy to tell if the enemy is being hit by a teammate's machine gun fire and you'll therefore
have a better idea on what their health is.

    cg_impactSparksLifetime   "250"

Description:

Time in milliseconds before impact sparks fade out.

Recommendation:

I leave this at default since I usually turn impactsparks off.

    cg_impactSparksSize   "8"

Description:

Size of each spark when cg_impactSparks is set to 1.

Recommendation:

I leave this at default since I usually turn impactsparks off. Increasing their size can make them easier to see at the tradeoff of becoming distracting.

    cg_impactSparksVelocity   "128"

Description:

The speed and direction of impact sparks when cg_impactSparks is set to 1. Values range from -128 to 128. Values less than 0 will feature impact sparks travelling downwards. Setting this to 0 means that the sparks will stay at the point of damage.

Recommendation:

I leave this at default since I usually turn impactsparks off.

Setting this to 0 has the effect of making them less distracting, while being more difficult to see at a distance. Also in an up close battle, using a SparksVelocity different from 0 allows you to discern which damage sparks are older than others by their height.

    cg_itemFx   "7"

Description:

When cg_simpleItems is 0, this controls how the items behave.

cg_itemFx [0|1|2|3|4|5|6|7]
0 = static
1 = bounce
2 = rotate
3 = bounce and rotate
4 = static (balloon spawn)
5 = bounce (balloon spawn)
6 = rotate (balloon spawn)
7 = bounce and rotate (balloon spawn)

Recommendation:

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

Values under 4 appear immediately on spawn, and do not "balloon" up. One idea is that the enemy can pick up the weapon while it was ballooning providing less visual information than if it had appeared suddenly such that one can miss the fact that they did pick up the item. Therefore the "competitive" options may be to use under 4.

It should be noted that the "ballooning" does not start until the weapon spawns. Personally I don't mind the ballooning of the default value (7).

    cg_kickScale   "0.5"

Description:

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

Recommendation:

I _strongly_ recommend setting this to 0 as it makes getting hit much less jarring. Depends on having cg_screendamage set to a non-zero value. So, you can set cg_screendamage to 0 and get this effectively made 0 as well.

    cg_killBeep   "7"

Description:

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

Values are as follows:

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

Recommendation:

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

    cg_lagometer   "0"

Description:

cg_lagometer [0|1|2]

1 = Show netgraph
2 = Show netgraph + client ping estimation.

How to interpret the graph from Yakumo:

Top bar is prediction
Blue is interpolation between two valid frames
Yellow is extrapolation since the last frame (waiting for another)

Yellow is bad, it will increase a lot if using timenudge.

On the top, green is ping for a properly received snapshot
Yellow is a properly received snapshot, but the previous one was suppressed to stay under the client set rate.
Red is packet loss

So.. if the top line is all blue, and the bottom line is completely flat and green then your connection is in great shape.

Recommendation:

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

    cg_levelTimerDirection   "1"

Description:

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

Recommendation:

I recommend setting this to 0 so that the timer counts up to the time limit, as it is generally easier to add than to subtract when timing items. Also this is the more common setting so you are much more likely to hear players giving out times in public team games that are derived from the timer counting up.

    cg_lightningImpact   "1"

Description:

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

Recommendation:

I recommend setting this to 0, although I can see that leaving it at 1 gives some feedback about the distance between you and the target. In practice I haven't found this feedback to be particularly useful, but others might. Something to test for yourself.

    cg_lightningImpactCap   "192"

Description:

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

Recommendation:

Since I use lightningimpact 0 I just leave this at default. Players that use 1 might try experimenting with this to see if the distance to target information can be heightened by adjusting this value.

    cg_lightningStyle   "1"

Description:

Controls the lightning stream effect.

cg_lightningStyle [1|2|3|4|5]
1. Blue twisty double beam
2. White jagged zappy single beam
3. Large blue/white zig zaggy rolling bolt beam from q3test
4. Thin blue/white single beam
5. Semi-Transparent picmip'd style triangular beam from Q3

Recommendation:

I personally recommend Style 4 as it is the thinnest. Plenty of strong players use setting 5, setting 2, and even setting 1. I have never seen setting 3 in a config, and I've read a lot of configs.

If you have cg_drawgun set to 1 or 2, and then hide it with cg_gunZ -8, cg_gunX -10, and center it with cg_gunY 3 your beam will be slightly thinner than normal. I think this works well in combination with lightningstyle 4.

    cg_lowAmmoWarningPercentile   "0.20"

Description:

Controls percentile level of ammo available before issuing a low ammo warning, for both the lowammoWarning sound and the "low" message on the weapon bar.

Min: 0.01 (1%)
Max: 1.00 (100%)

Recommendation:

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

    cg_lowAmmoWarningSound   "1"

Description:

Controls what sound is played when low on ammo.

0 = Disabled

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

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

Recommendation:

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

    cg_lowAmmoWeaponBarWarning   "2"

Description:

Controls the weapon bar ammo warning display.

cg_lowAmmoWeaponBarWarning [0|1|2]
1 = Draw weapon bar ammo value in red when empty
2 = Draw weapon bar ammo value in yellow when low and red when empty

Recommendation:

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

    cg_marks   "1"

Description:

When set to 1, burn marks and bullet holes and such will be shown on the walls for a short time after weaponsfire. Setting this to 0 turns off the effect.

Recommendation:

In general I recommend using 0 as it is extemporaneous information. I personally only turn it on when someone is drawing on the walls to see their "art" :-)

It does however give some potentially useful information, as enemy prediction/rockets that hit a wall will leave the mark showing for 10 seconds. This information could be used to interpret their location and where they might be headed. Probably duel is the game type where this would be most useful. Something to consider.(Thanks TIE for reminding me of this important detail).

    cg_muzzleFlash   "1"

Description:

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

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

Recommendation:

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

    cg_playerLean   "1"

Description:

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

Recommendation:

Largely personal preference. It could be argued that the player lean is vital information about their direction, it could also be argued that this is distracting. I use a value of 0.7 to strike a middle road between the two, erring on the side of the lean.

    cg_playTeamVO   "1"

Description:

Allows a client to disable some of the team related VO

Recommendation:

I recommend 0 to cut down on the announcer.

    cg_predictLocalRailshots   "1"

Description:

There are two explanations, one:

A value of 0 will feel less responsive in high ping environments but may prevent wrongly predicted rail shots and/or impacts.

Two:

When set to 1 the rail graphic is drawn instantly as if there were no latency at all. When set to 0, the rail graphic is drawn when the server sees the shot, so there is a latency shown.

Recommendation:

I recommend at least trying 0 as it gives a better clue as to what sort of lag is actually experienced and so adaptations can be made. If I am playing with the railbeam being drawn, using 1 tends to make railing more difficult for me. For others the opposite is true. Either way every player owes it to themselves to experiment with this cvar.

    cg_predictItems   "1"

Description:

Client prediction for picking up items.

Recommendation:

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

    cg_projectileNudge   "0"

Description:

Turns on or off projectile nudging, accepted values are from 0 to 80.

Recommendation:

When it was first added to the list of cvars there were no range limits. Setting it to a value of maybe 2000 or -2000, I forget which made it so that plasma balls would appear to hit their target immediately after firing even if they hadn't made it to the target yet. Same with rockets: the explosion would appear where the crosshair pointed immediately after firing, even if it hadn't really made it there yet.

The idea behind this is that when the player is on a laggy server there is a firing delay, so this cvar was designed to offset that delay by drawing the projectile so many ms ahead as if it had been fired earlier. This would apply to the rocket launcher and the plasma gun for sure, but perhaps the grenade launcher and BFG as well.

The effect (assuming it's there) is virtually undetectable. Use at your own placebo risk.

EDIT: February 2014, apparently its effect has been disabled for some time.

    cg_railStyle   "1"

Description:

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

Recommendation:

Mostly personal preference, however the spiral rail trail is slightly more centered as you can test by turning on cg_marks, railing a wall at eye level and then walking up to it and seeing where the mark lines up with the crosshair. At close range style 2 will be more centered, at the cost of this extra spiral graphic that cannot be removed or adjusted (other than color).

    cg_railTrailTime   "400"

Description:

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

Recommendation:

Very personal preference, however there are some interesting settings:

0 - Off, never shows the rail beam. Useful if you believe that the beam is distracting you.
1500 - This is the duration of the railgun's reload time, so when the beam has faded it means
you can shoot again.
1300 - Since you must still react to the rail beam fading, one idea is to subtract your would-be reaction time from 1500. So if your reaction time was estimated to be 150 ms, you could use 1350 and shoot as soon as you see the beam fade. (Thanks aeoL for this idea).
200 - Fades twice as fast, gives it a "snappy" feeling.
500 - One-third the reload time
999999 - I don't recommend doing this online, but in devmap you can make some neat railgun
beam art as the beams will stay for as long as you like. They are also color unique, so if
you change rail colors and fire again it will not affect the color of the previous beam.

    cg_rewardsVO   "1"

Description:

When set to 1 voice chats related to awards will be played. These include "Excellent!" and "Impressive!".

Recommendation:

I recommend using 0 as it is extemporaneous aural information.

    cg_scorePlums   "1"

Description:

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

Recommendation:

I leave this at 1. It is very minor visual clutter, and helps me to understand the scoring in some game types. Technically this is extemporaneous information since I either don't need the scoring information, or know it well enough that I don't need these numbers. So I can see the reasoning behind setting it to 0. It is a very very minor issue though.

    cg_screenDamage   "0x700000C8"

Description:

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

Recommendation:

Although information is given about the direction of enemy fire, I find this vague and difficult to interpret on the fly, even with many adjustments to the below screendamage cvars. It is also rare that you do not hear an enemy shot, or have a strong idea where the enemy is shooting from.

With this in mind I recommend using 0, as I find it to be more of a distraction/screen clutter than useful information. 

Setting this to 0 also renders cg_kickScale ineffectual. So if you use screendamage 0, and prefer kickscale to be 0 as well, you do not need to set kickscale to 0.

    cg_screenDamage_Self   "0x00000000"

Description:

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

Recommendation:

I recommend leaving this at the default.

    cg_screenDamage_Team   "0x700000C8"

Description:

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

Recommendation:

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

    cg_screenDamageAlpha   "200"

Description:

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

Recommendation:

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"

Description:

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

Recommendation:

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

    cg_selfOnTeamOverlay   "0"

Description:

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

Recommendation:

This is useful if you wish to see what your teammates see on the overlay, and learn what the various locations are called. Otherwise leave it at 0 because it is extemporaneous information.

    cg_shadows   "1"

Description:

Draws a shadow under the feet of players.

Recommendation:

I recommend leaving this at its default of 1. It seems to be useful visual information in predicting shots, and there are some rare cases when the player's shadow can be seen, but their model cannot.

    cg_simpleItems   "0"

Description:

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

Recommendation:

Personal preference. It is easier to see around simple items, but more difficult to see the items themselves from certain angles/distances.

    cg_simpleItemsRadius   "15"

Description:

When simpleitems is on, this number controls their size.

Recommendation:

The default is absolutely fine. A lot of players seem to be cranking up the value to the maximum or near its maximum these days, which makes for hilarious looking items. To me this defeats the purpose of simple items though, which is to make it easier to see around them.

However the size of the simple items is substantially smaller than the size of the non-simple items which might seem a bit strange to players not used to it and so could raise this value for a more "normal" feeling.

    cg_smoke_SG   "1"

Description:

This is the shotgun smoke shown while firing.

Recommendation:

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

    cg_smokeRadius_GL   "64"

Description:

This controls the size of the smoke trail on grenades.

Recommendation:

I recommend setting this to 0 as with many grenades comes many trails making it difficult to see. Since the grenade flies at an awkward trajectory however, one idea is to temporarily set a low value for this such as 8 to get a feel for how grenades fall/bounce. Ultimately though it is just a visual distraction.

    cg_smokeRadius_NG   "16"

Description:

Smoke trail for the Nail gun projectile.

Recommendation:

If you never play on maps that feature the nail gun, you can leave this at its default. Otherwise it is easier to see with this at 0.

    cg_smokeRadius_RL   "32"

Description:

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

Recommendation:

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

    cg_speedometer   "0"

Description:

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

Recommendation:

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

    cg_switchOnEmpty   "1"

Description:

When set to 1, trying to shoot a weapon that has run out of ammo will automatically switch to a weapon that does have ammo, or to the gauntlet if there are no others with ammo.

Recommendation:

Either 1 or 0 is ok.

Technically 0 is superior since you have control over which weapon to switch to instead of a weapon that is automatically decided for you. In this case though you need to train yourself to switch manually when the last shot has been fired, or you will end up shooting nothing.

However I've managed to use 1 without issue for pretty much my entire time in QL, as have many other players, so I feel that it is not terribly critical.

    cg_switchToEmpty   "1"

Description:

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

Recommendation:

I recommend leaving this at default. There are cases when you are anticipating picking up ammo and don't want to take the extra time to switch to the weapon _after_ you pick up the ammo. Also less noise is made without unnecessary switching.

    cg_teamChatBeep   "1"

Description:

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

Recommendation:

Completely personal preference. I can see that if someone regularly played with a large team and they relied heavily on team binds that were constantly in use during the game that turning this off might be a good idea. Otherwise it is an incredibly minor issue.

    cg_teamChatsOnly   "0"

Description:

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

Recommendation:

Leave this at 0 unless you have a strong need to mute other players on the server and would rather not mess with the block command.

    cg_teamHeadColor   "0x808080FF"
    cg_teamLowerColor   "0x808080FF"
    cg_teamUpperColor   "0x808080FF" 

Description:

These three cvars determine the torso color, "pants" color, and head color respectively of the teammate's model when they are set to a /bright model. After the 0x, each color channel gets two characters and the last two are for brightnessl: RRGGBB FF.

Recommendation:

I personally do not force a bright model for teammates as I am used to shooting at bright models. I use bitterman/red for teammates.

The brightness channel seems to have no effect on player model color unless using all 0's, so I recommend just leaving it at FF. Some examples on how to use the hex color system:

0xFF0000FF = As red as it gets
0x00FF00FF = As green as it gets
0x0000FFFF = As blue as it gets
0xFFFFFFFF = As white as it gets
0x000000FF = As black as it gets
0x00FFFFFF = Turquoise

I set teamuppercolor to white (0xFFFFFFFF) and use cg_forceTeamWeaponColor so that grenades from teammates become white.

    cg_trueLightning   "1"

Description:

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

Recommendation:

I remember reading somewhere that truelightning 1 is supposed to turn on a special client side prediction (up to 80 ms) which should make it so that if the beam is on the player it will count as a hit. In this case the beam is snapped to the crosshair, therefore aiming with the beam or the crosshair is just personal preference.

In practice I am not sure that truelightning 1 actually does this, but the substantial difference between 1 and say 0.98 might be an indicator that this is so.

If you turn on marks (cg_marks 1) and go to a laggy server say with 200 ms, set truelighting to 1 and shoot the LG at a wall while strafing you will see the marks lag behind the LG beams position substantially. Setting truelightning to 0 however matches them up perfectly.

I thought this may be an indicator of the lg's behavior in-game, but someone mentioned that the wall marks do not operate under the same guidelines as enemy players. Anecdotal evidence seems to suggest this is true as LG'ing at even very high pings doesn't seem to behave this poorly at values > 0, although it could just be me because my previous game was QW in which I had to put up with a lot of LG wagging so I might be unconsciously making adapting motions despite the way the beam is being drawn.

When you couple this with the netcode's other issues, such as the hit cylinder sometimes lagging behind/in front of where the enemy player is displayed, it becomes rather difficult to determine much of anything for sure.

Rather than enter into this technical mess without any developer confirmations I don't concern myself with the beam or the crosshair really. Instead I aim by patterns: I know what good LG'ing is supposed to look like from experiencing times when the LG hits well (hitbeep), watching good players and even observing the occasional aimbot. So, I am always comparing the geometry of the whole screen to what I think it should be and try to make the patterns match using a balance of movement keying and mouse work.

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

There are many players claiming a "best" value for truelightning. I have heard 0.5, 0.75, 0.77, 0.95 and 1. An interesting thing about 0.75 is that it used to be the default value, which was later changed to 1.

I think the best recommendation I can give is to pick a value between 0.5 and 1 and stick to it.

    cg_trueShotgun   "0"

Description:

When set to 0, the shot gun spread will appear slightly random, more like a real shotgun.When set to 1, the spread graphic will appear as the game actually uses it, in concentric rings.

Recommendation:

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

    cg_useItemMessage   "1"

Description:

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

Recommendation:

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

    cg_useItemWarning   "1"

Description:

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

Recommendation:

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

    cg_viewsize   "100"

Description:

Literally the size of the view on the screen. Using lower than 100 shrinks the screen and applies a grey border on what's left.

Recommendation:

There is some appeal to using values like 90 or 95 as they can help you focus on the screen in some cases, but really just using the default of 100 is the only thing I can recommend.

    cg_waterWarp   "1"

Description:

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

Recommendation:

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

    cg_weaponBar   "1"

Description:

This is the display of the "weapon bar", which shows which weapons you have and what ammo you have for each one. It has 4 values:

4 - Large Q3 style weapon bar that shows only upon changing weapons
3 - Horizontal weapon bar shown in the lower center
2 - Vertical weapon bar shown on the right side
1 - Vertical weapon bar shown on the left side
0 - off

Recommendation:

The only value I don't recommend is 0, as currently there is no other way to display this important information. Otherwise it is entirely personal preference.

    cg_weaponColor_grenade   "0x007000FF"

Description:

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

Recommendation:

I set this to the same value as cg_teamUpperColor (0xFFFFFFFF), and use cg_forceTeamWeaponColor 1. That makes my own grenades the same color as those of my team.

    cg_zoomfov   "22.5"

Description:

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

Recommendation:

I recommend a higher value than the default of 22.5, which is very low. When the zoom fov is set very low it becomes disorienting as the difference between zooming and one's normal fov is so large. A value of 60 seems quite reasonable to me, and I wouldn't go lower than say 37.

Obviously what works best for you with this value will depend somewhat on what fov you use when not zooming. Also if you play a lot of SpaceCTF you may find that the lowest possible value is best since the ranges are so far on that particular map.

     cg_zoomScaling   "1"

Description:

With Zoomscaling 1, zooming in will not happen instantly, but over a small time frame over which the fov will be moved between your current fov and the zoom fov. Similar to pressing the zoom-in button on a camera and having it zoom in quickly.

When set to 0 the fov changes instantly from the normal fov to the zoom fov.

Recommendation: I recommend using 0 as it is faster. However some players find the effect of an instantaneous fov change unpleasant and so leave this at 1. It isn't terribly critical and is mostly personal preference, as even with zoomscaling 1 it zooms in fairly quickly.

    cg_zoomSensitivity   "1"

Description:

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

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

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

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

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

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

In this case do not specify degrees for zoomfov.

Recommendation:

I recommend using zoomsensitivity 1 as it uses the more correct algorithm, and most do not need to change it. There's some appeal to lowering it just a tad for some added slow down during long distance rails, but it isn't really necessary.

    cg_zoomToggle   "0"

Description:

When set to 1, pressing the zoom key remains zoomed in until it is pressed again, as opposed to zooming while the key is held down.

Recommendation:

I recommend using 0 as it is extra work (and time) pressing and releasing the zoom key. Some find holding down a key unpleasant and benefit from setting this to 1.

    cl_allowConsoleChat   "0"

Description:

When set to 1 and something is typed into the console, upon pressing enter it will be chatted in messagemode1. Commands and cvars have to be preceded by a \ to work. This will be added automatically by the autocomplete if you press [tab] after typing part of a command or cvar.

Recommendation:

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

    cl_autoTimeNudge   "0"

Description:

When set to 1, supposedly sets the value of cl_timenudge based on ping.

Recommendation:

When set to 1, it will override any value of cl_timenudge including 0. It will internally use values lower than -20 depending on the ping. It causes a lot of stuttering of both your overall view and of enemy players. I find that despite its side effects I aim better with it set to 1 on laggy servers, such as those with 70 ms or greater. Some find the side effects overly detrimental to their aim.

    cl_demoRecordMessage   "2"

Description:

0/1/2

0 - No record message
1 - Message appears in the bottom center of the screen that says "recording" and states the
current file size of the demo.
2 - A small text is shown at the bottom left corner that says "REC".

Recommendation:

I recommend 0 unless you aren't used to demos and want to make sure it is recording, then I would use 2 to keep it out of the way.

   cl_maxpackets   "125"

Description:

Controls how many updates you send to the server.

Recommendation:

I recommend leaving this at 125. Using the old default of 63 feels laggy.

With 125 fps at maxpackets 63 one packets will be sent every other frame. With 125 fps and maxpackets 125, one packet will be sent every frame.

Supposedly like com_maxfps, it is limited to integer values of 1000/x. So for example: 125, 111 (close enough), 100, 50, 40.

It will also be changed internally depending on the value of com_maxfps, and what fps is currently being displayed. This is because at most it can send one packet per frame. If you have very inconsistent fps, you may benefit from maxpackets 63 as the feel will be more consistent.

    cl_mouseAccel   "0"

Description:

When set to a value > 0 the mouse sensitivity will increase as the velocity increases. Values < 0 are supposed to exhibit negative acceleration, however the behavior is buggy and not recommended.

The formula used by the game is as follows:

B + (A(v-c))^(P-1)

B = sensitivity
A = cl_MouseAccel
v = velocity (lower bounded at 0)
c = cl_MouseAccelOffset
P = cl_MouseAccelPower (lower bounded at 1)

When m_cpi is at its default of 0 both v and c are measured in counts per millisecond.
When m_cpi is set to the CPI of the mouse, v and c are measured in cm/second.

Recommendation:

Like sensitivity, this is about as "personal preference" as it gets.

One idea is to join an empty map and find an area where you can easily recognize two points that are directly in front of you and directly to the left or right at a 90 degree angle. Then with mouseaccel 0 make a comfortable motion with the mouse to the right. Adjust your sensitivity until the comfortable motion makes a 90 degree turn to the right. Then do the same for left and use a value in-between the two in an attempt to satisfy both directions.

Do the same for a 360 degree turn, taking note of the sensitivity value you arrived at. Don't worry that they aren't exactly multiples one another, your mind expects your arm/hand to move the mouse more for a greater turn.

I got something like:

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

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

Then go back to whichever position you were using to do the tests, and practice 180 degree turns. Increase cl_mouseAccel in increments of 0.05 until a 180 is comfortable.

The values you are left with should provide a nice "template" for adjustments and reflect some underlying physical truth about what mouse motions your hand is comfortable with making.

If you wish to know for sure how much sensitivity is being added per unit of velocity, you can use the following formula:

Sensitivity = Sensitivity + (cl_MouseAccel * V)

Where V = [(Velocity)(CPI / 2.54)] / 1000

Velocity is in centimeters/second.

Note: this formula assumes: cl_mouseacceloffset 0, cl_mouseaccelPower 2, and m_cpi 0.

For example:

CPI = 400
Sensitivity = 4
cl_mouseaccel = 0.1
Velocity = 50 cm / second (so if you had accel 0 and a base sens of 25 cm/360 that'd be two 360s in one sec!)

Sensitivity_at_this_speed  = 4 + (0.1 * V)

V = [(50)(400 / 2.54)] / 1000
V = 7.87402

Sensitivity_at_this_speed = 4 + (0.1 * 7.87402)
Sensitivity_at_this_speed = 4 + 0.787402
Sensitivity_at_this_speed = ~ 4.78

    cl_mouseAccelOffset   "0"

Description:

The velocity at which mouse acceleration starts.

Using positive values has the effect of delaying the application of acceleration until a given velocity is reached when
mouseaccel is > 0.

Measured in counts/millisecond when m_cpi = 0 which it is by default.

When m_cpi = the cpi of your mouse, it is measured in cm/second.

Negative values are permitted, in which case the accel behaves as if the velocity started at a higher speed, however this is silly when cl_MouseAccelPower is at its default of 2 because it is identical in effect to raising the base sensitivity.

Recommendation:

I recommend leaving this at 0 unless you know that what you're getting is what you want. To convert an offset velocity to m/s run the value through this:

[(v * 1000) / (CPI / 2.54)] / 100 = m/s

So for example cl_MouseAccelOffset 5, at 400 CPI is 0.3175 m/s.

If you prefer centimeters per second you can use this instead:

[(v * 1000) / (CPI / 2.54)] = cm/s

    cl_mouseAccelPower   "2"

Description:

The power curve of the mouse acceleration. In the code it is subtracted by 1, so power 2 is actually taking mouse accel to a power of 1, which is the same as multiplying it by 1. This results in a linear acceleration (a straight line).

Recommendation:

Personal preference. I would leave this at default unless you are sure that this is something you want.

Personally I have tried many times over the years to derive some advantage from this cvar, experimenting with both higher (greater than 2) and lower curves (between 1 and 2). I did not succeed in acquiring anything of merit.

    cl_mouseSensCap   "0"

Description:

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

Recommendation:

Depends highly on the mouse settings you use. Currently I am using 7.5 as this is the highest sens I can tolerate with my mouse accel at this time. With MouseAccelPower set greater than 2 using senscap becomes important as the sensitivity can skyrocket.

    cl_packetdup   "1"

Description:

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

Recommendation:

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

http://www.esreality.com/index.php?a=post&id=2111747

Perhaps a value of 0 is recommended if you have a clean connection, assuming that 0 is accepted by the code. Using 0 is a placebo risk.

Recently tests were run by Flashsoul and myself using wireshark. No extra packets were sent regardless of the packetdup value. Some still report a clear change in bandwidth usage using different values, so perhaps its mechanism is less obvious than sending more, or less packets.

    cl_timeNudge   "0"

Description:

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

Recommendation:

One idea is to use different timenudge values for different weapons. For example using -9 for most weapons, and 0 for the LG/RG.

As I understand it timenudge sets the time allowed for interpolation (adding images between two points for smoothness). At -20 this time is low or none resulting in other players appearing choppier while being displayed sooner. I also suspect that lower values of timenudge are truer to the player's actual position as opposed to a predicted one, although it's very difficult to know for sure.

The lower framerate can make prediction more difficult. Just imagine trying to catch a baseball that you can only see at 0.5 FPS, vs. one that you can see at 120 fps. At 0.5 FPS its trajectory would look choppy and unpredictable.

Now imagine that the smooth 120 fps baseball came at a price of a large latency, say 500 ms. It would also be harder to predict, but not as difficult as in the previous example because you could guess where it was in the future based on its easily seen trajectory in the past, just get ready to catch it earlier than you would normally.

None of the timenudge values are this extreme, but since quake is so fast and things occur in tens of milliseconds, being 20 ms off on a shot can mean the difference between a hit and a miss.

As for what to use I really can't say. I know players who have excellent aim with -20, and others who have excellent aim with 0.

For me personally using -20 ends up throwing off my aim since it reminds me of my quakeworld days which has a very responsive feel to it. QL isn't as responsive so I found myself taking less time to aim and just shooting as fast as possible, often missing quite a bit.

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

    color1   "7"

Description:

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

Recommendation:

Personal preference. I will say though that color 17 for both makes for a blue rail that stands out very little if that's something you'd like.

    color2   "25"

Description:

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

Recommendation:

Personal preference.

     com_idleSleep   "1"

Description:

Use sleep frames to reduce CPU usage.

Description from the changelog:

Added cvar to disable idle sleep, to prevent FPS issues that may be caused by low resolution timers in Windows XP or on-demand CPU scaling. Setting com_idleSleep to 0 will restore the previous behavior of using up an entire CPU to wait until the next frame. Unless disabling com_idleSleep has a direct effect, it is highly recommended that com_idleSleep is kept ON.

Recommendation:

If you are having trouble reaching your desired framerate, you might try com_IdleSleep 0. I personally get 200 fps if I set maxfps 250 with com_idleSleep 1, I have to change it to 0 to get the full 250.

     com_maxfps   "125"

Description:

Maximum rendered frames per second.

Recommendation:

The default of 125 is absolutely fine, as is the maximum of 250.

Only integer values of 1000/x are taken, to a max of 125 and a minimum of 30. Maxfps values are always rounded up, so if you input com_maxfps 112, it will really be 125. If you put in 105 it will really be 111.

Currently cg_drawFPS has a cap to prevent it from displaying a number that is higher than com_maxFPS. So the values shown by drawFPS can be incorrect, as for example com_maxfps 120 will show up as 120, even though it is actually 125.

If your computer can handle a stable 250 fps, it's definitely worth using. Of course maxpackets maxes out at 125, so you'll be sending a packet once every other frame. I find this to be a minor issue though, and prefer the extra smoothness of 250, even though my display refresh of 154 Hz only allows me to see an extra 29 fps. I long for the day that I might look upon 250 fps at 250 Hz.

    con_background   "0"

Description:

When set to 1 the console will have a background like snow on a television. When set to 0 the console background will completely black, or transparent as determined by con_opacity.

Recommendation:

When using 0, I find that setting con_opacity 0 as well seems to be easiest on the eyes. I still personally prefer 1, as the console text is easier to read.

    con_height   "0.5"

Description:

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

Recommendation:

I have yet to find a need to change this. I suppose I am used to the console going half way down since the earliest versions of quake 1.

    con_opacity   "0.75"

Description:

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

Recommendation:

If I happened to be using con_background 0, I like to set this to 0 as it seems to make for the easiest reading.

    con_scale   "0.5"

Description:

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

Recommendation:

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

    con_speed   "3"

Description:

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

Recommendation:

I strongly recommend setting this to a very high value, such as 999 such that the console comes down instantly. As someone who uses the console often waiting for it to go up and down is a waste of time.

    con_timestamps   "0"

Description:

Adds a time for each console entry. Time is given in M:ss:hhh where m is minutes, s is seconds, and h are hundredths. Works only when a game is in progress.

Recommendation:

I haven't had much use for this other than for some technical stuff. However it can be useful to give information about when something happened, like that you died 1 second after picking up the LG, or what the game time was when the mercy limit was hit.

Unless you really want the information, I recommend leaving it at 0 for a less cluttered console.

    handicap   "100"

Description:

Sets your player handicap.

With handicap 100, you can have a maximum of 200 health and 200 armor, which will tick down to 100. Shots do normal damage.

With handicap 50, you have a maximum of 100 health and 100 armor, which will tick down to 50. If you already have 100 armor, you will be unable to pick up more armor, until it ticks down to at least 99. Shots will do half of their damage.

Recommendation:

I usually only use this in the following circumstances:

1. When warming up with a bot. I use handicap 50 to prevent the bot from dying too quickly from my shots, therefore I get more aim practice time before the bot dies and I have to go and find him again.

2. When practicing LG with a friend, on for example hellsgate. Using a value like handicap 75 prevents the other player from dying so quickly and so more practice time is available. Setting it much lower than this makes it so that players run out of ammo before anyone has died. If both players lg at rather low accuracies they may find that a higher value works better.

3. When playing in say a Clan Arena game with much lower skilled friends, I have set up to handicap 50. The effect is very powerful and can make it extremely difficult to get good scores.

    in_mouse   "2"

Description:

The method that Quake Live will use for mouse input.

-1 - Windows cursor input, subject to cursor ballistics
0 - No mouse input
1 - Dinput (direct input)
2 - WM_INPUT (raw)

Recommendation:

The most recommended value is 2. Some like the slightly different feel of dinput. I would only use -1 if you've made sure that the windows cursor ballistics haven't added any unwanted acceleration or other such anomalies.

    in_nograb   "0"

Description:

When enabled the game will not "grab" the mouse, that is to say that it will not confine the mouse pointer to the center of the screen.

A known bug sometimes occurs where it is not reset back to 0, which causes the sensitivity to increase 100 fold and fixes the players view towards looking at the ground. Setting in_nograb back to 0 usually fixes the problem.

Appears not to require an in_restart after a change in its value.

Recommendation:

Leave this at 0.

    m_cpi   "0"

Description:

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

There are a couple requirements:

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

Note: In order to set m_cpi correctly, it should take into account any driver-level sensitivity setting that affects the game. For example, you have a 1000cpi mouse with a driver setting of x0.6 - you would set m_cpi to 600, not 1000. Many driver-level settings do not affect the game when in_mouse is 2. If not sure a quick test should clear things up.

2. That m_yaw is set to 0.022

After that, sensitivity changes from a dimensionless multiplier, to degrees per centimeter, and cl_MouseAccelOffset changes from counts per millisecond to centimeters per second.

In order to convert your existing sens and accel settings to the new scheme with m_cpi, there are some existing calculators out there that will do the conversion. If you want to do this manually, you can use the following formula for conversion from old to new.

new_sens = old_sens * (old_yaw * m_cpi / 2.54)
new_sensCap = old_sensCap * (old_yaw * m_cpi / 2.54)
new_accel = old_accel * (old_yaw * (m_cpi/2.54)^2 ) / 1000
new_pitch = old_pitch * (0.022 / old_yaw)
new_yaw = 0.022

One nice feature of this is that when changing the mouse CPI, the only value you have to change is m_cpi. So if you were using a 400 CPI mouse and had all your m_cpi values set, then switched to a mouse with 800 CPI, you wouldn't have to adjust your sensitivity any. Just set m_cpi to 800 and you're all done.

Recommendation:

Personal preference. I have however found that a lot of mice do not seem to have the exact CPI value stated which throws off the calculations when trying to convert from m_cpi 0 to m_cpi >0.

    m_filter   "0"

Description:

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

Recommendation:

I recommend m_filter 0. This is because interpolation adds frames in-between counts, and these wouldn't normally be shown as they aren't true to the actual counts that came in. It also adds a tiny bit of latency, which is negligible at values like 1 but becomes significant at values like 8+. It may also add what feels like positive acceleration, albeit this would be extremely tiny.

Some players adore the feeling m_filter 1 gives them and swear by it. Even top players have used it with great success. It's the kind of cvar that technically should be bad, but in practice the issue is not so simple. So you can give 1 a try to see if you like it. However I cannot recommend using >0.

    m_pitch   "0.022"

Description:

The vertical mouse sensitivity. When m_cpi = 0, this is in degrees per mouse count but is multiplied by sensitivity to produce the final x degrees/count value.

Recommendation:

Highly personal preference, however here are some ideas:

Leave m_yaw at 0.022, and use m_pitch 0.022 as well. That way the horizontal sensitivity remains identical to the vertical sensitivity for a consistent feel on both axis.

Increase m_pitch somewhat such that it is higher than m_yaw, to reflect the notion that it is more difficult to move the mouse up and down than it is side to side. This makes rocket jumps easier, turning while aiming downwards easier, and makes the horizontal sensitivity feel less sensitive in a way that may benefit hitscans.

Decrease m_pitch somewhat, such that it is lower than m_yaw. This will make it less likely that 180s result in some unwanted pitch movement. Most of the precision mouse motion needed appears to be in the horizontal movement, whereas the pitch is needed just to set up. For example if an enemy is on a high ledge and you wish to lg him, you set the pitch position so that the crosshair is level to him, then use the horizontal mouse motion to do the aiming. The pitch
is no longer needed, and much of the game is this way.

Use what works for you.

    m_yaw   "0.022"

Description:

The horizontal mouse sensitivity. When m_cpi = 0, this is in degrees per mouse count but is multiplied by sensitivity to produce the final x degrees/count value.

Recommendation:

As a rule of thumb I try to get by without ever changing this value as it makes it easier to read other people's configs and get an idea of what sensitivity they are using if I myself am using 0.022 yaw.

Random info:

The minimum number of degrees the quake guy can turn is 360/65536 or roughly 0.005493164 degrees. This is about 1/4 of 0.022.

Input algorithm looks like this:

dy = M (B + (A(v-c))^(P-1)) dx

dx is counts, dy is degrees. M is m_yaw.

Therefore increasing m_yaw increases both the base sensitivity _and_ the accel, as they are multiplied by it. So doubling m_yaw doubles the base sensitivity and the accel.

Also it should be noted that cl_MouseSensCap is ignored when cl_MouseAccel is 0.

Using accel 0 bypasses this input algorithm and appears to use something like this:

dy = M (B) dx

So that m_yaw * base sens = degrees per count. (dy/dx = M(B))

The same technical stuff that applies to m_yaw also applies to m_pitch.

    model   "sarge/default"

Description:

Sets your player model.

Recommendation:

The important difference between models is the sounds they make, since most players force models and won't see which model you have selected. Ideally you want sounds that are quiet as not to obscure important gaming sounds.

Ranger, Bitterman, Anarki and Xaero are all fairly quiet.

Doom, Bones, and Biker are ok too but are slightly louder.

Crash and Sarge are louder still, but remain popular.

Razor has nice jumping sounds, bad hit sounds.

Slash is somewhere in-between. Sounds aren't great, but not bad either. One nice thing is that her sounds are always short in duration.

Uriel is also in-between. The sounds are quieter than Slash's, however last for a longer duration.

Janet while her jump sound and high health hit sound is fairly benign, her lower health hit sounds are quite loud. Mynx sounds almost the exact same.

Lucy is similar to Janet in this regard, but worse. Jump sound fine, hit sounds aren't particularly loud but they are invasive and disturbing imo.

Klesk is also in the same boat, but worse still. The jump sounds are fine, however all the hit sounds are terrible. Arguably worse than Janets/Lucy.

Grunt is noisy, and it sounds like he's snoring or snarling with every jump.
Hunter is rather noisy, and terrible jump sound "oooah oooah oooah".
James is loud, and his jumping sound sounds like a robot is choking.

Keel is certainly loud. He makes a great enemy model since his sounds are fairly distinct. There is some bent appeal to using him as a player model in addition to an enemy model since then you make the same sounds as your opponent, and if your opponent is using enemy model keel you can get an idea of what they hear.

TankJR is loud as well. The hit sounds are less distinct than keel imo.

Major is loud is unnerving. Same with Sorlag.

Orbb is the worst sound wise. High pitched shrieking for every action.

    password   ""

Description:

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

Recommendation:

None. Quake Live prompts you for the password when connecting to a password protected server from the website so you usually don't have to mess with this cvar.

    r_BloomBrightThreshold   "0.25"

Description:

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

Recommendation:

A value of 1 simply turns bloom off. A value of 0.25 as the default wasn't a bad choice as it enables you to see all the bloom effects just fine. Using very low values causes bloom to simply take over the screen in an effect that looks like every near death experience ever portrayed on television.

Note:

The bloom menu can be found under game settings --> advanced --> post process. It features built-in presets where it says "Bloom Settings". These are quite useful for exploring the features of bloom. The "selective greyscale" option is quite interesting. I personally needed to turn down the sceneIntensity for it to be useable though.

    r_BloomIntensity   "0.50"

Description:

Sets the bloom intensity when r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the more intensive and bright the bloom effect will be. <0-10>

Recommendation:

Either the default, or a value that is not much higher than the default works. High values cause the bloom "spheres" to get totally out of hand to the point that it feels like looking at a brightly lit christmas tree through a very foggy window. Using zero simply turns off blooms completely.

    r_BloomPasses   "1"

Description:

Sets the number of rendering passes for bloom effect.

0 - off
1 - one pass
2 - two passes

Recommendation:

Whenever I have tested bloom I have always needed to set this to 2. Otherwise the effect is too subtle. I would consider using 1 if I was to use bloom on a regular basis however.

    r_BloomSaturation   "0.800"

Description:

Sets the degree of color saturation applied to the bloom effect when r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the more colorful the bloom effect will appear to be. <0-10>

Recommendation:

Very personal preferency. When set to its maximum blooms will be very colorful, and for example the green keel/bright model is enveloped in a very bright green halo. When it's 0 keel's "jacket" glows white as if it where made of white LEDs.

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

    r_BloomSceneIntensity   "1.000"

Description:

Sets the intensity of brightness applied to the non-bloomed world when r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the brighter the non-bloomed world will appear to be. <0-10>

Recommendation:

Values greater than 1 tend to cause walls that are as bright as the sun. Unlike r_contrast (see below) there are no dark surfaces at all.

Values less than 1 are more interesting. While the default is fine, a value of 0.5 can offset the brightening effect of colorcorrect. That and r_gamma of course.

    r_BloomSceneSaturation   "1.000"

Description:

Sets the degree of color saturation applied to the non-bloomed world when r_enableBloom 1 and r_enablePostProcess 1. The higher the value, the more colorful the non-bloomed world will appear to be. <0-10>

Recommendation:

I have no problem with the default. Values greater than 1 do exactly what the saturation button does on a television. Turns the colors up to the point that they look downright weird.

As with sceneIntensity, lowering the value has much more interesting results. A setting of 0 causes a world rendered in grey scale. Yet explosions, the LG beam, players and some objects retain their color. So one setup that is geared towards visibility of important objects such as weapons fire and player models could try using 0 and cranking up the settings for the objects.

    r_contrast   "1.0"

Description:

When r_enablePostProcess is set to 1, this controls the contrast.

A setting of 0.5 makes the screen appear as if it has a grey haze on it.

A setting of 2 gives everything a very bright and colorful look in an unpleasant way. Colors
become very sharp and hard on the eyes.

A setting of 10 renders everything bright orange, bright white, and dark black. Dark surfaces
appear as sun spots on the surface of the sun. Good for a laugh.

Description:

I recommend leaving this cvar at default. The only thing that can be gained from changing it in my opinion is using a value less than 1 such as 0.5, which makes the rocket explosions appear much more transparent. It comes at a terrible cost of making the rest of the game difficult to see though.

    r_customheight   "1024"

Description:

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

Recommendation:

Leave at default unless you are setting a custom resolution.

    r_customwidth   "1600"

Description:

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

Recommendation:

Leave at default unless you are setting a custom resolution.

    r_displayRefresh   "0"

Description:

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

Recommendation:

Use at least 120 Hz if possible. If not, try to get it as high as you can. Many LCDs are stuck at 60 Hz, or 75 Hz. CRTs can go much higher, provided the resolution stays fairly low. I recommend a utility like powerstrip to pencil your refresh rates. The game will not override them unless they are far from the value of displayrefresh. For example I use 154 Hz at 800x600, and set r_displayRefresh to 150, since it doesn't take a value like 154. My refresh rate remains at 154 regardless. However if I set r_displayrefresh to 75, I'll get 75 Hz. If I put in a value it doesn't like, it defaults to 60 Hz. Check your display's OSD to find out what refresh rate is actually being displayed. You may have to use an odd refresh rate value to eliminate tearing when using a CRT. I get tearing at both 120 and 125 Hz at 1024x768. I have
no idea what value to use to eliminate it, luckily I prefer 800x600. Probably this kind of  behavior varies with the display.

    r_dynamiclight   "1"

Description:

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

Recommendation:

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

Also, powerups can glow, and flags can glow which means they could sometimes be seen with dynamiclight 1 when they could not with dynamiclight 0. Definitely something to consider.

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.

Using r_vertexlight 1 renders dynamiclights ineffectual. However r_vertexLight 2 renables it.

    r_enableBloom   "1"

Description:

Enables light bloom effects when r_enablePostProcess 1.

Recommendation:

I personally recommend against using bloom, so if you have postprocess set to 1 then set r_enablebloom to 0. When bloom is enabled anti-aliasing doesn't work. With some tinkering there are some interesting bloom setups available but in general I find its effects distracting.

    r_enableColorCorrect   "1"

Description:

Enables color correction when r_enablePostProcess 1. At the time of writing this seems to only activate when chosen from the menu. Even when colorcorrectactive shows 1 it still isn't active.

Recommendation:

Whenever I mess with bloom I always have to turn this option off otherwise the display becomes too bright and colors become washed out.

    r_enablePostProcess   "1"

Description:

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

Recommendation:

If you're low on FPS, setting this to 0 can help tremendously. I actually recommend setting this to 0 anyways. It changes the brightness a bit but I like the effect, and it's nice to know that my machine is having an easier time running the game.

    r_fastsky   "0"

Description:

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

Recommendation:

Largely personal preference. I personally have a toggle set, so that on maps that have a particularly bright sky such as Thunderstruck of Sacellum, or even Almost Lost I can turn it off, but leave it on for other maps.

It's important to note that with r_fastSky 1, you cannot see through portals.

    r_fastSkyColor   "0x000000"

Description:

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

Recommendation:

I leave this at black, however I did try some other values and thought the effect was quite nice. If I used fastsky all the time I would seriously consider setting a value other than black.

Note: The hex color code used for this is only 6 characters which is different from the 8 character code used by
team/enemy colors. If you add the extra characters you will get unpredictable effects.

    r_fullbright   "0"

Description:

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

Recommendation:

The default value of 0 is absolutely fine. With 1 and vertexlight 1, the map becomes shockingly bright, even with mapoverBrightBits 1 although I thought this was at least playable, but very, very strange looking. I think it boils down to that if you use vertexlight 0 it has very little effect, but with vertexlight 1 it takes off like a wild animal. On some maps it will be nearly impossible to get a playable setup with vertexlight 1.

    r_fullscreen   "0"

Description:

0 - Windowed
1 - Fullscreen

Recommendation:

I strongly recommend playing in fullscreen. However fullscreen is not default in case there are problems, so this cvar is a must for every config.

    r_gamma   "1"

Description:

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

Recommendation:

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

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

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

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

    r_ignorehwgamma   "0"

Description:

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

Recommendation:

This usually has the effect of simply making everything dark and having to crank up the other brightness settings to compensate. Under normal circumstances I see no reason to use 1. I can see that if you play on different systems often, that it may be useful to use 1 in an effort to secure a more consistent brightness level across systems. I think in practice though this isn't really so realistic as the display is more likely to have a large effect on brightness than the driver settings, which are usually at default. I wouldn't be surprised if the default brightness of ATI drivers vs. Nvidia drivers is the same. So I suppose I recommend just leaving this at 0.

    r_intensity   "1"

Description:

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

Recommendation:

When r_enablePostProcess is 0 this cranks up the brightness in a very unpleasant way. Colors will quickly wash out. It basically turns all normal map lights into white hot nuclear reactions, and/or each surface seems to reflect light more brightly than it normally would such as that a little bit of light turns them into the sun's corona. Values lower than 1
are not allowed. I recommend leaving it at its default of 1.

    r_lightmap   "0"

Description:

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

Recommendation:

Similar to r_fullbright, this is kind of an "extreme" setting. It's tricky to get it to where the maps aren't simply too bright. It takes all the textures of the walls, rendering them in greys and bright whites. I find it easier to get a playable game with it than with vertex + fullbright. Perhaps it is comparable to drawflat in other games. Maybe it is better used only for mappers who wish to see their light sources more clearly. I recommend leaving it at 0 unless you're willing to tinker a lot and suffer through some maps being too bright.

    r_lodbias   "0"

Description:

Controls how other player models reduce in complexity by distance. The values range from -2 to 2. When set to 2, the enemy model will remain at lowest detail in all instances. When set to -2 it will remain at highest detail. When set to 0 it will oscillate between the two depending on the distance.

Also effects the appearance of some weapons when the gun is shown (drawgun 1 or 2 with sufficient gunXYZ values).

Recommendation:

I recommend using -2 with enemymodel keel so that he will remain at highest detail.

Some who have the gun shown dislike the high detail appearance of the gun models and so use lodbias 2. The RL is perhaps the most significant of these. It seems like a minor issue to me but may not be for someone else.

lodbias 2 is recommended for TankJR since he better fits the hit cylinder this way.

    r_lodscale   "10"

Description:

Level of detail scale adjustment.

A setting of 0 will keep the player model at lowest detail until they are very close, and then use medium detail.

A setting of 50 (maximum) will keep the player model at highest detail until they are very far away.

A setting of 10 is between the above two.

Setting r_lodbias to -2 kept the player at highest detail more often than r_lodbias 0 and r_lodscale 50 in a test though.

Recommendation:

I recommend setting r_lodbias to -2 or 2 and forgetting about r_lodscale (leave at default).That way the model's appearance stays as consistent as possible.

    r_mapOverBrightBits   "2"

Description:

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

Behaves differently depending on r_vertexLight, r_enablePostProcess, and r_ignoreHWgamma.

Recommendation:

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

Here are some example brightness setups:

r_mapoverBrightBits 1
r_overBrightBits 1
r_mapoverBrightCap 255
r_gamma 1.75

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

Description:

Allows you to cap the brightness of surfaces brightened by r_mapOverbrightBits (Most useful when using high values of r_mapOverBrightBits; vid_restart required after a value change).

Values range from 0 to 255.

Recommendation:

If you use high mapoverbrightbits like 10, try a value of maybe 125 or 150 to tone down the bright white textures on the map. Players managed for over a decade to play q3 (and QL for a couple of years) without this cvar though so it's not really needed, just a convenience.

    r_mode   "-2"

Description:

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

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

Recommendation:

Very personal preference, and not a simple issue.

First of all, you should try to use a resolution that you can get 125 fps on, and also one that your display can run at at least 120 Hz. If not, get as close as you can.

For CRT users this almost invariably means using a resolution at or under 1280x1024. With some of the new LCDs they run 120 Hz at their native resolution. This could be resolutions like 1920x1080 or 1680x1050. If you can get 125 fps at those resolutions and like the effect, go for it.

There is some controversy over what aspect ratio is best, be it 4:3 or the wider 16:9 and 16:10. Probably you can adapt to using either and play just fine.

I personally suspect that 4:3 makes it easier for the human mind to "chunk" the screen and take note of its geometry. Perhaps 5:4 is even better since it is slightly more square than 4:3. Maybe it depends completely on the person. It's hard to tell. Here are some example pro players that use low resolution:

Cypher (640x480) (may have changed to 800x600 recently)
Cooller (640x480)
avek (640x480)

Stermy (800x600)
Dahang (800x600)
czm (800x600)
k1llsen (800x600)

Spart1e (1024x768)
Evil (1024x768)

    r_overBrightBits   "1"

Description:

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

Recommendation:

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

There are two interesting options, one is to use r_overBrightBits 0, and a high gamma. It tends to make small crosshairs look a little dampened but with an adiquately sized crosshair it can look great. Yellows and greens stand out while the map remains predominantely dull colors. It is very easy on the eyes to play this way.

Vertexlight off + overbrightbits 0 makes for rocket explosions that are slightly more transparent than normal. With overbrightbits 0, r_mapoverbrightBits and r_enablePostprocess seem to have very little effect if any.

Another interesting, albeit extreme option is to use overbrightbits 2. This covers the display in a kind of bright grey haze, however rocket explosions become the most transparent that I've seen them. Plasma balls are slightly transparent and smaller tha normal, and even the LG appears thinner than normal. These benefits come at hefty cost though since the grey haze makes some items such as armor shards very hard to see. Player models are ok.

For example: r_overbrightbits 2, r_mapoverBrightbits 2, r_gamma 1.3, r_vertexLight 1, and r_enablePostprocess 0 make the transparent effect on rocket explosions very strong. Lowering r_gamma gives the map a lot more contrast while maintaining much of the transparencies.

Increasing r_gamma and/or r_mapoverBrightBits has the effect of amplifying the "grey haze", although it gets rid of the really dark areas.

Ultimately I think the effect is too strong so I recommend sticking to either r_overbrightbits 1 or 0. I think the majority of players leave it at 1 and only change r_gamma and/or r_mapoverBrightbits, and probably their display's brightness as well. This works pretty well but it is interesting to consider these other more obscure options.

    r_picmip   "0"

Description:

Texture color average/level of detail. Lower values will manipulate and blend the colors of themap textures. Textures at the highest value, ‘10’ appear nearly as solid colors. A vid_restart or map load is required before changes will come into affect.

Recommendation:

Largely personal preference. A value of 5 is popular as a happy medium. Setting it to 0 results in high quality, however a level that is complicated by quality textures may be visually distracting. Setting it to 10 solves this problem, however the
textures become so simple that depth perception may be difficult. Still many great players use either 0 or 10, and just about any value in-between. I personally use 5.

    r_railCoreWidth   "6"

Description:

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

Recommendation:

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

In an old cypher config (he's since changed settings) I found railstyle 2 with corewidth 20. So yeah, just use whatever you like :-)

    r_railSegmentLength   "32"

Description:

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

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

Recommendation:

These are largely personal preference. There are some interesting quirks though. If you set segmentlength to 1 or 0.5 you can get a thick looking rail beam. You can even choose to hide the core with corewidth 0.

If you're on a machine that is very fast, but want to help diagnose FPS problems for a friend, yet are having trouble doing anything that turns down your framerate, just set cg_railtrailtime to a very high number such that the beams stay. Then set segmentlength to maybe 0.5, and shoot a bunch of rails. When in the field of rails your FPS will be greatly taxed. I used this method once when I was trying to get the FPS to under 1 frame per second so I could see if the frames were being drawn or just popped onto the screen (they were). Increasing railwidth should amplify this effect still further.

    r_railWidth   "16"

Description:

Diameter of the segments in pixels.

Recommendation:

Personal preference. If you like the effect of segmentlength 0.5 or 1, and turn off corewidth you may like to adjust the width of the beam with this number.

    r_simpleMipMaps   "1"

Description:

Enables simple MIP mapping, boosts performance.

Recommendation:

This one is a tough call. Certainly the default value of 1 is fine. The question is whether or not there is something to be gained from using 0. With 0 the walls look smoother, and certain far away textures seem better preserved. Some say the player models tend to look less sharp. The effect is very subtle and comparing them side by side in a photo editor I definitely see a difference but it isn't a big one. I really cannot tell which is better so I'll have to call this one personal preference for now.

    r_subdivisions   "4"

Description:

Patch mesh/curve sub divisions. A value of 80 will replace curved surfaces with angled surfaces to give a performance boost. Only values of 4 and 80 are allowed in Quake Live.

Recommendation:

This one is controversial. Here are some pros/cons/information.

Pros of using 80:

In some cases the curve takes up part of a doorway in which case something may be seen with 80 that would not be seen with 4.

It results in more consistent map features, as far away curves will lower in quality. This happens much less with 80 since the quality is already low.

It is useful for learning to do some movement tricks consistently. For example on Campgrounds doing the rail to bridge jump from various points along the curve is easier since the curve is broken up into points to start from. (Thanks aeoL for this idea).

It might be the case that you can see something with 4 that you cannot see with 80, however you cannot shoot through that area, in which it would be better to use 80 such that if you can see it you can always shoot at it.

Cons of using 80:

Some maps may be rendered more correctly with 4, than with 80, such that perhaps something could be seen with 4 that could not be seen with 80.

Using 4 is much better looking in my opinion.

Important pictures illustrating the different effects:

Aerowalk: http://imageshack.us/a/img831/7135/kwgjgjr.gif

Campgrounds: http://imageshack.us/a/img692/9822/dxpn7xzc.gif
Campgrounds: http://imageshack.us/a/img24/4703/iomxigr.gif

FuriousHeights: http://imageshack.us/a/img542/669/j8pmjk7.gif
FuriousHeights: http://imageshack.us/a/img209/5472/tdbr9w3.gif

Bloodrun: http://imageshack.us/a/img89/1117/j1oyki9.gif <----- omg!
Bloodrun: http://imageshack.us/a/img694/5450/l9tjtjs.gif

Thanks FFT for these gifs.

    r_teleporterFlash   "1"

Description:

When set to 1, going through a teleporter makes the screen go entirely white for a split second. It is no longer than this unless the player is undergoing much lag.

Recommendation:

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

With teleporterFlash 0 the flash is not white, but black. Since this happens so quickly in the actual game it probably doesn't matter what value it's set to. Just because I thought it was neat to make the game potentially easier on my eyes by adjusting something that I'm not consciously aware of I set this to 0 though.

Another rather tenuous reason to use 0 is that if you're playing in the same room as  your opponents, and the room happens to be dark, teleporterflash 1 will momentarily "flash" which could inform your opponents that you have gone through a teleporter. Keep in mind that the corner of the eye can better pick up these subtle changes. (Thanks aeoL for this idea)

With this idea in mind, it could be possible to make a bind that produces a bright flash, such as : "r_gamma 10 ; wait ; r_gamma 1" in order to be really devious and fake a teleport flash. (Thanks ybl for mentioning this).

    r_textureMode   "GL_LINEAR_MIPMAP_LINEAR"

Description:

Sets texture filter.

Usage:

r_texturemode "GL_X_MIPMAP_Y"

X is the method for rendering textures, and Y is the method used to mip them.

A setting of GL_X, will render all textures with method X, and no mip mapping will be done.

The options for X and Y are, NEAREST and LINEAR.

So the following combinations are possible:

GL_LINEAR_MIPMAP_LINEAR = The default setting. It shows up close textures at normal quality, and far away textures are only slightly mipped to prevent moire patterning.

GL_LINEAR_MIPMAP_NEAREST = Up close textures are at normal quality, far away textures are mipped much more than with mipmap_linear.

GL_LINEAR = All textures are at normal quality and no mipping is done for far away textures.This causes plenty of annoying moire patterns. However, if you use a higher resolution, using this setting can result in a thinner tip to the LG.

GL_NEAREST = Gives everything an old school grainy look, almost exactly like d_mipcap 0 in quake1. This is with r_picmip 0, if r_picmip is 5 for example, it looks more like d_mipcap 3. It currently has a bug with crosshairs below a certain size where it will render them black. Some people like the look of gl_nearest or gl_nearest_mipmap_nearest, and they are nice options to have.

GL_NEAREST_MIPMAP_NEAREST = Similar to gl_linear_mipmap_linear, in that it mips just enough to prevent the moire patterning. It also doesn't suffer the small crosshair bug that gl_nearest does.

GL_NEAREST_MIPMAP_LINEAR = Up close textures are nearest, far away textures are mipped with linear. Looks almost identical to gl_nearest_mipmap_nearest.

Recommendation:

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

    r_vertexlight   "0"

Description:

When set to 1 it enables vertex lighting, 0 is lightmap. A setting of 2 uses vertex lighting, but enables the use of dyanmic lights (r_dynamiclight 1).

Recommendation:

I actually recommend using 1. There's something about the way the textures look that alters the way the game feels. It feels slower in a way that seems more conducive to aiming. It tends to be brighter than lightmap with less image quality. Pairing it with r_fullbright 1 has wild results.

If you're low on FPS, using 1 can help tremendously.

Also if you wish for dynamiclights to be off, using vertexlight 1 automatically does this so you can leave dynamiclights at 1 and take another cvar out of your config.

    r_windowedmode  "12"

Description:

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

Recommendation:

If you normally play in fullscreen, use a lower resolution than your screen resolution, so that when you go windowed you can see other applications that you may wish to use. For me a value of 5 (640x480) works perfectly for this.

    rate   "25000"

Description:

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

Recommendation:

I recommend leaving this at its default value of 25000. However with some testing it appears that the rate cvar does very little and does not make the difference for incoming data rates that it indicates, so it may make little or no difference what value is used. Leaving it at maximum puts you on the safe side though.

    s_ambient   "1"

Description:

Ambient sound effects. Things like wind blowing, rain falling, humming of machines, torches burning. An s_restart, vid_restart, map change or reload of the game is required for the change to take effect.

Recommendation:

I recommend setting this to 0. There is one downside however, and that's that with 0 set you cannot hear proximity mines beeping. I personally find this to be a minor issue compared to the substantial reduction in ambient noise, but it's something to be aware of.

    s_musicvolume   "0.25"

Description:

Volume of Quake Live's background music.

Reccommendation:

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

    s_volume   "0.8"

Description:

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

Recommendation:

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

Some say that if you keep your volume low it forces your brain to concentrate more on the visual aspect of the game and in turn can improve aim.

Others say having it up slightly louder helps them concentrate.

Obviously to prevent damage to your hearing you should not set this value too high.

    sensitivity   "4"

Description:

Sets mouse sensitivity, which is then multiplied by m_yaw and m_pitch to determine the final amount of degrees to turn per mouse count.

Recommendation:

This is about as personal preference as it gets.

One idea is to get an empty map such that you can find two easy points of reference that are directly in front and directly behind you. Then make a comfortable motion with the mouse to the right. Usually my hand/wrist/arm wants to stop at a certain spot. Adjust your sensitivity so that at that spot you make a 180 degree turn. Do the same for the left, which will usually yield a slightly different number. Use a value in-between the two in an attempt to satisfy the needs of each direction.

For me this number was ~6.25 on a 400 cpi mouse (roughly 16.6 cm/360).

Another wacky idea is to set your sensitivity in such a way that one mouse count changes the screen by one center pixel. To do that use this formula:

S = (360 /M) / ((360 / F) * H)

M = m_yaw
F = cg_fov
H = Horizontal resolution in pixels (for example 800 for 800x600)
S = sensitivity

Unfortunately at high CPI values, the sensitivity goes through the roof at lower resolutions.

These are just silly ideas anyways. Nothing beats the old fashioned play and adjust.

    timedemo = "0"

Description:

When set to 1, the next demo played will be run as fast as it can go, and when it is finished an FPS value is reported. If using the same demo across different systems, this can be used as a performance benchmark.

Recommendation:

Leave this at 0 unless you are doing benchmarking. Otherwise you may be confused as to why your demos seem to be stuck on fast forward playback

One thing you can do is in tandem with a utility like fraps, start a practice game with cheats enabled (devmap), and set timedemo to 1. It will then render as fast as it possibly can, and you will be able to see what fps values can actually be rendered on your hardware.

    timescale = "1"

Description:

The speed of game events. This can only be adjusted on localhost or during demo playback.

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

Recommendation:

Since any normal key being pressed during demo playback ends the demo, I recommend binding keys for use during demo playback elsewhere. From my own config:

bind F6                "+acc"                 // Accuracy
bind F5                "+scores"            // Scoreboard
bind pgdn             "timescale 1"       // Normal
bind pgup             "timescale 10"     // Fast forward
bind ins                "timescale 0.5"    // Half speed
bind del                "timescale 0.25" // Quarter speed

I tell people all the time who wish to improve their Lightning Gun accuracy to lightning battle with a friend, and record the game. Then play back the demo at timescale 0.25. You'd be surprised what you can learn from this.

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

    winkey_disable = "0"

Description:

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

Recommendation:

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

Commands:

    alias

Description:

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

Usage:

alias <aliasname> "[commands]"

For example: alias greet "say hello there"

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

It can be activated with the console:

\greet

Results in:

player: hello there

It can also be activated when it is bound to a key:

\bind h "greet"

Now pressing h will activate the alias "greet".

More than one command can be issued by a single alias, just separate each instruction with a semicolon. For example:

alias greet2 "cg_chatbeep 0 ; say hello there"

This can be bound to a key in exactly the same way as above.

An especially important feature of alias is its ability to be bound to a key for an on and off action by prefixing your aliasname with a + and - respectively. For example:

alias +greeting "cg_chatbeep 0 ; say hello there"
alias -greeting "cg_chatbeep 1"
bind h "+greeting"

When the 'h' key is held down, the alias for +greeting will be activated, when it is released the alias -greeting will be activated.

It is rare (if ever) that you would not want your -alias to undo the commands of your +alias, and in the example here cg_chatbeep is temporarily changed to 0 while the button is held down, and returned to 1 when the button is released.

In the scenario of this alias:

alias +lgFire "sensitivity 2 ; +attack"
alias -lgFire "sensitivity 4 ; -attack"

The sensitivity is changed to 2 when whichever button +lgFire is bound to is pressed, as well as the attack command issued. When the button is released the sensitivity is changed to 4 and the attack command is cancelled.

Note, a single alias takes a maximum of 255 characters. If for some reason you need to use an alias larger than this, split it up into multiple aliases. For example: alias blah0 "blah1 ; blah2" (Thanks andy17null for this info)

    bind

Description:

Assign an action to a key.

Usage:

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

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

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

Commands that start with a + will be activated while the key is pressed down, and deactivated when the key is released. For example bind mouse1 "+attack", +attack will continue to be issued while mouse1 is held down and will not stop until mouse1 is released.

Some keys have special names, these are:

semicolon
capslock
rightarrow
uparrow
downarrow
leftarrow
scroll Lock is "0x00"
kp_numlock
kp_slash
kp_star
kp_minus
kp_plus
kp_enter
kp_home
kp_uparrow
kp_pgup
kp_leftarrow
kp_5
kp_rightarrow
kp_end
kp_downarrow
kp_pgdn
kp_ins
kp_del
Mouse1
mwheelup
mwheeldown
aux1 - 17 (I assume these are for a game pad of some sort)

When in_joystick is 1:
Joy1 - 32

Unusual keys are identified with a scan code in hexadecimal. Quake uses different keyboard scan codes than the OS, making it tricky to determine what they are. For example, 0x97 is F7 for me, and scroll Lock is 0x00. These are different for different keyboards. Probably some experimenting will be required to be able to bind odd keys on your particular keyboard.

Some of the keys appear to be ignored by QL. For example I could not get print screen to work (I tried multiple hex codes), or the windows key (with winkey_disable 0 obviously), or the menu key.

    block

Syntax:

block <playername>

Description:

Hides all chats coming from a player. Useful for trolls.

    blocklist

Description:

Lists all players that are currently in your blocklist.

    callvote

Syntax:

callvote <command> <variable>

Description:

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

callvote kick annoyingtroll
callvote teamsize 2
callvote map FuriousHeights

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

    clear

Description:

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

    cmdlist

Description:

Lists the game's commands.

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

    cvarlist

Description:

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

You can also search for a cvar by typing cvarlist *searchstring. Very very useful when you cannot remember the full name of a cvar.

    demo

Syntax:

demo <demoname>

Description:

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

Gets rarely used as autorecorded demos usually have long names that are difficult to remember, in which case automated demo player tools such as QLDP are used instead.

    devmap

Description:

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

Open a practice game and enter the console, type devmap verticalvengeance (I hit tab to auto-complete and save on keystrokes).

From there I have a key bound to "give all ; god" which gives me all the weapons and renders me invincible. Now I can run around the map and try out all the weapons. If I want something to shoot at I will add a bot by typing "addbot anarki 4". Since the bot is feeble against someone who is invincible and with all the weapons, I usually set a handicap of 50 or
less which let's me shoot plenty without killing the bot and gives me an excellent chance to get a feel for whatever it is I happen to be testing.

    disconnect

Description:

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

    dropflag

Description:

When carrying the flag in a CTF style game type, issuing this command releases the flag. This can be extremely important as it enables you to transfer the flag to a more stacked teammate to improve the chances of a cap.

    droppowerup

Description:

Issuing this command drops the current powerup such as the quad, the battlesuit, invisibility and regen. Useful for when  you wish to give your powerup to a better stacked teammate who may be able to rack up more frags.

    dropweapon

Description:

Issuing this command drops the current when in certain team based game types. Very important to TDM as it enables you to give weapons to a teammate that needs them.

    exec

Description:

Executes a config file. The file itself must have the extension of .cfg or it will not work. Files are assumed to be located in home/baseq3.

Usage:

exec <filename>

exec lorf.cfg
exec lorf

The .cfg part can be omitted and it will be assumed.

Config files can be exec'd in other directories within home/baseq3 by specifying them:

exec backups/lorfabackup.cfg

Will look in home/baseq3/backups/ for lorfabackup.cfg

    forfeit

Description:

Ends the game in a duel, giving the player who entered it a loss and not a quit. It is also available to the losing player in team gametypes, when one player is left remaining.

    give

Description:

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

Usage:

give <item>

List of gives I know (the spaces are important):

give gauntlet
give machine gun
give shotgun
give grenade launcher
give rocket launcher
give lightning gun
give railgun
give plasma gun
give bfg10k
give grappling hook
give nailgun
give prox launcher
give chaingun

give red armor
give yellow armor
give green armor
give quad damage
give battle suit
give mega health
give armor shard
give personal teleporter
give regeneration
give invisibility
give haste
give flight
give health (changes health to the maximum non-tick value allowed by handicap, which is 100 by
default)

give bullets
give shells (shotgun)
give grenades
give rockets
give cells (this actually the plasma ammo, even though this would be lg ammo in other games)
give lightning (ammo for the LG)
give slugs (railgun)

give ammo (gives 999 ammo for all weapons)
give all

If anyone knows the rest of these let me know!

    god

Description:

Toggles god mode on/off when in devmap (cheats enabled). Very useful for testing things when you wish to play against a bot but don't want to be killed.

I have a bind to "give all ; god" which lets me play with all the weapons in localhost.

    in_restart

Description:

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

    loadhud

Description:

Loads the hud.

Comment:

Very useful for when testing different huds, as you can simply change cg_hudFiles to the new hud, and then type in loadhud to load it. No need to save the config and restart QL. Also saves time in making a hud, as you can run windowed, make some changes to the hud file, and then simply type in loadhud to see the effect of the changes.

    messagemode

Description:

Enters a chat prompt, in which a message can be typed and upon pressing enter will be seen by everyone on the server with the exception of certain game types that prevent spectator chat being seen by players when a game is in progress.

    messagemode2

Description:

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

    messagemode5

Enter a chat prompt; chats typed here will go to the last person who messaged from QL's online buddy chat. I recommend binding the backspace key for this one.

    name

Description:

The player's name. Can be styled in colors using the carot symbol (^).

Usage:

name "playername"

The colors are:

^1 = red
^2 = green
^3 = yellow
^4 = blue
^5 = cyan
^6 = Magenta
^7 = white
^8 = black (not supported for names but still works for chat)

So a 7 lettered name with all different colors would look like this:

name "^1p^2l^3a^4y^5e^6r^71"

Will make for a very colorful "player1" name.

While colors can be added, the name cannot be changed from its original lettering. If there is an error the name will simply be reset back to white in all lowercase letters.

Colors can also be used in chat.

    players

Description:

Lists the players on the server and which number they are. Required for admin actions on a spawned server which usually use the player's number to identify them instead of their name. Also useful when you are going to \block someone, as you do not have to view their name, remember exactly how it is written, and then enter the console and \block <thatname>. Instead you can just enter the console, type players, and then \block from that player's name shown on the list.

    quit

Description:

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

    ragequit

Description:

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

    readyup

Description:

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

    reconnect

Description:

Disconnect from the server, and then automatically connect again. Useful if there was a timeout due to lag. Instead of exiting the program and rejoining from the website, a reconnect can be issued instead.

    record  

Description:

Starts recording a demo.

Usage:

record <demoname>

If no demoname is provided, a file name of demo0000 will be used. If demo0000 exists, demo0001 will be used instead.

Demo files are placed in home/baseq3/demos

    reply

Description:

Replies the last person who messaged via the quake live buddy chat. Very useful if watching a demo and someone is messaging as you can reply them through the console because hitting your messagemode5 key will not work or will stop the demo.

Usage:

reply <message>

    say

Description:

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

Usage:

say <message>

    say_team

Description:

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

Usage:

say_team <message>

    screenshot

Description:

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

    screenshotJPEG

Description:

Takes a screenshot in JPG format. Saves a lot of space at the cost of some quality. Not recommended for low resolutions as the text can come out slightly blurry and difficult to read.

    serverinfo

Description:

Lists all the information about the server, including the infamous skillrating value. Sample output:

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

    set

Description:

set is very similar to alias, except that it does not support + and - commands, and it must be activated with an extra command called vstr which tells the game to do the stuff in the specified set.

So for the "hello there" example given above for alias this could be done instead:

\set greet "say hello there"
\vstr greet

Results in:

player: hello there

It can also be bound to a key:

bind h "vstr greet"

It also supports multiple commands:

set greet2 "cg_chatbeep 0 ; say hello there"

As a personal preference I choose to use set/vstr whenever possible as opposed to alias because I trust it more.

set also assigns a value to an existing cvar, for example:

set sensitivity "5"

    seta

Description:

Behaves almost exactly like set, except that it is more likely to be stored in the relevant config files. Recommended for use in config files for robustness. So when making a config, instead of just typing sensitivity "5", or set sensitivity "5", it is recommended that you use seta sensitivity "5".

    setviewpos

Description:

In practice mode, this transfers your current position to the position given. It takes positions in the format of the position and orientation numbers provided by "viewpos". See its entry below in this list.

Usage:

A sample output of viewpos is:

(674 82 498) : -90

So to "teleport" there:

setviewpos 674 82 498 -90

Very useful for trick jump training as you can bind a key to a location for example:

bind [key] "setviewpos 674 82 498 -90"

..and practice your trick move from that position over and over again simply hitting the key after each iteration to return the exact same spot.

    stoprecord

Description:

Stop recording a demo.

    team

Description:

Used to set team. The valid teams are:

red
blue
spectator
auto

These can be abbreviated with just their first letter:

r
b
s
a

Usage:

team <team>

    tell

Description:

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

Usage:

tell <playernumber> <message>

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

    tell_buddy

Description:

Talks to a friend via the quake live buddy chat.

Usage:

tell_buddy <name> <message>

    toggle

Description:

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

Usage:

toggle <cvar>

For example,

bind pause "toggle r_fastsky"

Upon pressing pause, if r_fastsky is set to 0, it will be changed to 1. If it is 1 it will be changed to 0. Its new value will be echoed in the console. Saves space in one's personal config since a toggle doesn't have to be created manually with alias or set/vstr.
  
    unaliasall

Description:

Removes all aliases, or rather after this command is issued, typing them in will say "alias suchandsuch not found". This is different from typing in a command/cvar the game is unfamiliar with, as this will report "command suchandsuch not found". So the game is still aware of their existence, but prevents them from working.

This is usually found after the bindings list in a config. To truly remove all aliases game settings must be reset via the website (game settings --> reset defaults).

For now this command is buggy, as it cancels out the use of aliases, but does not allow them to be realiased under the same name. I don't recommend keeping it in yourconfig.cfg.

    unbindall

Description:

Removes all key bindings. Usually found at the beginning of a config to clear all keys before binding them. I recommend using this only at the top of a config and nowhere else.

    unblock

Usage: unblock <playername>

Description:

Removes a particular player from the block list.

    viewpos

Description:

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

Comments:

Very useful for manual sensitivity testing, as it can tell you almost exactly when you've made a full 180 or 360 rotation, which reduces the margin of just eye-balling it. The last number is your orientation in degrees relative to some point on the map, so a 360 degree turn should land back at exactly this orientation.

    vid_restart

Description:

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

    vote

Description:

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

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

Usage:

vote yes
vote no

    vstr

Description:

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

Usage:

vstr <cvarname that originated from set>

    wait

Description:

Waits a gametic. There are two gametics per frame, so at 125 fps there are 250 gametics/sec. Useful to time commands precisely as the number of waits can be specified by adding a number after the wait command. For example, wait 1000 will wait 4 seconds at 125 fps. However while a wait is in progress, no commands can be issued which means no moving or shooting. This may have been done to prevent scripts that would time items.

    weapon

Description:

Selects a specific weapon.Usage: weapon #

List:

weapon [1-13]
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

    weapnext

Description:

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

    weapprev

Description:

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

    writeconfig

Description:

Writes a config with all the relevant cvars in it. Vital if an autoexec is present, because then the only way to save settings
is with: writeconfig autoexec

Usage:

writeconfig <filename>

Button Commands:

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

    +acc

Description:

Shows your weapon accuracies.

Different weapons have different accuracy values that are considered good. The vast majority of concern is given
to the accuracy values of the lightning gun and the railgun. Excellent accuracy values for these would be 40 % and 50 % respectively.

The stronger the player the better their dodging tends to be, and so accuracies are likely lower than normal against such players.

    +attack

Description:

Fires weapon.

    +back

Description:

Moves backward.

This term "+back" is also used to describe a very defensive style, for example:

"It was a very slow game with a low score, very +back".

    +button0

Description:

Fires weapon. Identical to +attack. Impress your friends by binding this for fire instead of attack :-P

    +button2

Description:

Use item. Makes the "click" sound when there is no item to use. Bind to mwheeldown or mwheelup (scroll wheel) to make a velcro sound. Warning: This can become a bad habit.

    +button3

Description:

The taunt key. Do not use this ever.

    +forward

Description:

Moves forward.

The term "+forward" is also used to describe a very aggressive/offensive style. For example:

"All that guy does is rush and attack, never slows down, he is very +forward".

    +movedown

Description:

Crouches, or swims down.

While crouching the player will travel at 1/4th the speed of running, and half the speed of walking (80 ups).

No footstep sounds will be made while crouching, and also the hit cylinder will be slightly smaller which comes at the
cost of mobility.

    +moveleft

Description:

Strafes left.

    +moveright

Description:

Strafes right.

    +moveup

Description:

Jumps, or swims up in the water.

    +scores

Description:

Displays the scoreboard.

    +speed

Description:

Run/Walk toggle.

While this key is held down no footstep sounds will be made by the player, however will travel at roughly half the speed (161 ups vs. 320 ups).

    +zoom

Description:

Zooms in when activated, zooms out when deactivated.

Links:

Muffin's console guide:

http://www.regurge.at/ql/

Worthless information about your worthless mouse:

http://www.funender.com/quake/mouse/index.html

Special Thanks:

TheMuffinMan86
Lam
Injx
SyncError
Regurge
govn0r
Yakumo
EmSixTeen
Wrl
Windex
aeoL
ybl
TIE
andy17null
pvh
FFT
Flashsoul

Guide by Lorfa: mklabyrinth@gmail.com

Last Update: February 2, 2014