A user-recommended list of configuration settings that can be tweaked in ioquake3 / OpenArena.

Using different head models[]

Many of the models in OA can be mixed and matched with different body and head configurations. The following two command console commands are used to achieve this.

/seta model "model name/skin name"

/seta headmodel "model name/skin name"

The first command sets the player's body and head to the specified model/skin. The second command sets only the head's model to that used by the specified model/skin.

For a list of model and skin names, look at the player model selector in the options menu in-game. The model name will be listed on the top of the previewed model while the skin name will be listed on the bottom. Note that if /skin is omitted from the previous arguments, "model name/default" will be used.

Here's an example:

/seta model "gargoyle/tech"

/seta headmodel "tony"

This gives the player the blue cyborg-looking body of Gargoyle and the default head of Tony.

Some models with specialized animations to the lower or upper body (i.e. Angelyss, Arachna) may not work with the headmodel changing trick and could place a head in the stomach or right hand.

Tweaking which improves performance[]

All the below is assumed to be typed in the console:

/cg_noprojectiletrail 1 <- Removes the trailing smoke from grenades/rockets which gives better visibility and higher FPS. (default 0)

/r_picmip <number 0-16> <- It is reduces texture quality, thus increasing FPS drastically when low on RAM. Very useful with very old graphics cards with small video RAM, really _useless_ with nowadays hardware. Higher value, lower quality (0 = best quality, 16 = worst quality; default value is 1). It's advisable to keep the best quality, as lower quality does not give any better performances, except specific cases with very, very old hardware. Note: this is linked with "texture detail" option in "graphics" menu, and the lowest quality you can set from there corresponds to r_picmip 3, thus altough you manually set it to an high value (for example, 8 -if allowed by videoflags lock-), when you will change anything from that menu and apply changes, you will then find r_picmip set to 3.

/r_detailTextures 0 <- Lowers the quality of the textures (default 1), giving some more fps

/r_swapInterval 0 <- Default 0

/r_showSky 0 <- Remove skybox. Default 0.

/r_fastSky 1 <- Disable high quality sky. Default 0.

/r_subdivisions 11 or 21 (default is 4). Changes geometric detail, as you can do from "Graphics" menu. Higher value means lower quality.

/cg_forcemodel 1 <- All models in the arena looks the same as your model, reduces memory usage by ~2mb/model. Default 0.

/cg_drawTimer 1 <- Enables a timer in the upper-right corner which helps you to time items/powerups. Default 0.

/r_gamma <number between 0 and 2> <- Not a tweak as such but improves visibility by removing dark-spots, sometimes considered a cheat in official competitions when set to higher than 1.3. Default value is 1.

/cg_truelightning 1 <- Lightning Gun (LG) shoots straight beam, following your aim. Makes for a better use of the LG. Default value is 0.0. See Manual/Graphic options#Straight lightning gun beam.

/cg_simpleitems 1 <- Shows items you can pick-up around the arena as 2D sprites (icons), drawing less polygons than when showing their 3D models. Default value is 0.

Tweaking online gaming parameters[]

/rate 25000 <- Increases the rate in which the packets are received, works best for DSL connections and upwards. (Default: 3000)

rate is a simple bandwidth limiter that specifies the maximum number of bytes per second the client wants to receive from the server. This variable is useful if you're playing over an analog modem (values 3000 - 4500) or an ISDN connection (values 4500 - 6000 or 12500 for bundled ISDN), if you're on cable or on DSL the maximum of 25 kB/s (value 25000) should be no problem (unless you're on a metered connection, where rate becomes a cost controlling device). The lower you set rate, the more information about the game state which the server deems 'unimportant' will be dropped and not be sent to the client, and the effects of this are very noticeable at low rates (no sound when other players shoot, players and projectiles popping up out of nowhere, getting hit without noticing it, etc.). You can also control "data rate" from the GUI, using Setup - System - Network menu (for example, "LAN/Cable/xDSL" option is equal to rate 25000, but the same text can be shown also if you set a lower value from the console). Server side, instead, they exist sv_minrate and sv_maxrate variables (both of them are set to 0 by default), that allow the server to not go beyond these specified limits for each client (setting a low sv_maxrate value may prevent clients from consuming all your server bandwith, if you haven't enough of it... or may allow a bit less difference between clients with good and bad connections. Except for these two reasons, it would be advisable to set sv_maxrate to 25000... anyway consider that 1 Mbps upload bandwidth is 1000000 bps / 8 (bits in a Byte) = 125000 Bps, and 125000 / 25000 = just 5 players supported at this sv_maxrate! Well, one could take in account that a client uses all its rate only when needed, but also that one should consider to leave some bandwidth free for overhead. See also Servers#Bandwidth.).

/snaps 40 <- synchronize your game world snapshots with the server's snapshots (hence snaps), and raising it should lower your ping. (Default: 20)

The in-game world isn't simulated continuously by the server, but in discrete steps called snaps (stands for "server snapshots"). The more snaps per second a server processes, the more smooth the simulation of the in-game world becomes, but the more frequently it has to send data to the clients to update their view of the in-game world. The number of snaps per second a server processes is set by the sv_fps cvar on the server, but for some clients with slow connections this value could be too high and the server would flood them with game updates if it sent that many snaps. Therefore the client can specify the maximum number of snaps it wants to receive per second. If the client specifies a snaps value smaller than the servers sv_fps the server will not send the client a snap every time it sends one to the other clients, but every second, third, fourth, etc. so the total number of snaps sent per second doesn't become higher than the snaps value specified. If sv_fps would be set to 60 for example, setting snaps to 60 would send 60 snaps per second to the client, setting snaps to 30 (or 40) would send 30 snaps per second (every second snap), setting snaps to 20 would send 20 snaps per second (every third snap), etc.
Most servers have sv_fps set to 20 (the default), some servers have it set to 40, and some modded servers (CPMA for instance) have it set to 30.
Note: if snaps > server's sv_fps, snaps will automatically be set to equal sv_fps. So if you have a very speedy connection and want to always get the best performances, you can set /snaps 999 and it always will get the max sv_fps snapshots possible for any server you connect to.

/cl_maxpackets 125 <- A setting which works well for most DSL modem users, it increases the packet size and makes pings more stable. Should be set to the same value as com_maxfps. Default value is 30.

cl_maxpackets determines once in how many frames (determined by com_maxfps) the client sends a packet to the server. If you set this to the same value as com_maxfps the client will send a packet for every frame processed, if you set it to ceil(com_maxfps / 2) the client will send a packet every second frame, etc. So if com_maxfps is set to 125 for example, you could set cl_maxpackets to ceil(125 / 1) = 125, ceil(125 / 2) = 63, ceil(125 / 3) = 42, etc. This also means that it makes no sense to set cl_maxpackets higher than com_maxfps. For more informations about com_maxfps (a variable that should be set to a framerate your machine can manage constantly), please read Manual/Graphic options#Framerate (it's related to game physics and some particular values may slightly help you).
Note: ceil() means to round up if there is a fractional part, no matter how small.

/cl_packetdup 0 <- If you experience high PL (packet loss, as you can see from red lines inside your "lagometer", enabled with \cg_lagometer 1), then set cl_packetdup 1 (default is 1) to send each packet two times. Setting it to 0 uses less bandwidth, but if a packet is lost, its information will not reach the server.

/cg_delag 1 <- Enables delagged hitscan weapons, which gives you a better experience, especially when playing with higher pings. Direct-hit-weapons have no lag to shoot and register the hit anymore[1]. Server must have delag support enabled (/g_delaghitscan 1), for it to be effective. See also Delag hitscan. Old mods designed for Quake 3 may not have delag support at all, or may use their own delag technologies (e.g. Unlagged, ZPM mods) and cvars instead.

/cl_timenudge 0 <- Leave at 0 for less lag and less trouble (default 0).

cl_timenudge is an old method (or better two methods) of reducing lag. It is incompatible with delagged gameplay (do not use both this and cg_delag for best results with hitscan weapons). When set correctly it enables you to assess when incoming projectiles are going to hit you in spite of your lag, enabling you to dodge them. It should be set to either half your average ping or minus half your average ping (this means also that you may need to change this value after you change server, to maintain the best experience).
  • Setting cl_timenudge to a positive value adds a delay of that number of milliseconds to the game controls (e.g. mouse and keyboard), but subtracts that same number of milliseconds from the lag on your display. You experience no lag on your display, but at the expense of doubling the lag on your game controls.
  • Setting cl_timenudge to a negative value enables the client prediction algorithm, predicting the future of the game the (positive) number of milliseconds you set ahead of time and showing it to you on your display. You experience no lag on your display and no lag on your game controls, but at the expense of never knowing if your targets are exactly in the locations where your client predicts and shows them. The faster and the more unpredictable your target moves, the bigger the chance that where you see it on your display is not where it actually is.
Technically speaking, cl_timenudge determines if a received snap is processed earlier (negative values) or later (positive values) by the client. The earlier a snap is processed, the more extrapolation (prediction) must be done and the less interpolation (smoothing) between the active snap and the next one is possible, because the more often the next snap won't be received in time by the client to process it. This means the minimum and maximum cl_timenudge values are related to the number of snaps the client receives per second: at 20 snaps there is a 1000 ms / 20 = 50 ms maximum and -50 ms minimum, at 30 snaps there is a 1000 ms / 30 = 33 ms maximum and a -33 ms minimum, at 40 snaps there is a 1000 ms / 40 = 25 ms maximum and a -25 ms minimum, etc.

/cg_projectilenudge -> set to your average ping (this means also that you may need to change this value after you change server, to maintain the best experience). Default value is 0.

cg_projectilenudge is the new method of reducing lag and is compatible with delagged gameplay. When set correctly it enables you to assess when incoming projectiles are going to hit you in spite of your lag, enabling you to dodge them. It should be set to your average ping time (not half your ping like cl_timenudge). This enables a client prediction algorithm also, but for projectiles only and not for targets so you can hit them with delagged hitscan weapons.
Note that it is possible to use cl_timenudge together with cg_projectilenudge, but calculating to which values you should set them together is not intuitive and therefor not very practical, and aiming and firing hitscan weapons becomes more difficult too because you have to take the cl_timenudge value into account and lead (or even trail) your targets.

/cg_smoothclients 1 <- enable extra prediction to give laggy players smooth movement instead of the usual 'skip from one location to the next' (default 0). (This cvar was removed in OpenArena 0.8.5.)

cg_smoothclients enables extra prediction for laggy players who don't update their status regularly (because of real or artificially induced data congestion or packet loss). Using cg_smoothclients is absolutely incompatible with using negative cl_timenudge values.

/g_synchronousClients 0 <- disable full synchronization with the server (default value is 0).

g_synchronousClients, when enabled (set to 1), forces your client to wait for the server's aknowledgement and response before proceeding to the next game state. Concretely, when enabled, you will feel a big delay between your key presses (eg: up arrow) and the intended action (eg: move forward). This cvar is an old reliquate of the past and was mainly used when recording demos (to avoid glitches and broken demos), but this should now be avoided, even when recording demos, since now there are other mechanisms to avoid such glitches (such as cg_delag).

/cl_nodelta 0 <- Setting to 1 disables delta compression, so you will be lagging like hell. Default value is 0.

/cg_predictitems 0 <- Disabling avoid false items pickup (but then there's no prediction and sometimes it can make you pick an item with a delay). Default value is 1.

/cg_cmdTimeNudge 0 <- Disable time nudge for commands. Default value is 0.

/cg_lagometer 1 <- Shows the lagometer, very useful to check if you are experienced networks problems. Default value is 1.

The lagometer is a complex but very useful tool. Basically, the color of the lower part is indicating if everything is normal or if you dropped some packets (red spikes). There are 2 graphs: roughly, the bottom part refers to your client connection, and the upper part to what you receive from the server (to be more correct, they are, respectively, "snapshot graph" and "frame graph"). When everything's normal, the snapshot graph should be green (smaller lines = lower ping = better), and the frame graph should be blue.
More accurate informations about lagometer are available here and here.

/r_swapInterval 0 <- If you set this to 1 or 2 or more it will delay ALL the game : movements, weapons shots, other players, etc...

Tweaking other user settings[]

Under Configuration examples/Scale mouse sensitivity with zoom, you can find a trick which allows to create a "manual zoom" feature which allows to keep the same mouse feeling while zooming (or in general, after changing your field of view setting). It also allows to insert additional levels of zoom.


  1. Trying to explain better: you aim and shoot to where you see an enemy, but your fire command requires some time to reach the server... when this happens, the other player may already result at a different position on the server, and thus you may miss the hit, if lag compensation is not active. With delag active, instead, if you correctly aimed when you fired with your instant-hit weapon (e.g. railgun), server will register the hit anyway when it will receive your data, even if your enemy has moved in the meanwhile.

See also[]

External links[]