bzfs(s) bzfs(s) NAME bzfs - BZFlag game server SYNOPSIS 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] [-publi- caddr 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 (includ- ing a player's system or one without graphics). Terminat- ing 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 argu- ment 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 speci- fying -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 val- ues 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 pro- vided. -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 pass- word for use in remote administra- tion such as /kick messages. -public description Advertise this server on the inter- net 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 multi- cast. 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. Nor- mally a server advertises itself at the local address and port. Some servers are not accessible from the internet at this address (for exam- ple servers behind a firewall using bzfrelay). Use this option to spec- ify 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 automati- cally. 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 play- ing, and even during a game the server uses very little CPU, so it's not a burden on the system to leave one run- ning and it won't interfere with a player using the same system (except on Windows 95, which really sucks at multi- tasking). The server will continue to run until termi- nated. 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 super- flags and teleporters for maximum effect. You may want to allow play- ers 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 playabil- ity 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 for- ward them to the server. See bzfrelay for a BZFlag fire- wall 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 differ- ently. 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 con- tact 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 play- ers 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. How- ever, 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 inter- face. 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 inter- face option to bzflag, replacing interface with the cor- rect 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 out- side 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 geome- try, 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. How- ever, you may be able to create a multicast tunnel, a vir- tual 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(g), bzfls(s), bzfrelay(y), mrouted(d) bzfs(s)