Quake3/cpma/docs/client.txt
Network Settings
cg_optimiseBW (default = 0)
1 - Significantly reduces the amount of non-critical data sent to you.
Regrettably, this also makes you unable to see players through portals,
thanks to a bug in the Q3 engine. Small price to pay though for the
HUGE difference it makes to team games.
Servers can, and by default do, force this on for all clients. It’s
probably worth setting it to 1 anyway though, just in case you end up
on a server that’s changed it to 0.
2 - Use this if your conn is UTTERLY starved for upstream bandwidth
(i.e. from you TO the server). Essentially, if you’re on dialup or one
of those Belgian Warp connections.
Understand that if you’re warpy and you choose to NOT set this because
you like the advantage you get from warping, you’re screwing YOURSELF.
Your shots will end up with potentially huge random delays on them, so
even if you’re LPB the server may not see that you fired until up to
100ms after the fact, effectively making your weapons act like you have
an unstable and much laggier conn, and without cg_nudge’s ability to
smooth it out.
cg_nudge (default = 0)
A replacement for id’s crippled cl_timenudge.
Allows you to use nudges beyond -25, and automatically adjusts them
to your ping: if you use -50 with a 20 ping, you get -20. If you spike
to 40ms for a few seconds, you get -40 during the spike.
This give you a "consistent worldview" that cl_timenudge can’t, and
generally helps regardless of your connection.
cg_xerpClients (default = 0)
A replacement for id’s cg_smoothclients that does something useful. :)
-1 - Hacked extrapolation: intended for HPBs
This smooths players out when you use high timenudges, at the cost of some
accuracy. It’s typically easier to hit a smooth target that’s a few pixels
misplaced than it is to hit one that looks like it’s teleporting all over
the map, so this combined with cg_nudge is the best option for HPBs.
0 - No extrapolation. Fine you’re LPB.
1 - id’s smoothclients: fine if you have TN 0, worthless otherwise.
cg_lagHax (default = -1)
A combination of adaptive prediction and an updated version of the famous
"50ms hack" we introduced way back in 99v6 that also does small amounts of
lag compensation.
Capped at 100ms no matter what: this is intended solely to make European /
EastUS v WestUS / etc games a bit less of a hassle, not to hack dialup
players into aimgods at the expense of everyone else.
0 disables it, -1 means "as much as I’m allowed": it’s naturally adaptive.
You’ll lose some of your "feel" for lag, which messes up your RL aim, etc.
This doesn’t suffer from the CS/etc problems of "total BS" shots that piss
everyone off; it’s not trying to be some panacea for modemers; and I’m
honest enough to call it the hack that it is instead of pretending that it
magically makes lag suddenly not exist, but all in all it’s a pretty nice
end result.
If you use this, any form of nudging will generally make you LESS accurate
if your ping’s under 100ms, because it’ll screw up the adaptive calcs.
cg_predict <0|1|2> (default = 1)
Replaces cg_nopredict
0 - off
1 - normal
2 - optimised
The normal prediction path is extremely slow at times (notably around
curves) and can cost you 100fps on a GHz machine. This new scheme is MUCH
faster, but slightly more prone to errors. Oddly enough, it’s still more
accurate than the original id prediction code (i.e. before the CPMA fixes).
If you have a slow machine, it’s definitely worth trying. Note that
cg_predict 2 was introduced 9 Sep 2002, the definition of a "slow machine"
has changed since then. Most of today’s computers will not notice any
difference.
Note: Do not use cg_predictItems 1 with cg_predict 2.
cg_predictItems <0|1> (default = 1)
Toggle client-side item prediction. 0 option to not do local prediction
of item pickup.
If you get many false pickups (due to lag, packetloss or high ping)
you should definitely use 0. It’s annoying when the client predicts that
you picked up RL, only to notice a bit later that you did not pick up
anything.
Note: Do not use cg_predictItems 1 with cg_predict 2.
cg_smoothClients
Does not exist in CPMA - see cg_xerpClients instead
cl_maxpackets (default = 63)
Basically, the higher value, the more correct info you send to the server
and the more you will hit and the less you will warp - set as high as
your connection allows
cl_packetdup (default = 1)
Set to 0 if your connection is fine - set higher if you experience much
packet loss
cl_timenudge (default = 0)
This still exists in CPMA, but should always be 0 unless you’re so used
to "normal" Q3 netcode that you’ve become dependent on it. All it really
does now is mess up the automatic adaptive nudges.
snaps
snaps should NOT be set in your config. CPMA adjusts snaps value
according to the server’s sv_fps value. If you join a sv_fps 20 server
your snaps get set to 20, if you join a sv_fps 30 server your snaps get
set to 30 etc...
cl_allowDownload <0|1> (default = 0)
Toggle downloading of pk3 files from servers. Should generally be left
at 0 as you rarely reach high download speeds.