Manpages
bzfs
Section: Games and Demos (6)Index
Return to Main Contents
NAME
bzfs - BZFlag game serverSYNOPSIS
bzfs [-a velocity rotation] [-b] [-c] [+f {good|flag-id}] [-f {bad|flag-id}] [-g] [-h] [-help] [-i interface] [-j] [-lagwarn {time/ms}] [-mp {count|[rogue-count],[red-count],[green-count],[blue-count],[purple-count]}] [-mps {max-score}] [-ms shots] [-mts {max-score}] [-p port] [-noudp] [-passwd password] [-public description] [-publicaddr address[:port]] [-publiclist url] [-q] [+r] [-r] [-requireudp] [+s flag-count] [-s flag-count] [-sa] [-st time] [-sw count] [-synctime] [-t] [-time time-limit] [-ttl ttl] [-version]DESCRIPTION
Bzfs is the server for BZFlag, and it must be running to play. It can be run on any system on the network (including a player's system or one without graphics). Terminating the server terminates the game in progress.Options
-
- -a velocity rotation
- Enables inertia and sets the maximum linear and angular accelerations. The units are somewhat arbitrary so you'll have to experiment to find suitable values. The values must be non-negative and higher values yield greater inertia.
- -b
- When -c is supplied, this option randomly rotates the buildings.
- -c
- Enables the capture-the-flag style game. By default, the free-for-all style is used.
- +f {good|flag-id}
- Forces the existence of the given flag. If specified multiple times for the same flag-id, then that many flags will appear. The good argument is equivalent to specifying +f once for each kind of good flag.
- -f {bad|flag-id}
- Disallows random flags of the given type. Required flags given by the +f option are still provided. The bad argument is equivalent to specifying -f once for each kind of bad flag.
- -g
- Quit after serving one game.
- -h
- Buildings are given random heights.
- -help
- Shows a help page and lists all the valid flag id's.
- -i interface
- Server will listen for and respond to ``pings'' (sent via multicast) on the given interface. The server uses the first multicast enabled interface by default. Clients use this to find active servers on the network. This is also the TCP/UDP/IP address the server will listen on.
- -j
- Allows jumping.
- -lagwarn time/ms
- Send warnings to players that lag more than time.
- -mp {count|[rogue],[red],[green],[blue],[purple]}
- Sets the maximum number of players, total or per team. A single value sets the total number of players allowed. Five comma separated values set the maximum for each team. If a count is left blank then no limit is set for that team, except for the limit on the total number of players. Boths forms may be provided.
- -mps max-score
- Sets a maximum score for individual players. The first player to reach this score is declared the winner and the game is over.
- -ms shots
- Allows up to shots simultaneous shots for each player. This is 1 by default.
- -mts max-score
- Sets a maximum score for teams. The first team to reach this score is declared the winner and the game is over.
- -p port
- Listen for game connections on port instead of the default port. Use -help to print the default port.
- -noudp
- Do not use a parallel UDP channel for player communication.
- -passwd password
- Specify a server administrator password for use in remote administration such as /kick messages.
- -public description
- Advertise this server on the internet with the given description. By default, a server will respond to broadcast or multicast queries, allowing clients to find servers on the local subnet or accessible through multicast routers. However, this doesn't allow clients to find servers not accessible via multicast. The -public option causes the server to register itself with a bzfls server, which clients can query to get a list of bzfs servers.
- -publicaddr address[:port]
- Advertise this server with the given address and port. Only has an effect when used with -public. Normally a server advertises itself at the local address and port. Some servers are not accessible from the internet at this address (for example servers behind a firewall using bzfrelay). Use this option to specify the address and/or port that internet users should use to access this server.
- -publiclist url
- Advertise this server on the bzfls servers listed at url. Only has an effect when used with -public. A built-in url is used by default. The BZFlag clients use the same built-in url so, by default, clients will see public servers automatically. See bzfls for a description of the format of url.
- -q
- If specified, the server will not listen for nor respond to ``pings''. BZFlag sends out these pings to give the user a list of available servers. This effectively makes the server private, especially if the -p option is also used.
- +r
- Makes most shots ricochet. Super bullets, shock waves, and guided missiles do not.
- -r
- Allows rogues to join the game. By default, no rogue players are allowed.
- -requireudp
- Require clients to use parallel UDP. If players fire before opening a UDP channel, kick them off the server.
- +s num-flags
- The server will have an extra num-flags random super flags available at all times. The -f option can be used to restrict which types of flags will be added. Required flags given by the +f option are not included in the num-flags total.
- -s num-flags
- The server will have up to num-flags random super flags available at any time. The -f option can be used to restrict which types of flags will be added. Required flags given by the +f option are not included in the num-flags total.
- -sa
- Antidote flags are provided for players with bad flags.
- -st time
- Bad flags are automatically dropped after time seconds.
- -sw count
- Bad flags are automatically dropped after count wins. Capturing a team flag does not count as a win.
- -synctime
- Forces all clients to use the same time of day. The current time is determined by the server's clock. This disables the + and - keys on the clients.
- -t
- Adds teleporters to the game.
- -time time-limit
- Sets a time limit on the game to time-limit. The game will be stopped time-limit seconds after the first player connects.
- -ttl time-to-live
- Sets the maximum number of hops a ``ping'' reply will take. This effectively limits the range of the server in the network. Clients more than time-to-live hops away will not receive notification of the server's existence.
- -version
- Prints the version number of the executable.
Notes
The server uses nearly zero CPU time when nobody is playing, and even during a game the server uses very little CPU, so it's not a burden on the system to leave one running and it won't interfere with a player using the same system (except on Windows 95, which really sucks at multitasking). The server will continue to run until terminated. If a game is in progress when the server goes down, all players will be kicked off and the game will be aborted without warning. The server resets itself when all players have quit. All players must quit to reset the server when a game is over (because of a score or time limit).The following game styles are recommended starting points.
-
- -c [-b]
- Basic capture-the-flag game. It teaches teamwork and dogfighting skills.
- -r -s -t
- Free-for-all with superflags and teleporters. Rogues are allowed. Teaches players how to use superflags and teleporters for maximum effect. You may want to allow players to drop bad flags with any of -sa, -st, and -sw.
Notice that the maximum number of shots for these styles is one. Having only one shot greatly increases playability and learning speed. Multiple shots decrease the required skill level and make it virtually impossible for even a skilled player to avoid getting shot for any length of time. More experienced players will still dominate the game, but beginners will have an easier time making kills.
Networking
Communication between the server and clients (i.e. between bzfs and bzflag) during a game is via TCP. Use the -help option to get the server's default port. If there's a firewall between the server and client, the firewall must accept connections from the client to this port and forward them to the server. See bzfrelay for a BZFlag firewall relay.Clients can search for servers by sending and receiving multicast UDP packets. For a client to discover a server, there must be a multicast route between them with fewer hops than the default TTL (time-to-live) which is 8 or whatever the TTL was set to using the -ttl option to bzflag. However, a client can still connect to a server beyond the multicast TTL. Clients can also find servers advertised using -public by querying bzfls servers.
Some communication between clients, such as position and orientation information, is normally sent directly via multicast UDP packets. Other data, like flag grab and kill messages, are sent to the server via TCP which then turns around and broadcasts it to all players via TCP. Since being in a game implies connection to the server, all players are guaranteed to get all messages sent via TCP. But the multicast UDP packets may be routed differently. If other players can see your tank in the game but it never appears to move and shots go through it, chances are high that your multicast packets are not getting routed correctly.
BZFlag will, upon connecting to a server, attempt to contact the server via multicast. If it gets a reply then multicasting is used for the duration of the game. If it receives no reply then it falls back to using the TCP server connection to transmit player-to-player packets. The server will broadcast these packets to the other players and send any multicast player-to-player packets to the player via TCP. This normally solves any communication problems at the expense of higher network traffic. However, there still may be problems if you can multicast to the server but not to some other players.
The first thing to check is that multicast packets are being sent on the right interface. By default, multicast packets are sent on the first multicast capable interface. This is normally the right choice, but if your system has more than one network interface (other than the loopback interface), then you may have to use a different interface. A typical scenario of this situation is a remote system connected via ISDN to a main network. Use netstat -i to list your interfaces, then use the -interface interface option to bzflag, replacing interface with the correct interface IP address.
The next thing to check is the TTL (time-to-live) on the client. By default it is 8. This means all other players must be no more than 8 hops (multicast routers) away. You can use a TTL as high as 255. Since sites are recommended to not forward multicast packets with TTL's below 32 outside the site, you cannot normally play BZFlag across the Internet unless you set the TTL above 32. If any player joins the game using a TTL greater than everyone else, then the server and all clients automatically begin using the higher TTL. This helps ensure that everyone can see everyone else, but, due the nature of the network geometry, this cannot be guaranteed.
If the TTL is high enough, check the multicast network. You must have a multicast router between all subnets from your subnet to every other subnet with a player. If all players are on the same subnet then no multicast router is required. Since multicast routers connecting a site to the Internet normally prevent packets with TTL's below 32 from going out onto the Internet, you can't normally play BZFlag across the Internet if the TTL not above 32. However, you may be able to create a multicast tunnel, a virtual point-to-point link between any two subnets on the Internet. You'll need to run a tunneling router at both ends of the tunnel. See mrouted for more information about a multicast router.
SEE ALSO
bzflag(6), bzfls(6), bzfrelay(6), mrouted(1)
Index
This document was created by man2html, using the manual pages.
Time: 05:43:01 GMT, April 20, 2024