Difference between revisions of "How to server"
m |
|||
(37 intermediate revisions by 2 users not shown) | |||
Line 2: | Line 2: | ||
<br /><br /> | <br /><br /> | ||
− | '''The easiest way of running a server is installing [[nQuakesv]] package. [http://nquake.com/ | + | '''The easiest way of running a server is installing [[nQuakesv]] package. Get it [http://nquake.com/ here].'''<br /> |
+ | [[File:Nquake download.png|thumb]] | ||
+ | It includes everything you need to start a server, including:<br /> | ||
* Modern QuakeWorld server: [[MVDSV]] <br /> | * Modern QuakeWorld server: [[MVDSV]] <br /> | ||
* Modern modification: [[ktx]]<br /> | * Modern modification: [[ktx]]<br /> | ||
Line 9: | Line 11: | ||
It is preconfigured, just asks the user simple questions to complete the configuration. Take note on the ports the servers will be running (you must know them to connect to the servers)<br /> | It is preconfigured, just asks the user simple questions to complete the configuration. Take note on the ports the servers will be running (you must know them to connect to the servers)<br /> | ||
− | + | For more details, continue reading! | |
<br /><br /><br /> | <br /><br /><br /> | ||
− | == KTX Server Setup == | + | == Choosing a provider == |
− | If for some reason you need to upgrade KTX, you'll have to compile it. here's how to do it (using | + | Game servers can run on any computer that is connected to a network. To host a game server on the internet, '''renting a VPS in a Datacenter''' is the most common, effective and cheapest way. <br /> |
− | <pre>1. git clone https://github.com/ | + | There are VPS offerings in most of the countries in the world. Choosing one with good routing that is good can be a daunting task. Below are some facts and tips for choosing a VPS provider. |
+ | * Rule of thumb: the higher the distance between the server and the client, the higher the ping. | ||
+ | * Routing is important: the player's ISP AND the VPS Datacenter determine the route that the game packets (information) have to travel to reach the destination. This directly affects the ping. Also, as a rule of thumb, the less [https://en.wikipedia.org/wiki/Hop_(networking) hops], the better ping. | ||
+ | * The ping will be the same regardless of its direction. Host A ping to Host B '''is the same''' from Host B to Host A. | ||
+ | * Well located servers using good routes enable us to play with sub 100ms ping between continents. But nothing can beat the speed of light - distance is key. Routes using [https://www.submarinecablemap.com/ submarine cables] (when possible) are often better than routes that go through datacenters on land, because of the number of [https://en.wikipedia.org/wiki/Hop_(networking) hops]. | ||
+ | * How to test the ping? Some VPS providers have a Looking glass you can use to test latency. ''Looking Glass is an open source publicly available networking script to check the Host, Ping, Traceroute, MTR, Speed, and Latency of the VPS or Server and Network.'' Here are some examples: | ||
+ | ** Well known VPS provider looking glasses: | ||
+ | *** https://www.edisglobal.com/blog/looking-glass | ||
+ | *** https://www.vultr.com/resources/faq/#downloadspeedtests | ||
+ | *** https://inet.ws/lg/ | ||
+ | *** https://www.hostzealot.com/looking-glass | ||
+ | *** (...) and many many more. Google "''VPS looking glass <country>''" or "''looking glass <provider>''" | ||
+ | ** Looking glass "hub", multiple in one website: https://looking.house/index.php | ||
+ | ** And another site that allows you to ping from multiple providers at once: https://ping.sx/ping | ||
+ | * You can test your own ping to a VPS, or test any other ip ping to that VPS. Examples: | ||
+ | ** Test your own ping to the VPS network by placing your own ip in the "ping" textbox. | ||
+ | ** Test some existing QW server ping to the VPS network. This is useful to test if the VPS can be useful for [[QWfwd]] proxies. This is how different players can get the best possible ping to a destination server. | ||
+ | ** Test the ping to other VPS (looking glass). The Looking glass also has a test ip, which you can use to ping to. This is useful to check the connection between VPSs, for [[QWfwd]] proxies. | ||
+ | * Currently online QuakeWorld servers: '''https://tools.quake.world/servers/''' | ||
+ | |||
+ | === Server specifications === | ||
+ | In terms of minimum server specifications, it depends on what you plan to run there. But a single core cpu and 1gb of RAM is enough to run a couple of [[KTX]] ports, [[QWfwd]] and [[QTV]]. | ||
+ | No need to overpay. | ||
+ | |||
+ | == Server maintenance == | ||
+ | === Antilag === | ||
+ | As of 2024, there are updates to antilag feature that have not been merged in the main repositories. If you want to set qw servers with the latest antilag, you got to compile them yourself.</br></br> | ||
+ | |||
+ | [[Ciscon]] has prepared scripts to compile the binaries for [[KTX]] and [[MVDSV]]. These scripts are included in nQuakesv, but you can also find them [https://github.com/ciscon/random/tree/master/quake-scripts/build here] (the nQuake ones). </br> | ||
+ | All you have to do is edit the scripts: | ||
+ | * MVDSV script: replace in gitrepo <code>qw-group</code> with <code>dusty-qw</code> | ||
+ | * KTX script: replace in gitrepo <code>qw-group</code> with <code>dusty-qw</code> | ||
+ | * KTX script: replace in gitbranch <code>master</code> with <code>al-merge-2</code> | ||
+ | And run them. If they run successfully, the server is ready to go with the updated binaries.</br> | ||
+ | Here's the list of dependencies to run them (linux Debian): <code># apt-get install git qstat make gcc pkg-config cmake curl unzip -y</code> | ||
+ | </br> | ||
+ | Here are the links to the Antilag repositories in Github: [https://github.com/dusty-qw/mvdsv mvdsv antilag] and [https://github.com/dusty-qw/ktx/tree/al-merge-2 ktx antilag] | ||
+ | |||
+ | ===Updating server binaries=== | ||
+ | If you are lazy, the latest precompiled server binaries are here: https://builds.quakeworld.nu/ | ||
+ | </br>See Antilag section above. | ||
+ | |||
+ | ===Updating maps=== | ||
+ | If using Linux [[nQuakesv]], please run <code>./update_maps.sh</code> to get the latest maps on your server. | ||
+ | ====Uploading individual maps==== | ||
+ | Map files (.bsp files) go into /qw/maps folder. | ||
+ | A way to do it fast is the following: | ||
+ | # Download file locally | ||
+ | # Open terminal (in windows or mac or linux) and use '''scp''' to copy the file to the remote location: | ||
+ | scp <file.bsp> <username>@<server>:~/nquakesv/qw/maps | ||
+ | SCP also allows to use SSH keys (-i <path to key file>) and defining a custom port (-P <portno>).<br> | ||
+ | Alternatively, you can use [https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html pscp] (Putty scp), as it is better adapted to Windows OS.<br> | ||
+ | Example with private key and custom port:<br> | ||
+ | pscp -i "C:\priv.ppk" -P 26789 faust.bsp myusername@myserver.org:/quakeantilag/qw/maps | ||
+ | You can create a script for your servers for doing it faster. | ||
+ | |||
+ | ===Updating server configs=== | ||
+ | If using Linux [[nQuakesv]], use the built-in scripts to do so: | ||
+ | ./update_binaries.sh | ||
+ | ./update_configs.sh | ||
+ | |||
+ | ==Advanced== | ||
+ | === KTX Server Setup === | ||
+ | If for some reason you need to upgrade KTX, you'll have to compile it. here's how to do it (using QW-Group's github) | ||
+ | <pre>1. git clone https://github.com/QW-Group/ktx | ||
2. cd ktx | 2. cd ktx | ||
− | 3. . | + | 3. cmake . |
− | 4. make | + | 4. make -j$(nproc) |
5. ls -altr (look for qwprogs.so) | 5. ls -altr (look for qwprogs.so) | ||
6. copy qwprogs.so to ktx/ folder | 6. copy qwprogs.so to ktx/ folder | ||
Line 23: | Line 89: | ||
If you haven't done it already, you should edit pwd.cfg and change the rcon password. You should also edit portX.cfg and change the sv_serverip to the external (WAN) ip:port of the machine. | If you haven't done it already, you should edit pwd.cfg and change the rcon password. You should also edit portX.cfg and change the sv_serverip to the external (WAN) ip:port of the machine. | ||
− | == MVDSV Setup == | + | === MVDSV Setup === |
− | Compiling MVDSV (using | + | Compiling MVDSV (using QW-Group's github): |
− | <pre>1. git clone https://github.com/ | + | <pre>1. git clone https://github.com/QW-Group/mvdsv |
2. cd mvdsv/build/make/ | 2. cd mvdsv/build/make/ | ||
− | 3. . | + | 3. cmake . |
− | 4. make | + | 4. make -j$(nproc) |
5. chmod 755 mvdsv | 5. chmod 755 mvdsv | ||
6. copy mvdsv to your quake/ folder</pre> | 6. copy mvdsv to your quake/ folder</pre> | ||
Line 36: | Line 102: | ||
./mvdsv -port 27501 -game ktx +exec port1.cfg</pre> | ./mvdsv -port 27501 -game ktx +exec port1.cfg</pre> | ||
− | == Firewall Configuration == | + | === Firewall Configuration === |
''iptables -A PREROUTING -t nat -p udp -i eth1 --dport 27500 -j DNAT --to 192.168.0.1:27500'' | ''iptables -A PREROUTING -t nat -p udp -i eth1 --dport 27500 -j DNAT --to 192.168.0.1:27500'' | ||
− | == Raspberry Pi server == | + | === Raspberry Pi server === |
− | + | Raspberry Pi (arm/arm64) binaries for qwfwd, mvdsv, and ktx binaries are available from https://builds.quakeworld.nu | |
<br /> | <br /> | ||
[[Spike]] also compiled binaries for [[FTE]], both client and server. Download them from [https://mega.co.nz/#!ykhhjbTD!C6EoEjmykfQ5FJrrNFml-GlkFaJ23c8iPN9Ekqm_YxY here]<br> | [[Spike]] also compiled binaries for [[FTE]], both client and server. Download them from [https://mega.co.nz/#!ykhhjbTD!C6EoEjmykfQ5FJrrNFml-GlkFaJ23c8iPN9Ekqm_YxY here]<br> | ||
− | |||
Test results on a raspberry 1, 512mb ram: <br /> | Test results on a raspberry 1, 512mb ram: <br /> | ||
Line 50: | Line 115: | ||
- raspberry pi 2 should be enough for 4on4<br> | - raspberry pi 2 should be enough for 4on4<br> | ||
− | == | + | === Qizmo === |
− | + | See [[Qizmo]] - '''Server''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Tutorials]] | [[Category:Tutorials]] |
Latest revision as of 09:30, 30 September 2024
This page describes how to setup a QuakeWorld server.
The easiest way of running a server is installing nQuakesv package. Get it here.
It includes everything you need to start a server, including:
It is preconfigured, just asks the user simple questions to complete the configuration. Take note on the ports the servers will be running (you must know them to connect to the servers)
For more details, continue reading!
Choosing a provider
Game servers can run on any computer that is connected to a network. To host a game server on the internet, renting a VPS in a Datacenter is the most common, effective and cheapest way.
There are VPS offerings in most of the countries in the world. Choosing one with good routing that is good can be a daunting task. Below are some facts and tips for choosing a VPS provider.
- Rule of thumb: the higher the distance between the server and the client, the higher the ping.
- Routing is important: the player's ISP AND the VPS Datacenter determine the route that the game packets (information) have to travel to reach the destination. This directly affects the ping. Also, as a rule of thumb, the less hops, the better ping.
- The ping will be the same regardless of its direction. Host A ping to Host B is the same from Host B to Host A.
- Well located servers using good routes enable us to play with sub 100ms ping between continents. But nothing can beat the speed of light - distance is key. Routes using submarine cables (when possible) are often better than routes that go through datacenters on land, because of the number of hops.
- How to test the ping? Some VPS providers have a Looking glass you can use to test latency. Looking Glass is an open source publicly available networking script to check the Host, Ping, Traceroute, MTR, Speed, and Latency of the VPS or Server and Network. Here are some examples:
- Well known VPS provider looking glasses:
- https://www.edisglobal.com/blog/looking-glass
- https://www.vultr.com/resources/faq/#downloadspeedtests
- https://inet.ws/lg/
- https://www.hostzealot.com/looking-glass
- (...) and many many more. Google "VPS looking glass <country>" or "looking glass <provider>"
- Looking glass "hub", multiple in one website: https://looking.house/index.php
- And another site that allows you to ping from multiple providers at once: https://ping.sx/ping
- Well known VPS provider looking glasses:
- You can test your own ping to a VPS, or test any other ip ping to that VPS. Examples:
- Test your own ping to the VPS network by placing your own ip in the "ping" textbox.
- Test some existing QW server ping to the VPS network. This is useful to test if the VPS can be useful for QWfwd proxies. This is how different players can get the best possible ping to a destination server.
- Test the ping to other VPS (looking glass). The Looking glass also has a test ip, which you can use to ping to. This is useful to check the connection between VPSs, for QWfwd proxies.
- Currently online QuakeWorld servers: https://tools.quake.world/servers/
Server specifications
In terms of minimum server specifications, it depends on what you plan to run there. But a single core cpu and 1gb of RAM is enough to run a couple of KTX ports, QWfwd and QTV. No need to overpay.
Server maintenance
Antilag
As of 2024, there are updates to antilag feature that have not been merged in the main repositories. If you want to set qw servers with the latest antilag, you got to compile them yourself.
Ciscon has prepared scripts to compile the binaries for KTX and MVDSV. These scripts are included in nQuakesv, but you can also find them here (the nQuake ones).
All you have to do is edit the scripts:
- MVDSV script: replace in gitrepo
qw-group
withdusty-qw
- KTX script: replace in gitrepo
qw-group
withdusty-qw
- KTX script: replace in gitbranch
master
withal-merge-2
And run them. If they run successfully, the server is ready to go with the updated binaries.
Here's the list of dependencies to run them (linux Debian): # apt-get install git qstat make gcc pkg-config cmake curl unzip -y
Here are the links to the Antilag repositories in Github: mvdsv antilag and ktx antilag
Updating server binaries
If you are lazy, the latest precompiled server binaries are here: https://builds.quakeworld.nu/
See Antilag section above.
Updating maps
If using Linux nQuakesv, please run ./update_maps.sh
to get the latest maps on your server.
Uploading individual maps
Map files (.bsp files) go into /qw/maps folder. A way to do it fast is the following:
- Download file locally
- Open terminal (in windows or mac or linux) and use scp to copy the file to the remote location:
scp <file.bsp> <username>@<server>:~/nquakesv/qw/maps
SCP also allows to use SSH keys (-i <path to key file>) and defining a custom port (-P <portno>).
Alternatively, you can use pscp (Putty scp), as it is better adapted to Windows OS.
Example with private key and custom port:
pscp -i "C:\priv.ppk" -P 26789 faust.bsp myusername@myserver.org:/quakeantilag/qw/maps
You can create a script for your servers for doing it faster.
Updating server configs
If using Linux nQuakesv, use the built-in scripts to do so:
./update_binaries.sh ./update_configs.sh
Advanced
KTX Server Setup
If for some reason you need to upgrade KTX, you'll have to compile it. here's how to do it (using QW-Group's github)
1. git clone https://github.com/QW-Group/ktx 2. cd ktx 3. cmake . 4. make -j$(nproc) 5. ls -altr (look for qwprogs.so) 6. copy qwprogs.so to ktx/ folder 7. restart the server
When restarting the server, if it outputs a message about failing to load qwprogs.so you'll have to recompile mvdsv also.
If you haven't done it already, you should edit pwd.cfg and change the rcon password. You should also edit portX.cfg and change the sv_serverip to the external (WAN) ip:port of the machine.
MVDSV Setup
Compiling MVDSV (using QW-Group's github):
1. git clone https://github.com/QW-Group/mvdsv 2. cd mvdsv/build/make/ 3. cmake . 4. make -j$(nproc) 5. chmod 755 mvdsv 6. copy mvdsv to your quake/ folder
Then run it. it has several command line parameters, such as -port (to choose port) -game (to choose folder) and +exec (to automatically run a cfg and +set sv_getrealip ). Example mvdsv execution commands:
./mvdsv -port 27502 -game ctf +set sv_getrealip 1 ./mvdsv -port 27500 -game prox +exec qw_server.cfg ./mvdsv -port 27501 -game ktx +exec port1.cfg
Firewall Configuration
iptables -A PREROUTING -t nat -p udp -i eth1 --dport 27500 -j DNAT --to 192.168.0.1:27500
Raspberry Pi server
Raspberry Pi (arm/arm64) binaries for qwfwd, mvdsv, and ktx binaries are available from https://builds.quakeworld.nu
Spike also compiled binaries for FTE, both client and server. Download them from here
Test results on a raspberry 1, 512mb ram:
- with 7 players + 1 spec, cpu usage was around 80% with everyone spamming sng at dm3 outside
- in conclusion it will be enough for 2on2, not sure on a competitive 4on4 match.
- raspberry pi 2 should be enough for 4on4
Qizmo
See Qizmo - Server