This guide will explain how you can make your quake 3 running the way it was made/should run.
This is also assuming you do not have a wireless connection or a 56k connection or cant even hold 125fps solid. otherwise don’t bother with half of these settings.
These settings are also with complete disregard to personal preference and could possible hinder your abilities, so experiment with what works for you and for different pings.
RATE 25000 (25kbps)
Watch your lagometers green spikes when this is set lower. mostly everyone can handle this it just depends on how solid your connection is, routing, the server, etc..
Measured in Bytes per second. This is the maximum rate at which you will be able to receive data from the server. You should set this to the highest downstream rate your own connection can achieve consistently. This should not be set higher than 25000. For most of you this will be set at 25000, but for others with slower connections, you can take the rate at which you connect at and divide it by 10 to get your Rate value. If you set your rate higher than what your connection can actually achieve, this is what will happen:
When there are more players on the server (or just players constantly shooting) there is more data that needs to be sent from the server to the clients. If you have your rate set too high, the server will try to take advantage of your extra bandwidth. So when the server tries to send you 250Kbps down your 36Kbps connection, you will be flooded, your ping will 999, you will get mass packetloss and your connection will either hang or you will get kicked by the server.
SNAPS 40
40 is a general number because the server will lower it to the servers sv_fps for you. cpma forces your snaps to equal the servers sv_fps when you connect so dont bother setting a value
This setting is the number of ‘snapshots’ that you receive from the server per second. A snapshot is a ‘picture’ of what is happening in the game since the last snapshot. This is the data transmission equivalent of a framerate.
This setting should be set equal to the server’s sv_fps setting (default is 20). Some servers use sv_fps 30 and I have seen some sv_fps 40 servers. I have never seen a server using a sv_fps greater than 40. Regardless of how high you set your snaps setting, you will not be able to receive more than the rate at which the server runs which is defined by its sv_fps setting. So you can set your snaps to 40 and play on a sv_fps 30 server without needing to adjust your snaps – it will run at 30 anyway.
If you have dialup or wireless you will probably be better using snaps 20. The higher the snaps the more bandwidth will be needed, so snaps 30 or 40 may cause the connection to be less stable.
R_DISPLAYREFRESH xxx
Set to your monitors refreshrate. ie: 120hz,75hz, etc..
Cl_MAXPACKETS XXX
This is the Maximum number of data packets that can be SENT to the server per second. The higher you set this, the smoother your game will feel as your actions (run, shoot, jump etc.) will be updated more frequently. Broadbanders will be able to go up to 125 (but not higher) but this depends on your individual connections. Dialup users will just about be able to manage 30, so 20 is more of a stable setting.
Also if you set your MaxPackets too high, your ping will start to rise. This is due to the increase in upstream bandwidth usage. So you should set your MaxPackets as high as you can without it affecting your ping (and without going over 125).
COM_MAXFPS
This is the maximum graphical framerate permitted. You can not use any MaxFPS value. The only valid values are those which are equal to (1000/x) where x is an integer. So for example your 125fps comes from (1000/8 = 125). If you try and set MaxFPS to 120, you will still get 125fps. This is because any invalid setting is rounded up to the next (1000/x).
Some valid Values for MaxFPS:
1000/3 = ~333
1000/4 = 250
1000/5 = 200
1000/6 = ~166
1000/7 = ~142
1000/8 = 125
1000/9 = ~111
1000/10 = 100
1000/11 = ~90
1000/12 = ~83
1000/13 = ~76
1000/14 = ~71
1000/15 = ~66
1000/16 = ~62
1000/17 = ~58
1000/18 = ~55
etc.
R_SWAPINTERVAL
0: Off
1: TRUE vsync in quake 3, it LOCKS your fps with your monitors refresh rate. So, those of you that know what your doing, OVERRIDE your monitors refreshrate to 125hz at whatever resolution you play in, most of you should be able to get 120hz with a crt. And if you can’t get over 100hz with your monitor, you’ll probably experience mouse lag.
Test by slowly upping the refresh rate and going ingame, if your screen shuts off, hit the console key and type /quit and hit enter. You’ll have to do this blind so be carefull 🙂
example: say your desktop resolution is 1024×768 but you play in 800×600, in your video cards profile override the refreshrate for 800×600 so when quake 3 loads, your screen resolution bumps down from 1024 to 800 and that raised refreshrate gets used automatically.
– if you dont notice a difference, then you’ll love q4
With R_swapinterval 1
xxx equals your FRAMES PER SECOND(monitors refresh rate), if you set this to ANY NUMBER lower than this, it will CUT YOUR MAXPACKETS IN HALF.
example: FPS =125 CL_MAXPACKETS =100 means your MAXPACKETS BECOME 63 (half your fps because 100 is NOT divisible by 125)
CL_MAXPACKETS xxx and COM_MAXFPS
This is where your graphical framerate affects your connection. The actual MaxPackets sent to the server MUST be equal to (your_FPS/x), once again where x is an integer. If you set your MaxPackets to a value which is not equal to (your_FPS/x) then your MaxPackets will actually be rounded down to the nearest valid setting.
Most of you will use MaxFPS 125. If so, your valid MaxPackets values will be as follows (assuming your PC can achieve its MaxFPS value constantly):
(always round up these calculations to integers)
125/1 = 125
125/2 = 63
125/3 = 42
125/4 = 32
125/5 = 25
etc.
You should choose the largest value that your connection can handle. If your MaxPackets is not set to a valid value, it is a potential waste of bandwidth and therefore potential lag/instability.
For example, if your framerate drops to 100 then your valid MaxPackets values will change to:
100/1 = 100
100/2 = 50
100/3 = 34
100/4 = 25
etc.
So if you have your Cl_MaxPackets set to 100 and are using 125fps then mostly your MaxPackets will be at 63 (this is the largest value not exceeding the input Cl_MaxPackets limit). However, when the framerate drops to 100fps, the MaxPackets will change to 100 as this is now the largest value that does not exceed the input Cl_MaxPackets limit. If your connection cannot handle 100 packets it will cause your ping to rise or spike. Even if it can handle the jump from 63 to 100 packets, this may well cause your ping to fluctuate more than if your actual MaxPackets were constant.
*Oh and having maxfps 333 can mess up a server by causing everyone else to lag. I don’t know why or under what circumstances, but I’ve seen it happen when two or three players with 333fps get on the same server.
With R_swapinterval 0
xxx equals your COM_MAXFPS, if you set this to ANY NUMBER lower than your com_maxfps, it will CUT YOUR MAXPACKETS IN HALF.
example: COM_MAXFPS =125 CL_MAXPACKETS =100 means your MAXPACKETS BECOME 63 (half your fps because 100 is NOT divisible by 125)
IN_MOUSE
IN_MOUSE -1
Captures the position the Windows cursor and passes that info to the game to change the camera angle. Once that is done for a frame, the cursor is returned to the center of the screen. There is nothing else applied to the data until it gets to the sensitivity, acceleration, m_yaw, and m_pitch part of the code.
Pros:
-As responsive as you can get
-It’s accurate
-Perfect for Logitech’s SetPoint Implementation Option
Cons:
-The cursor can clip the edge of the window and not be able to go further, resulting in negative acceleration. The higher your Q3 resolution and framerate, the less you will run into this problem (800×600 is pretty much safe for any sens, 640×480 might have some clipping with low sens). Higher mouse sampling rates or r_finish should also be used to prevent Q3 from getting 2 or more large mouse samples in one frame.
-Must use CPL mouse fix (or alternative) to eliminate Windows enabling Pointer Prescision automatically for games in WinXP.
-Some may start to miss jumps set to -1
IN_MOUSE 1
Uses DirectInput to directly acces the mouse, bypassing the windows cursor. It also applied ~12ms worth of mouse smoothing automatically before reaching the sensitivity and acceleration part of the Q3 code.
Pros:
-No negative acceleration
-Works independantly of Windows cursor settings (i.e. Sensitivity and Pointer Prescision)
Cons:
-Uncontrollable mouse smoothing which adds latency to mouse actions.
-Delay when clicking mouse (click -> wait 12ms -> shoot = bad)
-Even raising your mouserate (hz) even makes a large difference, not so much in new mice since alot come set to around 500hz. Use cl_showmouserate 1 to see ingame.
CG_PREDICT
0 – off
1 – normal / default
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 at all.
Note: Do not use cg_predictItems 1 with cg_predict 2.
CG_SHOWPLAYERLEAN
0: Allows the disabling of viewed model leaning that was introduced in the 1.27x patches. Players appear to “lean” in the direction they are walking in so its easy to see them change directions.
1: Could be used to help judged where the persons moving next. Then again it can throw you off.
CL_PACKETDUP 0-3
0 uses the least ammount of bandwidth and doesn’t “waste” time sending packets twice. Set higher if you have much packetloss. You can check your packetloss easily by using cg_predict 1. I use cl_packetup 2 or 3 is about as high as i would go.
CG_OPTIMISEBW
MUST be 1. Don’t ever use 0, and only use 2 if your connection is REALLY bad, ie 56k or below.
CG_NUDGE
Keep at 0 if you ping below 90-100. If you ping higher use negative nudge(not recommending due to extremely choppy players, almost the same as cl_timenudge)
CL_TIMENUDGE
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.
This affects how your client processes the snapshots it receives. Normally the client compares one snapshot with the next and interpolates between the two. If you set this to a negative value, you can adjust the interpolation of snapshots to compensate for lag by making your client start interpolating BEFORE it recieves the next snapshot. In other words, it will be predicting what the next snapshot will look like and using that prediction as a basis for the interpolation. At some point during this nudged interpolation, the actual next snapshot will arrive from the server. At this point, the client will replace the predicted snapshot by the actual snapshot and recalculate the interpolation. This difference between the two is the prediction error. However at this point, you will not see a huge jerk due to the change from predicted to actual data as the prediction error is decayed away to ensure the gameplay remains as smooth as possible, even if it is slightly inaccurate.
The more negative timenudge you use, the more predictions will happen and therefore the more inaccurate the predicted data will be. Therefore, even though these errors are decayed, the jerks will be more noticable and as a result other players will seem to move less smoothly.
Effectively, the greatest negative value is equal to 1000/sv_fps (of the server) however -12 is a recommended maximum to keep the gameplay smooth and accurate, even if there is a little less lag compensation.
There is also another side to the timenudge story. You can use positive values of timenudge to affect snapshot interpolation with an opposite effect. Using positive values means that your client will wait for extra time before interpolating the 2 snapshots. This can be useful if you have a higher ping or a packetlossy connection. In these cases snapshots are likely to be lost and the time between each snapshot arriving can fluctuate greately as some packets are delayed or whatever. In this case, even if you are not using any timenudge, the client may have to start interpolating before the next snapshot has arrived, simply because it is late. By using a positive timenudge, you can ensure that the client waits those crucial few milliseconds more to allow the next snapshot to arrive successfully, thus keeping gameplay smooth and accurate – even if the incoming data is deliberately lagged.
Btw using timenudge will not affect your ping on the screen, simply because your ping has not changed. Timenudge has nothing to do with your actual ping, but it has everything to do with your lag. I would like to add that timenudge only directly affects the lag of the incoming data and does not directly affect the data that you send to the server. Whether timenudge indirectly affects your outgoing data is unlikely but that issue is best being left for a timenudge-specific topic.
/cl_AutoNudge (Avaible in Quake3e) automatic time nudge that uses your average ping as the time nudge, values:
[0] Off
[1] ON
CG_XERPCLIENTS
-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 – Can be used but errors will occur (players in walls and stuff)
CG_LAGHAX
-1 is nice, shouldn’t be changed unless you have ping over 100 and use negative nudge.
DISABLE PUNKBUSTER -CPMA ONLY
Most cpma servers do not run punkbuster, you need to know cuz you need to know.
seta cl_punkbuster 0
pb_cl_disable
CG_LAGOMETER
interpreting the lagometer (the graph in the lower right corner):
The upper graph (blue/yellow) slides one pixel for every rendered frame. Blue lines below the baseline mean that the frame is interpolating between two valid snapshots. Yellow lines above the baseline mean the frame is extrapolating beyond the latest valid time. The length of the line is proportional to the time.
The lower graph (green/yellow/red) slides one pixel for every received snapshot. By default, snapshots come 20 times a second, so if you are running >20 fps, the top graph will move faster, and vice versa. A red bar means the snapshot was dropped by the network. Green and yellow bars are properly received snapshots, with the height of the bar proportional to the ping. A yellow bar indicates that the previous snapshot was intentionally
supressed to stay under the rate limit.
The upper graph indicates the consistancy of your connection. Ideally, you should always have blue bars of only a pixel or two in height. If you are commonly getting big triangles of yellow on the graph, your connection is inconsistant.
In a heavy firefight, it is normal for modem players to see yellow bars in the bottom graph, which should return to green when the action quiets down. If you are getting several red bars visible, you may want to look for a server that drops less packets.
Number 1 is a normal, stable lagometer display, with a narrow, flat green line at the bottom, which reflects a fairly low (50) and stable ping. The upper blue line has only a tiny bit of yellow in it. Yellow above the blue line is undesirable, since these are frames that are extrapolated by your client, which means that it is making a kind of educated guess about where moving objects are, in the absence of “real” snapshot data from the server.
Number 2 contains many yellow triangles above the blue, but there is still blue in between them. The blue indicates frames that are interpolated between valid snapshots, but the yellow means that the client is extrapolating outside of valid snapshot data. The height of the yellow indicates the time since the last valid snapshot, which is why triangles form. The longer the time without a valid snapshot, the higher the yellow line, until valid snapshot data is again rendered and the yellow suddenly disappears. When this happens, the client will put players back where the server says they should be, which may not be where the client had extrapolated their movements. The game would appear choppy as the cycle of extrapolate/correct/extrapolate/correct continued.
Number 3 shows a large yellow triangle forming at the edge of the lagometer. As time passes without a valid snapshot having been rendered, the height of the triangle grows accordingly. This is a graphic representation of the phenomenon of lag. Note that there are spikes in the green, showing that the client’s ping is momentarily climbing.
Number 4 shows red spikes, which mean that snapshots have been dropped by the network, either in transmission (packet loss) or because the client can’t handle them (cpu tied up by other tasks, like taking repeated screenshots.) CoD and all Quake-engine games use UDP packets because they are fast and easy to handle, but they have no retransmission or error-correction capability. The server sends them and forgets about them. Once lost, they are lost for good. Red spikes like these occur from time to time, and occasional red spikes are not necessarily bad unless they are wide (each pixel in width is one snapshot lost) or frequent. During DoS attacks on our host, the lagometer will show almost solid red. (Red spikes will always be this height. There is no meaning associated with the height, which is purely arbitrary.)
Number 5 shows a big yellow triangle, which would manifest in-game as a brief freeze, followed by players “teleporting” to nearby locations as the client gets correct information from the server. Remember, any yellow means the client is trying to guess where players should be in the absence of proper information from the server.
Number 6 shows a long string of connected yellow. With no blue in sight, any movement by the player will result in the “skating” or “rubber-band” effect, where the player is “snapped back” to where the server last put him. This shot is not really typical of that effect, since it was the result of taking many back-to-back screenshots. When this happens spontaneously in the game, a triangle will form that grows to the top of the lagometer, so what you really see is a yellow bar all the way to the top.
Remember, the only thing that is “really” happening in-game is what the server is calculating. If the server cannot get this information to the client, the client will render a guess about what is going on. Since players move at about 10 feet per second in the game, one missed snapshot can make a difference of 6 inches in location.
Four missed snapshots (one-fifth of a second in duration) can make a difference of two feet! This is why your client sometimes appears to show a sure hit, but the server may register a clean miss. Playing with the lagometer on can help you understand what is “really” going on in the game
CG_SMOOTHCLIENTS
Smoothes out the visibility of a high ping player that otherwise would stutter/warp around to you. In order to use this the server also has to enable it. That means your accuracy can vary from server to server.
– “0”: Off (should be used when you are using negative timenudge)
– “1”: On