Difference between revisions of "Creating a server"
(→Getting your server on the public list)
|Line 131:||Line 131:|
== Regarding "cheat" servers ==
== Regarding "cheat" servers ==
While the license for BZFlag allows users to run any server modification that they wish, or to modify the code in any way, the project administration asks that users do not publish or host "cheat" type clients or servers. These cheats ruin the game for the average player, when they are mixed in with the normal game servers and clients. We understand the desire to expand and modify the game and
While the license for BZFlag allows users to run any server modification that they wish, or to modify the code in any way, the project administration asks that users do not publish or host "cheat" type clients or servers. These cheats ruin the game for the average player, when they are mixed in with the normal game servers and clients. We understand the desire to expand and modify the game and sources, so it is requested that anyone wishing to run a game that uses modified code or logic to do so using a different network protocol than the current public release. This will let modified games be played, and prevent modified clients from being used on public unmodified games, as they would be incompatible. The BZFlag project administrators reserve the right to remove the public listings of any game servers that do not adhere to this rule. Administrators also reserve the right to remove any global accounts or access to public services at any time.
Revision as of 20:27, 15 May 2014
Creating a server is the process of using BZFS software to host a game for users to play on.
Running a server can be done in both public or private modes. It involves running the server software BZFS on some host computer. For public servers this host computer must be connected to the internet, and be able to accept incoming connections on a fixed port.
Planning a Server
Before you create a server, you need to decide what you want your server will be like. There are a few requirements in creating a server. First, you need a good connection. If you are on a high end DSL or higher connection you will be able to host a few players. With really fast connections, such as T1 or related, you could host dozens (although you may not want to do so).
You must provide an address to connect to. You will specify this address when you run the server (more on this below). The address may be your IP address (something like 22.214.171.124), or the domain name pointing to your computer (e.g. BZFlag.ducati.org). If your server is going to be on a machine that is connected via DSL or Cable, figure out if your provider is giving you a dynamic or a static IP. If the IP address is static, your life will be a little easier since you can specify that address once and forever. If the IP is dynamic, this means that your internet provider will change the address once in a while (without warning). In this case you probably want to "Alias Your IP Address" to a static name (click on the link for how to).
Next you need to have an idea of how your server is going to look: you are probably already familiar with the game style (CTF, Rabbit) from playing on existing servers. You may specify a map or ask your server to create a random one. You will also be able to specify many details of the game play (how many good and bad flags, jumping, ricochet, etc...). All of this is accomplished in the next step.
Configure your Server
In this step, you specify all the server options. The cleanest way to accomplish this is to create a configuration file. Fortunately, the BZFlag installation provides you with a sample configuration file that you can modify according to your wishes. You will find this file in the directory where you installed BZFlag under a subdirectory called
misc. The file is named
bzfs.conf in a text editor (in windows, notepad will be just fine; in GNU/Linux, Unix, Debian, etc.. : vi would work nice).
bzfs.conf to understand all the options. Remove the # sign on the lines corresponding to the options you want to set. Add # at the beginning of the line if you don't want that option. After you have finished your changes, you can save that file with a different name (this will be helpful if you want to run server with different configurations: just save many files with different names).
Note also that recent BZFlag installations come with a "nice" web-based configuration builder that lets you create a configuration using a simple web form. Run it by selecting "BZFS configuration builder" from the BZFlag folder in the start menu. Your web browser will pop up with a web form that will prompt you for several configuration choices. Please note that the form will not save the configuration file for you: you will still have to copy and paste the text generated by the web form into your configuration file.
Here is an incomplete list of things you must or can specify in the configuration file.
- Choose a password for administrative purposes. With this password, you can use the administrative operations, such as changing the lag kick threshold or setting environment variables. This is done by adding the following line to your configuration :
-passwd PASS(replacing PASS with a password of your choice). Once the server is running, run your client and login as an administrator by entering "
/password PASS" (without quotes "") as a chat message.
- If the server is to be public, you must specify the server people should connect to. The option is added with the following line "
-publicaddr server.name.com:5154" (without quotes), or "
-publicaddr 126.96.36.199:5154" where you should replace
188.8.131.52:5154with your IP address.
5154is the port the server will listen to. Make sure it is the same number as the one specified in a line starting with
-p 5154. You can change the port but don't do that if you don't know what you are doing. We recommend you use port numbers that are proven to work in other servers.
- Specify other options. For example, if you want to allow jumping, then your conf file should have a line starting with
-j. Other options are: ricochet, which needs a line starting with
+r. Read through
bzfs.confand you'll find out how to specify the game style (rabbit, ctf, etc...), the number of flags, etc.... If you want to run different configurations you can create as many conf files as you like (with different names of course). Just specify the correct configuration file you want to invoke in the bat file mentioned in the previous paragraph. One of the options that you can set in the configuration file is a map the server should use.
- You can choose whether to use a custom map or a random one. If you use a random one, decide whether or not to include teleporters. If you want to include them, add (again, to your configuration) the option "
-t". If you are playing CTF and you want a random map, use "
-cr" instead of standard "
-c", in addition to "
-t". For a custom server, use:
-world "MAP_NAME"; replacing
MAP_NAMEwith the file name of the map, which must be in the BZFS directory. You have probably seen that when you visit other server, one of the menus has the "save map" option. That means you can save that map for use on your server. Just save it somewhere in your pc, and specify the location of the map in the configuration file, next to the line that starts with
- You can choose the max number of players (for example
-mp 10says there can't be more than 10 players). But just because you can host many, decide if you really want to. The more players on your server, the higher the overall latency will be and the more bandwidth your server will consume. Moreover, more than 4 players per team on a ctf or more than 6 players on a rabbit style is just not fun. Experiment if you plan to host a lot, otherwise don't worry. Not only latency that matters, but many players will make the field busy. Tanks will get killed often and there would be a lot of action. This is good, and bad. Good in that it is a lot of fun! But bad in that the average alive time may only be a few seconds.
- A server description would be nice. Note that there is a small limit on how many characters you can put for description, and it gets smaller based on how long the server address is. Add a description by adding option:
- You can choose what flags, if any, to include or restrict. You must be familiar with the flag abbreviations, which are listed using command "
bzfs -help" near the end of the help message. Add flags to the server using "
+f ABBR" and restrict flags using "
-f ABBR" replacing
ABBRwith the flag abbreviation.
This should get you started, but there are many more options you can set. Some of them are explained below in the section "Good Administration". In any event, most of the options can be understood by reading the file bzfs.conf provided with the installation.
Getting your server on the public list
BZFlag has a central list server that keeps track of all the public servers. Using the
-public "some text" command line argument will tell your local server to attempt to register itself on the public server. This is normally all that is required to get your server listed.
The list server will need to be able to access your server just as other players will. This is done by connecting back to the public IP address where your server is running. The list server only checks the tcp connection back to your server at present, though players will also try udp on the same IP address and port number.
You can view the raw server list in your web browser. If you do not see your server, then your server is firewalled or misconfigured and the list server cannot contact it. You will need to resolve this if you want your server to be publicly accessible.
Note: when you run the bzflag client on the same network as a server it should discover the server by using a broadcast ping. If your server shows up in the list, but without the description next to it, this means that you found it through broadcast discovery, and not from the public list server. If the server description that you included on the
-public "this text" command line option is there, then your server is correctly listed on the public server list.
-d options to the server will result in some useful (and some useless) messages from the server.
bzflag@phoenix:~/bzflag-1.10$ src/bzfs/bzfs -d -d -d -i 184.108.40.206 -p 51540 -public "My Server Name" style: 0 There is a voting arbiter with the following settings: vote time is 60 seconds veto time is 10 seconds votes required are 3 vote percentage necessary is 50.099998 vote repeat time is 300 seconds available voters is initially set to 200 Running a public server with the following settings: public address is 220.127.116.11:51540 listening on 18.104.22.168:51540 with title of "My Server Name" Sent ADD message to list server GET /db/?action=ADD&nameport=22.214.171.124:51540&version=BZFS1910&gameinfo=0000000100000000000000000000c800c800c800c800c800c800c8& build=126.96.36.19940809-RELEASE-linux-gnu&title=My+Server+Name HTTP/1.1 Host: my.BZFlag.org Cache-Control: no-cache Player  accept() from 188.8.131.52:50579 on 6 Player  on 6 removed: Disconnected
- the -i parameter is used here to force an IP address. This server happens to have more than one IP address. This is not required on most servers.
- the -p parameter is used to pick a different port number than the default. If you are only running one server, it is recommended that you leave this off and use the default port number.
- notice the debug line that starts with "
GET". This is the request that was sent to the bzflag list server to attempt to get listed
- notice the "
Player " lines. This indicates that the list server connected back and then disconnected. If you don't see this then it is likely that your server is firewalled and the list server is unable to connect back and so will not list your server.
Running the server
There are different ways to run a server. On both Windows and *nix, the program (BZFS) is in the directory where you installed BZFlag (most likely: "
C:/Program Files/BZFlag2.0.0", or on your usr account). The program containing the server is BZFS.exe. Double clicking on it will run a server with default options, but clearly you want to specify your own options, for example those you saved in the configuration file generated in the previous step. One way to do it is to specify all the commands for the server in a batch file, so you can just double click on it to start a server. On other systems such as Linux, create an executable with the commands, or a shell script, or see if there are any related ways to store console/text based command interface commands in a "shortcut" style.
On Windows: Here is a [SampleBatchFile]. Open notepad or any other text editor, copy the content of the file, make the changes that you need to change (notably: the location of BZFS and the config file bzfs.conf). Save the file with a nice name and extension .bat (for example: nicename.bat) on your desktop or a window of your choice. You probably understand what the batch file is doing: the lines beginning with "set" specify the content of some variables, such as the location of BZFS and the configuration files. The server is started on the line next to last (before "pause").
If you don't want to have a batch file or for some reason your batch file doesn't work, here is a procedure that always works: from the start menu in your windows machine, look for the "command prompt" and click on it. A black window will open up. Type:
cd "c:\Program Files\BZFlag2.0.0" (this should work in most cases, unless you installed BZFlag in a different directory). Once you are there type:
bzfs -conf "C:\Program Files\BZFlag2.0.0\Data\bzfs.conf" (change what is between quotes with the exact location of the configuration file).
On *nix: Use a config file, or a shell script. A config file can be made simply by taking all of your command line options you want to pass to BZFS, and placing them in a config file, one options on each line. An HTML file has been created that is shipped with BZFlag (in /data/ on binary releases, and in /misc/ in source releases or CVS). A shell script can be made the same way. A config file can be used, by changing directory to BZFS, and do "bzfs -conf CONF.conf", replacing CONF.conf with the config file in the same BZFS directory.
Once the server is running, log into it with your client and type /password PASS, where PASS is the password you chose in the configuration step. You'll be greeted by the client as an administrator. The KeysAndCommands and ServerCommands pages list a number of things you can do as an admin (although I don't think either of those pages is complete). If when you type one of those commands you get a "You do not have permission" message on client commands, it means that you forgot to login as admin (or somehow your login failed). Type in your client /password PASS replacing PASS with the password that you specified in the configuration phase. If this doesn't work shut down your server, go back to the configuration step and make sure you are getting the right password.
Sharing Administration Status
Helpful links about this topic:
Sometimes people will want to share administrator status. Multiple people can be assigned permissions on a server, and all can do more than the normal DEFAULT group (general public). This allows a server to be better administrated, as when one admin is not watching it, another one can. So how do you do this? This is quite easy to do. First off, configure your server to accept group permissions. This is done through BZFS command "
-groupdb FILE". This stores group names and permissions for that group. Its syntax for adding groups is: "GROUPNAME: permissions...", replacing GROUPNAME with the name of the group. Don't worry about adding ADMIN or DEFAULT groups, as those get thrown in automatically. Make one up, but please do not alter ADMIN group, as this is stuff administrators can do, and why limit yourself? Groupnames may not have spaces or quotes. Replace "permissions" with permissions, and take out the backslash in the command. For example, write "lagstats" instead of "/lagstats". So a sample line would be, "JRADMIN: playerlist ban kick". Separate permissions by a space, and DO NOT put permissions on different lines! Make sure the group name and ALL permissions are on the same line!
Now that you have your groups laid out, you must create a pas-swo-rd dat-ab-ase to store nicks and passwords created using "/register", as only registered users may be added to groups. To add people to a group, have them register, and enter BZFlag admin client command "/setgroup CALLSIGN GROUPNAME", replacing CALLSIGN with their callsign, case sensitive (add quotes around it if the callsign has spaces), and GROUPNAME with the name of the group to add them to. And that?s it! Easy as pie! This enables you to have multiple admins on one server. But what if you don't want other admins? Easy, create a smaller admin group, such as JRADMIN, in which they have more privileges than a normal person, but not as many as an admin. One privilege you MUST be very careful in giving a person is /shutdownserver. This is terrible if misused, as it kills the server. Trust wisely. And finally, if your server supports /report, starting in 1.11.*, people with privilege to "/viewreports" can see any reports filed, regardless of whether or not the person with that privilege has the computer that stores the reports.
Shutting down your server
If you have had enough of your server, shut it down by entering /shutdownserver in the client. You can also just terminate BZFS execution, but this is not proper and takes a while for the client server list to realize it was terminated.
Now that the server is running, how does it work? Well, the BZFS window or execution must stay alive to keep the server alive. If you close the BZFS window or halt its execution, the server goes too. It will stay on the server list for a short time if halted suddenly.
Closing the server window, or halting its execution, is somewhat like turning off the power suddenly as a way to shutdown your computer - it is not proper, and is not recommended.
Just because you have a server, that's not all. You must maintain it and keep your players satisfied. Check it often. One way to get feedback is to support the "/report" command.
Enable this using BZFS by setting the configuration option "-reportfile FILENAME" replacing FILENAME with a file to use to write reports to, or "-reportpipe FILENAME" replacing FILENAME with the file to pipe reports to. Reports are made through the client and are simply human messages.
But besides that, you must watch the people that come on your server. Often times people will pause or become "NR", not responding. "Not responding" means that they haven't sent a packet in a while (5 seconds by default). This happens to people with slow connections, or people with messed up connections because their connection simply can't send packets fast enough to be within the threshold. Usually they will be kicked automatically for idling too long, but if not, a kick is suitable. Take action against teamkillers (people who kill their own team on PURPOSE, not by occasional mistake), cheaters (a ban is usually nice :), people who log in/off constantly (people who constantly log on & off to reset their score, a warning is suitable), and any other nasty behavior.
You may want to implement a filter to filter chat or callsigns or both from abusive words. Make a file with a phrase/word that should be filtered on every line, and add it to the server using configuration option "-badwords FILE", replacing FILE with the file name IN QUOTES that is found in the BZFS directory. Then set whether to filter chat, callsigns, or both using "-filterCallsigns" and/or "-filterChat". Sometimes, BZFS will be too strict and filter things that aren't bad. You can make simple exact matches happen using "-filterSimple".
So you have a filter, but what if a bad person comes on? Take reasonable action, a warning to start, a permanent ban at worst. Punishment severity is, in order, a warning (use the chat), a kick (/kick REASON), a temporary ban (/ban IP DURATION REASON), and a permanent ban (/ban IP REASON). IP is delinquent's IP address (found using "/playerlist" admin command), DURATION is the amount of time in minutes (do not put a number alone if to ban forever), and REASON is an optional text string of the reason, which will be sent to the player and recorded in your logs. If you want to just kick a person off the server temporarily, use "/kick REASON", replacing REASON with an optional text string of the reason why. If you want bans to last after you shut down or restart your server, make sure you specified a ban file, which is a file that BZFS can store banned IPs in, using BZFS command-line option "-banfile FILE", where FILE is the name of the file in the BZFS directory.
World files should have the ".bzw" file extension and be in BZW format. If world files live in the "
worlds" directory under the config directory they will be usable when you start a simple server from inside the client. You should not use this method to run a dedicated server, just for starting a LAN game etc. The "
worlds" directory is located:
- "~/.bzf/worlds/" - on Linux and Unix Systems.
- "My Documents\My BZFlag Files\worlds\" - on Microsoft Windows.
- "~/Library/Application Support/BZFlag/worlds" - on Apple Mac OS X.
BZFlag has not been carefully audited for buffer overflows and other remote attacks, however, large packets or suspicious packets make the server kick the player that sent it. You should never trust the server to be your guard. It's a good idea to run your BZFlag server as a user with minimal permissions on your machine and to run it in a chroot jail.
Regarding "cheat" servers
While the license for BZFlag allows users to run any server modification that they wish, or to modify the code in any way, the project administration asks that users do not publish or host "cheat" type clients or servers. These cheats ruin the game for the average player, when they are mixed in with the normal game servers and clients. We understand the desire to expand and modify the game and its sources, so it is requested that anyone wishing to run a game that uses modified code or logic to do so using a different network protocol than the current public release. This will let modified games be played, and prevent modified clients from being used on public unmodified games, as they would be incompatible. The BZFlag project administrators reserve the right to remove the public listings of any game servers that do not adhere to this rule. Administrators also reserve the right to remove any global accounts or access to public services at any time.
http://my.bzflag.org/bb/viewtopic.php?t=2915 post on the BZFlag Forums