I guess it's about time the R1Q2 server got a somewhat usable README
For instructions on setting up a Linux R1Q2 server, you may find this guide useful:http://www.sp1r1t.org/networks/quake2/q2_linux_server_howto.phpDesign Goals
The server portion of R1Q2 (r1q2ded, dedicated.exe or r1q2 +set dedicated 1) is primarily designed to be stable, secure and fast. Stability and robustness is essential for a server. R1Q2 doesn't trust anything - even the Game DLL you are using. Values passed by the Game DLL are inspected for out of range data, memory allocated by the Game DLL is checked for overflow and leak conditions and a host of other features help prevent a buggy mod from causing stability problems. There are also numerous stability fixes inside the server itself, such as the extended uptime fix that would result in any Q2 server crashing after having around 20 players on it for 7 days continuously and a bunch of other problems that existed in the 3.21 release.
Security is another area where the R1Q2 server is focussed. A large number of server-crashing exploits were found in the 3.21 source release as well as other malicious exploits that enabled users to steal cvars, run arbitrary commands on connected clients, download files from the server that shouldn't be allowed, exhaust network bandwidth with spoofed UDP packets and a host of other widely known and not so widely known attacks. All known bugs and exploits
are patched in R1Q2 and messages logged when an exploit attempt is detected. A large selection of security related server cvars are also available to help stem any future exploits. Things such as sv_strict_userinfo_check check a client's userinfo string conforms to the Q2 standard, sv_filter_stringcmds removes potentially dangerous low and high ASCII characters from commands and a bunch of other cvars allow you to control how little or how much R1Q2 checks. The reason many of these are configurable and not simply on by default is that some mods or clients have come to expect little to no checking on the server side. Things like coloured names break the userinfo specification and thus will be filtered out by sv_strict_userinfo_check, coloured chat binds make use of high ASCII values and will be filtered by sv_filter_stringcmds, etc.
Finally, the server aims to be as fast as possible. This is accomplished by having separate dedicated server binaries (r1q2ded, dedicated.exe) that contain no client code, allowing for a smaller executable. Redundant code is removed, pointless error checks for conditions that could never occur are gone, file system lookups, alias and command searches are made much faster due to use of binary trees and a range of other optimizations applied where appropriate. Even with all the new features, the R1Q2 server should be just as fast, if not faster than the Q2 3.20 binary.
Full compatibility is of course preserved with all existing mods, clients and admin DLLs such as Q2Admin. If you don't want to read up on all the new commands and cvars, you can simply use the R1Q2 Server instead of your current server binary and it should work just fine."Old" vs "New" mods (Linux Only)
You have probably noticed that there are two versions of the R1Q2 server for linux, one called r1q2ded and one called r1q2ded-old. These are both exactly the same version of the R1Q2 server, just compiled with different compilers in order to provide support for different mods. The baseq2 deathmatch, CTF, OSP tourney, TDM and many other mods require using r1q2ded-old because those mods were compiled with old version of GCC. Newer mods that are still in development today such as Gloom, CTC and any mod that you build from source yourself will require using r1q2ded. If you're unsure which one to use, just try both. One of them will likely crash and the other one won't
With the b4xxx release of R1Q2, one of the largest changes ever was introduced to the server. The way in which the server processes network messages was completely rewritten to allow for a much higher level of control over how messages are sent. Prior to b4xxx, the server process worked like this: each player has 2 "buffers", one for reliable messages such as chat text, configstring updates, stuffcmds and other messages that are essential to be delivered and one for unreliable messages such as sounds, entity updates, temporary entities, etc where it doesn't matter if the packet is lost. Both of these buffers are around 1400 bytes long. The Game DLL is able to write directly into the buffer of each client and the server also adds data to both buffers. However, since these are just essentially 1400 bytes of memory, once something is written into the buffer, it's meaning is lost and it is just considered part of a network message. Even worse, if too much data is written, the entire buffer contents are emptied (unreliable overflow) or the client is kicked off the server with an overflow (reliable overflow). R1Q2 b4xxx changes all of this. The 1400 byte buffers are gone, in their place is a new netcode management system. Each time the Game DLL or server wishes to send something to a client, the type of message, size, reliability and message data is captured into a separate buffer. These buffers are then able to be queued up so that the server knows exactly what is in each type of buffer and whether it is reliable or not. The concept of "overflowing" a buffer is no longer relevant as the messages are simply queued up and as many that can be fit into a packet are sent and the rest saved for later. In the case of an unreliable overflow, the server no longer has to discard the entire message, it can simply leave out the portions that wouldn't fit. It even has the power to reorder the messages so the most important ones can go first to ensure that they will fit. Auto downloading is also improved, thanks to the ability to queue and discard unneeded messages, a client that is auto downloading should never get kicked off the server due to heavy activity from existing players in game. The new netcode management provides a much more reliable network subsystem and should eliminate any client overflows from the server and greatly improve how heavy activity is handled.
A new and somewhat experimental network protocol is also available, called protocol 35. R1Q2 clients and some other clients (notably EGL at present) can make use of this protocol. It offers support for compressed packets, enhanced delta states and numerous other bandwidth saving improvements. Clients using protocol 35 will enjoy faster connection times, faster free-flying observer movement, faster auto downloading and a few other new features.
Server-side cheat detection is improved somewhat through closer inspection of client packets. In particular, a new "bad movement" detector can spot clients that are moving too fast or too slow/laggy and optionally kick them. For users of NCServer, R1Q2 has copied the "visibility check" features that you may wish to use. Please note however that the R1Q2 server offers no actual protection against client-side cheats such as aimbots or wallhacks.
Limited rcon allows you to configure a set of rcon commands that use a separate password (lrcon_password). This allows you to give out the lrcon_password to players or clan leaders who you would not trust with the full rcon_password. The addlrconcmd and dellrconcmd commands can be used to configure which commands can be used with limited rcon. You should avoid using the lrcon feature in Q2Admin and use this if possible as the Q2Admin lrcon feature is inherently insecure.
A file system cache speeds up searches in pack files and on the filesystem. This will crash your server if you modify a file after it has been loaded by R1Q2 unless you do an fsflushcache command or run with fs_cache 0.
Server-side connection blocking is available through the use of "blackholes". If the mod you are using doesn't support IP bans or has limited support for such, you can block troublesome players from the server directly with the addhole/delhole commands. These support a bitmask to be used with the IP address to enable you to block precide CIDR blocks and other things. For those that don't want to learn CIDR, just remember that 126.96.36.199/32 = 188.8.131.52, 184.108.40.206/24 = 1.2.3.*, 220.127.116.11/16 = 1.2.*.* and 18.104.22.168/8 = 1.*.*.*. If you specify the MESSAGE option, the player will be sent the message before having the connection rejected. If you specify SILENT, only you will see the message in the 'listholes' command.
A bunch of new commands are provided to check client cvars, userinfo or stuff commands and other features. Please see the server commands thread for more information about the new commands and what they are for. The built-in help in R1Q2 server is expanded with each command now showing it's purpose, syntax and an example of how to use it. I'm not going to go into detail here except where needed.
Server-side entity replacement and map overriding support. Using this you can create "virtual" maps that exist only as a .override file on the server, but load up an existing map with a modified entity string. Example: q2dm1.bsp is your normal q2dm1. To add some excitement, you want to put a quad in the map, but don't want clients to have to download a whole new .bsp. So you edit the entity string for q2dm1 to include a quad, then generate a .override file specifying "maps/q2dm1.bsp" as the map to load with the new entity string. Then you save the .override file as 'maps/q2dm1-quad.bsp.override' and you can use 'q2dm1-quad' as if it were a valid map, eg in map rotations, 'gamemap q2dm1-quad', etc. Upon loading it, the server will change the real map back to q2dm1 and use the modified entity string specified in the .override file.
The .override file format is a proprietary R1Q2 binary format including a bitfield specifying what is present. This allows it to be extended at a later date without breaking compatibility. I've created a PHP script to generate a .override file since explaining the format here would take too long. Generate the .override file at http://r-1.ch/r1q2gen.php
. If you don't know how to get an entity string from a .bsp, try entdump: http://r-1.ch/entdump.c
(Win32 binary: http://r-1.ch/entdump.exe
, runs from cmd prompt, eg entdump q2dm1.bsp > q2dm1.txt). Note that the server will very likely crash if you use a bad .override file so be careful! Please don't ask me about this feature if you aren't sure how to use it, it's pretty complicated and amazingly hacky but it does work. I think.
A new range of sv_ server cvars also exist to help configure your server how you want it. For example, you can prevent auto downloading if too many players are connected, limit how many packets/second each client can send, disable use of cl_nodelta, hide server stauts information for private matches and a bunch of other settings. These are all explained in the 'server cvars' thread, however, some of the more complex ones are outlined below.
This cvar is designed to help reduce the "freezing" effect when there is a high amount of activity. If the entity updates are unable to fit into the space allocated to them, the client will not receive ANY entity updates at all. This manifests itself as a freezing effect on the client where they seem unable to move and nothing is happening around them. In reality, they can still move and send commands but they will not see the results of anything they try to do since the entity updates are not able to fit into a packet. sv_packetentities_hack 1 attempts to eliminate this problem by "cutting off" the updates once they are about to get too big. This results in some updates sending and the rest being lost. This eliminates the freezing problems but also introduces a new one. Since some updates were lost, the client and server start disagreeing about what state a certain entity is in. This manifests itself as warning messages such as U_REMOVE: oldnum != newnum and odd "effects" such as flying/wrong models, teleporter/gib/other effects on entities that shouldn't have them and other strange things. These effects are usually only temporary until the player leaves the high activity area. Setting sv_packetentities_hack to 2 will try to send all entity updates to protocol 35 clients by compressing them first. If they still do not fit however, they will be cut off. sv_packetentities_hack 2 is the recommended setting if you wish to make use of this workaround, but be sure your players know what is happening or you may end up with even more complaints about the warning messages and artifacts!
All entities are marked as either in use or not in use. Due to possible bugs in some mods, entities that are marked as not in use are still sent to clients. These may be wasting bandwidth or the mod could be expecting them to get through to the client. Either way, this behaviour is not correct and no mod should ever send entites that aren't marked as in use. Setting sv_entity_inuse_hack to 1 will avoid sending any entity updates for entities that aren't marked as in use. This may break some mods that have come to expect the previously buggy behaviour but will save bandwidth if the entity updates were pointless to begin with. sv_entity_inuse_hack 1 is recommended, if it causes any kind of problems with the mod you run, set it back to 0. It has been reported that the base Game DLL source code may have such a bug that will result in invisible players if this is set to 1.
This cvar controls whether use of the 'map' command to change levels is allowed. I have added this because many people believe that to change levels, you should use the 'map' command. This is incorrect - the 'gamemap' command should be used to change levels. The 'map' command does more than just change the level - it completely unloads the Game DLL, erases all client state and forces a full reconnection to the server. The 'gamemap' command is the correct way to change the level as it does not cause the Game DLL to unload nor lose any client state. Unfortunately as with sv_entity_inuse_hack, some buggy mods do not properly behave when used with 'gamemap' or have internal stability problems which requires use of the 'map' command in order to reload them. Setting sv_allow_map 1 will allow use of the 'map' command.Staying Up-to-Date
Since the R1Q2 server is still being developed, it is important to stay up to date with the latest versions. Although old versions should be quite safe to use, newer versions often have improved features, optimizations or new commands that you may wish to use. Staying up to date is simple thanks to the r1q2 updater tool available from the R1Q2 page. Simply run it periodically (once a month should be fine) and it will update your installation of R1Q2.
GameHost users will want to check out the GameHost thread
for information on how to get R1Q2 and GameHost working together seamlessly.
For those of you running Q2Admin alongside R1Q2, it is strongly recommended you use a fixed 1.17.43 version
that contains bug fixes for a memory corruption condition that can cause problems when used with R1Q2. There are also a few security related updates in the modified version.
It is highly recommended that you subscribe to the security mailing list
if you run any R1Q2 server at all. If a security vulnerability is found in the R1Q2 server, a message will be posted to the mailing list informing of any workarounds or updates needed.
If you have any questions or problems with the R1Q2 server, please post a thread in the forums.