Lorfa's 264
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 1,274 commands/cvars, this takes only the most important 193
cvars and gives recommendations and often times extra info not
included in the basic list. It also includes explanations for the 71
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 based on my own config:
http://pastebin.com/EQTVHbXR
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.
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.
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 under water.
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 loud, jarring, and completely unnecessary.
cg_chatbeep "1"
Description:
When set to 1, regular chat messages typed in messagemode1 will beep when they are received.
Recommendation:
Completely personal preference, it's nice to know the option is there.
cg_crosshairBrightness "1.0"
Description:
The brightness of the crosshair, 0 being black, 1.0 being normal.
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, or somewhere in-between.
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 in-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 an excellent choice. I experimented with other values
but found most of them unnecessary and/or distracting.
Styles 1, 4 and 7 could work as an accessibility feature for the hearing impaired.
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.
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 in fact there, just moved
out of my visual range faster than I was able to perceive them. 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 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 will be accepted by com_maxfps. Why
exactly this was done is not clear. 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 in the map on 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
Recommendation:
For
the LG I recommend using cg_drawgun 2, gunZ -8, gunX -10, and gunY 3.
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.
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 excellents (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.
Recommendation:
I've
never felt the need to change this, but it's a great feature to have.
The lowest it goes is 0, which is unfortunately not completely
transparent although still very clear.
cg_drawTeamOverlayX "0"
Description:
The Y 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.
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, and if so I'd rather
have it be 0 ms.
I
did some testing, playing 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. 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 24-32 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_forceBlueTeamModel ""
Description:
Forces
the blue team to use a specific model. This will override
cg_forceEnemyModel or cg_forceTeamModel. The color is determined by
cg_EnemyUpper/lower/headcolor.
Recommendation:
I recommend leaving this at default. I can't imagine needing it. It's nice to know the option exists I guess.
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.
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_forceRedTeamModel ""
Description:
Forces
the red team to use a specific model. This will override
cg_forceEnemyModel or cg_forceTeamModel. The color is determined by
cg_TeamUpper/lower/headcolor.
Recommendation:
I recommend leaving this at default. I can't imagine needing it. It's nice to know the option exists though.
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 110. 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. I
personally just use the default of 100.
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 is a distraction.
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 3 (centered) for thin and centered LG purposes.
After some analysis, it appears that gunY 2.7 is slightly more centered than 3.
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) for 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 one of those was personal preference.
A
post on ESR talking about strange commands in the configs of pro
players mentioned cg_hitbeep 1. After some investigation I realized
that there was something to it.
When setting 2 or 3 is used, the
client _must_ get damage information from the server before it can
decide which sound to play. This produces a tiny delay in the hitbeep
which is not important for most weapons. The LG however is sensitive to
this, and using a value of 1 makes for more accurately played "beeps".
Since the GT/LG/MG/PG/CG all have a set amount of damage per hit, you
lose no vital information by using hitbeep 1.
However, the RL/GL/SG/PM/NG all have a variable damage. In this case hitbeeps 2 or 3 provide information that could be vital.
So, I recommend using hitbeep 2 or 3 (I personally prefer setting 3 so that
a high pitched tone indicates a high amount of damage.) for the RL/GL/SG/PM/NG and hitbeep 1 for the GT/LG/MG/PG/CG.
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. 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.
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. This can have the effect though of making them easier to see.
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 b.b. 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. Playerse 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 don't know
anyone who uses setting 3.
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 excellently 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:
I
recommend using 0 as it is extemporaneous information. I only turn it
on when someone is drawing on the walls to see their "art" :-)
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. I have it lower to 0.5 when using
the rail gun to prevent a bad habit I have of suddenly flicking the
rail too far in the direction of the player's 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, but I choose to set it to the maximum anyways.
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.
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:
I
recommend setting this to 0, as it will turn off all screen damage
color flashes which I think are distracting. Setting this to 0 also renders cg_kickScale
ineffectual.
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.
cg_simpleItems "0"
Description:
Draws the items as flat symbols instead of 3d objects.
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_dust "24"
Description:
This
is the smoke trail given off when a player is walking in dust, or I
suppose it's a dust trail. Such dust can be found on the CTF map
siberia.
Recommendation:
Dust is rather uncommon in
Quake Live, and the dust trail can even give some information with
which to predict shots. I recommend leaving it at default.
cg_smokeRadius_flight "8"
Description:
This is the smoke that appears behind the player when they have the flight powerup and are flying.
Recommendation:
Leaving this at its default is fine. It is a very minor graphic.
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_haste "8"
Description:
This is the smoke trail that appears on the feet of a player who has the haste powerup.
Recommendation:
This is a very minor issue, so there is no problem with leaving it at its default.
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, running out of ammo will automatically switch to a weapon that does have ammo.
Recommendation:
Leave
at default. No point in trying to shoot a weapon that has no ammo.
There is some appeal in using 0 in that the auto-switch may switch to a
weapon you find less preferential, and that you could override this by
manually switching. I haven't found this to be an issue so far.
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 is the alpha channel: RRGGBBAA.
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
alpha 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 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.
I use 0.98, however 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:
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.
One
idea is to use different zoom fov values for different weapons. I find
that a zoom fov of 60 or other low-ish value is useful for railing, but
makes little sense for the other weapons.
A value of say, 85 for
the LG makes it so that zooming alters my view and sensitivity enough
to affect aiming in case I am missing while zoomed out, yet not so low
that I cannot make quick corrections and/or the enemy quickly dodges
out of view.
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 even the lowest possible value is best since the ranges
are so far on that particular map.
cg_zoomOutOnDeath "1"
Description:
Automatically zooms out upon death.
Recommendation:
No need to change this unless using a special script that zooms in all the time.
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 pretty 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 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 "63"
Description:
Controls how many updates you send to the server.
Recommendation:
I recommend setting this to 125. Using the 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 cl_maxfps, it is limited to integer values of 1000/x. So for example: 125, 111, 100, 50, 40.
cl_mouseAccel "0"
Description:
When
set to a value >0 the 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 0)
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 is 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 motions your hand is comfortable making with
the mouse.
cl_mouseAccelOffset "0"
Description:
The
velocity at which mouse acceleration starts. 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, this is silly when cl_MouseAccelPower is 2 though
because it is identical 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.
Using positive values has the effect of lowering the sensitivity at a given velocity when
mouseaccel is > 0.
cl_mouseAccelPower "2"
Description:
The
power curve of the mouse acceleration. In the code it is subtracted by
1, so power 2 is actually multiplying mouse accel by 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 this is something you want.
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.
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 a
while now I've been using -10 for everything except the rail which I
have set to -6.
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.
Using 0
however feels very laggy and unpleasant to me. So I use -10 a healthy
middle ground, and the -6 for the rail reminds me to predict carefully
with it as I have a habit of getting caught up in the game and just
aiming very quickly which seems to work for the other weapons but not
the rail.
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_allowConsole "0"
Description:
When to set its default of 0, the console can only be triggered by hitting CTRL+ALT+`
When set to 1 the console can be triggered simply by hitting ` (same key as ~ (tilde))
Recommendation:
I strongly recommend a setting of 1 for quick console access.
com_maxfps "125"
Description:
Maximum rendered frames per second.
Recommendation:
The default of 125 is the most circumspect value.
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.
con_background "1"
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:
I think it's a minor issue so I don't set 0 in my config, however 0 along with con_opacity 0 seems to be easiest on the eyes.
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 "1"
Description:
Determines the size of the console text, a range between 0.5 and 1 can be used.
Recommendation:
I have yet to find a need to change this value, but it is nice to know the option exists.
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
personally have never had any use for
this so I leave it at 0. 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.
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. However,
standard players have ads and the mouse pointer must be available
during these ads so it is then set to 1 to allow mouse movement for the
duration of the ad while the game loads.
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. For me personally I tend to use a higher pitch than
yaw (like 0.024) as so far this has been more natural for my hand.
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.00549316406 degrees. This is roughly 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:
I
don't think any model is particularly bad, however some have more
annoying sounds than others. Probably orbb is the most annoying.
Popular models include sarge, doom, ranger, bitterman, yuriko, mynx, anarki and xaero.
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
in-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 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:
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.
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, and most of its effects are distracting.
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
colorcorrectactive is 1 and it still doesn't activate.
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.
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_inBrowserMode "9"
Description:
Sets the resolution of Quake Live when running in windowed mode. Uses the same mod list as r_mode.
Recommendation:
I
set this to 5 (640x480) as it takes up less space in my browser window
and better enables me to do things like talk to friends. For your
particular desktop resolution this may not apply. In which case it's entirely
personal preference.
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 so that the player 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.
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 in-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 and forgetting about r_lodscale (leave at default).
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.
Recommendation:
I recommend subdivisions
80 as it results in more consistent map features. In some cases the
curve takes up part of a doorway in which case something may be seen
with 80 that wouldn't be seen with 4. I have heard that the opposite is
also true in certain cases, but not sure if I believe it. It's
unfortunate since subdivisions 4 is so much better looking in my
opinion.
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.
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.
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.
rate "16000"
Description:
Controls packets so that your downstream connection bandwidth does not get saturated. (Max bytes per second)
Recommendation:
I
recommend setting this to its maximum 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 no difference what value is used. Setting it to 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_mixahead "0.140"
Description:
Sets
the time delay before mixing sound samples. This is for fine-tuning the
mixer and will mix ahead the number of seconds specified.
Recommendation:
Leaving this at its default is perfectly fine, however if you have fps issues you might try the following:
Lower
s_mixahead from its default of 0.140 in increments of 0.01 until you
hear sound crackling or the sound cuts out/repeats. I can go as low as
0.07 and this yielded +300 fps in a timedemo.
As to how that
translates to an active framerate in-game is hard to say. I recently
tried on someone's system and it didn't help much, although I'm sure
not if their system is typical for this case.
s_mixPreStep "0.05"
Description:
This is for fine-tuning the mixer. It will mix this number of seconds every mixing step.
For a laugh set s_mixPrestep to a low value like 0.02, makes the plasma and machine gun sound hilarious.
Recommendation:
The default is fine, however if you're strapped for FPS, mixPrestep and mixahead might be able to help.
s_mixPrestep
can be increased slightly in increments of 0.01 for greater fps.
However it's a lot more touchy than mixahead, on one system I was only
able to go from the default of 0.05 to 0.06, anything past that and the
sounds started crackling. I suspect that this also causes some sound
delay, but it is rather minor.
When using both a low value of
s_mixahead, and trying to increase s_mixPrestep I've found that I am
unable to raise prestep very much without sound anomalies. At mixahead
0.07, and prestep 0.06 I get some crackling. With mixahead 0.07 and
prestep 0.07 sound fails. See the chart below for the results of time
demo testing.
With s_mixPrestep alone:
0.06 = +10 fps
0.07 = +30 fps
0.08 = +50 fps
0.13 = +350 fps (slightly delayed sounds)
0.14 = +375 fps (sound failure)
0.04 = no change
0.03 = no change
0.02 = no change (beginning of funny sounds)
0.01 = -6 fps (full on funny sounds)
0.005 = -6 fps (more of the same)
0 = -7 fps
With s_mixahead 0.07:
0.06 = +40 fps (occasional crackling)
0.07 = +60 fps (sound failure)
0.04 = -52 fps
0.03 = -125 fps
0.02 = -207 fps
0.01 = -261 fps
0 = = -290 fps
These
results are just on my system as I've seen them vary dramatically on
different machines. If you're strapped for FPS it's worth looking into
though.
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
:-)
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 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.
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,
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. Extremely useful for getting to the "base
screen" where only the quit option is displayed. From here you can open
the console and do just about anything, including running timedemo
benchmarks.
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 (lightning gun, plays the sound but doesn't work)
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 reconnect. 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. When alias was first added it
had bugs and I have never fully trusted it since. By now the bugs were
fixed a long time ago, so it's just a quirk of mine anymore.
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".
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.
toggleconsole
Description:
Opens the console. Bound to the `~ (tilde) key by default.
togglemenu
Opens the game menu. Bound to Esc by default.
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) : XY-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 is 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.
+button3
Description:
The taunt key. Do not use this ever.
+forward
Description:
Moves forward.
This term 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
Guide by Lorfa: mklabyrinth@gmail.com
Last Update: September 24, 2012