This page supposes you already read Manual/Multiplayer page. It has been split creating this "Advanced" page to make that one shorter and easier to read for simple players (since many things written here are most useful for server admins).
Optimize for LAN
If the "Optimize for LAN" option is enabled, the machines that connect to your server from your own LAN (from the same subnet) will ignore the "rate" limit (it will work at 99999 bytes/second, which is even beyond the hard-coded 90000 bytes/s maximum usually available) and will get a "snapshot" for each server "frame" (they should get a more accurate representation of the simulated world). This "ignore rate limit" feature works only if your server "dedicated" mode is not set to 2, and only for machines in your same subnet. If you connect to your server from your "loopback" address (127.0.0.1, your own machine), it should always ignore the rate limit, not counting this option value.
This means that you can:
- Run a server for LAN (dedicated 0 or 1) with no optimization
- Run a server for LAN (dedicated 0 or 1) with optimization
- Run a server for Internet (dedicated 2) with no optimization for LAN (probably this is meant to not give further advantage to LAN players over Internet players, other than the lower ping)
The "Optimize for LAN" option corresponds to the \sv_lanforcerate <0 or 1> variable. Default value is 1.
For more info about "rate", "snaps", etc, please take a look to Tweak#Tweaking online gaming parameters; for bandwidth calculation, see Servers#Bandwidth. For info about the "dedicated" server modes, please read the Dedicated server section below.
A server can be "pure" or not, depending from the value of the /sv_pure <0 or 1> variable. It is highly recommended to keep the "pure" option enabled (sv_pure 1, which is the default value). Turning it off may cause problems, and should be done only for testing.
When a server is "pure", it will load and use only stuff (with few exceptions, e.g. configuration files or demo files) that is already packaged into .pk3 files. All clients connecting to that server will do the same, and will only use pk3 files that are present on both server and client, ignoring potential pk3 files owned by the client only (e.g. players will not be able to use custom player models if the server does not contain them, too). This allows the game to load and unload patch files as needed, allowing users to connect to servers using different versions of the game (e.g. if an OpenArena 0.8.5 client connects to a 0.8.1 server, the pk3 containing the 0.8.5 data will simply be ignored, and the client will use the same versions of game logic, maps and models as the server is using; when connecting to a 0.8.5 server, instead, the client will load 0.8.5 version of game logic, maps and models.). Please notice that not all OpenArena versions are compatible each other; sometimes major version changes are needed, making backwards compatibility impossible. Also remember that this system does not affect program executables, but pk3 files only. See also Manual/Automatic downloading.
Turning off "pure" option, then, may bring to compatibilty problems caused by servers and clients using different pk3 versions (and may make cheating even easier), and usually should be avoided. Disabling it may be useful during developing, instead, cause of the removal of the need of packaging stuff inside pk3 files before using it. The classic example is when creating a map: you can place the .bsp file directly inside a folder like homepath/baseoa/maps and test it it without the need to copy it inside a pk3 file (which is a .zip file, with different extension) each time you compile a new version of the map.
Important: "Pure server" option applies to both "dedicated or not" servers (including single player modes). A server being "pure" does not mean it uses only official OpenArena stuff, and does not guarantee it does not contain some third-party pk3 files that may cause you some kind of trouble (server admins have to check their additional pk3s do not cause problems). More, if you download some pk3 that causes problems, you may notice the problem only when playing locally, because that pk3 could be ignored when connecting to a different "pure" server.
Tip: After connecting to a server from your client, you can scroll back the console up to the "-- FS_Startup --" section, which lists all your pk3 files: after each file it will mention "on the pure list" or "not on the pure list", telling you if that pk3 is also on the server or not (thus, ignored).
You may use this trick to determine whether the server is using the lastest OA release or not. Example: you have OA 0.8.8 and, while connecting to a certain server, you notice red colored console and menus (instead of usual 0.8.8 blue): then you can guess the server is based upon the old OA 0.8.1 version... checking in the console should confirm you that your pak6-patch085.pk3 and pak6-patch088.pk3 files are "not on the pure list", because the server does not have them.
It is possible to start a server game also as "dedicated server": in this case the local machine will not use the graphical system and you will not be able to play directly from that OpenArena process. It is useful if you want to set up a permanent OpenArena server. You can run a dedicated server using "standard" OpenArena executable, or using a specific one designed for this mode only.
In short (very short), you can enable "dedicated server" mode simpy launching openarena +set dedicated <number> from your OS command line, or typing \dedicated <number> in your command console, then loading a map.
Allowed values are 0 (no dedicated server: in this case, you can/must play!), 1 (dedicated server, not broadcasted to master server: usually used for LAN or if you want to play with your friends only, manually giving your address to them) and 2 (dedicated server, broadcasted to master server: meant for Internet, if you want that everyone may be able find your server). Remember that you can even publish your server and restrict access using a password. When running OpenArena.exe in dedicated server mode, if you type \dedicated 0 you will return to standard functionality, and current clients will be disconnected.
You can also start the dedicated server launching oa_ded.exe instead of openarena.exe: this should use less system resources (so it is advisable, especially if you want more server processes on your machine - in that case, you can manually set different ports for each process (launching the software with +set net_port <port number> option), or the program will "sense" that UDP port 27960 is already in use and new istances of oa_ded.exe will automatically use 27961, 27962, etc.), and works only as dedicated server (dedicated 0 is not allowed). You have only the console. Using it, you don't need to type / or \ before a command. It works in plain text mode, so it uses less resources, but does not show text colors: using this executable, you will see ^1Colored ^2text instead of Colored text, where it is used. (Note: updated binaries (e.g. nightly builds) do show colored text.)
Note: oa_ded.exe is the "dedicated server" executable file for Microsoft Windows; under GNU-Linux, it is oaded.i386; under Mac OS, it is oa_ded.ub: please read here for more info.
In case you start oa_ded and it immediately quits, try launching it from command prompt, or try immediately load a map via OS command line parameters (e.g. oa_ded +map wrackdm17).
There are many options that may interest you, and you may to prepare custom configuration files with an external text editor, then load them using /exec <cfg file name> command, to don't have to set them every time. Or you may add command line options to a shortcut, like "C:\...\oa_ded.exe" +set dedicated 2 +map oasago2 +set sv_hostname Your_server_name.
You can start one (or more) dedicated server(s) on a machine, then start a standard OpenArena process and use /connect <server address:port> command to connect to it also from the same machine.
Tip: You can control your server remotely, so you don't need to physically work on that machine to make changes. Please read remote control for more informations.
Hint: remember that you may need to configure your router/firewall, especially if you want your server to be accessible from the Internet.
Tip: your server can set a "message of the day" that will be shown by the clients when they will connect. If you are interested, see message of the day.
Warning: a bug (discovered in OpenArena 0.8.5, and not addressed in 0.8.8) prevents IPv6 OpenArena servers from being shown on standard dpmaster servers! For more info, please read here (and here you can find a modified dpmaster server).
Tip: if using standard (non-ded) binaries, it is advisable to do not switch between non-dedicated and dedicated server modes (or vice versa) after startup, but to use OS command line parameter instead, otherwise that may trigger a few minor bugs. More infos in this thread.
An "hitch" is a sort of slowdown or interruption in the program "loop" that handles game events; this is usually caused by "long" operations like loading a map or loading a bot. When running as dedicated server, if there is a hitch longer than 500 msec, you will find a "Hitch warning: xxx msec frame time" message in the server console. Players may experience some glitches in gameplay for a while, anyway you shouldn't have to worry about them, unless hitches are too frequent or too long...
However, you could try to check if there are other programs running in your machine that use too much CPU, or try to defragment your hard disk, or try to give an higher priority to the server process (under Microsoft Windows, you can do this using Task Manager or the good Process Explorer from Sysinternals), or to restart your machine. Or you may need to use some better hardware.
Note: hitches which happen only in specific maps, and only when there are bots in the map (not counting the moment when a bot is added to the match) may be caused by a map which has not been well optimized for bot play by its author (see Mapping manual/Bot play) and you may thus notice the game "freezing" for a split of second by now and then even while playing the map locally, in singleplayer with bots; if that's the case, there is very little a server admin can do about that.
IPs, routers and firewalls
If you want your friends to join your server, please check your IP address ("internal" if you are playing within a LAN, and "external" if you want to play over the Internet. For example, you can go here to know your external IP address.) and tell it to your friends. You may need to setup your firewall to allow both incoming and outgoing traffic on UDP port 27960, and/or your router to forward (search for "port forwarding", "port mapping" or "virtual servers" options in your router configuration... you may check "NAT", "NAT/PAT" and "services" sections of your router config) that port from your external address to the internal IP of your server machine. You need administrator access to your router/firewall do to this. "Port triggering" (that may be called "Special Applications" in Sitecom routers), instead, probably is not suitable for servers, since after a certain time without traffic on the outgoing port, the router will close the incoming port.
Warning: some internet connections, even if "home" connections, like some with fiber-optic communication technology, may work in a way that may resemble a LAN: behind a NAT/PAT, with you sharing the same external IP with other users of your ISP at the same time. In this case, it could be very difficult or even impossible to setup a listening server accessible from outside the network of your ISP.
Remember that your firewall settings could prevent other players from joining your server, or even prevent you from joining other servers (to be able to connect to other servers, your firewall has to permit outgoing traffic for the UDP ports used by that servers, usually from 27960 to 27970 -but they could be different- and 27950 to get the server list from the master server; anyway often all outgoing traffic is enabled by default). If you have problems, check its settings (a firewall could be integrated in your operating system, or could be a third-party software (for example, supplied with an antivirus program), or could be managed by a network router or by a proper server). Standard port for OpenArena is 27960 (UDP), but sometimes it may be different (for example, there could be more OpenArena servers sharing the same IP, each linked to a different port): it is controlled by net_port variable and it is important for server administrators. To communicate with "master server" (to get the server list), your firewall has to permit outgoing traffic on UDP port 27950 (this one is not customizable). Some software firewalls may allow to completely enable or disable network access for specific programs (checking for their executable files) instead of specific ports.
To be able to quickly autodownload possibly required extra files when connecting to a server that uses HTTP download (a.k.a. WWW download, it is the way to get high download speeds), you need your firewall to permit outgoing traffic to TCP port 80 (or TCP port 21 in case of FTP download). It is the most common settings, usually enabled by default: if you can surf the web freely, probably you are already ready for this.
If you want to run a server and enable http download to permit your clients to autodownload data at high speed, you have to place a copy of the required pk3 files on a web server: we are not going to tell you how to setup a web server, but obviously you will need to allow (and probably "portforward") incoming traffic on TCP port 80 to the machine that runs the web server. You can also host that files on an external web server from third part (there are services that give some web space at no charge), in this case the web server and firewall configuration is not your problem, you have just to place the files in the right path. Please read Manual/Automatic downloading for more info.
Important: some routers or firewalls may not allow computers inside your local network to connect to your own external IP address (if you are lucky, instead, they may contain "NAT reflection" feature, that allows to access resources binded to your external IP, from your LAN; you may be able to use some other tricks to obtain similar effects). When using your own server, local computers should be able connect to its internal (local) IP address without too much effort.
If your router/firewall supports QoS (Quality of Service) feature, you can try to set traffic for OpenArena ports as "high priority" or "low latency" to get better performances. This should make your other network applications not to slow down OpenArena connection too much.
Tip: you can have only a single server session for each IP/port combination. You can have multiple servers (that may correspond to one ore more physical machines) published on Internet using different external ports or different external IP addresses (more rare).
It exists a variable called net_qport (do not confuse it with "net_port"). If two players from the same LAN, that share the same internet access using a NAT (having the same public IP), try to connect to the same Internet server, they will not be able to play if both of them have the same net_qport value. In OpenArena 0.8.5, it works correctly: its value is automatically (and randomly) changed each time you launch the game, so you do not have to worry about it. In some previous versions of OpenArena, like 0.8.1, it was set to 0 by default, so if more players from the LAN had to connect to the same internet server, each of them had to start OpenArena with a different net_qport set from the command line (for example, a player with openarena.exe +set net_qport 46316, another with openarena.exe +set net_qport 37937, etc.).
Another thing about IP addresses: they can be static or dynamic. If you only want to play as a client, you can skip this part; if you want to setup a server, especially with fast downloading enabled, or simply are interested in networking, continue reading. In case of static IP, the ISP (service provider, if we are talking about internet and your external IP) or your network administrator (if we are talking about a local network and your internal IP) gives to you a specific address that never changes, that you may need to type in your router or computer configuration; this means that your server will always be reachable at the same address. In case of dynamic IP, instead, your address may change (usually, each time you reboot your router or computer, but sometimes for other reasons, or sometimes you may reboot the router/PC and find the same ip -if the "lease" time is not expired yet-); this means that your server may change its address through time. This should not be a big problem with OpenArena, since (in internet, running your server in "dedicated 2" mode) your server informs the "master server" about its own existence and address now and then (and in "local" LAN mode, clients scan all their own subnetwork each time), so clients should be able to find it... however, if you want to publish your server IP on a forum board or on your internet site, for instance, that information would lost its validity sooner or later. And, more important, address change could be a major problem if you host your web/ftp server (needed for high speed automatic download) under the same internet connection: maybe, in this case, third-party "Dynamic DNS services" -examples: DNSexit, No-Ip, hopto.org or DynDNS- (that -communicating with a specific software on your PC or with a specific feature of your router- allow to have a "fixed" domain name that will automatically point to your new IP when it changes. Some providers may offer the service for free, while others may request payment.) may help you; in a LAN environment, instead, configuring the web server computer with a static address, leaving only the game computers in DHCP client mode, could be a nice idea.. Having a dynamic dns name may also be useful to have your friends around the world connect to your game server directly, just typing your dns name to join it, without the need for you to tell them your IP each time or to publish on the master server a game server you prefer to keep hidden.
If you want to simply test your internet connection speed, you can go to Speedtest.net (bandwidth test) and Pingtest.net (ping and packet loss test). Obviously, higher bandwidth is better (as a client, OpenArea does not need enormous bandwidth, since you can play even with a 56k modem... but if you want to act as server, you should have nice download and especially upload speeds to support various clients -see Servers#Bandwidth-) and lower ping and packet loss is better (there should be almost no packet loss). "Jitter" refers to "Packet delay variation", difference between maximum and minimum ping duration: lower it is, better it is. Malware infections (viruses, worms, trojans, etc.) may have a bad influence on your network performances.
This can interest you also when acting as a client (player): if you cannot connect to the master server (you cannot browse the "internet" servers list), and believe you correctly configured your firewall, may try to check if your DNS has a problem "resolving" dpmaster.deathmask.net. Try ping dpmaster.deathmask.net in your OS command line... if it cannot find the host, your ISP's DNS may filter it out for some reason (Note: if you can resolve its IP address, but do not get replies to ping, it may mean that your firewall may block "ICMP" packets... ICMP protocol is used by the "ping" OS command, but is probably not required for OpenArena, which uses UDP protocol)... so you may try using a different DNS server: to simply try this, you can use the nslookup command. On both Windows and Linux, type nslookup dpmaster.deathmask.net in the OS command line interface to resolve the address with your usual DNS server, and type nslookup dpmaster.deathmask.net 126.96.36.199 to query the DNS server of Google for the task. If your usual DNS server cannot resolve the address, and Google's DNS can, you may have to change the DNS server in your computer IP configuration (or in your router configuration).
In order to check if your own server is reachable, continue reading.
Tip: server is actually running only when a map is loaded. Also check you effectively have some player slots available (sv_maxclients variable controls how many players -including bots- your server will accept... default value is 8).
To check if your router/firewall(s) are correctly configured, you can try using this tool (PFPortChecker, for Microsoft Windows, free), with OpenArena and oa_ded programs closed. Cause of its nature, troubleshooting of UDP is not too easy, and this tool claims to be more accurate than others for UDP checking. Note: you do not need to install also the optional "Ask toolbar" that comes with that intallation package: it is not related to the test, it's simply a web browser toolbar like others.... you can uncheck its option during installation.
Another test tool is available here (UDP Test Tool, for Microsoft Windows); it is freeware, just enter your email address and they will give you the links to download it and some other freeware test tools from the same developer, e.g. a similar tool designed for testing TCP instead of UDP.
Be sure you loaded a map before doing this test. If your settings are OK, you can check if your server is reachable from internet starting your server and then following this link, putting your external IP or IP:PORT in the place of My_server_IP. If you can see your server infos, it should be ok, and people should de able to play on your server. Specifing your address this way works also if your server is not "dedicated 2" (not published on master server: if your server is not "dedicated 2", only who knows your IP can see your server information or connect to it from Internet).
Be sure you loaded a map before doing this test. If you created a "dedicated 2" server, you should verify that it really appears in the server list (to be found by who don't know your address), so check if you can find it in this list. If you can't see it in that list, but the previous test (specifing your address) worked, it may be that your port 27960 is open, but your router changes your source port when sending your packets outside. Semi-Technical explaination (may contain some litte imprecisions): a "dedicated 2" server informs "master server" about its own existence sending a packet called "heartbeat" (it does it automatically, but you can force it when you want, using \heartbeat command), then master server replies asking for info and your server replies giving its name, gametype, current map, etc. After these three packets (that use port 27960 -you- and port 27950 -master server-), that are enough for the previous test (specifing your address), more packets are exchanged, and they may come from different addresses and ports. These additional packets are sent from outside to the port from which your previous packets were transmitted to the server. So, if your router initially changed the source port of your packets, for example, using port 38120 instead of 27960, the additional packets will be directed to your incoming port 38120, thus being blocked by your router/firewall, or simply not controlled by OpenArena (that checks port 27960). Address/port shifting behavior comes from NAT/PAT router features, great inventions that allow many computers to share a single internet access, but make more difficult to configure servers. If you are using a dial-up modem, probably you are not using NAT and your PC address is your external address; if you are using a router, probably you are using NAT and your PC has an internal address, while your router has both an internal and an external address; sometimes, but it is more rare (usually if your router supports it and if your ISP gave you more external addresses), it is possible for your server to use a specific external IP address directly, without using NAT/PAT. If your "dedicated 2" server is not shown in the server list, you should check that your router sends your OpenArena initial packets using source port 27960, without changing it: you may check for an option similar to "Corresponding NAT entry for outgoing connection" for your port forwarding/port mapping/virtual servers previously configured incoming rule in your router/firewall configuration... it may fix the problem. If a such option is not available, you should try to manually add another rule (that will co-exist with the incoming NAT rule for 27960): an outgoing NAT rule specifing UDP 27950 port as destination or UDP 27960 port as source. Be aware that some NAT options may bring to the server shown up in dpmaster list, but with a strange (random) port number! Check that the port listed there is the desired one! Some routers may also have some "Application level gateway" options, maybe you may take a look to them, too.
Note: OAWire can help you with doing quicker connection tests (allowing to connect to a server with a single click on the dpmaster web page). However, remember that some routers do not allow to connect to your external IP address from within your LAN (your server have to appear on dpmaster web page anyway -if not, you need to fix something-, but if you want to check if it is possible to connect to your server, you may need to use a machine from a real different network connection).
If you know enough about networking, you can try to analyze your network traffic, trying to discover what's wrong. You should check your router/firewall logs for errors and blocked packets, and use a network protocol analyzer software on your server machine. Wireshark is a famous, free and multiplatform tool. If you are using a modem, remember that the software may not be able to acquire dial-up (PPP) traffic. If you are using a router, remember that if it is using NAT/PAT, internal and external addresses and ports may be changed by your router after/before (depending from packet direction) the software reads the packes. To allow the maximum amount of traffic being read by Wireshark, you may need to temporarily (remember to fix everything after the test) disable your software firewall (if you use one), and to configure your physical firewall to allow bidirectional traffic on all UDP ports, and to configure your router to "port forward" all incoming UDP traffic to your server internal IP: be careful, the last one may cause problems if there are more computers attached to your LAN.
If you think everything is correcly configured, but your server still isn't accessible from the internet, you may try temporarily disabling in your OS additional network cards (physical or virtual) listed in your system which are currently not required. Some adapters (e.g. "TAP virtual devices" used by some VPN software, including some "secure navigation/secure vpn" coming with some antivirus solutions) might interfere with port forwarding, even if they are not currently connected. So, temporarily disabling additional network devices and testing again may be worth a try, paying attention to do not disable the network card you actually wish to use.
It is also possible that your server works and it is possible to connect to it, but clients may have difficulties in playing caused by excessive lag. It is advisable to connect to your server, especially when there are various other players connected, and take a look if everything works fine. Hold the "TAB" key and take a look to players "ping"... if many of them have high values, or that have big fluctuations, there is something strange. Playing the game, notice if a particular networking icon appears over the head of the players: it means that they are experiencing a big lag or that they unexpectedly closed/lost the connection... it's normal enough to see it by now and then (players that have connection problems by their own are possible), but if you see it often and over the head of more than a player, it is an alarm signal. If you can, connect from the internet (from outside your LAN) and take a look to the "lagometer", to check that lines shown are green (yellow and red are a bad sign) and similar enough (similar lines means a constant ping).
If there are problems, they could be caused by your connection (e.g. usually using a wireless network is not a good idea), or you may have other running programs that consume your CPU or network bandwidth (in this case, also from other machines), or your OpenArena server may not be correctly configured. E.g. you may have a too high sv_fps value -that may cause too many network packets sent- (commonly used values include 20, 25 and 40), or erroneous sv_maxrate and sv_maxclients values (take in account your connection bandwidth -that is usually expressed in bits, kbits or Mbits-, especially upload bandwidth, and think about how many players it can hold at the current sv_maxrate value, that is expressed in Bytes, and 1 Byte=8 bit: see Servers#Bandwidth for more info and calculations). Sv_minrate should be lower than sv_maxrate, and by default it's set to 0.
You should not have problems to play (at least, as a client) while connecting through transparent/intercepting proxy servers (usually those that do not need to set them in the "proxy" section of your web browser configuration, they are simply set as the default gateway in your network settings) that do not require authentication. Obviously, unless their firewall settings block you (e.g. blocking non-web-surfing ports).
If the proxy is not of that kind, and instead your web browser needs to be informed about its existence, in order to work... things are going bad for online gaming. Probably you will not be able to play OpenArena online.
As you can see here, Quake 3 had some commands related with the use of a proxy server to access the internet.
These are the default values. One has to set them from the command line, when starting the game. Some authentication methods are not supported.
Maybe the ioquake3 team has not continued development of this function: some quick tests to use it with OpenArena 0.8.5 have been a failure. Maybe it uses an old SOCKS implementantion, or this part of the nework code it is simply "broken". You may do some tests, but be ready to see it not working. If you know some way to have them work, please tell us.
What did you say?
Terms used here are mysterious for you? You can take a look to some Wikipedia pages to learn what they mean (be aware that some pages there could be even harder than this one... anyway you don't need to know everything in detail): Server (computing), Game server, Client (computing), Multiplayer video game, Internet Protocol (IP), IP address, User Datagram Protocol (UDP), Transmission Control Protocol (TCP), Bandwidth (computing), Local Area Network (LAN), LAN Party, Dial-up Internet access, Point-to-Point Protocol (PPP), Broadband Internet access, Modem, DSL modem, Router, Firewall (computing), Network address translation (NAT), Port address translation (PAT), Port forwarding (a.k.a. Port mapping or Virtual Servers), Port triggering, TCP and UDP port, Demilitarized zone (computing) (DMZ), DMZ host, Application-level gateway (a.k.a. Application layer gateway, ALG), Quality of service (QoS), Cross-platform (a.k.a. Multiplatform), Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6), Proxy server, SOCKS, Default gateway, Web server, Hypertext Transfer Protocol (HTTP), File Tranfer Protocol (FTP), Loopback, Localhost, Subnetwork (Subnet), Ping, Latency (engineering), Lag, Lag (online gaming), Packet loss, Packet relay variation (sometimes referred as Jitter), Hop (networking), Integrated Services Digital Network (ISDN), Asymmetric Digital Subscriber Line (ADSL), Fiber-optic communication, Internet service provider (ISP), Domain name, Domain Name System (DNS), Dynamic DNS (DDNS), Dynamic Host Configuration Protocol (DHCP), Internet Control Message Protocol (ICMP), Operating system (OS), Command-line interface (CLI), Network interface card (NIC), Malware (Malicious software).
See also: Servers. You can find a server configuration example there (you may save it to a text file in your baseoa folder and then load that configuration with \exec config_file_name. You can find more examples in Configuration examples page, mixing them with the main example configuration.). Other commands available in Command console and Manual/Console Commands pages.
Some commands and variables may be available only when acting as server, or as dedicated server, or as client. When playing locally, you are both client and server.
- \connect <server:port> - Use from client. This command allows you to specify a particular server to connect to. For example, \connect 127.0.0.1 or \connect 127.0.0.1:27960 (use the server's IP instead of 127.0.0.1, anyway this address will work if you launch two OpenArena precesses on your machine, one as "dedicated server" and the other as a client).
- \reconnect - Use from client. Reconnects to the last server. Useful if you lose connection for some reason.
- \disconnect - Use from client. Disconnects you from the current server, returning to main menu. If your client was the host (acting as "listening server", the opposite of "dedicated server" mode), all other clients will be disconnected, too.
- \callvote <command> <parameters> - If the server allows it, players can "vote" to change some server settings, for example map or g_gametype.
- \serverinfo - Use from server. Gives information about your own server. If you run it from a client, while connected to another server, you may notice this would still try to report information about your own, inactive, server (notice the "mapname: nomap" line), not about the one you are connected to.
- \status - Use from server. Gives information about connected clients.
- \clients - Use from client. Gives information about connected clients (like client id).
- \serverstatus - Use from client. Gives information about the server you are connected to (e.g. current map, gametype and dmflags).
- It is also possible to use \serverstatus <server> or \serverstatus <server:port> to query information from a server you are not actually connected to.
- \dumpuser <playername> - Use from server. Shows informations about a specific player (like handicap, rail colors, model/skin...). It shows also the skill level of a bot.
- \net_restart - Restarts networking system, applying pending changes in your IP/port configuration, if any. If it applies one of such pending changes, it shows your machine hostname, IPv4 and IPv6 addresses and ports.
- \net_ip <IPv4 ADDRESS> - Tells the game which IPv4 address it has to use. Default value is "0.0.0.0", and usually there is no need to change it, with the game accepting connections using any of the machine's IP addresses. But sometimes you may want to specify an IP to be used, e.g. if you want to host more server processes on the same machine using different IPs (you may need to configure those multiple IPs in your OS, before), or if you have some problems detecting local network servers, due to the game scanning the wrong LAN (or subnet) in case you have more networking cards enabled (both physical and virtual, e.g. VirtualBox virtual NIC). You can change /net_ip value in console and then use /net_restart to apply the change, or directly start the game with the address specified in the OS command line (e.g. openarena.exe +set net_ip 192.168.0.1).
- \net_port <number> - Without parameters, shows your own UDP network port (it is used together with your IPv4 address). To choose a different port, launch openarena.exe (or oa_ded.exe) with +set net_port <port number> option (or, from OpenArena, pull down the console, and after changing /net_port value, use /net_restart command). Default port is 27960: if program finds it is already in use, it will automatically use port 27961, 27962, and so on... Please remember that the in-game server browser, when scanning for local servers, detects only those using 27960-27963 ports interval, but anyway you can connect to local servers using any port, manually specifing IP and port.
- \net_ip6 <IPv6 ADDRESS> - Similar to net_ip, but specifying an IPv6 address instead of an IPv4 address. Default value is "::".
- \net_port6 <number> - Similar to net_port, but specifying the port to be used with your IPv6 address. Default value is 27960.
- \net_qport <number> - In some versions of OpenArena, like 0.8.1, it was set to 0 by default, with the bad effect of preventing two or more players from the same LAN, with the same extenal IP (behind a NAT), from joining the same Internet server. The workaround was to launch the game manually specifying a different net_qport (for example, openarena.exe +set net_qport 46021) for each player. In OpenArena 0.8.5, it works correctly: a random net_qport is chosen automatically every time you launch the game, thus you do not have to worry about it.
- \heartbeat - Use from "dedicated 2" server mode. Informs the "master server" about the existence of your server, to allow other players over the Internet to find it. Heartbeat packets are sent automatically by "dedicated 2" servers (thus, usually you do not need to enter this command), but you can force the operation with this command.
- \sv_maxclients <number> - Use from server. This is the number of clients that will be able to connect to your server at the same time (including bots, human players and spectators). Default value is 8, and 16 is a quite common value... anyway it can be higher or lower (still considering this game is not designed for "massive" amounts of players). A change will be effective after a map restart. Take in account your connection bandwidth (especially upload bandwidth) and your sv_maxrate value. See Servers#Bandwidth for more infos.
It is advisable to keep this value higher than your bot_minplayers in team-free modes and higher than the double of your bot_minplayers in team-based modes, otherwise new human players may not be able to connect to the server because it would be aleady "full"!
- \g_maxGameClients <number> - Use from server. This is the maximum number of players allowed to play on the server, while the others may only spectate. Example: if you have sv_maxclients 8 and g_maxgameclients 5, up to five players will play at the same time, while the remaining three will only spectate. Default value is 0, that means that all players connected to your sever will be able to play (like if you would set g_maxgameclients at the same value as your sv_maxclients). Note: no indication is provided to users explaining why they cannot join any team, however they can usually find out the g_maxgameclients value by checking /serverstatus.
- \addbot <botname> <other parameters> - Use from server. You can manually add a bot. If you want, you can also specify the team (red or blue) during team matches, and the skill level (from console, the skill level can also be fractional). For example, \addbot sarge 4.6 blue adds the Sarge bot, with a skill level of "4.6" (between "hardcore" and "nightmare"), to the blue team. Complete format is addbot <botname> [skill 1-5] [team] [msec delay] [altname] (it is possible to add a bot giving a different name to it).
- \kick <playername> - Use from server (or use with "callvote" from client). Disconnects a player or a bot from the server. If the name contains spaces, use quotes (like \kick "player name").
- \kick allbots - This variant kicks all the bots from the server.
- \kick all - This variant kicks everyone from the server.
- \clientkick <clientid> - Use from server. This command kicks a player, specifying its "client number" instead of its name.
- \bot_minplayers <number> - Use from server. Automatically adds or removes bots depending from how many human players are connected, thus having at least the specified numbers of players (humans or bots) in the arena (or in each team, during team-based games). Bots are chosen randomly. Useful to always offer a challenge to who connects to your server. Default value is 0. Set the bot skill level using g_spskill.
It is advisable to keep this value lower than your sv_maxclients in team-free modes and lower than half of your sv_maxclients in team-based modes, otherwise new human players may not be able to connect to the server because it would be aleady "full"!
- \g_spskill <number> - Use from server. Changes the default skill level for the bots (added by \bot_minplayers) added after you set it. Default value is 2.
- \sv_pure <0 or 1> - Use from server. This should usually be set to 1. It allows to load only stuff (like maps or models) that is packed inside pk3 files, and is used to automatically load or not patch files, to match the OpenArena version used by the server.
- \sv_lanforcerate <0 or 1> - Use from server. If this is enabled and dedicated mode is not 2, clients on your same subnet will ignore the "rate" value and will get all the "snapshots" the server will elaborate. Default value is 1. See Optimize for LAN above and Tweak#Tweaking online gaming parameters.
- Password-protected servers (see Servers#Password-protected servers for more info):
- \g_password "<privpass for everyone>" - Use from server. After set, it will require all the clients to specify this password to join the server. It creates a "private" server. Set to "" or to "none" to make the server "open" again.
- \password "<privpass>" - Use from client. Set it to match the password for the "private" server you are connecting to, to be able to enter. Ask the server admin for the password.
- \sv_privateClients "<number>" - Use from server. Slots subtracted from sv_maxclients (slots "reserved" for private clients, without the need of a full "private" server). Not needed for a completely private server.
- \sv_privatePassword "<privpass for privclients>" - Use from server. Sets the password needed by the clients to use the "reserved" slots. Not needed for a completely private server.
- \g_autonextmap <0 or 1> - Use from server. If set to 1, when a match ends the next map will be randomly picked up from an apposite gametype-specific map-pool, without using a classic map rotation script (it ignores classic rotation scripts). Default value is 0. Introduced with OA 0.8.8. See g_autonextmap for more infos.
- \g_delaghitscan <0 or 1> - Use from server. If set to 1, enables "delag hitscan" technology to compensate network latency effects when using "hitscan" (instant hit, such as the machinegun) weapons, for all the clients which will require it. In OA 0.8.8, its default value is still 0, however it may be a good idea for server admins to set it to 1. Delag tech has been introduced in OA since version 0.7.1: it not supported by most old mods designed for Q3, however a few Q3 mods did have delag techniques by their own (such as Unlagged, ZPM mods).
- \cg_delag <0 or 1> - Use from client. This enables the clientside component of delag technology for hitscan weapons. It has got effect only when playing on servers which use g_delaghitscan 1. Its default is 1 (enabled); by disabling it, you would not take advantage of delag technologies (having to predict opponents movements also when using instant-hit weapons, then), while your enemies may still use it against you. Turning on or off "delag hitscan" option from the GUI ("Setup" -> "Game options" menu) changes the values of both your clientside and serverside variables.
- \map_restart <number>. Restarts the map after the specified number of seconds (default: 5). Allows to make some changes effective.
- Variables which store integrated server browser preferences (rarely changed through console):
- ui_browserMaster - Kind of servers to search. 0=Local, 1=Internet, 6=Favorites. Default 0.
- ui_browserGameType - Gametype to show. 0=All, 1=FFA, 2=TDM, 3=Tournament, 4=CTF, 5=1FCTF, 6=Overload, 7=Harvester, 8=Elimination, 9=CTF Elimination, 10=LMS, 11=Double Dom, 12=Domination. Pay attention: values from 0 to 3 do not correspond to the same g_gametype values. Default 0.
- ui_browserSortKey - Field to order by. 0=server name, 1=map name, 2=open player slots, 3=game type, 4=ping time, 5=human players. Default 4.
- ui_browserShowFull - Show full servers in the list. 0=hide, 1=show. Default 1.
- ui_browserShowEmpty - Show empty servers in the list. 0=hide, 1=show. Default 1.
- ui_browserOnlyHumans - Consider human players only or also bots. 0=show/count both humans and bots, 1=show/count humans only. Default 0.
- It looks like the "hide private" option is not stored in a cvar, and you always find it enabled when entering the server browser.
<please add some more related commands here>
- Also, if you plan to run both a client and an internet server on the same machine: either always launch the server before the client, or set the server (and the router/firewall accordingly) to use a different port than the standard one: if the server tries to use 27960 UDP port of your PC, but your client already took it, your server would not be reachable from outside because your NAT settings would end up forwarding incoming traffic to your client process instead.
- If you wish to use the feature built-in your router, check which dynamic dns service providers it does support before registering to one!
- Your game server machine internal IP not varying is important for not breaking the port forwarding in case of an internet-accessible server: you may consider setting that machine IP address manually or thorugh a "DHCP reservation" to be sure it will never change.
- Having unstable ping may represent a problem: in case you experience large and frequent ping variations while you are not using bandwidth consuming applications, you may have to contact your ISP. Other than your OS "ping" command, also WinMTR tool may help you testing ping variations, to then report them to your ISP (it shows a line for each "hop", helping identifying where the problem starts).
- You can use /serverinfo command from your server console to see if it is actually running: if "map" line reports "nomap", you have no map loaded!
- You can use PFPortChecker too check any TCP or UDP port, so you can also use it for other uses, not only for OpenArena -remember to temporarily close the program that normally controls that port, to allow the port checker to take control of it-. It checks the reachability of the desired port on your machine from the internet, from their servers.
- You can use UDP Test Tool to check any UDP port -they have another tool for testing TCP ports-, and you can use it for other uses, not only for OpenArena -remember to temporarily close the program that normally controls that port, to allow the port checker to take control of it-. You need to install the software on two machines: on your server and on a client that will send test packets to the server: this allows to test your server reachability not only from the internet, but also from other segments of your LAN (e.g. from your LAN to your DMZ), depending from the connection used by the client part.
- Not sure if the first master server's response points directly to your 27960 port (maybe the heartbeat packet specified it in its data?) or points to the random, temporary port generated by your PAT (that may momentarily work because that port has not been closed yet, so the PAT still redirects it to your real port for a moment).
- Note: in OA 0.8.5 there was a bug, and the command would have closed the program there... this has been fixed in OA 0.8.8 binaries.
- You can however host more server processes on the same machine using the same IP.
- Game physics (framerate dependent, fixed or accurate)
- Remote control
- OpenArena Clan Roster
- Killing Sprees, Death Sprees and Multikills
- Basic game options
- Special game options
- Manual/Automatic downloading
- Manual/Using Mods
- Configuration examples
- Map rotation script
- Tweak, especially Tweak#Tweaking online gaming parameters
- FAQ#How can I organize matches with my friends all around the world? How can I talk with them?