OpenArena supports various game modes, with slightly different rules. Mainly, you have to choose among varous gametypes. You should take a look to Manual/Gamemodes, and to Basic game options for infos about fraglimit, capturelimit and timelimit. Additional mods may add new gametypes and options.

In this page we are going explain some additional game options, usually controlled by CVARs, variables set using command console. They are not "gametypes", they are special game options.
They are serverside stuff, that generally works if you are playing locally or if you are managing a server (no sense to mess with them while you are playing on someone else's server). They are controlled by serverside variables (although some of them may have some influence on some client settings).

You can find some examples of their use in the Configuration examples page.

Some of them have their effect applied immediately (e.g. g_speed), while others (e.g. g_instantgib) are activated at match (re)start (in this case, remember to set them before the "map" command in your server configuration, or type a /map_restart).

Note: some of the settings listed in this page are from Quake 3 Arena (ancestor of OpenArena), but many of them have been added by OpenArena itself and thus will have no effect while running old mods.

Please notice: if you are a server administrator, it could be a nice idea to set them using /sets command (for example, sets g_elimination 1); see set variables for important infos about this. Doing this, the variables are flagged as "serverinfo", thus being shown in "serverstatus" as happens for server parameters like fraglimit and gametype. This means that you can allow players to know if these options are enabled or not, checking from dpmaster web page, Qtracker or similar. Otherwise, players will not be able to know if they are enabled, unless they find out by themselves when playing on your server and noticing that there is "something" different than usual.
Also message of the day can be used to inform who is connecting to your server about some server settings, if you wish.

Elimination features outside Elimination mode[]

  • /g_elimination <0 or 1> - If you enable this, you will use some features from Elimination/CTF Elimination/Last Man Standing modes within other game modes, for example Free For All: you will enter the game with the weapons set for Elimination mode, you will be able to rocket-jump without hurting yourself, you will not find items (no ammo boxes, no health, no armor, no powerups, etc.) around the arena. Score mode will instead be the the one for the gametype selected, as usual. Default value is 0.
    You don't need to care about this cvar if you are playing "true" Elimination, CTF E or LMS mode. Please refer to Elimination#CVARs to control starting ammo and other options (not all the elimination_ cvars affect the g_elimination option). It may require a /map_restart to make the change effective.
    Please notice that in Elimination/CTF Elimination game modes (\g_gametype 8 and 9), both self and team damage are controlled by \elimination_selfdamage; but when using other game types and enabling /g_elimination, it controls only damage to yourself: damage to team members is still controlled by \g_friendlyfire, as usual.
    Note: dmflags are stronger than elimination_selfdamage: elimination_selfdamage cannot enable selfdamage if dmflags forbids it.

    You may want to try also \g_vampire or \g_regen to get health.

Vampire mode[]

  • /g_vampire <number.dec> - If you set this value above 0, you will gain health when inflicting damage on an opponent. For example, if you set it to 0.3, you will get health for about 1/3 of the damage to your opponent; if you set it to 1.7, you will get more health than the damage to your opponent, and with 1.0 you get the same amount of health as the damage caused. Be careful, since if you hit a corpse (the dead body of someone already killed, but not yet disappeared), you will receieve damage (you will lose health instead of gaining it): randomly spamming around with explosive ammo may be dangerous (and in particular, may be a major problem with proximity mines). Default value is "0.0" (disabled), and usually (if you want to use vampire mode) it is advisable to use values lower than 1.0, e.g. 0.3.
  • /g_vampire_max_health <number> - When \g_vampire is used, maximum health value is customizable using this CVAR. Default value is 500. Note that this should not be set higher than 998, because 999 and over counts as infinity and the player will become impossible to kill. Another "risk" related to this cvar is to fall in a deadly pit that gives 999 damage and survive because you had more health, remaining trapped there until you suicide (/kill): to be absolutely sure you cannot survive to a fall that should kill you, this cvar should not be set over 798, because 799 (max vampire health) + 200 (max armor) = 999. Anyway, this risk exists only in few maps: in a correctly programmed map, being at the bottom of the deadly pit should continue to damage you, killing you in a short time anyway.

Automatic regeneration[]

  • /g_regen <number> - You can change this value to automatically get health as time passes, up to 100. Higher you set it, faster health will regenerate. Default value is 0.


  • /g_instantgib <number> - "Instantgib" mode removes all items from the arena (no other weapons available, no health bonuses); you will have unlimited railgun ammo, and you will kill anyone with a single shot. 0=off, 1=rail only, 2=rail+gauntlet (gauntlet gives instant kill, too). You can set it to 0 or 1 also from "Skirmish" or "Multiplayer-Create" menu. Default value is 0. "Instantgib", also known as "Instagib", is a popular game mode, found -with some variants- in various Q3A mods, for example CorkScrew.


  • If you like railgun-only matches, but you prefer to need more than a single hit to kill or to be killed, consider the option to use "g_elimination" feature, accordingly using the "elimination variables" to give only railgun ammo, but more starting health and armor (in this case, do not enable the "instantgib" feature).
  • If you would like to try other weapons as immediate frag machines, you may disable g_instantgib and mix extreme g_damageModifier values with dmflags 8 and potentially dmflags 1024 (dmflags 1032). See Configuration examples/One shot one kill for more info.

All rockets[]

  • /g_rockets <0 or 1> - "All rockets" mode removes all items from the arena (no other weapons available, no health bonuses); you will have unlimited rocket launcher ammo only. You can set it to 0 or 1 also from "Skirmish" or "Multiplayer-Create" menu. Default value is 0. Note: Rocket jumps still hurt you; if you want to do them without getting injuried, you can set g_rockets 1, g_elimination 1 and elimination_selfdamage 0. Alternatively, if you are running at least OpenArena 0.8.8, you can set g_rockets 1 and dmflags 1032[1]. See also Configuration examples/All rockets mode with rocket jumps.

Friendly fire[]

  • /g_friendlyfire <0 or 1> - This variable comes from Quake3. This option allows to choose if players can hurt and kill their team-mates during team game modes (except for Elimination and CTF Elimination game modes, where team damage is controlled by \elimination_selfdamage value). If it is enabled, if you kill a team-mate of yours, you (thus, your team) will lose a frag; if it is disabled, your shots will not damage them. Friendly fire hurts friends as much as it would do with foes, but does not trigger the "hit sound".
    Default value is 0, and if you create a match from Skirmish or Multiplayer-Create menu, you can see that it its enabled by default for Team Deathmatch mode, and disabled for other team modes (Capture The Flag, One Flag Capture, Overload, Harvester, Domination, Double Domination). With FF, you should pay more attention to where you shoot!

Award pushing[]

  • /g_awardpushing <0 or 1> - When it is enabled, you will get a frag (score) if you shoot a character causing him to fall in a deadly pit (he will not lose score)[2]. If it is disabled, instead, the one falling in the deadly pit will lose a point (you will not earn score), just like he would have committed suicide while not attacked. Since OA 0.8.5, mid-air suicide (/kill), while g_awardpushing is enabled, results in a point to the attacker.

If "award pushing" is active, you will hear a second "hit sound" if the enemy gets hurt/dies after falling down cause of being "pushed" by your fire. Since OA 0.8.5, this variable is enabled by default, altough this feature is not present in the original Quake 3 game.

Note: since OA 0.8.5, in some gametypes committing suicide in any way when there are only two players in the arena causes the other player to get a point instead of the suicide victim losing one. This is independent from "award pushing" setting. See also Manual/Gamemodes/Appendix#Scoring changes comparing to Q3A.

Catch up[]

  • /g_catchup <number> - This variable allows to balance the effectiveness of the weapons of more and less skilled (or that joined the game later) players, to help the latter ones to not get an enormous score gap from the first ones. It enables a sort of "automatic handicap" (but it does not change your "handicap" value -that is a client-side variable, while this one is server-side-... it is a different thing, and the two can even work together. Catch up does not change the maximum health level, unlike what handicap does.). While handicap affects the same way all the attacks of the player that uses it, g_catchup affects all players, but the damage reduction varies dynamically depending from players' score. If it is enabled it will reduce damage done to low scoring players by up 50% (rounded up): it changes the damage caused by the attacks, if the attacker is more skilled (has got an higher score, starting from 6 points ahead) than the attacked.

Catchup has been added in OA 0.8.5. Default value is 0 (disabled). An higher value means that the leader's attacks will get weaker more quickly (always starting from the sixth point of difference with the score of the victim). Negative values do not work. A value of 5 could be advisable, anyway you can consider your fraglimit: with a low fraglimit, an higher catch up value is advisable, while with an high fraglimit, you can also use a lower catch up value.

That's the algorithm for calculation:
damageModifier = 100-min(50,(max(5,attacker-target)-5)*g_catchup)
attacker = killer's score
target = victim's score
damageModifier = damage dealt in percent (100% = full damage)

Some examples:

  • A value of 1 means that a player with a score of 20 would only deal 95% damage to an enemy with score 10 or 90% damage to an enemy with score 5. Both the player with 5 and the player with 10 would deal 100% damage against each other and the player with 20.
    • g_catchup = 2 would have reduced the damage done by leading player to 90% and 80%, respectively.
  • If it is set to 5 then the damage will be reduced by 5% for each frag above 5 from the score of the target player that is behind. If the target has a higher score than the attacker 100% damage will always be dealt. If the target is at most 5 frags behind the attacker 100% damage will be dealt. Catchup can therefore not be used to overtake the firstplace (except by providing momentum) in direct battle.

You can do some tests enabling \g_debugdamage 1 (this shows damage info on console, and is 0 -disabled- by default).

Please remember that catch up applies to both team-based and not-team-based modes, and takes in account invidual score, not only actual "frags". So, in gametypes where individual score can raise up quickly due to performing some actions, "catch up" might kick in very soon. As an example, if you are fast at capturing flags, you might find your attacks nerfed even if you killed nobody yet.


  • /g_runes <0 or 1> - This option disables or enables the "Runes" (also known as "Team Power-ups", "Permanent Power-ups", "Persistent Power-ups" or "Permanent runes"), some special items that were introduced with Quake 3: Team Arena; they are supported since OA 0.8.5 and not available in most old mods. As far as OA 0.8.8, the Missionpack mod ignores this variable and always shows the runes, if the map contains them.

They are "permanent" because, after you get one, you will have it until you die. They are "team" because usually you can get only the ones dedicated to your team (usually, those you find in your own base). Note: Whether they can be gotten by everyone or only by a certain team depends on the options set by the creator of the map, so there could be some maps with them available independently of the teams. If they have the "dedicated team" limitation, they are useless during non-team-based matches (in some maps you could see them and discover that you are not able to pick-up them), so the map creator could hide them for non-team-based matches (see Mapping manual/Additional gametype support#Limiting entities to certain gametypes) or even replace them with non-team-limited runes or other items. A player can have only one of them at once, and to have more players with the same rune at the same time, there must be more spawn points for it.

The runes are Doubler, Guard, Scout and Ammoregen.

Runes are disabled by default in baseoa (the main game), and always enabled instead in The Mission Pack (a mod designed to resemble Team Arena more closely). In baseoa, you can enable or disable them using g_runes <0 or 1>, and they will appear on maps that include them (for example, you can find "Guard" rune in oa_ctf4ish map, and all of them in am_thornish map).

In Configuration examples/No powerups and holdable items, you can find an example about how to disable specific runes while keeping the others, thanks to Disabling and replacing items features.

Game physics[]

Changing the game physics can enable particular game styles. Please notice that, in some maps, setting too low speed or too high gravity may prevent you from reaching some places (your jumps may be too short).

Note: if you are searching info about the various ways the program can simulate the physics ("framerate-dependent", "fixed" and "accurate" physics modes), see Game physics instead.


  • \g_speed <number> - This variable comes from Quake3. This variable controls the players' speed. This refers to the standard speed when running, and (without the need to change this value) the speed can go beyond this value when "pushed" by jump-pads or explosions, and with particular techniques like the strafe jumps. Changing this value, obviously, allows the players to move faster or slower than usual. It does not affect spectators, weapons or moving objects. Default value is 320.


  • \g_knockback <number> - This variable comes from Quake3. This variable controls the power of the "pushing" caused by weapons. For example, setting it to an higher value, will allow more powerful rocket jumps. Default value is 1000.


  • \g_gravity <number> - This variable comes from Quake3. This variable changes the gravity level, making the jumps higher or lower (and changing the falling speed). It is usually set to 800, but its value is related to each map: when a map is loaded (or the match is restarted), g_gravity assumes the value selected by the map creator for that map.

This means that, if you want to change it, you have to change it after the map has been loaded, and every time a new match begins. If you are using a map rotation script, you have to place the "g_gravity" command after the "map" command (we suggest at the very end of the line), and you have to use "map" command instead of "map_restart" even to play in the same map again, otherwise the map's value will overwrite yours. And be sure to set g_dowarmup to 0: this gravity script works with the "elimination warmup" (that is controlled by elimination_warmup and elimination_activewarmup variables), but not with the "generic warmup" (that is controlled by g_warmup and g_dowarmup); in case of g_dowarmup 1, g_gravity would be reverted to map default at the end of warmup!
Please notice that situations that cause a map restart (e.g. voting for a "shuffle" of the teams during team-based games) and do not trigger the map rotation script (e.g. manual map changes), will cause the gravity change back to map default until the new match ends and the map rotation script continues to the next map.

set d1 "map am_galmevish; set nextmap vstr d2; g_gravity 1200"
set d2 "map am_galmevish; set nextmap vstr d1; g_gravity 400"
vstr d1 // start loop at d1

To avoid problems with g_gravity auto-reset feature, OpenArena 0.8.8 indroduced a new variable, g_gravitymodifier.

Gravity modifier[]

  • \g_gravitymodifier <number.dec> - This variable has been introduced with OpenArena 0.8.8 (this does not work in previous versions or old mods). G_gravity value (map default or user customized) is multiplied by g_gravitymodifer value, and the result will be the effective gravity. Examples: g_gravity 800 * g_gravitymodifier 1.2 = 960 actual gravity; g_gravity 800 * g_gravitymodifier 0.7 = 560; g_gravity 600 * g_gravitymodifier 1 = 600. Default value is 1.

Important: unlike g_gravity, g_gravitymodifier does not automatically return to its default value, but keeps the last value you set until you change it again. If you set a g_gravitymodifer value and then change map, the next map will use the same multiplier (the actual gravity may vary in case of a different g_gravity value).

G_gravitymodifer may be useful while trying to emulate different framerate physics (e.g. to emulate 125fps physics while using accurate physics instead; however, the rounding error caused by framerate-dependent or fixed framerate physics varies with different g_gravity values, so there isn't a single g_gravitymodifer value that can emulate 125fps physics at all gravity values; anyway most maps use g_gravity 800 -more info here-), or to make lighter map rotation scripts, and to avoid problems in case of map_restart.

Quad factor[]

  • \g_quadfactor <number.dec> - The "quad damage" power-up, by default, multiplies the damage caused by your shots by 3.[3] It is possible to change the multiply factor with this variable. Default value is 3.

G_quadfactor holds fractonary values (e.g. setting it to 1.5 will cause "quad damage" user to make only 1.5 times normal damage). G_quadfactor should be kept to "sane" values: excessive values (anything above 6, maybe?) may make the player really too powerful, while fractions below 1 (e.g. 0.5) would make the "quad damage" player cause less damage than standard players (and negative values would even cause weird knockback effects). To prevent such weird effects, since OA 0.8.5, in baseoa the Quad will not spawn if g_quadfactor is <= 1.0[4].

Damage modifier[]

  • \g_damageModifier <number.dec> - Added by OpenArena 0.8.8. This variable allows to modify the damage caused by all weapons and triggers (including falling damage). It multiplies the standard damage by the number specified in the variable. It is possible to use fractional parts. Examples: if a certain hit would normally cause a damage of 10, with g_damageModifier set to 0.5, it will cause a damage of 5; with g_damageModifier set to 1.5, it will cause a damage of 15; with g_damageModifier set to 2, it will cause a damage of 20. G_damageModifier values of 0 and lower will have the same effect as setting it to 1 (no change). Default value is 0.

May be used, for example, to create a crazy "One shot one kill" match, in combination with dmflags 8, as seen in Configuration examples/One shot one kill.

Spawn protection[]

  • \g_spawnprotect <number> - When your character respawns, may immediately face better equipped opponents, that may be waiting for you near the spawning point (note: "camping" is not considered a nice thing in Q3-style games, and spawn-point camping is not polite either). Spawn protection prevents you from getting damage when being shot just after you respawn. The variable controls the time (in milliseconds) you will be protected from other players shots when respawning. Default value is 500, meaning you are protected for half second only. A value of 2000 would protect you for two seconds, etc. This protection immediately runs out when you fire for the first time (when you shoot, you immediately become vulnerable).

This protection was not included in the original Quake 3 game (it has been added by OA 0.8.8), thus many old mods do not have it, while various mods implemented their own spawn protection (e.g. CorkScrew or AfterShock). You should refer to each mod documentation for infos. These implementations may have various differences from the one of baseoa: they may be controlled by different variables, with different default values and different unit of measurement (e.g. seconds instead of milliseconds); they may show a glowing color overlay around spawn-protected characters (baseoa implementation does not give any visual feedback about spawn protection, to avoid causing the player be too easily identified); they may prevent players from shooting at all until their protection time expires.

Note: in modes like instantgib a skilled "A" player may be quick enough to shoot at a respawning "B" player before B's protection runs out (even without camping near a spawning point)... with no effect and ending up being killed in turn because B is able to immediately shoot back while A has to wait weapon reload time. In such environments, server admins may like to disable spawn protection (setting the variable to 0). This, of course, opens the way to spawn point campers again.

Forced respawn time[]

  • \g_forcerespawn <number> (default value is 20) - When a player dies, usually he has to wait 2 seconds before being allowed to respawn by pressing the fire button, and after 20 more seconds respawning is forced. But that "20" is just the default value, and the server admin may change g_forcerespawn variable to customize this time, expressed in seconds. This is supported since Q3A, and should work with most mods.

If you wish to force your players to respawn as soon as possible[5], you may set the variable to 1 (one second after the initial 2 secs wait); you if wish to let them stay dead as long as they wish, you may set it to 0 (no limit).

Since OA 0.8.8, this may be used in conjunction with "respawn waves" (\g_respawntime, default value is 0) to force mutiple players to respawn temporally near. See Respawning in waves section for more infos.

Respawning in waves[]

Premise: when a player dies, usually he has to wait 2 seconds before being allowed to respawn by pressing the fire button; after 20 more seconds respawning is forced (that "20" is a default that can be customized, see Forced respawn time section). Recent OpenArena versions include a counter which shows the time before being allowed to respawn, followed by the "click fire to respawn" text.

Since OpenArena 0.8.8, it is possible to allow players to respawn "in waves".

  • \g_respawntime <number> sets the time between waves, in seconds. Default value is 0 ("waves" feature disabled). If set to a number <n> bigger than 0, "click fire to respawn" will be allowed only every <n> seconds, allowing all the players who died in a <n> seconds time window (shifted by 2 secs before the wave) to respawn at the same time if they wish (already holding the fire key when the respawn timer reaches 0 allows to respawn as soon as possible). Since the minimum time before respawning is still 2 seconds, dying less than 2 seconds before a wave causes the player to fall in the next wave.

Example: we have "\g_respawntime 10"; player A dies at 0:00, player B dies at 0:07, player C dies at 0:09 and player D dies at 0:15. Player A and B will be allowed to spawn by the same wave, while player C and D will be allowed to spawn by the following wave. Player A will have to wait about 10 seconds, and player B will have to wait about 3 seconds: both of them will get "click fire to respawn" at 00:10. Player C will have to wait about 11 seconds, and player D will have to wait about 5 seconds, both getting "click fire to respawn" at 0:20.


  • "Respawn waves" may be used in conjunction with small[6] \g_forcerespawn values to actually force the players of each wave to respawn temporally near each other: e.g. if you set g_forcerespawn to 1 (default value is 20), all players of a certain wave will have to spawn within the same second. See also Forced respawn time section.
  • As a small side effect, enabling "respawn waves" may also discourage a little from abusing the /kill command, due to adding some (variable) delay before respawning after each death. People may not like waiting and so they may prefer trying the best they could to remain alive, rather than committing suicide (to avoid fighting or searching for items), when low on health.
  • In badly designed maps with very few respawn points, in case of many dead players at the same time (e.g. with a long delay between waves), this may cause some telefrag. But hopefully this should be a relatively rare scenery.
  • Players can set \cg_showtimer 1 to know the time elapsed since the beginning of the match.

Weapon respawn time[]

  • \g_weaponRespawn <number> sets the time, in seconds, after which weapons re-appear after being picked up by someone. It does not affect Team Deathmatch (TDM) mode. Default value is 5.
  • \g_weaponTeamRespawn <number> works the same, but only affects Team Deathmatch (g_gametype 3) mode. Default value is 30.


  • Map authors may set custom respawn times for each single item in the map, overriding the timings set by these variables.
  • In TDM, ammo storage works differently from all other modes, and it's way easier to go beyond each weapon "base" ammo load; see Manual/Weapons#Pickup rules for info. So, if you want to try setting g_weaponTeamRespawn to a lower value, probably you may try something like 15 or 20... there should be no need to go as down as 5.
  • These variables exist since Q3A and should work with most mods.
  • Setting these variables to 0 would cause the player staying on a weapon spawn point to reach its max ammo load (200) almost immediately in TDM mode and in just two or three seconds in other modes.

Delag hitscan[]

Quake 3 Arena didn't include a good system to compensate network latency, so you had to predict your foes' movements and aim a little ahead of them -more when your ping is higher-. So, mods like Unlagged were born to add such compensation[7].

Since OA 0.7.6, the main OpenArena game (baseoa) includes built-in delag hitscan feature. If unlag hitscan is enabled on both the server and the client, you don't need to aim ahead of your enemy, when using hitscan weapons (machinegun, shotgun, lightning gun, railgun, chaingun).

Involved cvars are

  • \g_delagHitscan <0 or 1> - Server-side variable. Allows (1) or not (0) players to use delag. Default value is 0.
  • \cg_delag <0 or 1> - Client-side variable. Players having it set to 1 enable the feature for themselves, if the server allows it. Default value is 1.

Enabling or disabling "Unlag hitscan" option from the GUI ("game options" menu) will turn both cvars to 1 or 0 at the same time.

When lag compensation is active, you don't have to worry about tweaking your \cg_truelightning variable: see Manual/Graphic options#Straight lightning gun beam.

You can refer to Tweak page for infos about \cl_timenudge -which should not be used in conjunction with delag- and \cg_projectilenudge cvars, client-side variables which may help you to somehow compensate latency also with projectile weapons. While delag is mostly an offensive improvement (to more easily hit targets with hitscan weapons), those cvars are mostly defensive (to help dodging incoming projectiles).


  • \dmflags <number> - Default value is 0. This is a special variable that allows to change some aspects of the game.

This is a "bit field" variable. Each option is identified by a number, and each number is the double of the previous: if you want to enable two or more options, you have to add up the two (or more) numbers, and set the variable accordingly. E.g.: to enable both the option corresponding to 8 and the one corresponding to 16, you have to set the variable to 24 (16+8=24).
This sounds strange to human beings, but is friendly for computers, that work with binary digits (see binary numeral system on Wikipedia). In binary digits, 8 is written as 1000, 16 is written as 10000, and 24 is written as 11000: for the machine it is easy to check if each position of that numer is set to 0 or to 1, and acts accordingly (each position represents a different option).
To know which options are enabled, starting from a certain dmflags value, convert it from decimal to binary using a scientific calulator (e.g. Microsoft Windows calculator "calc" can show a "scientific" version of itself), e.g. dec 40 = bin 101000, and then consider that the fourth position (starting from the right) is 8, the fifth is 16 and the sixth is 32: this way, you understand that 40 means that options 8 and 32 are enabled.
To know how to set the variable, starting from the options you want to enable, is easier: just use a standard calculator and sum the values corresponding to the options you want.

Tip: you can use the small and useful OA DMFlags tool, available here, to easily determine which dmflags options are active on a server by typing a "decimal" dmflags value (that you should be able to retrive from /serverstatus or /serverinfo commands[8])... or to know how you should set the dmflags variable on your server, by clicking on the chekboxes that represent the options you wish, and then reading the decimal value.

Quake 3 dmflags[]

These are the dmflags values inherited from Quake 3. These are probably valid with any OpenArena release and most mods, too.

No falling damage[]

  • 8 - No falling damage. Disables falling damage. Players do not suffer from landing damage -unless the map itself contains an hurting "trigger", e.g. when you fall into deep space-.

Fixed FOV[]

  • 16 - Fixed FOV. Disables field of view change. Forces all players to see the game like having the default FOV (90); only own weapon is drawn accordingly to the FOV chosen. Can be used to make the game more fair for all players. Also affects "zoom FOV" (forces its default of 22.5). Note: Videoflags include another kind of FOV lock ("Basic lock"), less restrictive than this one.

No footsteps[]

  • 32 - No footsteps. Disables footstep sounds. Jumping, pickups and weapon sounds can still reveal players presence.

Mods dmflags[]

Dmflags values that come from specific mods (example here):

  • You have to search in the documentation that comes with each mod (web sites, readme files, pre-defined .cfg files...)
  • Mod-specific dmflags will not be the same in baseoa or other mods (same dmflags values may do nothing or do different things, when used in different mods).

OpenArena dmflags[]

Dmflags added starting with a certain OpenArena version. They will not work on old mods[9] or servers running previous OA versions.

Instant weapon change[]

  • 64 - Instant weapon change. Introduced with OA 0.8.8. Weapon switch takes no time; weapons still need to reload before being changed.

Non-accelerated jumping[]

  • 128 - Non-accelerated jumping. Introduced with OA 0.8.8. Disables strafe jumping and thus limits you to g_speed for plain level moves effectively. It is important to know that on Accelerator Pads you shall not press forward or you slow down and fall down. Movement and stopping gets non-slippy. Side-effect is an increased mouse sensitivity (you can try /sensitivity lowered by 1/5).
    Makes many maps impossible to be played as they were meant -strafe jumping is an important part of Q3-style gameplay-, but could be useful for some mod creators. Trivia: this dmflags is also known as "no bunny hopping", altough that is a bit misleading, considering that bunny hop is a technique slightly different than strafe jump, and bunny hop is not included in the standard OA game (baseoa), but is available in few mods only... and such mods probably do not care about this dmflags value.

Total invisibility[]

  • 256 - Total invisibility (also known as "no invisibile skin", although a bit misleading maybe). Introduced with OA 0.8.8. Players that hold the invisibility powerup become completely invisible, instead of being almost invisible.

Light voting[]

  • 512 - Enable non-majority vote (also known as light voting). Introduced with OA 0.8.8. Quake 3 and OpenArena up to 0.8.1 (and 0.8.8 by default) require that more than half of the players vote yes for a vote to pass (this means that not voting equals to vote "no": if there are 12 players on a server and 6 vote yes and 1 no, the vote fails); OA 0.8.5 changed this to a different method ("light voting", "non majority vote"... in the previous example vote would succeed because there are more yes-votes than no-votes and more than 30% of all voters voted yes and at least 2 players voted yes). OpenArena 0.8.8 makes "classic" voting system return, and enabled by default... but now allowing server admins to select their preferred voting system. In OA 0.8.8, not using this dmflags makes the server use classic voting; enabling this dmflags, instead, makes the server use light voting. Please notice that old mods always use the classic mode only, unless the mod itself has been designed with a different voting system. Mods based upon OA 0.8.5 game logic (if any exist) may have lightvoting always enabled. Note: lightvoting in 0.8.5 had a bug, so a vote would be ignored if the player respawned after voting; this has been fixed in 0.8.8.

No self damage from weapons[]

  • 1024 - No self damage from weapons. Introduced with OA 0.8.8. You get no damage from your own plasma, rockets, grenades and BFG. Reminder: falling damage is controlled by dmflags 8, instead (1032 means both protections enabled, and may be very nice while playing in all rockets mode: tons of rocket jumps!). Your proximity mines do not hurt yourself anyway. Note: dmflags are stronger than elimination_selfdamage: elimination_selfdamage cannot enable selfdamage if dmflags forbids it.


  • \videoflags <number> - Default value is 7. This is a special variable that allows to limit users' range of allowed values for some graphic options, to prevent them from using some graphic settings that may give them unfair advantage against other players, or that may simple be impractical for effective use.

This has been introduced with OpenArena 0.8.5 and is sometimes also known as "fairflags". Its locks (or at least some of them, like vertex lock) have no effect while using old mods, based upon game logic older than OA 0.8.5.
It is a server-side "bit field" variable, just like "Dmflags" is: please read Dmflags section to understand how to interpret a bit-field variable.
Default value of 7 means that all the three locks are enabled by default (7=4+2+1). A value of 0 allows maximum user customization of the settings involved.

Basic lock[]

  • 1 - Basic lock (a.k.a. FOV lock). Limits maximum field of view value, making the highest effective cg_fov and cg_zoomfov values to 140 (without the lock, the highest effective value is 160, but it's quite impractical to use). User can set higher values, but only his own weapon will be drawn that way: all the rest will be drawn like with 140 FOV. Note: if you are interested into forcing all players to use the same FOV (90) while playing on your server, there's the Fixed FOV dmflags for that.

Extended lock[]

  • 2 - Extended lock. Limits r_picmip, r_intensity, r_overbrightbits, r_gamma, etc. to sane values. Example: if a player sets r_picmip to 16, that variable will be automatically reverted to 3 (the worst texture quality allowed when this lock is enabled. Note about r_picmip: best texture quality is r_picmip 0, and higher values mean lower quality.). It does not include the basic lock features (FOV lock): if you want to enable both of them, you have to sum up their values.

Vertex lock[]

  • 4 - Vertex lock. Prevents users from using "vertex lighting", forcing them to use "lightmap lighting" instead. Vertex lighting allows to achieve higher frames-per-seconds, but makes the game look worse and the different looking may give an unfair advantage helping spotting other players. This videoflags forces clients to set r_vertexlight variable to 0 (which is its default value). Note: if clients set /cg_autovertex 1 (its default value is 0), they will automatically have r_vertexlight enabled each time they will connect to a server that has this videoflags lock disabled. See also Manual/Graphic options#Lighting.


  • g_dowarmup <0 or 1> - If this variable is set to 1, players have some "warmup" time to freely go around the arena before each actual match starts, without affecting their score in the meanwhile. An on-screen timer informs players about remaining time before actual match start. If this variable is set to 0, the warmup is not executed, and the match immediately starts. Default value is 0.
    While playing in Tournament gametype, warmup is executed even if this variable is set to 0: this is meant to give the next combatant the time to realize it's his turn to fight.
  • g_warmup <number> - This variable controls the actual duration of the "warmup", in seconds. Default value is 20; you may wish to make it lower.

It is important to know that Elimination, CTF Elimination and Last Man Standing modes include a separate warmup feature of their own, so it is advisable to disable g_dowarmup while playing in those modes, to avoid "double" warmups. For infos about the variables that control that warmup type (that is divided into "active" and "inactive" warmup), please refer to to Elimination#CVARs.

Server admins' g_gravity tweaks in map rotation scripts do work correctly with Elimination-specific warmup (if placed in the right place), but not with generic warmup (gravity is reverted to map default when warmup ends): server admins may choose to disable g_dowarmup, or to tweak g_gravitymodifier instead of g_gravity. Fore more infos, please refer to "Gravity" and "Gravity modifier" sections.

Disabling and replacing items[]

Server administrators (and people playing locally) can have some control over weapons (and items in general) spawning in the arena, preventing all items of a certain kind from spawning (e.g. removing all railguns), or replacing them with something else (e.g. replacing all "megahealths" with "personal teleporters"). Disabling items is supported since the original Q3A game, while replacing them requires OpenArena 0.8.8 or later.

Please read Disabling and replacing items page.
We have an apposite page about this topic, hence there is no need to repeat all that stuff here, too :-)

Auto change map[]

Since OpenArena 0.8.8, it is possible to use auto change map ("g_autonextmap") feature as an alternative to the old-fashined map rotation scripts. Auto change map feature isn't broken by changing gametype, as long as it's correctly configured.

Please read G_autonextmap page.
We have an apposite page about this topic, hence there is no need to repeat all that stuff here, too :-)

Blood and gibs[]

The \com_blood variable affects blood and gibs, including enabling/disabling the ability to reduce corpses into pieces and thus the ability to prevent kamikaze from auto-triggering. Its effects vary depending on how it is set on the server and on the client. Such effects are explained in Manual/Graphic options#Blood and gibs, please refer to that. Default value is 1.

Gametype-specific settings[]

There are some options which control the way some things work in specific gametypes.

Just to name a few,

  • Obelisk properties for Overload mode (gametype 6):
    • g_obeliskRespawnDelay <number> (default 100): seconds before an obelisk respawns and a can be attacked again.
    • g_obeliskHealth <number> (default 2500): starting/max health points of each obelisk.
    • g_obeliskRegenAmount <number> (default 15): how much health the obelisk automatically regenerates each time.
    • g_obeliskRegenPeriod <number> (default 1): seconds between obelisk health regenerations.

Elimination and Elimination-like modes have got plenty of elimination* cvars to customization.

See also[]


  1. Dmflags 1032 means option 8 (no falling damage) + option 1024 (no self damage from weapons) enabled. If you want to enable other dmflags options at the same time, the total will vary.
  2. This does not happen if he regains ground control before dying, or dies after more than 5 seconds.
  3. Why the "quad" name with "triple" damage, you ask? Quake 3 inherited it from the previous games in its franchise, that were mostly single-player "campaign" games where the player had to fight against powerful monsters (and some of them required a lot of hits to get killed), so a quadruple damage was good for Quake 1 and Quake 2. Quake 3 developers probably thought that in a deathmatch, instead, a triple firepower would have been enough, or the game would have been too much unbalanced. In the Quake series, the symbol of the quad damage item was a "Q" ("Q" as in "Quake" and as in "Quad"), so it was a distinctive mark of the series, thus they continued using the same name also in Q3, even if the real damage was triple instead of quadruple. In OpenArena, its symbol is no more a "Q", but the name is still the same for compatibility reasons.
  4. After a quad spawn has been negated due to this, you will need to restart/change the map in order to make it spawn again, even after having set a sane value.
  5. From players' perspective, the only action they can do to respawn "as soon as possible", is to already hold the fire button when the initial 2 secs wait ends. Recent OpenArena versions show a timer to inform players when respawning is available, so they can just click then and lose very little time.
  6. Small, but not 0!
  7. 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. Unlagged mod documentation explains well what the latency problem is.
  8. "Serverstatus" command gives you infos about the server you are currently connected to. "Serverinfo" gives you some infos about your own server, even if it's not running and you are connected to a different one.
  9. A few mods may use the same dmflags values to achieve different functions instead... the only source of information about that would be each mods documentation.