This tutorial will show you how to create a dedicated server for World of Padman and everything you need to know about a basic setup, necessary files, useful commands and variables. This tutorial may be a bit more extensive than you are used to.
General information about servers
First of all, this tutorial is targeted at dedicated servers, therefore the document’s title. The difference between a local server, i.e. if you host a game from within your local computer and a dedicated server, i.e. you rent a server which is running 24/7, are huge. I won’t go into the details, you only need to know that if you want to have a short match with your friends, it is better to do so with the in game options WoP presents to you or to find an empty server.
Still here? Then welcome again, future server admin, you have a great responsibility. But don’t worry, if you follow this tutorial, there will be no problems. In case there are still problems after reading, ask me. I assume you know how to access your server, since I won’t cover these basics in this tutorial.
Now before we can actually start, a few final words about the hardware your server should have. The absolute minimum to run a dedicated server is a 500 MHz CPU, 256 MB RAM and about 1.5 GB free space for the default installation of World of Padman. Depending on whether you want to use bots, you should have a faster CPU. If you want to serve more clients, your server will need more bandwidth. In fact, you don’t really need to worry about the bandwidth, as most current servers are equipped with a 1000 MBit connection, which is really enough to run a WoP server.
I ask you do obey these requirements. There are already more servers than players, so we do not need another server which is empty all the time. If you want your server to be well-liked, take some time to configure it properly and also watch out for how the players behave. Apply the latest patches for the game and maybe even add some good custom maps.
You will need a basic installation of WoP, i.e. the PK3 files, which are platform independent, the server executable for your OS and a configuration file, which we will create throughout this tutorial. The PK3 files and the executable can be obtained from WoP’s download page or from your OS’ packet manager. Please don’t forget to install the latest patch.
I advise you to create a start script for the server. With a start script, you can easily restart your server using cron jobs or whatever you like. In the rest of the tutorial I will assume that you are using a Linux distribution and that you installed the game to /usr/local/games/WoP. Of course you can install it to any folder you like, but don’t forget to adjust the path from the examples I give.
Command line switches
Let’s get to the start script. You can pass almost every command you would issue in game to the server executable. Please take special care about that, since it will make your life much easier. I will now show you an example script, explanations follow later on.
#!/bin/sh cd /usr/local/games/WoP ./wopded.i386 +set dedicated 1 +set net_port 27961 +set com_hunkMegs 256 +exec server_settings.cfg
In this example I start a LAN-only server, listening on port 27960 (UDP), using 256 MB of RAM and will execute the commands in server_settings.cfg. As you can see, I set certain variables using +set and then load a configuration file using +exec. The general syntax to issue a command as a parameter to the server executable is +command. Don’t worry if you don’t know where all these commands and variables come from, I’ll explain them in the next section.
Prior to explaining all the variables is how to set them. There are different ways to do so. As you have seen, you can set variables on the command line. This is only used for variables which are read-only and can just be set at the server’s startup. Now you might realize why we set the port and amount of RAM at startup. Both can not change while the server is running. If you want your server to listen on another port, you need to shut it down first, then restart it using the new port.
The basic syntax to set a variable is simply set variable value. An example would be set g_gametype 0. Be aware that you can set non-existing by mistake variables if you mistype their name! If you want to set a variable to a value which consists of two or more parts, use quotes for the value, i.e. set variable “bla1 bla2”.
You can intentionally use this feature to provide further information to the players. If you use set to set a non existing variable, it will be shown in your server’s console, but not to the players. To set new variables which are visible to the players use sets. I ask you to do so and give some information about your server like in the following example.
sets ".Admin" "ENTE himself" sets ".Location" "Germany" sets ".Email" "firstname.lastname@example.org" sets ".IRC" "padman@qnet"
I have chosen to prefix the variable names with “.”, so one can easily distinguish between real variables and those which are meant to be additional information. These variables won’t be shown in game, but can be seen in advanced server browsers.
Now that you know how to set variables, let’s see how we can use this command and others in a configuration file, which will hold all the settings for our server.
The configuration file, or short the config, is the file which holds all the settings for your server. It does nothing else but executing all the commands you write into it. That is, you could also set the gametype at your server’s console every time, but the config will simplify this task for you.
You can and should add comments to your config, which explain settings and give further information for you. Comments start with //. Any line starting with // will be ignored by WoP. I will now show you a sample of a config, which would be saved as a separate textfile, which you then feed into your server in the server’s startscript.
// Simple sample configuration file for a WoP server set sv_hostname "My First WoP Server" set sv_maxclients "10" set pointlimit "200" set timelimit "20" set g_gametype "3" set rconpassword "mysupersecretpass" set g_log "wop_server.log" map wop_cabin
As you can see, we are simply setting variables to certain values. Most of the variables have telling names. At the end of the file, we load a map to get things started.
In this simple example, a single map and a single gametype are good enough for testing purposes. On your server you should have rotating game types and maps, which I will explain in the next section.
Map and game type rotation
A game type or map rotation is nothing else than setting the game type variable and loading a map. Both are commands you already know. WoP has a variable named nextmap, which will be executed when a round finished. You have heard right, you can also execute variables. That is, assign a command to a variable and then execute this command. Now this is exactly what we will do for our rotation. I will now again show you an example rotation, which you can copy and paste into your config.
// Map rotation set m1 "map wop_backyard; set next_map vstr m2" set m2 "map wop_diner; set next_map vstr m3" set m3 "map wop_cabin; set next_map vstr m4" set m4 "map wop_trashmap; set next_map vstr m5" set m5 "map wop_padgarden; set next_map vstr m6" set m6 "map wop_padkitchen; set next_map vstr m7" set m7 "map wop_padlibrary; set next_map vstr m8" set m8 "map wop_padship; set next_map vstr m9" set m9 "map wop_padattic; set next_map vstr m10" set m10 "map wop_huette; set next_map vstr m11" set m11 "map wop_bath; set next_map vstr m12" set m12 "map wop_jail; set next_map vstr m1" // Game type rotation set g1 "pointlimit 20; g_gametype 0; set next_gametype vstr g2" // FFA set g2 "pointlimit 3; g_gametype 4; set next_gametype vstr g3" // LPS set g3 "pointlimit 30; g_gametype 5; set next_gametype vstr g1" // FFA Team // Set initial values set next_map "vstr m1" set next_gametype "vstr g1" // Modifying nextmap set nextmap "vstr execnextmap" set execnextmap "vstr next_gametype; vstr next_map; set nextmap vstr execnextmap" // Load first map vstr nextmap
I have added a few comments to explain what is going on. First of all, we set a whole bunch of new variables, i.e. m1, m2, m3 and so on. This is a list of maps we will use. You can name your variables like you want to, e.g. map_one, map_two, map_three and so on would work as well. Every variable is actually a command, which loads a map and sets next_map to the next map in our array. The game type rotation works accordingly. Note that the last one will load the first one again, otherwise the rotation would stop at the last map or game type. As you can see, one can combine mutliple commands into one. Just merge them with “;”.
Now for the interesting part. I have defined a new variable called execnextmap which will load the next game type and map and then set nextmap again. As you can see, I have used a new command named vstr. This command will execute the contents of a variable as if it were a command you actually typed in. The final vstr is simply to load the first map of the array, similar to the map wop_cabin in our config without rotation.
Feel free to add more maps to this template. You can also modify the point limit depending on the game type. Another crazy thing you can do is to include the current game type in your server’s name. To do so, you will of course first need to know which variable you need to set.
Controlling the server
As I have mentioned in the introduction, I assume that you know how to access your server. Every time I mentioned the server’s console, I meant the console of WoP, not your OS’ shell. Of course you can open a SSH or VNC connection to your server every time you want to change a setting, but there are easier ways to do so. I will now discuss how to use the in game options of WoP to do rcon, which is the abbreviation for remote control. If you don’t want to start WoP every time, I recommend you to use a server browser like XQF, which has inbuilt rcon support, so you don’t even need to have WoP installed.
Using rcon is very simple. In fact, you only need to prefix all your administration commands with rcon, i.e. rcon command. But hey, before you can do so, you will first need to set a password for rcon on your server. Chose a strong one, in times of brute force attacks you’re always at risk. So please replace “mysupersecretpass” by your own strong password.
Actually this is a fetch-ahead of an upcoming chapter. In your config, add a line like the following one to set the rcon password on your server.
set rconpassword "mysupersecretpass"
Don’t lose this password and don’t give it to anyone! What you need to do next is to set this password clientside. You can also use rcon with rcon password command, but since you use a strong password, it would be quite stressful to write your password all the time.
For now, start WoP on the computer you want to use for rcon. In game open the console via Shift+Esc. In the game’s console type the following command, which will set your rcon password clientside and save it to your client’s config.
seta rconPassword "mysupersecretpass"
Now you can connect to your server and control it from in game. In case your server is full and thus you can’t connect to it, there is another possibility to use. Use this command, to administrate your server from within WoP without connecting to it.
set rconAddress 126.96.36.199:27060
Of course you will need to use your server’s IP and port. Although setting variables is the most important command, you will also need other commands which will be explained in the next section.
You already know a few commands, these are set, exec, sets, map and vstr. I will now give you a list of common commands and their explanations. Please note that these are not all possible commands. To obtain a list of all available commands on your WoP server, use the command cmdlist, which will then output a list of commands without their functions. If you’re working directly on your server, you can use the auto complete function of the game console. Simply type the first few letters of a command or variable, press tab and the game will either show you some possibilities or auto complete the name if there is only one possibility.
set variable value
Sets a variable to a certain value. Note that some variables are read-only or can only be set at startup. Some variables require you to load a new map.
sets variable value
Sets a variable, which will appear in a server browser. Used for additional information about your server.
Shows a list with various information about every player on the server, including bots.
Kicks the user with the given name. You don’t need to care about colored names or capital letters. You can also use the player’s number, shown by the status command. Furthermore you can kick all users via kick all, but I do not recommend this. Rather shut down the server as a whole. Furthermore, you can remove all bots via kick allbots.
Kicks the player with the given number. The number can be obtained via the status command.
Loads the map with the given name. Current game type will be kept.
Reloads the current map and keeps game type.
addbot botname botskill team joindelay funname
Adds the bot with the character of the given botname, skill, team, after a delay. Funname overrides the bot’s default botname.
Executes the given configfile. All commands and variables of this file will be used and overwrite current ones. You can use this command to separate a mod’s variables from your server’s settings. Simply create a single config, e.g. mymod.cfg which you load with exec mymod.cfg inside your main config.
Since the banUser and banClient commands are disabled in WoP, you’ll need to use IPs to ban players from your server. ipmask is the IP of the player you want to ban, which can be obtained via the status command. You can also use wildcards, e.g. addIP 192.246.40.*.
This command simply removes an ipmask you have added with addIP. You must use the same name you have entered, i.e. you can not remove 188.8.131.52 if you have added 192.246.40.*.
Prints the contents of g_banIPs, i.e. the banned IPs you have added.
forceteam playerid team
Forces the given player into a team. Either use playername or id. Team can be “red”/”r”, “blue”/”b”, “spectator”/”s”, “free”/”f”.
This is an alternative to /set g_gametype. You can enter the string of the gametype, e.g. setgametype syc team.
Executes a variable’s value as if it were a command you typed in. Used for game type and map rotation.
And now for the variables we talked about. Since there are so many of them, this chapter is subdivided into sections. You should use set to set variables. Use the auto complete function of the game console or the command cvarlist, which will print a list of all variables. Most of the variables you need are covered in the sample configs, which come with your WoP installation. They are located in /usr/local/games/WoP/wop.
If you use a mod, there might be even more variables you’ll have to set. Those are usually documented in the mod’s readme.
Sets the point limit for the current game. You should change this within you map rotation according to the game type. If set to 0 there will be no limit and rounds will only be limited by time limit. If you set point and time limit to 0, you should enable votes so players can change the map themselves.
Sets the time limit for the current game. If set to 0 there will be no limit.
Defines whether you can harm your team mates or not. Better leave this off (set to 0), since WoP is more of a fun game and most players are not really able to do real team play.
Sets the number of lives to start with in game type Last Pad Standing.
This defines some of the gameplay rules for Last Pad Standing. Add up one or more of the following values, i.e. for multiple point and no Arrows set to 2+4, i.e. 6.
- 1 for point limit: A round is finished after one player has won the game as many times as specified with pointlimit. Therefore set pointlimit and g_LPS_startlives to proper values.
- 2 for multiple points: Everybody gets (g_LPS_startlives – [players with lives left] + 1) lives. Thus players can join during the match.
- 4 for no names: Don’t show the LPS arrows in game. Don’t confuse this with the client setting for the arrows.
Sets the game type being played. You probably like to change this using map rotation.
- 0 for ffa: Free For All
- 1 for tourney: Tournament
- 2 for single: Singleplayer (not used)
- 3 for syc: Spray Your Color
- 4 for lps: Last Pad Standing
- 5 for ffa: Free For All Team
- 6 for ctl: Capture The Lolly
- 7 for syc_tp: Spray Your Color Team
- 8 for bb: Big Balloon
If set to 1, players can issue votes. Be aware that this sometimes involves voting for non existing game types or maps, kicking unaware PadPlayers, vote spam in general and could even break your carefully planned map rotation.
g_doWarmup, g_warmupReady, g_warmup
Defines whether to do warmup (set g_doWarmup to 1), how many percent of the players need to be ready for the game to start (set g_warmupReady to decimal value between 0 and 1), how long the period of warmup should last (set g_warmup in seconds).
Defines how strong players should be knocked back if being damaged. The default value is 1000.
Defines, whether players will automatically join a team once connected (set g_teamAutoJoin to 1). Note that players will still stay in their team on new games. If g_teamForceBalance is set to 1, one can’t join a team if it has more players than the other one. You should really consider to set these two variables in order to have fair and balanced team play on your server.
Set g_weaponRespawn in seconds to define the time until weapons will be re-spawned after being picked up. Use g_weaponTeamRespawn to define a separate time in seconds for team based game types which usually should be higher than the one for Free For All.
This defines how fast players will walk. The default value since WoP 1.5 is 280, before it was 320. Don’t set this to high as it makes the game unplayable.
This defines how strong the player is attracted to the ground. The higher the value, the stronger the gravity. The default value is 800.
This defines the amount of damage a player can do while having the PadPower powerup. A value greater than one makes the player hand out more damage.
This can either be set to 0 or 1. If set, players will be re spawned after a certain time. This is useful to reduce those who don’t re spawn in order to camp for powerups.
This defines how much health points a single Killerduck has. If set to -1, Killerducks can’t get killed.
You can actually disable items in the game without using a mod! To do so, set a cvar to 1 which is called disable_classname, e.g.
set disable_weapon_imperius "1" set disable_ammo_imperius "1"
- 8 for no falling damage: This has been left over from Q3. WoP doesn’t have falling damage anyways.
- 16 for a fixed FOV: Forces everyone’s FOV (field of view, configured with cg_fov clientside) to 90.
- 32 for no footsteps: Players don’t emit footsteps sounds.
Sets the maximum number of clients on the server. This includes bots.
Sets the number of clients that are allowed to play. If set to 0 all clients can play, otherwise some have to spectate.
Sets the number of private clients. This is usually used to reserve some space for admins or VIPs. They need to have the correct password to join.
Defines after how many seconds an inactive client will be kicked. Inactive means, no movement, chatting or looking around at all. You shouldn’t set this too low, otherwise you might annoy players that are only away from keyboard for a short time. In general it is a good idea to set this variable, as inactive players only suck bandwidth or will be fragged by unfair players. Inactive players will be warned 10 seconds before they are kicked.
If the server doesn’t recieve a command from a client within this time in minutes, the client will be dropped. This might happen if the connection hangs, i.e. lags for a longer period.
g_log sets the file name of the server’s log file. g_logsync specifies how to write the log.
- 0: when the internal buffer is full
- 1: every time a new message for the log arrives
You can allow clients to download any custom maps and mods running on your server (set sv_allowdownload to 1). Files can either be server by your server, or from an external server via ftp/http. In the latter case you’ll need to set sv_dlURL as described later on. It is usually a good idea to use an external server, since otherwise the downloads would get subtracted from your gaming server’s bandwidth which might cause lags.
You can define up to 5 master servers by using sv_master1 to 5 followed by the master servers URL. Usually you shouldn’t need to set any of them.
If set to 0, only players from the IP list you have created with addIP are allowed to play. If set to 1, permit players from the IP list entering the server.
This defines the server’s name that will be displayed in the server browser. It may contain color tags aswell.
This defines a “message of the day” which will only be displayed in either the server browser or in game if you display server infos (default toggle with K). It doesn’t have a real use.
rconpassword, sv_privatePassword, g_password
rconpassword sets the password for remote control of the server. If none is set, you can only use the server’s command line to issue commands. sv_privatePassword sets the password for private clients. Their places are reserved on the server. Private clients need to type password blabla in console to join. g_password sets the password for any client that wants to join. If it is set, clients need to write password blabla in console.
Always set this to 1. Otherwise players could use modified PK3 files i.e. to cheat.
You need to set this variable on server startup. It controls whether your server sends heartbeats to the master servers, i.e. if it will be listed in game. Don’t forget that in order for the server to be listed you must open the port in every firewall between your server and the internet.
- 2: the server will send heartbeats to the master servers
- 1: it won’t, although people can still join if they know IP and port
This defines the UDP port the server will listen on. This is the port you need to open in your firewall. If you want to host more than one server on one IP, each instance has to use a different port.
This is the maximum amount of RAM the server will use. The more it uses, the faster it usally loads maps as they will be cached. The minimum should be 256 MB.
Specifies the folder the engine will search for files. This is used for mods, as discussed later on. The WoP engine will look for files inside /usr/local/games/WoP/wop, ~/.padman/wop and in, for example, /usr/local/games/WoP/mymod and ~/.padman/mymod.
bot_enable, bot_minplayers, bot_nochat, g_spSkill
Defines wheter bots are enabled (set bot_enable to 1). If so, they fill up to bot_minplayers slots but leave, if human players join. bot_nochat disables the maybe annoying slogans the bots like to say (set to 0). If you use bot_minplayers, this number of bots will be added using g_spSkill, which can be between 1 and 5.
The maximum Datarate for a single client to the server is defined by sv_maxRate. If your server doesn’t have a fast and reliable connection you shouldn’t set this above 25000. If a client has a lower datarate then defined by sv_minRate, he will be rejecten while connecting.
The server checks for the players’ ping while connecting. If it is below sv_minPing or above sv_maxPing, the player will be rejected.
Yes, even a server has a fps setting! If you set this higher than default, the server will need more bandwith but clients might encounter a more fluent gameplay. It might also cause some bugs in gameplay. If you find any bugs, use WoP’s bug tracker or drop a line in the bug reports channel on WoP’s Discord server.
Modifications, or in short Mods, modify the gameplay. Sometimes they add new game types, sometimes they replace player or weapon models. There are two kinds of mods. Server side ones and those that have some client side code as well. The first type is easier to setup, since clients do not need to download the mod. The second sort needs to exist on the player’s computer, either since he downloaded it separately or from your server.
In both cases you should create a separate folder for your mod which will include its files and server config. To do so, simply create a folder inside either /usr/local/games/WoP or ~/.padman. If you named your folder mymod, it will appear as mymod in the game. To tell the server that you want to use a mod, you’ll need to specify +set fs_game mymod in your start script.
Server side mods
A server side mod usually consists of a file called qagame.qvm. QVM stands for Quake Virtual Machine, it is thus platform independant. Inside your mod’s folder, create a subfolder called vm and copy the qagame.qvm inside vm. Read the mod’s documentation and don’t forget to set the mod’s variables in your server config.
Client side mods
Client side mods may include a server side mod. Any new game content can be seen as a mod. If you have a pure server, i.e. sv_pure 1, every client will need to have exactly the same files as the server uses. Therefore you need to distribute the download in some way. The most comfortable way for players is to enable the auto download option on your server.
To do so copy the mod’s PK3 files inside ~/.padman/mymod or /usr/local/games/WoP/mymod and then upload them somewhere. Set sv_allowdownload 1 and point sv_dlURL to your upload folder. The URL can either be http or ftp. You need to follow a certain scheme. Let’s assume you set sv_dlURL to then you’ll need to put your pk3s inside mysite.com/downloads/mymod. A client will automatically append your mod’s name (to be more correct; fs_game) to sv_dlURL. The files must be accessible with anonymous ftp or as a direct http download.
Again, don’t forget to include the mod’s variables in your config. Of course you’ll also have to look for updates of the mod and replace the files on your server and upload accordingly.