en:games:quake_3_arena
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
en:games:quake_3_arena [2020-05-01-15-57] – [Graphics Hack] 7saturn | en:games:quake_3_arena [2021-03-30-12-26] – [Settings That Affect Gameplay Mechanics] 7saturn | ||
---|---|---|---|
Line 12: | Line 12: | ||
* Hotseat: no | * Hotseat: no | ||
</ | </ | ||
- | The third reincarnation of Quake is one of the most revered first person shooters in gaming history. It was released on December 5th, 1999 by [[Activision]]. Its idTech 3 engine is also the basis of a lot of other games, for instance [[Star Trek - Voyager Eliteforce]]. In 2005 idTech released the source files of this engine under the GPL, giving rise to even more new games, developed and maintained by the open source community. | + | The third reincarnation of Quake is one of the most revered first person shooters in gaming history. It was released on December 5th, 1999 by [[Activision]]. Its idTech 3 engine is also the basis for a lot of other games, for instance [[Star Trek - Voyager Eliteforce]]. In 2005 idTech released the source files of this engine under the GPL, giving rise to even more new games, developed and maintained by the open source community. |
===== Installation ===== | ===== Installation ===== | ||
The game still installs well even under Windows 10 (2019-03). The only drawback is the not startable '' | The game still installs well even under Windows 10 (2019-03). The only drawback is the not startable '' | ||
Line 19: | Line 19: | ||
===== Graphics Hack ===== | ===== Graphics Hack ===== | ||
The game engine does offer a rather limited set of graphics resolutions. Especially the wide screen resolutions are only a few. This however, only goes for the presented resolutions in the game menu. Actually the engine does provide all available resolutions of your graphics card. The article [[Q3A Graphics Hack]] describes, how you can use them. These steps also work for most of the other [[Quake 3 Based Games]]. | The game engine does offer a rather limited set of graphics resolutions. Especially the wide screen resolutions are only a few. This however, only goes for the presented resolutions in the game menu. Actually the engine does provide all available resolutions of your graphics card. The article [[Q3A Graphics Hack]] describes, how you can use them. These steps also work for most of the other [[Quake 3 Based Games]]. | ||
+ | ===== Settings That Affect Gameplay Mechanics ===== | ||
+ | Q3 is known to have >> | ||
+ | ==== com_maxfps ==== | ||
+ | This value limits your maximum frame rate, at which you computer updates the graphical representation of the game state (read: what you can see on your monitor). It is an integer value, that theoretically can take any number but in practice can only take values of (1000 / //x//), where //x// is an integer number greater than 1. So values such as 500 (//x// = 2) or 125 (//x// = 8) are OK. Values that do not hit these spots will be rounded up (e. g. for '' | ||
+ | |||
+ | Certain values of this cvar my result in higher jumps or lower jumps. The optimal value is 125. This video explains it in more detail: [[https:// | ||
+ | ==== rate ==== | ||
+ | This value defines the bytes per second your client will allow to receive at max. It is send to the server and regarded as your upper limit. If the server itself has set a lower limit, it will us its own limit. When nothing is going on on the server (e. g. nobody moves or shoots) this rate must not necessarily be used up entirely. A very common value for this is 25,000. The higher the better for you, unless you reach your downstream capacity. If you set this too high for your downstream, you might experience higher pings, loss and in general a bad experience up to the point where you drop off from the server. | ||
+ | ==== snaps ==== | ||
+ | The server does not send you a continuous stream of changes as it processes them. It sends you snap shots of the current situation. This variable defines how often the server should send you an update on the current game state (kind of a frame rate but for the game state). The higher you set this, the more accurate will the representation of the current game flow be on your end. But at the same time it will consume more bandwidth. So if you reach the upper limit of your connection, you may again experience lagg, loss and drop outs. A very common value would be 40. However, just like with '' | ||
+ | ==== cl_maxpackets ==== | ||
+ | This defines how many packages per second you send to the server. Similar to the snaps, this is an update from you (the client) to the server. The higher you set this value, the more smooth your game experience will be. However, if you use a too high value for your upstream bandwidth, you will again experience loss which might result in situations such as shooting (and from your end actually hitting the target) but not hitting the target anyways as the shot never reaches the server and therefore does not count at all. And of course, lagg, ping spikes and stuff like that will happen more frequently. This is a sensitive value. The max value is 125. For really low bandwidth connections such as dial up, 20-30 might be sensible. | ||
+ | |||
+ | Also note: Setting '' | ||
+ | ==== Value Compatibility ==== | ||
+ | If you use '' | ||
+ | |||
+ | So for your generic 125 FPS, the allowed '' | ||
+ | |||
+ | For a computer that cannot handle 125 but 100 '' | ||
+ | ==== cl_packetdup ==== | ||
+ | This cvar controls how often you re-send //the same// packet (duplication). This is meant as a means against a lossy connections. If one of the duplicated packages is lost, it is covered by another one of the bunch. The downside of this is that of course it increases your bandwidth by the given factor. 0 means it is off. 1 means, a package is send 1 more time than necessary, 2 means two duplicates, and so on. So bandwidth strain is also increased to 2, 3 or even more times. Similar to a too high '' | ||
+ | ==== cl_timenudge ==== | ||
+ | Any network game has the problem, that the actual game flow is chopped into snapshots or frames and that the rate of this chopping may vary for all involved computers. This quantization also means, that there is kind of a dead time in-between two snaps. But the game continues for everyone locally anyways. Hence, this dead time may be interpolated on the client (so that during those 3 frames on your 125 fps PC you get not stuck playing on a 40 fps server until the next frame updates from the server). This also means, the client has to do predictions on what will be going on in the meantime. (This goes especially for the server, too, as it is kind of the master of what the game states of the clients should be using as a reference.) Only when the next frame update from the server arrives, your game state will be >>set straigt<< | ||
+ | |||
+ | '' | ||
+ | |||
+ | But you can also use positive values, meaning the interpolation starts //after// the expected server update frame would happen. So in essence it would only kick in, if the server' | ||
+ | |||
+ | Important: This will by no means fix any ping problems or loss. It just tries to compensate for it. | ||
+ | ==== r_swapinterval ==== | ||
+ | If you set this to 1, the fps value is synced with the actual hardware refresh rate of your monitor. For many players this is 60, which will act exactly as if you set the '' | ||
+ | ==== cg_predict ==== | ||
+ | This affects how your client predicts what will go on (see [[# | ||
+ | ([[https:// | ||
[[games database|Back to the games database]] | [[games database|Back to the games database]] |
en/games/quake_3_arena.txt · Last modified: 2023-08-19-09-50 by 7saturn