BZFlagWiki - User contributions [en]

Bz BaseURLHandler

2013-06-02T00:17:52Z

Constitution: spelling

{{BZFS_API_Doc}}{{BZFS_API_Class}}
==Delcaration==
class bz_BaseURLHandler
{
public:
bz_BaseURLHandler();
virtual ~bz_BaseURLHandler();
virtual void done(const char* URL, void * data, unsigned int size, bool complete);
virtual void timeout(const char* URL, int errorCode);
virtual void error(const char* URL, int errorCode, const char *errorString);
}

==Description==
This is the base class for callbacks from [[bz_addURLJob]]. It is used to return info about a URL request back to the calling plug-in.

Plugins should derive there own callback class from this class and implement their own versions of the virtual methods that they require.

==Methods==
void done(const char* URL, void * data, unsigned int size, bool complete);
This is called as data is returned from the request. The complete paramater will be true on the last call for this job.

void timeout(const char* URL, int errorCode);
This is called when the URL job times out. This is usually because the server is offline

void error(const char* URL, int errorCode, const char *errorString);
This is called when the URL job errors out. This is usually because the URL is bad.

Plug-ins

2013-05-14T12:11:14Z

Constitution: Added step to remove preceding "lib" from plugin targets on Xcode.

BZFS can be built to support the loading of external libraries as plug-ins. These plug-ins can alter or replace the logic applied by the server, as well as automate many common tasks.

Plug-ins are one of the more popular ways to apply modifications to the game. They do not require modifications of the BZFS application source code so it can be kept up to date with out the need to constantly apply patches. They have also proven to be a very simple method for distributing modifications from developers to players.

==Overview==
Plug-ins are compiled dynamic link libraries, that are built for the same OS/RuntimeEnvironment as the BZFS server that hosts them. On [http://www.microsoft.com/windows Microsoft Windows] they are built as [http://en.wikipedia.org/wiki/Dynamic-link_library DLL] files. On [http://www.linux.org Linux] and other [http://www.unix.org/ Unix]-like systems they are built as .so files.

==Use==
Plug-ins are loaded at startup by the '''-loadplugin''' option, or at run time with the ''/loadplugin'' command. If the full path to the plug-in is not specified, then [[BZFS]] will search a number of known sub directories for the plug-in as it attempts to load it. Using a valid path to the plug-in on load is highly recommended. While playing, all plug-ins loaded onto the server are visible with the /listplugins command.
===Parameters===
Some plug-ins take parameters that are passed to the plug-in on load. This is often a numeric value, or a path to a file. To pass a parameter to a plug-in, simply add a ',' after the plug-in name or path, and then add the parameter. Parameters can not have spaces, due to the way [[BZFS]] parses command line options and / commands.

On load, plug-ins install a number of callbacks and event handlers with the hosting [[BZFS]] that are called when specific events happen. This allows the plug-in to perform additional actions on these events, or if need be, alter the results of the default logic of the server.
===Search Paths===
[[BZFS]] searches for plug-ins in two standard locations: the config directory and the global plug-ins directory. The config directory is where the BZFlag config.cfg file is located, and the global plug-ins directory is $(prefix)/lib/bzflag/.

==BZFS API==
All plug-ins are linked to the [[BZFS API]]. This programing layer provides the interface to the BZFS application. All events and functions that a plug-in can call are in the [[BZFS API]].

==Standard plug-ins==
The [[BZFlag Source]] distribution contains a number of plug-ins that are maintained by the project [[:Category:Developer|developers]].
These plug-ins are located in the ''/plugins'' directory.

As of March 2013, [[BZFlag SVN|SVN]] TRUNK contains the following plug-ins:

*[[airspawn]]
*[[autoFlagReset]]
*[[bzfscron]]
*[[chathistory]]
*[[customflagsample]]
*[[fairCTF]]
*[[fastmap]]
*[[flagStay]]
*[[hiddenAdmin]]
*[[HoldTheFlag]]
*[[keepaway]]
*[[killall]]
*[[koth]]
*[[logDetail]]
*[[nagware]]
*[[Phoenix]]
*[[playHistoryTracker]]
*[[plugin_utils]]
*[[pushstats]]
*[[rabbitTimer]]
*[[rabidRabbit]]
*[[recordmatch]]
*[[regFlag]]
*[[RogueGenocide]]
*[[SAMPLE_PLUGIN]]
*[[serverControl]]
*[[serverSidePlayerSample]]
*[[shockwaveDeath]]
*[[superUser]]
*[[teamflagreset]]
*[[thiefControl]]
*[[timedctf]]
*[[TimeLimit]]
*[[webReport]]
*[[webstats]]
*[[wwzones]]

==Third Party Plug-ins==
A number of non-developers have created plug-ins for BZFS, and usually release them on the [http://my.bzflag.org/bb/ BZFlag Forums].

Here are the steps to compile a hypothetical third party plug-in named "Example":

# In the plugins directory of the BZFlag source tree run the command '''./newplug.sh Example'''
# Remove all of the files from the newly created plugins/Example directory (they were created by newplug.sh)
# Copy all of the distributed Example files into the plugins/Example directory
# In the top-level BZFlag source directory run '''autogen.sh''', '''configure''', and '''make''' as usual

When that finishes successfully the plug-in should be ready to use as described above.

In Xcode on Mac OS X, follow these instructions:

# Click on the BZFlag project name in the project navigator. Click Add Target, and create a new C/C++ Library. Name the plugin, and select "Dynamic" for type.
# In the project navigator, move the new library target from the bottom of the screen into the "Targets" group.
# Click on the BZFlag project name in the project navigator again. In the list of targets, select the BZFlag application target. In the Build Phases tab, in the Target Dependencies pane, add your new library target as a dependency of the application target. Also add it to the Copy Files phase for the PlugIns directory.
# Select your new library target. Select the Build Settings tab, and locate the Other Linker Flags option. Add the option "-undefined dynamic_lookup"
# Find the Architecture build setting for your new library. Make sure it is the same architecture as the main codebase, or click Levels, click the Architecture setting under your library target, click Other, and delete the setting. This will make it assume the overall project build architecture.
# Find the Executable Prefix build setting for your new library, and delete the "lib" setting.
# Add your source file(s) to the project, and make them members of your library target.
# Build as usual.

==Preparing a Linux BZFS==

In order to run plugins in BZFS, you need to recompile it with the --enable-shared option on the configure script.

''Note that as of 2.4.0 the BZFlag configuration has --enable-shared automatically enabled.''

$ ./configure --enable-shared --disable-client;
make;
make install;

==Plug-in Development==
{{DoDoc|Describe the basics of plug-in development.}}

==History==
The plug-in system was added in BZFlag V. 2.0.4 and was initially met with a lukewarm reception by some of the core developers and the maintainer. The community has since embraced the concept and built a multitude of useful modifications, many that have been incorporated into the project as standard plug-ins.

For Version 3.0 major changes to the [[BZFS API]] have been made to increase its lifespan.

[[Category:Server]]
[[Category:Development]]
[[Category:Plug-Ins]]

Master-ChildAccountSystem

2013-02-12T00:22:29Z

Constitution: sp

{{DesignDocument}}

==Overview==
The main goal of the Master/Child account system is twofold;
# To limit or remove the liability of project services under the COPPA laws [http://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Protection_Act]
# To provide additional features for parents to use when managing a child's time online.

==Concept==
In order to support children that current authentication system will be converted into what will be known as "master accounts". These master accounts will only be given out to users who are 13 years of age or older and will store personally identifiable information such as an e-mail address. Users who sign up for an master account must agree to the site terms and be 13 or older. Any user who has a master account and is found to be under the age of 13 will have the account delete and all saved data flushed from the system.

Master accounts will be have the option of creating a fixed number of "child" accounts that are linked to the master account. These child accounts will NOT store any identifying information and will only contain a callsign and a randomly generated password. A parent can then allow his/her children to use these accounts for play. A user who creates a child account will agree to a separate set of site terms that will grant the server the rights to store the call-sign and randomly generated password.

Since a parent is required to create the child account and no personal information for the child is stored, this will limit the liability for the project under COPPA.

==Additional Features==
Since the child accounts will be linked to a master account we can add a number of parental control features based on the child account, including

# Listing the servers and log-in times or linked accounts
# Limiting what servers the child accounts are shown in the list server based on parent defined filters
# Preventing child accounts from authenticating on forbidden servers based on parent defined filters.
# Preventing authentication based on parent defined time-frames.
# Allowing the master account to reset the child password to a new random password, or revoking access to the account.

==Other uses==
Players that wish to play under multiple callsigns could also create child accounts to use. This would prevent the large number of account renames that happen and limit the number of times an account gets "stolen" during a name change.

==Implementation==
===General Plan===
The initial implementation can be built upon the current authentication system. Child accounts would be stored in a separate database or table and tied to the BZID of the master account. Child accounts would be given a BZID in a specific range so they would not collide with the normal BZID system (use negative numbers, or a prefix?). A website would be made to allow users who authenticate with Weblogin to create and manage child accounts. The list server would be modified to check the child user list if the callsign was not found in the master password database.

When this is complete the current COPPA group on BZBB would be mass emailed and asked to provide proof that they are over 13 years of age. Those users who provide proof would be removed from the COPPA group and made normal users. The users who were left would all be notified that they now need to have a parent create a child account for them and the current accounts will be deleted. This will let us purge the COPPA group of users who are no longer too young.

When the COPPA group is purged the forum system will be changed to disallow users under 13 from registering new accounts and direct them to the child account system.

===Specifics===
# Child accounts should never be able to set a password, they must always use the password set by the master account. This password will be defaulted to a randomly generated password for enhanced security against weak passwords.
# A separate table would need to store a record that stored the data from every master user that created a child account. This includes the Child account name, date, IP address used, and a flag indicting that the user checked the "I agree" checkbox on the new child account form. This table is the proof that the user is agreeing to let us store the data for the child.
# The current PHPBB system will need to be modified to check the child account list when creating new accounts to know what names are invalid.
# Child accounts should not be allowed to login to webauth and only be allowed to authenticate in game by default. The master account can enable web logins if it desires.
# Child accounts should be added to a special "group" on the list server to identify them as child accounts. This will let servers know if the account is a child and they can set permissions appropriately.
# A method should exist for converting a child account to a master account with the master account's permission. This can be used when a child turns 13 and is capable of maintaining their own account. The master account would be asked to agree to a set of terms that state that the new user is of age.

===Database Design===

[[Image:BZ_Child_Accounts_DB.png]]

===GUI Design===
The GUI should be done in a manner that can be extended into a full user manager.

'''Main log-in page.'''

This page should look as similar as possible to the current weblogin system to show consistency and trust. Eventually the same log-in page should be used for both systems.

[[image:Users_BZFlag_Org_Login_Mockup.png|450px]]

'''Child account page.'''

This page will list the child accounts that the master currently has. Here they can add/remove and edit the child accounts. On creation the user will be asked for the child account name, and a randomly generated password will be show in the password field after the account is created. Normally the password field will be blank and will only be used if/when the user wishes to set the password manually or use the Random button to generate a new random password. The system will NOT store the password, only a hash to it.

[[image:Users_BZFlag_Org_ChildAccounts_Mockup.png|450px]]

Master-ChildAccountSystem

2013-02-12T00:19:38Z

Constitution: sp

{{DesignDocument}}

==Overview==
The main goal of the Master/Child account system is twofold;
# To limit or remove the liability of project services under the COPPA laws [http://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Protection_Act]
# To provide additional features for parents to use when managing a child's time online.

==Concept==
In order to support children that current authentication system will be converted into what will be known as "master accounts". These master accounts will only be given out to users who are 13 years of age or older and will store personally identifiable information such as an e-mail address. Users who sign up for an master account must agree to the site terms and be 13 or older. Any user who has a master account and is found to be under the age of 13 will have the account delete and all saved data flushed from the system.

Master accounts will be have the option of creating a fixed number of "child" accounts that are linked to the master account. These child accounts will NOT store any identifying information and will only contain a callsign and a randomly generated password. A parent can then allow his/her children to use these accounts for play. A user who creates a child account will agree to a separate set of site terms that will grant the server the rights to store the call-sign and randomly generated password.

Since a parent is required to create the child account and no personal information for the child is stored, this will limit the liability for the project under COPPA.

==Additional Features==
Since the child accounts will be linked to a master account we can add a number of parental control features based on the child account, including

# Listing the servers and log-in times or linked accounts
# Limiting what servers the child accounts are shown in the list server based on parent defined filters
# Preventing child accounts from authenticating on forbidden servers based on parent defined filters.
# Preventing authentication based on parent defined time-frames.
# Allowing the master account to reset the child password to a new random password, or revoking access to the account.

==Other uses==
Players that wish to play under multiple callsigns could also create child accounts to use. This would prevent the large number of account renames that happen and limit the number of times an account gets "stolen" during a name change.

==Implementation==
===General Plan===
The initial implementation can be built upon the current authentication system. Child accounts would be stored in a separate database or table and tied to the BZID of the master account. Child accounts would be given a BZID in a specific range so they would not collide with the normal BZID system (use negative numbers, or a prefix?). A website would be made to allow users who authenticate with Weblogin to create and manage child accounts. The list server would be modified to check the child user list if the callsign was not found in the master password database.

When this is complete the current COPPA group on BZBB would be mass emailed and asked to provide proof that they are over 13 years of age. Those users who provide proof would be removed from the COPPA group and made normal users. The users who were left would all be notified that they now need to have a parent create a child account for them and the current accounts will be deleted. This will let us purge the COPPA group of users who are no longer too young.

When the COPPA group is purged the forum system will be changed to disallow users under 13 from registering new accounts and direct them to the child account system.

===Specifics===
# Child accounts should never be able to set a password, they must always use the password set by the master account. This password will be defaulted to a randomly generated password for enhanced security against weak passwords.
# A separate table would need to store a record that stored the data from every master user that created a child account. This includes the Child account name, date, IP address used, and a flag indicting that the user checked the "I agree" checkbox on the new child account form. This table is the proof that the user is agreeing to let us store the data for the child.
# The current PHPBB system will need to be modified to check the child account list when creating new accounts to know what names are invalid.
# Child accounts should not be allowed to login to webauth and only be allowed to authenticate in game by default. The master account can enable web logins if it desires.
# Child accounts should be added to a special "group" on the list server to identify them as child accounts. This will let servers know if the account is a child and they can set permissions appropriately.
# A method should exist for converting a child account to a master account with the master account's permission. This can be used when a child turns 13 and is capable of maintaining there own account. The master account would be asked to agree to a set of terms that state that the new user is of age.

===Database Design===

[[Image:BZ_Child_Accounts_DB.png]]

===GUI Design===
The GUI should be done in a manner that can be extended into a full user manager.

'''Main log-in page.'''

This page should look as similar as possible to the current weblogin system to show consistency and trust. Eventually the same log-in page should be used for both systems.

[[image:Users_BZFlag_Org_Login_Mockup.png|450px]]

'''Child account page.'''

This page will list the child accounts that the master currently has. Here they can add/remove and edit the child accounts. On creation the user will be asked for the child account name, and a randomly generated password will be show in the password field after the account is created. Normally the password field will be blank and will only be used if/when the user wishes to set the password manually or use the Random button to generate a new random password. The system will NOT store the password, only a hash to it.

[[image:Users_BZFlag_Org_ChildAccounts_Mockup.png|450px]]

Compiling

2013-01-30T02:03:15Z

Constitution: Updated the instructions for Mac OS X and removed some outdated information.

==Overview==
Compiling BZFlag is the act of building executable applications for a target system using the raw source code. This is usually not necessary to [[Installing|install the game]].

==Obtaining sources==
In order to compile a user must have his or her own copy of the [[BZFlag_Source|Source Code]]. The code can be obtained from a source archive from the [[Download]] page, or from the BZFlag [[BZFlag_SVN|Subversion]] server.

==README files==
Users should always read the README files for the appropriate operating system. These files are located in the root directory of the source code tree.

==Compilers==
BZFlag is capable of being built on a number of compilers. The compiler used will depend in some way on the operating system of the computer doing the build.

* Windows computers can use the Visual C++ compiler, or the MinGW compiler (based on GCC). Windows is the most popular client OS and nearly all clients are built with the Visual C++ compiler, including the official binaries.
* Macintosh OS X computers use the Xcode compiler (or optionally gcc, see notes). OS X is the second most popular client OS, official builds are built with Xcode, not GCC.
* Linux and BSD computers use the GCC compiler. Linux is the third most common client OS and packages for distributions are built using GCC.

===Visual C++===
The most common way to build on windows to to use the Visual C++ 2010 compiler (Both Express and Retail versions are supported).
The current free Express version of Visual C++ can be found at [http://www.microsoft.com/express/vc/ http://www.microsoft.com/express/vc/]

===GCC===
If the required dependencies are installed, the user must then run the following commands from at root level of the source tree

./autogen.sh
./configure
make
make install

Please note that depending on permissions levels the '''make install''' command may need to be run as an administrator or root. On Macintosh OS X, do not run make install when building with GCC. Run the program from the source directory or install it manually as desired instead.

===Xcode===
The Xcode system uses the '''Xcode/BZFlag.xcodeproj''' project. Building is fairly straightforward. Follow the instructions in the README.MacOSX file.

==Dependencies==
In order to compile BZFlag, some third party libraries may be required depending on the operating system being built for. The readme file for each OS will contain the current dependencies for each OS and should be consulted before attempting any build.

The following is a general dependency list for version 2.4.

===Windows (Visual Studio)===
The only third party dependency required to build the client is the DirectX SDK that is available from Microsoft. A download is available at http://www.microsoft.com/en-us/download/details.aspx?id=6812.

If a user wishes to build a full set of windows installers, they will need to install the NSIS installer system, available from http://nsis.sourceforge.net.

All other dependencies are included.

===Linux (GCC)===
====Required Libraries====
* SDL development libraries (1.2.10 or greater)
* SDL-sound development libraries (1.2.10 or greater)
* libtool
* automake
* autoconf
* g++
* mesa development libraries (gl, and glu)
* mesa development libraries

====Required Libraries====
These libraries are included with the source tree but users may have better results using ones included with a Linux distribution.

* curl development libraries
* c-ares development libraries
* glew development libraries
* zlib development libraries

===Macintosh OS X (Xcode or GCC)===
====Required Libraries====
* SDL framework 1.2 (1.3 may not work on all versions of OSX)

==Other build systems==
Other build systems may be supported in the various readme files (minGW, IRIX, SOLARIS,etc..) see the [[Compiling/Solaris_Notes]] page for more info.

[[Category:Development]]
[[Category:Compiling]]
[[Category:Tutorials]]

Plug-ins

2012-12-16T12:35:58Z

Constitution: Added instructions for adding a plug-in to the Mac OS X Xcode project

BZFS can be built to support the loading of external libraries as plug-ins. These plug-ins can alter or replace the logic applied by the server, as well as automate many common tasks.

Plug-ins are one of the more popular ways to apply modifications to the game. They do not require modifications of the BZFS application source code so it can be kept up to date with out the need to constantly apply patches. They have also proven to be a very simple method for distributing modifications from developers to players.

==Overview==
Plug-ins are compiled dynamic link libraries, that are built for the same OS/RuntimeEnvironment as the BZFS server that hosts them. On [http://www.microsoft.com/windows Microsoft Windows] they are built as [http://en.wikipedia.org/wiki/Dynamic-link_library DLL] files. On [http://www.linux.org Linux] and other [http://www.unix.org/ Unix]-like systems they are built as .so files.

==Use==
Plug-ins are loaded at startup by the '''-loadplugin''' option, or at run time with the ''/loadplugin'' command. If the full path to the plug-in is not specified, then [[BZFS]] will search a number of known sub directories for the plug-in as it attempts to load it. Using a valid path to the plug-in on load is highly recommended. While playing, all plug-ins loaded onto the server are visible with the /listplugins command.
===Parameters===
Some plug-ins take parameters that are passed to the plug-in on load. This is often a numeric value, or a path to a file. To pass a parameter to a plug-in, simply add a ',' after the plug-in name or path, and then add the parameter. Parameters can not have spaces, due to the way [[BZFS]] parses command line options and / commands.

On load, plug-ins install a number of callbacks and event handlers with the hosting [[BZFS]] that are called when specific events happen. This allows the plug-in to perform additional actions on these events, or if need be, alter the results of the default logic of the server.
===Search Paths===
[[BZFS]] searches for plug-ins in two standard locations: the config directory and the global plug-ins directory. The config directory is where the BZFlag config.cfg file is located, and the global plug-ins directory is $(prefix)/lib/bzflag/.

==BZFS API==
All plug-ins are linked to the [[BZFS API]]. This programing layer provides the interface to the BZFS application. All events and functions that a plug-in can call are in the [[BZFS API]].

==Standard plug-ins==
The [[BZFlag Source]] distribution contains a number of plug-ins that are maintained by the project [http://my.bzflag.org/wiki/index.php/Category:Developer developers].
These plug-ins are located in the ''/plugins'' directory.

As of August 2009, [[BZFlag SVN|SVN]] TRUNK( version [[BZFlag 3.0|2.99]]) contains the following plug-ins:

*[[airspawn]]
*[[bzfscron]]
*[[chathistory]]
*[[chatlog]]
*[[customflagsample]]
*[[fastmap]]
*[[flagStay]]
*[[hiddenAdmin]]
*[[HoldTheFlag]]
*[[HTTPServer]]
*[[httpTest]]
*[[keepaway]]
*[[killall]]
*[[koth]]
*[[logDetail]]
*[[mapchange]]
*[[nagware]]
*[[Phoenix]]
*[[playHistoryTracker]]
*[[python(plug-in)|python]]
*[[rabidRabbit]]
*[[recordmatch]]
*[[regFlag]]
*[[RogueGenocide]]
*[[SAMPLE_PLUGIN]]
*[[serverControl]]
*[[serverSideBotSample]]
*[[shockwaveDeath]]
*[[soundTest]]
*[[teamflagreset]]
*[[thiefControl]]
*[[timedctf]]
*[[torBlock]]
*[[unrealCTF]]
*[[weaponArena]]
*[[webadmin]]
*[[webReport]]
*[[webstats]]
*[[wwzones]]

==Third Party Plug-ins==
A number of non-developers have created plug-ins for BZFS, and usually release them on the [http://my.bzflag.org/bb/ BZFlag Forums].

Here are the steps to compile a hypothetical third party plug-in named "Example":

# In the plugins directory of the BZFlag source tree run the command '''./newplugin.sh Example'''
# Remove all of the files from the newly created plugins/Example directory (they were created by newplugin.sh)
# Copy all of the distributed Example files into the plugins/Example directory
# In the top-level BZFlag source directory, edit configure.ac, and add plugins/Example/Makefile to the list of AC_CONFIG_FILES
# In the top-level BZFlag source directory run '''autogen.sh''', '''configure''', and '''make''' as usual

When that finishes successfully the plug-in should be ready to use as described above.

In Xcode on Mac OS X, follow these instructions:

# Click on the BZFlag project name in the project navigator. Click Add Target, and create a new C/C++ Library. Name the plugin, and select "Dynamic" for type.
# In the project navigator, move the new library target from the bottom of the screen into the "Targets" group.
# Click on the BZFlag project name in the project navigator again. In the list of targets, select the BZFlag application target. In the Build Phases tab, in the Target Dependencies pane, add your new library target as a dependency of the application target. Also add it to the Copy Files phase for the PlugIns directory.
# Select your new library target. Select the Build Settings tab, and locate the Other Linker Flags option. Add the option "-undefined dynamic_lookup"
# Find the Architecture build setting for your new library. Make sure it is the same architecture as the main codebase, or click Levels, click the Architecture setting under your library target, click Other, and delete the setting. This will make it assume the overall project build architecture.
# Add your source file(s) to the project, and make them members of your library target.
# Build as usual.

==Preparing a Linux BZFS==

In order to run plugins in BZFS, you need to recompile it with the --enable-shared option on the configure script.

''Note that as of 2.4.0 the BZFlag configuration has --enable-shared automatically enabled.''

$ ./configure --enable-shared --disable-client;
make;
make install;

==Plug-in Development==
{{DoDoc|Describe the basics of plug-in development.}}

==History==
The plug-in system was added in BZFlag V. 2.0.4 and was initially met with a lukewarm reception by some of the core developers and the maintainer. The community has since embraced the concept and built a multitude of useful modifications, many that have been incorporated into the project as standard plug-ins.

For Version 3.0 major changes to the [[BZFS API]] have been made to increase it's lifespan.

[[Category:Server]]
[[Category:Development]]
[[Category:Plug-Ins]]

DevelopmentPlans/2.3

2011-05-12T22:06:55Z

Constitution: Sign up for a few of the changes.

==Overview==
BZFlag 2.3 will be a development version that will be released as 2.4.0.0. This is to get around the problem that [[BZFlag 3.0]] development has stalled and does not look like it will continue. This is a last ditch effort to get development moving again.

==Goal==
The goal is to release a new version of [[Main Page|BZFlag]] that is incompatible with 2.0.x for a good reason, and has at least one new feature that will make many players '''want''' to upgrade.

The hope is that this process will renew developer motivation and attract new developers.

==Schedule==
* Solicit specific change proposals that can be completed within one month. Each proposal must be sponsored by an individual developer who will lead its implementation. '''In Progress'''
* When proposals are in and accepted by consensus, start the 1-month countdown clock.
* Move trunk to a v2_99_branch.
* Copy v2_0branch to trunk and change protocol number.
* Implement accepted proposals and test.
* Change the version docs to make compatibility be the minor version number.
* Document server upgrade process for the many server owners.
* After 1 month, revert any changes that have caused unfixed regressions.
* Do a release candidate before final release?
* Make trunk into 2.4.0.0 for release.
* Tag Trunk to 2_4branch and release.

==Projects==
These are the many ideas, both new and old, for changes to BZFlag.

===Viable Projects===
The developers believe any (but not all) of the following could be added to 2.3 within the proposed schedule.

====Backports====
These 2.99 features are suitable for porting to 2.3.

* Connection header change (HTTP-style) ''JeffM''
* New GUI elements ''DTRemenak''
* Server-side scoring ''DTRemenak''
* Segmented simulation loop (to prevent wallwalking)''JeffM''
* Server-side flag ID and pickup
* [[2.3_NewShotGraphics|New shot graphics]] (geolaser/geothief)''JeffM'' '''Discuss on IRC'''
* HUD markers ''JeffM''
* [[2.3_QualityChanges|Removal of low graphics, promotion of experimental to high]]. ''JeffM''
* Server list from GSoC ''DTRemenak''
* BZFS API rework ''JeffM''
* Remove local authentication (the /identify command)
* Windows project cleanup ''JeffM''
* New make system
* New source docs (authors etc...) ''Constitution''
* Server-side handicap
* Guided Missile shot checks
* Stealth fixes for rabbit ''mdskpr''
* Asynchronous screenshot compression so client won't freeze up during screenshots ''DTRemenak''
* BZFlag update notification ''DTRemenak''
* Wings velocity change (additive flap instead of instant upward velocity) ''blast007''
* Message protection (ensure network messages are valid)
* Add message types so that actions (/me) are properly implemented
* New artwork ''JeffM''
* Server option to disable teamkills ''JeffM''
* OpenFFA ''JeffM''
* Download URL change (to force just images.bzflag.org, not any .org or .bz) ''Constitution''
* Remove option to turn off fog ''JeffM''
* Require OpenGL 1.2 ''JeffM''
* Only allow a single end shot credit for holding the shield flag ''Thumper''
* Only players with POLL permission are eligible to take part in a vote ''Thumper''
* Add the /serverdebug command ''Thumper''
* bzfs: Report errors to stderr instead of stdout ''Thumper''
* bzfs: Add -utc switch to output log messages in UTC instead of localtime ''Thumper''
* bzfs: Fix timestamp buffer size so -ts micros output fits ''Thumper''
* Joystick input fixes/enhancements ''DTRemenak''
* Remove -geometry and make -window take a size ''JeffM''

====New Changes====
* Round Robin for services
* Fix the protocol bug that version [[BZFlag 2.0.16|2.0.16]] was a band-aid for
* Facilitate moving global services (e.g., my.bzflag.org) to new hardware, if any changes will help ''JeffM'' ''Blast007'' ''JoeVano''

===To Evaluate===
These items need further evaluation to see if they can be or should be backported from 2.99. These may exist as code or patches.

====Backports====
* Map changes
* HTTP plugins ''JeffM''
* New API events ''JeffM''
* Custom flag system ''DTRemenak''
* BZFSCron ''Thumper''
* Server Side Players ''JeffM''
* Bug fixes not in notes ''Thumper''
* New flags
* Rabbit as proper team

====New Changes====
* Countdown/reload timer position fix for when showCoordinates is enabled ''mdskpr''
* SVN props cleanup
* Display BZBB rank images in game. ''JeffM''

===Exclusions===
These items should not be done or backported at this time due to stability issues or the large effort required. These are generally the blocking items preventing 3.0's current release.

* Network buffering
* Lua
* Lag compensation (needs a lot more testing)
* Acceleration changes
* Font system (still has some bugs/glitches and possible performance issues)
* New Translations (requires the new font system)
* Map geometry changes (requires flag zap zone support or breaks existing servers)

DevelopmentPlans/2.3

2011-05-11T21:21:09Z

Constitution: Added section for trivial/polish features

BZFlag 2.3 will be a development version intended to sidestep the abandonment of [[BZFlag 3.0]] development.

==Goal==
The goal is to release a new version of [[Main Page|BZFlag]] that is incompatible with 2.0.x for a good reason, and has at least one new feature that will make many players '''want''' to upgrade.

The hope is that this process will renew developer motivation and attract new developers.

Note: This proposal requires changing the version docs to make the compatability be the minor version number.

==General ideas==
* Facilitate moving global services (e.g., my.bzflag.org) to new hardware.
* Add one or two non-trivial client features so the players will be motivated to upgrade
- graphics quality?
- server list backport?
- Cloaked Shot flag (hoping for better than this)
* anti-cheating?
* Fix the protocol bug that version [[BZFlag 2.0.16|2.0.16]] was a bandaid for.
* Remove the /identify command.
* BZBB rank promotions! ;-)

==Schedule==
* Immediately open 2.0.17 up for whitespace, Subversion properties, copyright notices, and other easy changes that don't break protocol.
* Solicit specific change proposals that can be completed within one month. Each proposal must be sponsored by an individual developer who will lead its implementation.
* When proposals are in and accepted by consensus, start the 1-month countdown clock.
* Copy trunk to a V3_FAIL tag.
* Copy v2_0branch to trunk and commit a change that requires a new protocol number.
* Implement accepted proposals and test.
* After 1 month, revert any changes that have caused unfixed regressions.
* Update version docs and make trunk into 2.4.0.0 for releease.
* Tag Trunk to 2_4branch trelease.

==Backports==
These items should be moved back from V3 into the new version.

* Connection Header Change
* Round Robin for services
* New GUI elements
* Server Side Scoring
* Sim loop breakup (to prevent F5)
* Server Side Flag ID and pickup
* New Shot Graphics
* Hud Markers
* Removal of low graphics, promotion of experimental to high.
* Server List from SOC
* API rework
* Remove Identify
* Windows Project Cleanup
* New Make system
* New source docs ( authors etc..)
* Server side handicap
* Gm shot checks
* Stealth fixes for rabbit
* Screenshot fixes
* Update Notification
* Wings Velocity Change
* Message Protection
* New artwork
* no Tks
* open FFA
* download URL change ( to force just images.bzflag.org, not any .org or .bz )
* remove fog options ( let server force)
* require GL 1.2

==Backport evals==
These items should be evaluated to see if they can be or should be moved back, but are not critial.

* Map changes.
* HTTP plugins
* New API events
* BZFChron
* Server Side Players
* Bugfixs not in notes
* New flags
* Rabbit as team

==Things NOT to backport==
These items should not be moved back due to stability issues. These are generaly be the blocking items preventing V3s current release.

* Network buffering
* Lua
* Lag Comp
* Acceleration Changes
* Font System
* New Translations
* Map geometry changes ( requires flag zap zone support or breaks existing servers. )

==Trivial/Polish features==
The following limited number of trivial/non-invasive new features or changes should be considered for implementation before the final stable release. These may already exist as patches which were rejected because they were for branch rather than trunk.

* Countdown/reload timer position fix for when showCoordinates is enabled

Google Summer of Code: 2009

2009-04-07T01:06:06Z

Constitution: Add myself to the mentors list

The 2009 Google Summer of Code was announced in February, 2009. BZFlag is once again participating as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we are very excited to be participating again. We are accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] are available.

Note that for 2009, we're expecting to only accept two or three new students so that we can focus our time and attention on those individuals and our upcoming major release. That means you're really encouraged to talk with us early on and make an outstanding project proposal. The best way to get our attention at this time is to make bug fixes. We look forward to working with you!

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome and encouraged to apply with their own ideas. They should run those ideas by one of the developers beforehand to make sure they are consistent with the scope and focus of the project, though, as there are some ideas which will not be accepted regardless of the quality of the application and applicant. We've additionally provided several project ideas important to BZFlag development that we would very much like to see proposals for, shown in following.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== Suggest your own idea ===
BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== Cheat preventions ===
This task involves making BZFlag more robust towards preventing various cheats from working in the game. This task implicitly requires adding protections on the server, moving game logic from the client to the server, and/or adding heuristics and other measures for detecting and dealing with cheat clients. The student should have a strong grasp of the variety of BZFlag cheats that are available. Please go into detail about which cheats you're interested in preventing and how you intend to employ those preventive measures. For information on known cheats, check out the [[Known Cheats]] wiki page. ''This is a high-priority idea.''

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== Modularization of game logic ===
Much of the game logic is presently mixed in with BZFlag's graphics code. This lack of organization make it difficult to find code when necessary, and does not allow bzfs, bzrobots, or other tools to utilize the game logic. The game code should be modularized into [[DevelopmentGoals#libGame|libgame]] so that all that is left in the client code is the graphics subsystem. This will also ease the possible future integration of a 3D graphics engine. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== Network Testing and Simulation Environment ===
This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

As a participant in last year's program, Jude Nelson started work on BZWorkBench. It is a world file editor with a very solid foundation but much work still remains to be done, including a cross-platform GUI, mesh support, and other editor features. Ideally, two students would work on this. For example, one student could focus on improving the GUI's workflow and ease-of-use, and another could focus on finishing the back-end object manipulation.

The current GUI does not conform to a specific HIG, nor does its usability resemble many other 3D editors; this should change. The back-end still lacks support for many of the objects added in BZFlag 2.0, such as Meshes, texture matrices, dynamic colors, etc.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that is fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== Finish server-side players ===
BZFlag includes players that can be run and managed from the server through a server-side plugin. Unlike the client-side BZRobots project, server-side robots have entirely different issues that they have to account for and information that they have access to. This project would entail taking the work that has already been started to completion. As this is a continuation, please do contact the developers before proposing this idea to determine the current status and work required.

'''Requirements''':
*Familiarity with C/C++
*Ability to pick up a work-in-progress

'''Difficulty''': medium

=== Dead Reckoning and other Networking Enhancements ===
The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== Multiple display support===
Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===In-game profile management===
BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (joevano/Donny_Baker)
* James Lawrence (spldart)
* Bernt Hansen (Thumper_)
* Jeff Makey (BulletCatcher)
* Jørgen Pedersen Tjernø (jorgenpt)
* Joshua Bodine (Constitution)

[[Category: Development]]

Modular Collisions

2008-07-22T07:23:11Z

Constitution: Initial edit

In present trunk code, collisions between tanks and shots are detected and reported from clients and do not undergo any kind of server-side verification. This is a straightforward approach that allows for a single authority on collisions and keeps the synchronization issues at a minimum, but because the server does not verify the information sent by the clients, it is possible to modify clients to have a smaller hit zone (or none at all). Thanks to lag compensation and timestamps in messages, the server has all the information it needs to do basic checks on collisions between tanks and shots. Implementing such a verification system is the goal of the collisions branch, which is the subject of one of the 2008 Google Summer of Code students' projects.

BZFlag on IRC

2008-05-20T03:37:41Z

Constitution: update ICF team name

The BZFlag communities use the [http://freenode.net/ freenode IRC network] for communication and collaboration. [http://en.wikipedia.org/wiki/IRC IRC]

The [http://freenode.net/ freenode network] is used for all IRC communications.
Common channels include:
* [irc://irc.freenode.net/#bzflag #bzflag]
* [irc://irc.freenode.net/#bzchat #bzchat]

A web interface is provided to these channels at http://my.BZFlag.org/irc/irc.cgi
==Channels==

===#bzflag===
The #bzflag channel is the primary development and support channel. The major developers and many long time community members are users. Discussions in the channel range from development and coding discussions to technical support and bug reports. #bzflag is a great channel to discuss new features and bugs. The channel is moderated by the project administration and development staff. '''This channel is not for help with specific servers or administration issues'''

===#bzchat===
The #bzchat channel is a more informal channel designated for player community discussions.

===Other channels===
A number of players, servers, and [[leagues]] have their own channel for more focused discussion, some of these include:

* ##bar (DUCLeague team, The Barbarians)
* #BoomBZ (Team Channel for GU team [BoOm])
* ##bz-inc (DUCLeague team, [http://my.bzflag.org/league/index.php?link=teaminfo&id=689/ Bz-Incorporated])
* ##bzflagr (Support channel for the [http://bzflagr.net BZFlagr.net servers.])
* #bzfx (Support channel for the bzfx.net BZFlag servers)
* ##bzpod (Channel to discuss the BZFlag podcast, BZPod)
* #bzflag (On irc.stormcenter.net, support channel for [http://www.bztank.net BZtank] servers)
* ##bzw (A place to discuss map making for BZFlag, including ideas and help)
* #divi (Support channel for [http://divi.fairserve.net Divibox] and other [http://fairserve.bzflag.org Fairserve] servers)
* #dub (Support channel for the dub.bzflag.org BZFlag servers)
* ##ducleague (Support channel for [http://my.bzflag.org/league/ Ducati League (DucLeague)])
* #forestforce ([http://gu.bzleague.com/index.php?link=teaminfo&id=10 GULeague Team])
* ##guleague (Support channel for [http://gu.bzleague.com/ GamesUnited League (GULeague)])
* #hepcat (Support channel for borrego.hepcat.org BZFlag server) ''defunct''
* ##icf (Support channel for [http://gu.bzleague.com/index.php?link=teaminfo&id=112 Invisible Carniverous Flies, (GULeague)])
* #inleague (Support channel for [http://in.bzleague.com InterNational League (INLeague)])
* #kas (GULeague team, KAS)
* ##norang (Support channel for [http://bzflag.norang.ca Norang.ca] BZFlag servers)
* #pillbox (Support channel for [http://pillbox.bzleague.com/ Pillbox League (PBLeague)])
* ##planetmofo (Support channel for [http://www.planet-mofo.com planet-mofo.com] servers)
* #plosileague (Support channel for [http://bzfx.net/league/ Plosileague])
* #silvercat (Support channel for [http://silvercat.bzflag.org/ Silvercat BZFlag servers]) ''defunct''
* ##t42 ([http://gu.bzleague.com/index.php?link=teaminfo&id=39 GULeague team])
* ##untamed ([http://my.bzflag.org/league/index.php?link=teaminfo&id=909 DUCLeague team])

==IRC Clients==
To access the IRC network you need to use an IRC client, there are many IRC client softwares available for most operating systems.

http://irchelp.org/ is an excellent resource for more information on general IRC.

===Web IRC Interface===
The project provides a [http://my.BZFlag.org/irc/irc.cgi web based interface] to the main IRC channels. These are intended mostly for tech support issues, and the web interface is limited in the number of channels it can access.

==External links==
http://my.BZFlag.org/irc/irc.cgi

http://irchelp.org/

[[Category:Development]]
[[Category:Support]]

BZFlag on IRC

2008-04-24T04:15:58Z

Constitution: Re-alphabetize "other channels" listing, add #divi channel info, update ICF team name.

The BZFlag communities use the [http://freenode.net/ freenode IRC network] for communication and collaboration. [http://en.wikipedia.org/wiki/IRC IRC]

The [http://freenode.net/ freenode network] is used for all IRC communications.
Common channels include:
* [irc://irc.freenode.net/#bzflag #bzflag]
* [irc://irc.freenode.net/#bzchat #bzchat]

A web interface is provided to these channels at http://my.BZFlag.org/irc/irc.cgi
==Channels==

===#bzflag===
The #bzflag channel is the primary development and support channel. The major developers and many long time community members are users. Discussions in the channel range from development and coding discussions to technical support and bug reports. #bzflag is a great channel to discuss new features and bugs. The channel is moderated by the project administration and development staff.

===#bzchat===
The #bzchat channel is a more informal channel designated for player community discussions.

===Other channels===
A number of players, servers, and [[leagues]] have their own channel for more focused discussion, some of these include:

* ##bar (DUCLeague team, The Barbarians)
* #BoomBZ (Team Channel for GU team [BoOm])
* ##bz-inc (DUCLeague team, [http://my.bzflag.org/league/index.php?link=teaminfo&id=689/ Bz-Incorporated])
* ##bzflagr (Support channel for the [http://bzflagr.net BZFlagr.net servers.])
* #bzfx (Support channel for the bzfx.net BZFlag servers)
* ##bzpod (Channel to discuss the BZFlag podcast, BZPod)
* ##bzw (A place to discuss map making for BZFlag, including ideas and help)
* #divi (Support channel for [http://divi.fairserve.net Divibox] and other [http://fairserve.bzflag.org Fairserve] servers)
* #dub (Support channel for the dub.bzflag.org BZFlag servers)
* ##ducleague (Support channel for [http://my.bzflag.org/league/ Ducati League (DucLeague)])
* #forestforce ([http://gu.bzleague.com/index.php?link=teaminfo&id=10 GULeague Team])
* ##guleague (Support channel for [http://gu.bzleague.com/ GamesUnited League (GULeague)])
* #hepcat (Support channel for borrego.hepcat.org BZFlag server)
* ##icf (Support channel for [http://gu.bzleague.com/index.php?link=teaminfo&id=112 Incredible Chipper Frogs, (GULeague)])
* #inleague (Support channel for [http://in.bzleague.com InterNational League (INLeague)])
* #kas (GULeague team, KAS)
* ##norang (Support channel for [http://bzflag.norang.ca Norang.ca] BZFlag servers)
* #pillbox (Support channel for [http://pillbox.bzleague.com/ Pillbox League (PBLeague)])
* ##planetmofo (Support channel for [http://www.planet-mofo.com planet-mofo.com] servers)
* #plosileague (Support channel for [http://bzfx.net/league/ Plosileague])
* #silvercat (Support channel for [http://silvercat.bzflag.org/ Silvercat BZFlag servers])
* ##t42 ([http://gu.bzleague.com/index.php?link=teaminfo&id=39 GULeague team])
* ##untamed ([http://my.bzflag.org/league/index.php?link=teaminfo&id=909 DUCLeague team])

==IRC Clients==
To access the IRC network you need to use an IRC client, there are many IRC client softwares available for most operating systems.

http://irchelp.org/ is an excellent resource for more information on general IRC.

===Web IRC Interface===
The project provides a [http://my.BZFlag.org/irc/irc.cgi web based interface] to the main IRC channels. These are intended mostly for tech support issues, and the web interface is limited in the number of channels it can access.

==External links==
http://my.BZFlag.org/irc/irc.cgi

http://irchelp.org/

[[Category:Development]]
[[Category:Support]]

Google Summer of Code: 2008

2008-04-08T00:21:54Z

Constitution: The student application period has ended

The 2008 Google Summer of Code was announced on February 25, 2008. BZFlag has been accepted again this year as a mentoring organization. Given our enormously successful participation in the program in 2007, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag accepted student project proposals from March 24 until April 7 ending at 5:00 PDT (0:00 April 8 GMT). Further information on our proposal ideas are below. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available. '''''Accepted student proposals will be announced here and on the Google Summer of Code homepage on April 21 at around 12:00 PM PDT (19:00 GMT).'''''

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

Provided below is a promotional flyer to help spread the word about our involvement with the Google Summer of Code. Flyers are available in various languages that we have mentors for so that students from all over the globe can be informed about the program. While many developers can converse fluently in other languages, English is still expected for most developer discussions. Feel free to distribute the flyer around your local colleges and universities.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

High praise and special thanks to Harry Keller (aka Saturos) for designing our 2008 GSoC flyer.

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome and encouraged to apply with their own ideas. They should run those ideas by one of the developers beforehand to make sure they are consistent with the scope and focus of the project, though, as there are some ideas which will not be accepted regardless of the quality of the application and applicant. We've additionally provided several project ideas important to BZFlag development that we would very much like to see proposals for, shown in following.

Ideas marked with an "*" asterisk indicate entries where we have received at least two or more applicant submissions for that idea.

== Suggest your own idea ==
BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

== Cheat preventions ==
This task involves making BZFlag more robust towards preventing various cheats from working in the game. This task implicitly requires adding protections on the server, moving game logic from the client to the server, and/or adding heuristics and other measures for detecting and dealing with cheat clients. The student should have a strong grasp of the variety of BZFlag cheats that are available. Please go into detail about which cheats you're interested in preventing and how you intend to employ those preventive measures. For information on known cheats, check out the [[Known Cheats]] wiki page.

== Global authentication daemon ==
The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

== BZWorkBench world editor enhancement ==
As a participant in last year's program, Jude Nelson started work on BZWorkBench. It is a world file editor with a very solid foundation but much work still remains to be done, including a cross-platform GUI, mesh support, and other editor features. Ideally, two students would work on this. For example, one student could focus on improving the GUI's workflow and ease-of-use, and another could focus on finishing the back-end object manipulation.
The current GUI does not conform to a specific HIG, nor does its usability resemble many other 3D editors; this should change. The back-end still lacks support for many of the objects added in BZFlag 2.0, such as Meshes, texture matrices, dynamic colors, etc.

== Enhanced server listing ==
The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that is fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

== Modularization of game logic ==
Much of the game logic is presently mixed in with BZFlag's graphics code. This lack of organization make it difficult to find code when necessary, and does not allow bzfs, bzrobots, or other tools to utilize the game logic. The game code should be modularized into [[DevelopmentGoals#libGame|libgame]] so that all that is left in the client code is the graphics subsystem. This will also ease the possible future integration of a 3D graphics engine.

== Dead Reckoning and other Networking Enhancements ==
The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".

== Enhanced cross-platform multiple display support ==
Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

== Enhanced Statistics system ==
The goal of this idea would be to extend the existing web based statistics system to be more robust.

Features could include:

*Better integration with the list server.
*Use of a plug-in or server based stat "push" system instead of the current "pull" system.
*Better publishing of stats
*Publishing of recorded stat data to other sites.
*Better tracking of registered and unregistered players
*Tracking of leagues and individual match games.
*Generalizing the stats system to be used in other games/projects.

== Integrated BZFS web interface ==
The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. Please go into detail on how exactly you'd go about doing this.

== Network Testing and Simulation Environment ==
This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment.

== Cross server communications system ==
This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

== In-game profile management ==
BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

= Mentors =
The mentors for 2008 are;
* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

= Thanks & Appreciation =

Thank you to the following individuals in the BZFlag community that helped prepare GSoC-related marketing materials:

* Harry Keller (aka Saturos)
* Julio Jiménez Borreguero (aka jujibo aka Manu)
* Dexter Mason (aka whodaman)
* Sean Morrison (aka learner aka brlcad)
* Jeffrey Myers (aka JeffM)

[[Category: Development]]

Lag

2008-04-01T23:32:17Z

Constitution: Current version is 2.0.10

The term Lag is a shorthand version for the concept of [http://en.wikipedia.org/wiki/Lag Network Latency]. It represents the real world delay in sending messages from one computer to another over a network. All network connections have latency.

==Overview==
Lag is the network latency of a connection, or the time it takes for a network packet to travel from one host to another. Due to the speed of light, all network transmissions take some time, there is no such thing is a true "0" lag.

Different types of internet connections have different latency characteristics, dependent on the technologies they use. Most modern broadband systems ( like cable modems or DSL ) have a minimum latency that measures in a few milliseconds. Modems can have minimum latencies that measure in the 10s to 100s of milliseconds. The bandwidth rating of a network connection has little impact on it's minimum latency. A DSL line rated at 3 megabits in bandwidth often has the same latency as one rated at 1 megabit.

The distance along the network a message travels will also increase the time it takes to reach it's destination. The more hubs, routers, and switches the packets have to travel ( or hops ) will add additional time, as each hop takes some time to complete. Hosts that are more physically distant usually have more hops between them, due to the nature of the internet.

==Lag and BZFlag==
Latency affects real time games in a very specific manner. A message sent from one user to the server will take some time to reach the server. This means that by the time the server receives a position update from a player, that user may have (and probably has) already moved from that position. Additional time is spent sending the message from the server to the other players. Depending on the latency of the various network connections, each player will get the update message at a different real world time.

The short version of this is, when you get a message, the client isn't there anymore. This presents problems for messages that are time sensitive, such as positional updates, and shots.

The current version of BZFlag ([[BZFlag 2.0.10|v.2.0.10]]) does not do any type of latency compensation on player messages. This means that the player you see on your screen is not where he is on his screen. This can produce an error in the perceived game states between the 2 users. One user may shoot where he believes the other is, and in his view score a hit, while on the other user's screen he has moved away from the position and saw a clear miss. The first user simply has not received his new positional update yet, because it is in the middle of network transmission.

The BZFlag server has a method for measuring the latency of each client, and displaying it as a numeric value in milliseconds. You can check lag for all players by using the command '''/lagstats''' while playing (just send '''/lagstats''' as a chat message). Lagstats shows an approximation of the amount of time it takes for a network message to go back and forth from one player to the server and back again, not the amount of time it takes to go from one player to another player. For example, if you fire a shot, your client sends a message to the server, giving shot direction and speed. The server then relays this information to all the other clients.

Other lag-related problems are "missing" or "dropped" packets and "jitter". These can occur if there are more severe network problems which cause messages between players and the server to simply get lost, or to be delayed by inconsistent amounts of time. In an attempt to keep this explanation simple, these problems will not be covered here, other than to say that they compound the effects of lag to an even higher degree.

Lag affects what you see while playing BZFlag, especially if the delay is high. The most common effect seen is "shots going through other tanks." Many times you will hear players say "my shot went through you", or "why didn't you die." Many people have been accused of cheating due to the sometimes misunderstood effects of lag.

== Fixing Lag ==
How to fix lag depends on what is causing it.

=== Slow Internet Connection ===
Lag can be caused by a slow internet connection, such as dial-up. In that case, find a server that is more allowing, or get a better connection.

=== Satellite Internet ===
Satellite internet is far too laggy for BZFlag. Sorry.

=== Automatic Updates ===
Make sure software is not running scans for automatic updates in the background.

=== Downloads ===
Don't download something and play BZFlag at the same time.

=== Internet-intensive programs ===
Other programs, such as other people playing an online game on your network, can cause lag.

=== Distant Server ===
Try a different server. Often, lag is just caused by distance.

==The lag test program==
[[Image:Sample.png|thumb|200px|right|Chestal's lag-recording test program]]

On the right, is a capture from a test program created by Chestal. This test program allows us to accurately capture and replay events which occur in BZFlag. With a small modification to the BZflag client program, it is possible to log tank movements and shots to a file. This file can then be analyzed with a special visualization program. In this sample, you can see two tanks, surrounded by circles which are their 'hit-zones'. Any shots which intersect the hit-zone circle should result in an exploding tank! The green tank represents the player who was logging, other tank(s) are always red. Here, the green tank was lucky enough to avoid both shots by squeezing between them!

NOTE: The tools mentioned here are not generally available, due to the large size of the log files created, and requirements of the visualization tool. There was some progress on this (automatic playback, height indicator, map displaying, callsigns) but the results are not available to the public, either.

===A real, common example of lag.===

Here is a rather common example of a near-miss (no tanks exploded in this sequence). This is a real example, not an illustration. All three tankers were running the special logging client described above, and these images visualize all three captured logs at approximately the same moment. Note that even though lag was relatively low (all players were below 100ms), these captures show that each player sees something a bit different. Keep in mind that the green tank in each image is the one who's log is being shown. Click on any image for a full screen capture of the visualization tool.

[[Image:Smallb.png|thumb|262px|right|Tank B's View]]
TANK B's LOG:

Here we see tank B's point of view. From here, we see a shot which appears to hit tank A. In fact from this tank's point of view, it clearly does hit tank A.

(Note: Tank B lag was approx. 50ms)

[[Image:Smalla.png|thumb|262px|right|Tank A's View]]
TANK A's LOG:

And, here is tank A's point of view. The shot here has missed tank A. Keep in mind that tank A is moving forward here.

(Note: Tank A lag was approx. 90ms)

[[Image:Smallc.png|thumb|262px|right|Tank C's View]]
TANK C's LOG:

Tank C sees something similar to what tank B saw.

(Note: Tank C lag was approx. 25ms)

===So, what happened?===

'''Probably the most important factor to keep in mind here is that it is a player's OWN client which determines when he/she is hit,''' as it has the most accurate representation of its own tank location. Your tank's position is calculated locally, without any lag.

So, tank A did not explode, because it 'knew' that it had moved forward to avoid the shot. Due to the delay from lag, tanks B and C still saw tank A at its old position which had occurred a little over 1/10 second ago, so it '''appeared''' to them that the shot went through.

In conclusion, not only can understanding lag make you a better player, but it can also explain why shots seem to go through other tanks. In general, your shots will be much more accurate if you compensate for lag by shooting where you opponent will be in 100ms, or whatever you and your opponent's combined lag is. Of course, if your opponent is constantly switching directions, this can be difficult.

[[Category:Client]]
[[Category:Server]]

Lag

2008-04-01T23:29:49Z

Constitution: Fix parenthesis

The term Lag is a shorthand version for the concept of [http://en.wikipedia.org/wiki/Lag Network Latency]. It represents the real world delay in sending messages from one computer to another over a network. All network connections have latency.

==Overview==
Lag is the network latency of a connection, or the time it takes for a network packet to travel from one host to another. Due to the speed of light, all network transmissions take some time, there is no such thing is a true "0" lag.

Different types of internet connections have different latency characteristics, dependent on the technologies they use. Most modern broadband systems ( like cable modems or DSL ) have a minimum latency that measures in a few milliseconds. Modems can have minimum latencies that measure in the 10s to 100s of milliseconds. The bandwidth rating of a network connection has little impact on it's minimum latency. A DSL line rated at 3 megabits in bandwidth often has the same latency as one rated at 1 megabit.

The distance along the network a message travels will also increase the time it takes to reach it's destination. The more hubs, routers, and switches the packets have to travel ( or hops ) will add additional time, as each hop takes some time to complete. Hosts that are more physically distant usually have more hops between them, due to the nature of the internet.

==Lag and BZFlag==
Latency affects real time games in a very specific manner. A message sent from one user to the server will take some time to reach the server. This means that by the time the server receives a position update from a player, that user may have (and probably has) already moved from that position. Additional time is spent sending the message from the server to the other players. Depending on the latency of the various network connections, each player will get the update message at a different real world time.

The short version of this is, when you get a message, the client isn't there anymore. This presents problems for messages that are time sensitive, such as positional updates, and shots.

The current version of BZFlag ([[BZFlag 2.0.8|v.2.0.8]]) does not do any type of latency compensation on player messages. This means that the player you see on your screen is not where he is on his screen. This can produce an error in the perceived game states between the 2 users. One user may shoot where he believes the other is, and in his view score a hit, while on the other user's screen he has moved away from the position and saw a clear miss. The first user simply has not received his new positional update yet, because it is in the middle of network transmission.

The BZFlag server has a method for measuring the latency of each client, and displaying it as a numeric value in milliseconds. You can check lag for all players by using the command '''/lagstats''' while playing (just send '''/lagstats''' as a chat message). Lagstats shows an approximation of the amount of time it takes for a network message to go back and forth from one player to the server and back again, not the amount of time it takes to go from one player to another player. For example, if you fire a shot, your client sends a message to the server, giving shot direction and speed. The server then relays this information to all the other clients.

Other lag-related problems are "missing" or "dropped" packets and "jitter". These can occur if there are more severe network problems which cause messages between players and the server to simply get lost, or to be delayed by inconsistent amounts of time. In an attempt to keep this explanation simple, these problems will not be covered here, other than to say that they compound the effects of lag to an even higher degree.

Lag affects what you see while playing BZFlag, especially if the delay is high. The most common effect seen is "shots going through other tanks." Many times you will hear players say "my shot went through you", or "why didn't you die." Many people have been accused of cheating due to the sometimes misunderstood effects of lag.

== Fixing Lag ==
How to fix lag depends on what is causing it.

=== Slow Internet Connection ===
Lag can be caused by a slow internet connection, such as dial-up. In that case, find a server that is more allowing, or get a better connection.

=== Satellite Internet ===
Satellite internet is far too laggy for BZFlag. Sorry.

=== Automatic Updates ===
Make sure software is not running scans for automatic updates in the background.

=== Downloads ===
Don't download something and play BZFlag at the same time.

=== Internet-intensive programs ===
Other programs, such as other people playing an online game on your network, can cause lag.

=== Distant Server ===
Try a different server. Often, lag is just caused by distance.

==The lag test program==
[[Image:Sample.png|thumb|200px|right|Chestal's lag-recording test program]]

On the right, is a capture from a test program created by Chestal. This test program allows us to accurately capture and replay events which occur in BZFlag. With a small modification to the BZflag client program, it is possible to log tank movements and shots to a file. This file can then be analyzed with a special visualization program. In this sample, you can see two tanks, surrounded by circles which are their 'hit-zones'. Any shots which intersect the hit-zone circle should result in an exploding tank! The green tank represents the player who was logging, other tank(s) are always red. Here, the green tank was lucky enough to avoid both shots by squeezing between them!

NOTE: The tools mentioned here are not generally available, due to the large size of the log files created, and requirements of the visualization tool. There was some progress on this (automatic playback, height indicator, map displaying, callsigns) but the results are not available to the public, either.

===A real, common example of lag.===

Here is a rather common example of a near-miss (no tanks exploded in this sequence). This is a real example, not an illustration. All three tankers were running the special logging client described above, and these images visualize all three captured logs at approximately the same moment. Note that even though lag was relatively low (all players were below 100ms), these captures show that each player sees something a bit different. Keep in mind that the green tank in each image is the one who's log is being shown. Click on any image for a full screen capture of the visualization tool.

[[Image:Smallb.png|thumb|262px|right|Tank B's View]]
TANK B's LOG:

Here we see tank B's point of view. From here, we see a shot which appears to hit tank A. In fact from this tank's point of view, it clearly does hit tank A.

(Note: Tank B lag was approx. 50ms)

[[Image:Smalla.png|thumb|262px|right|Tank A's View]]
TANK A's LOG:

And, here is tank A's point of view. The shot here has missed tank A. Keep in mind that tank A is moving forward here.

(Note: Tank A lag was approx. 90ms)

[[Image:Smallc.png|thumb|262px|right|Tank C's View]]
TANK C's LOG:

Tank C sees something similar to what tank B saw.

(Note: Tank C lag was approx. 25ms)

===So, what happened?===

'''Probably the most important factor to keep in mind here is that it is a player's OWN client which determines when he/she is hit,''' as it has the most accurate representation of its own tank location. Your tank's position is calculated locally, without any lag.

So, tank A did not explode, because it 'knew' that it had moved forward to avoid the shot. Due to the delay from lag, tanks B and C still saw tank A at its old position which had occurred a little over 1/10 second ago, so it '''appeared''' to them that the shot went through.

In conclusion, not only can understanding lag make you a better player, but it can also explain why shots seem to go through other tanks. In general, your shots will be much more accurate if you compensate for lag by shooting where you opponent will be in 100ms, or whatever you and your opponent's combined lag is. Of course, if your opponent is constantly switching directions, this can be difficult.

[[Category:Client]]
[[Category:Server]]

Google Summer of Code: 2008

2008-03-07T00:14:01Z

Constitution: /* Cheat preventions */

The Google Summer of Code 2008 was announced on February 25, 2008. Given our enormously successful participation in the program in 2007, BZFlag plans to reapply to participate in the program in 2008. If accepted, BZFlag will accept student project proposals from March 24 to March 31 ending at 5:00 PDT (0:00 April 1 GMT). Further information on the application proccess and some proposal ideas are below.

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

Provided below is a promotional flyer to help spread the word about our involvement with the Google Summer of Code. Flyers are available in various languages that we have mentors for so that students from all over the globe can be informed about the program. While many developers can converse fluently in other languages, English is still expected for most developer discussions. Feel free to distribute the flyer around your local colleges and universities.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

High praise and special thanks to Harry Keller (aka Saturos) for designing our 2008 GSoC flyer.

= Preparing an Application =

There is specific format to applications, but students should be detailed in their approach and background information about themselves. They should state specifically what they intend to deliver and any implementation details they feel relevant such as what language they intend to use. C/C++ proposals are preferred though others will be considered. Students that just submit the summaries contained below will not do very well. If you talk with us on IRC about your SoC proposal, you should include your IRC nickname somewhere in your proposal.

Early proposal submission are encouraged as it gives us more time to review your proposals in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline will not be a negative consideration as all submissions will be predominantly judged on their merit, but submitting and discussing early is an advantage for submissions that are similar to other submissions.

Students are asked to propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Their ability to perform the task is outright presumed, so they are supposed to propose a task that they are comfortable and knowledgeable with performing.

= Program Evaluation =

All the applications we receive will be reviewed, evaluated, and critiqued. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult. ''This cannot be stressed enough.'' It will be really hard to narrow down the submissions but in the end we will have only so many slots to work with and the line will eventually need to be drawn. Every application will be read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to still see some of you become involved in our software development.

In the end, submissions will be selected according to the overall long-term impact that accepting the proposal could make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. Particular notice will be made of students that are responsive to questions and readily interactive in the IRC channel. Communication is a good thing.

While there's never any guarantee that work on any code will be integrated, this is very much the desire and '''intention''' of our participation in the Summer of Code. Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.

Biding BZFlag's acceptance into the program, the final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome to apply with their own original ideas. They should run those ideas by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.

Ideas marked with an "*" indicate entries where we have received at least two or more submissions for that idea.

== Dead Reckoning and other Networking Enhancements ==
The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".

== Modularization of game logic ==
Much of the game logic is presently mixed in with BZFlag's graphics code. This lack of organization make it difficult to find code when necessary, and does not allow bzfs, bzrobots, or other tools to utilize the game logic. The game code should be modularized into [[DevelopmentGoals#libGame|libgame]] so that all that is left in the client code is the graphics subsystem. This will also ease the possible future integration of a 3D graphics engine.

== Global authentication daemon ==
The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

== Enhanced server listing ==
The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that is fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

== BZWorkBench world editor enhancement ==
As a participant in last year's program, Jude Nelson started work on BZWorkBench. It is a world file editor with a very solid foundation but much work still remains to be done, including a cross-platform GUI, mesh support, and other editor features.

== Enhanced cross-platform multiple display support ==
Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

== In-game profile management ==
BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

== Integrated BZFS web interface ==
The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. Please go into detail on how exactly you'd go about doing this.

== Network Testing and Simulation Environment ==
This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment.

== Cross server communications system ==
This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

== Cheat preventions ==
This task involves making BZFlag more robust towards preventing various cheats from working in the game. This task implicitly requires adding protections on the server, moving game logic from the client to the server, and/or adding heuristics and other measures for detecting and dealing with cheat clients. The student should have a strong grasp of the variety of BZFlag cheats that are available. Please go into detail about which cheats you're interested in preventing and how you intend to employ those preventive measures. For information on known cheats, check out the [[Known Cheats]] and [[Subtle Cheats]] wiki pages.

== <INSERT YOUR IDEA HERE> ==
BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

= Thanks & Appreciation =

Thank you to the following individuals in the BZFlag community that helped prepare GSoC-related marketing materials:

* Harry Keller (aka Saturos)
* Julio Jiménez Borreguero (aka jujibo aka Manu)
* Dexter Mason (aka whodaman)
* Sean Morrison (aka learner aka brlcad)
* Jeffrey Myers (aka JeffM)

[[Category: Development]]

BZFlag 2.99

2008-03-05T02:48:49Z

Constitution: grammar fix

BZFlag version 3.0 is the next planned release of BZFlag.

==Overview==
Version 3.0 is currently in development and marked as version v2.99.x. Upon release it will be marked as version v3.0. The primary goals for this version are improved server side stability and security in an effort to minimize the impact of clients that have been modified to provide their users benefit ( aka, cheating ). Additional efforts are being made to extend the server side customization of the game. v3.0 will be completely incompatible with all previous versions of the game. Users of v3.0 will only be able to play on 3.0 servers. This is similar to how v2.0 was incompatible with 1.10.

==Development==
Development began on 3.0 on October 25th 2005. After an initial rush of changes, development stalled, as a number of bugs were found in the current release build of the time ([[BZFlag 2.0.4|v2.0.4]]). These bugs and problems, as well as a number of graphical changes from [[trepan]] necessitated the release of compatible [[BZFlag 2.0.6|v2.0.6]], [[BZFlag 2.0.8|v2.0.8]], and [[BZFlag 2.0.10|v2.0.10]] releases.

==Version Number Change==
v3.0 is the first version to use the new version numbering system. The 3.0 release initially began as the 2.1 development line, with the intent of being released as version 2.2. Part of the way through development, however, the [[Versions|versioning]] number scheme changed and the development revision changed from 2.1 to 2.99. With previous releases the minor version number in the version triplet (major.minor.revision) represented protocol and client compatibility. With 3.0 compatibility is instead reflected in the major version number. This new scheme gives more "room" to deal with minor packaging revisions and patch release updates.

==Features==
v2.99 already has a number of server side features that make for a much improved gameplay experience.
Features such as
*Flag pickups
*Identify
*Pausing
*Water Death
*Shot type
*Bots
have all been moved to the server, preventing a modified client from changing the outcome of the game logic. Additional features are planed to be moved server side, including shot, hit, and death detection.

A number of small checks and fixes have been put in to verify the game state as well.

Changes have been made to the graphical quality settings. What was Experimental quality in 2.0.8 is now High quality. Medium quality is between the old High and Medium, and Low has remained mostly unchanged.

The new Experimental mode includes new shot and flag graphics. Examples of the new shots (internally called, GeoBolt and GeoLaser) can be seen here.
<gallery>
Image:Geo_bolt_example1.jpg|A shot in experimental in 2.99
Image:Geo_bolt_example2.jpg|Another shot in experimental in 2.99
Image:Geo_laser_example1.jpg|The thief beam in 2.99
</gallery>
It should be noted that the new shot graphics are not for people with older or slower video cards.

A full list of changes can be found in the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/NEWS NEWS] file in the [[BZFlag Source]] code in [[BZFlag SVN|SVN]].

==Known Issues==
A lot of stuff needs testing, and probably doesn't work.

==Release Date==
As is always the case for major updates to BZFlag, '''''3.0 will be released when it is done'''''. At present, a number of major features still need to be implemented before a new release will be made.

==See also==
[[Versions]]

[[Category:Versions]]

Radar Marker

2008-03-03T06:46:33Z

Constitution: Spelling, fame->frame

{{DesignDocument}}
==Overview==
A radar marker is a generic radar specific object controlled by the server. It is used to flag things such as the location of team flags, and hunted targets. There is also a [[Radar Marker(object)|proposed map object]] that would allow maps to define arbitrary markers in the map.

==Contents==
The object will contain a sub-type and associated data.

The client will then display each subtype on the radar view only. Unknown sub-types will be ignored.
All 3d point data would be in world space, with the objects being drawn in Z order ( lowest to highest ) in orthographic projection with the map.

==Uses==
By taking the maker logic off of the server, we can make the logic be more customizable by the servers' game logic and plug-ins. Addin an option to tie a marker to the location of a specific moving object (tank) would allow for a number of gameplay variations.

==Implementation==
The client would only need to know how to draw a number of generic marker types ( various shapes ) in a server defined color. The server would simply send a marker message to the client with postional data ( and an attachment object if desired ). The client would then not need to know what this marker is, but simply store it and draw it every frame. Some radar marker types could also have HUD marker components ( flag and hunt ), this should be optional.

By using a separate message system for the markers that is not tied to the map file, the game can send out dynamic updates to the markers while the game is running. This can allow for additional game play modes such as domination, where the controlled base is flagged on the radar with the appropriate color.

[[category:proposed changes]]

Google Summer of Code: 2008

2008-03-03T06:30:05Z

Constitution: Add Modularization of game logic proposal idea

The Google Summer of Code 2008 was announced on February 25, 2008. Given our enormously successful participation in the program in 2008, BZFlag plans to reapply to participate in the program in 2008. If accepted, BZFlag will accept student project proposals from March 24 to March 31 ending at 5:00 PDT (0:00 April 1 GMT). Further information on the application proccess and some proposal ideas are below.

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

Provided below is a promotional flyer to help spread the word about our involvement with the Google Summer of Code. Flyers are available in various languages that we have mentors for so that students from all over the globe can be informed about the program. While many developers can converse fluently in other languages, English is still expected for most developer discussions. Feel free to distribute the flyer around your local colleges and universities.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

High praise and special thanks to Harry Keller (aka Saturos) for designing our 2008 GSoC flyer.

= Preparing an Application =

There is specific format to applications, but students should be detailed in their approach and background information about themselves. They should state specifically what they intend to deliver and any implementation details they feel relevant such as what language they intend to use. C/C++ proposals are preferred though others will be considered. Students that just submit the summaries contained below will not do very well. If you talk with us on IRC about your SoC proposal, you should include your IRC nickname somewhere in your proposal.

Early proposal submission are encouraged as it gives us more time to review your proposals in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline will not be a negative consideration as all submissions will be predominantly judged on their merit, but submitting and discussing early is an advantage for submissions that are similar to other submissions.

Students are asked to propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Their ability to perform the task is outright presumed, so they are supposed to propose a task that they are comfortable and knowledgeable with performing.

= Program Evaluation =

All the applications we receive will be reviewed, evaluated, and critiqued. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult. ''This cannot be stressed enough.'' It will be really hard to narrow down the submissions but in the end we will have only so many slots to work with and the line will eventually need to be drawn. Every application will be read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to still see some of you become involved in our software development.

In the end, submissions will be selected according to the overall long-term impact that accepting the proposal could make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. Particular notice will be made of students that are responsive to questions and readily interactive in the IRC channel. Communication is a good thing.

While there's never any guarantee that work on any code will be integrated, this is very much the desire and '''intention''' of our participation in the Summer of Code. Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.

Biding BZFlag's acceptance into the program, the final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome to apply with their own original ideas. They should run those ideas by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.

Ideas marked with an "*" indicate entries where we have received at least two or more submissions for that idea.

== Dead Reckoning and other Networking Enhancements ==
The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".

== Modularization of game logic ==
Much of the game logic is presently mixed in with BZFlag's graphics code. This lack of organization make it difficult to find code when necessary, and does not allow bzfs, bzrobots, or other tools to utilize the game logic. The game code should be modularized into [[DevelopmentGoals#libGame|libgame]] so that all that is left in the client code is the graphics subsystem. This will also ease the possible future integration of a 3D graphics engine.

== Graphics Engine Integration ==
One of the long-standing desires for BZFlag is to improve the graphics capabilities in the game by integrating with an existing rendering engine. This task would be to integrate BZFlag with a graphics engine like [http://ogre3d.org/ OGRE], [http://www.crystalspace3d.org/ Crystal Space], [http://www.openscenegraph.com/ OpenSceneGraph], or [http://irrlicht.sourceforge.net/ Irrlicht].

== Global authentication daemon ==
The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

== Enhanced server listing ==
The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that it fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

== BZWorkBench enhancement ==
As a participant in last year's program Jude Nelson started work on BZWorkBench, a world file editor with a very solid foundation. Much work remains to be done on the editor, including a cross-platform GUI and mesh support.

== Two-player tanks ==
Make modifications to the game such that it is optionally possible (e.g. via a server configuration) to allow multiplayer tanks where one player can only drive and the other can control the turret. The implementation would have to be some simple/intuitive interface to join and depart tanks as well as implemented in a fashion that preserves the "spirit" of BZFlag's operational simplicity.

== Enhanced cross-platform multiple display support ==
Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

== In-game profile management ==
BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

== Integrated BZFS web interface ==
The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. Please go into detail on how exactly you'd go about doing this.

== Network Testing and Simulation Environment ==
This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment.

== Cross server communications system ==
This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

== <INSERT YOUR IDEA HERE> ==
BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

= Thanks & Appreciation =

Thank you to the following individuals in the BZFlag community that helped prepare GSoC-related marketing materials:

* Harry Keller (aka Saturos)
* Julio Jiménez Borreguero (aka jujibo aka Manu)
* Dexter Mason (aka whodaman)
* Sean Morrison (aka learner aka brlcad)
* Jeffrey Myers (aka JeffM)

[[Category: Development]]

Google Summer of Code: 2008

2008-02-26T11:40:06Z

Constitution: Copied in some of the info and ideas from last year

The Google Summer of Code 2008 was announced on February 25, 2008. Given our enormously successful participation in the program in 2008, BZFlag plans to reapply to participate in the program in 2008. If accepted, BZFlag will accept student project proposals from March 24 to March 31 ending at 5:00 PDT (0:00 April 1 GMT). Further information on the application proccess and some proposal ideas are below.

= Preparing an Application =

There is specific format to applications, but students should be detailed in their approach and background information about themselves. They should state specifically what they intend to deliver and any implementation details they feel relevant such as what language they intend to use. C/C++ proposals are preferred though others will be considered. Students that just submit the summaries contained below will not do very well. If you talk with us on IRC about your SoC proposal, you should include your IRC nickname somewhere in your proposal.

Early proposal submission are encouraged as it gives us more time to review your proposals in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline will not be a negative consideration as all submissions will be predominantly judged on their merit, but submitting and discussing early is an advantage for submissions that are similar to other submissions.

Students are asked to propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Their ability to perform the task is outright presumed, so they are supposed to propose a task that they are comfortable and knowledgeable with performing.

= Program Evaluation =

All the applications we receive will be reviewed, evaluated, and critiqued. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult. ''This cannot be stressed enough.'' It will be really hard to narrow down the submissions but in the end we will have only so many slots to work with and the line will eventually need to be drawn. Every application will be read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to still see some of you become involved in our software development.

In the end, submissions will be selected according to the overall long-term impact that accepting the proposal could make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. Particular notice will be made of students that are responsive to questions and readily interactive in the IRC channel. Communication is a good thing.

While there's never any guarantee that work on any code will be integrated, this is very much the desire and '''intention''' of our participation in the Summer of Code. Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.

Biding BZFlag's acceptance into the program, the final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome to apply with their own original ideas. They should run those ideas by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.

Ideas marked with an "*" indicate entries where we have received at least two or more submissions for that idea.

== Dead Reckoning and other Networking Enhancements ==
The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".

== Graphics Engine Integration ==
One of the long-standing desires for BZFlag is to improve the graphics capabilities in the game by integrating with an existing rendering engine. This task would be to integrate BZFlag with a graphics engine like [http://ogre3d.org/ OGRE], [http://www.crystalspace3d.org/ Crystal Space], [http://www.openscenegraph.com/ OpenSceneGraph], or [http://irrlicht.sourceforge.net/ Irrlicht].

== Global authentication daemon ==
The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

== Enhanced server listing ==
The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that it fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

== BZWorkBench enhancement ==
As a participant in last year's program Jude Nelson started work on BZWorkBench, a world file editor with a very solid foundation. Much work remains to be done on the editor, including a cross-platform GUI and mesh support.

== Two-player tanks ==
Make modifications to the game such that it is optionally possible (e.g. via a server configuration) to allow multiplayer tanks where one player can only drive and the other can control the turret. The implementation would have to be some simple/intuitive interface to join and depart tanks as well as implemented in a fashion that preserves the "spirit" of BZFlag's operational simplicity.

== Enhanced cross-platform multiple display support ==
Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

== In-game profile management ==
BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

== Integrated BZFS web interface ==
The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. Please go into detail on how exactly you'd go about doing this.

== Network Testing and Simulation Environment ==
This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment.

== Cross server communications system ==
This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

== <INSERT YOUR IDEA HERE> ==
BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

= Promotion Flyers =

Harry Keller (aka Saturos) is working on creating a flyer which will be used to help spread the word about our involvement with the Google Summer of Code. Flyers will be translated to other languages that we have mentors for so that students from all over the globe can be informed about the program. While many developers can converse fluently in other languages, English is still expected for developer discussions.

[[Category: Development]]

Google Summer of Code

2008-02-26T10:47:03Z

Constitution: GSoC 08 is on, changed wording and listed timeline

Since 2005, Google has run an open source software development program specifically for students called the [http://code.google.com/soc/ Google Summer of Code] (GSoC). Under this program, Google funds students to write code for open source projects during the northern hemisphere's summer timeframe. The student efforts are focused on projects that they themselves propose to projects such as BZFlag, sometimes catering to ideas that the project suggests or ideas entirely of the student's own conception. Student proposals are then reviewed, evaluated, and ranked by the project. Google allocates a certain number of slots to each participating project/organization which in turn determines how many student developers we get to work with.

= BZFlag participation =

== [[Google Summer of Code/2008|2008 (more details here)]] ==

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will likely continue to participate in the program of course per our mentoring capacity to successfully interact with students and Google's renewed approval of BZFlag's participation. Mentoring organizations may apply for participation between March 3 and March 12, and the accepted organizations will be announced on March 17. If accepted as a mentoring organization, BZFlag will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|128px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}
BZFlag first participated during GSoC's third year in 2007. A detailed after-the-fact discussion and analysis of BZFlag's first-year participation is included in the article ''[http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf “Postmortem” Perspectives of a First-year Participant in the 2007 Google Summer of Code for BZFlag]''. This article was given to Google in August 2007 as a final report, per se, of our involvement (you're only a first-year participant once).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

= Preparing an application =

There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what they intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) are intended to be used. Fwiw, C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. Students that just submit simple vague descriptions or reiterate the topic ideas we suggest with no detail will be outright disregarded.

Early proposal submission are encouraged as it gives us more time to review the proposal in detail, comment on it, potentially ask for additional input, and iterate with the student on their ideas. In the past, submitting closer to the deadline hasn't been a negative consideration as all submissions are predominantly judged on merit, but submitting and discussing early is an advantage for submissions that have similar goals.

Students should propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Their ability to perform the task is outright presumed by the nature of submitting a detailed application, so students should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.

= The application process =

Just about every GSoC project receives considerably more project proposals than can be accepted. Each proposal is reviewed, evaluated, and critiqued. Of those applications, only a small subset are selected so keep in mind that the selection process is rather competitive and difficult. ''This cannot be stressed enough..'' It remains rather hard for most projects to narrow down the submissions but in the end we all only have so many slots to work with and the line eventually has to be drawn. Every application gets read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal to work on BZFlag.

In the end, submissions are selected according to the overall long-term impact that accepting the proposal can make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel. Communication is a good thing.

While there's never any guarantee that work on any code will be integrated, this is very much the desire and one of the core '''intentions''' of participation in the Summer of Code. Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.

= Integrated development =

Students that participate with the BZFlag project are required to adhere to specified [[Google Summer of Code Acceptance|development requirements]], selected students then work on their projects through the summer. Students are expected to be fully integrated with the BZFlag development community throughout the program, actively engaged in their work, and intently working ''with'' the other BZFlag developers throughout the design and implementation of their projects. If the student successfully completes what they propose, they are ultimately paid $4500 for their work and the BZFlag community hopefully gains a new long-term developer. In all, the program is a pretty darn good deal for many students, great publicity and marketing for both Google and BZFlag, and a great opportunity for BZFlag development initiatives.

Thanks for your interest and we look forward to seeing students apply!

[[Category: Development]]

BZFlag Project

2008-01-16T00:17:38Z

Constitution: Jeff is an admin again; put him back

The Project Administrators are users responsible for maintaining the global network services of the project.

==Current Administrators==
The current administration staff for the SourceForge project includes:
*[[Tim Riker]]
*[[David Trowbridge]]
*[[Sean Morrison]]
*[[Jeff Myers]]

[[Category:Concepts]]

BZTourney

2007-11-22T03:26:15Z

Constitution: Oops, make the link show.

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===SVN===
The project uses an SVN repository for managing code, maps, web content, etc. relating to the tournament. Public SVN access is available using the following command:
svn co <nowiki>http://bztournament.net/svnroot</nowiki>
Commit access to the repository is granted to most project contributers. If you have something to contribute, and desire commit access, please ask on the ##bztourney IRC channel (see above). Web access to the repository is available at http://bztournament.net/viewvc/?root=bztourney.

===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-11-22T03:24:42Z

Constitution: New ViewVC URL

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===SVN===
The project uses an SVN repository for managing code, maps, web content, etc. relating to the tournament. Public SVN access is available using the following command:
svn co <nowiki>http://bztournament.net/svnroot</nowiki>
Commit access to the repository is granted to most project contributers. If you have something to contribute, and desire commit access, please ask on the ##bztourney IRC channel (see above). Web access to the repository is available at [http://bztournament.net/viewvc/?root=bztourney].

===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-11-22T03:02:53Z

Constitution: Update SVN URL, remove AAA's project

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===SVN===
The project uses an SVN repository for managing code, maps, web content, etc. relating to the tournament. Public SVN access is available using the following command:
svn co <nowiki>http://bztournament.net/svnroot</nowiki>
Commit access to the repository is granted to most project contributers. If you have something to contribute, and desire commit access, please ask on the ##bztourney IRC channel (see above). Web access to the repository is available at [http://bztournament.net/viewvc http://bztournament.net/viewvc].
===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

DevelopmentGoals

2007-11-15T00:03:11Z

Constitution: BZWorldBuilder is BZWorkBench

This page describes the development goals for the project. It is a set of desired features, problem areas, wishlist items that define the general direction that the developers feel the project should be taken in.

==Tools==

BZFlag has a number of sub-tool projects, each with there own needs.

===BZWorkBench===
BZWB is a world/map editor that was completed for the 2007 Google Summer of Code program that BZFlag participated in. It is mostly functional but lacks a number of features, including.

* A UI that is usable.
* Mesh support

===ModelTool===
Model tool needs to tessellate strips and fans into faces when the mesh is used with regular geometry.

==Services==

The public services offered by the project are also open for development.

===List Server===
The list server that is in use now is considered by many to "suck". A new list server/authentication system that can work using some sort of distributed network system to allow for redundancy would be greatly desired.

Proposals have included:
* Re-writing the existing php list server to be more efficient.
* Using MYSQL syncing features to split up the server.
* Using LDAP for authentication
* Moving away from PHP/Apache to a real compiled daemon.
* moving away from HTTP to a more efficient TCP protocoll.

===Group Management===
The current system of using phpbb to manage user groups is proving to be logisticaly dificult given the large number of servers and the groups that their server owners desire. A more user centric group management system would be a large help.

A full spec for the system can be found at [[Group Management System]]

===Main Website===
A more data driven site would be beneficial, as well as integrated user management.

===Game Statistics===
A more push oriented stats system is desired.

==Codebase==

===libGame===
As much game code as possible needs to be generalized into a lib game and be shared by the client and server.

===Cleanups===
The current codebase has a number of files/functions that need to be broken up for better reuse and maintainability, these include.
* bzfs.cxx
* playing.cxx

==Game server==

===Authoritative Server State===
The game server needs to keep full track of where every player and every shot is. This state needs to be pushed out as the authortive state to all clients. The server needs to also verify all input according to the current game's rules. This state needs to include at least the following;

* Player position
* shot positions and paths
* death and shot ends.
* Player/world collision verification

Part of this is described in the [[Server Updated Shots]] design document.

===Server Side players===
Need to be finished.

===Server side logic for as many actions as possible===
The game server should provide the logic for as many events/actions as possible, such as flag capturing, death on hit, and others.

==Game Client==

===Graphics system split===
The graphics subsystem of the game client needs to be split out and made into it's own module that can be optionally built in. This will help standalone bots.

===Graphics Engine Evaluations===
Existing third party graphics engines/libraries need to be evaluated to see if they would provide the game with significant features. Engines such as OGRE, Crystal Space, and Open Scene Graph look promising.

BZFlag 2.0.10

2007-10-05T22:02:18Z

Constitution: Updates from ChangeLog

BZFlag version 2.0.10 is a future version of the BZFlag game that is hoped to be released in October of 2007. It is primarily intended to fix a number of small issues that have been found in 2.0.8 and provide good binary packages for the various Linux distributions.

==Tag And Code Freeze==
On September 17th at 14:00 PST, the code for v2_0branch was frozen for the build of 2.0.10RC1. Binary builds for this version were posted on the BZFlag forums at http://my.bzflag.org/bb/viewtopic.php?t=11480

==Proposed Names==
The proposed names for the release are as follows
* "Never Say Never"
* "Sasquatch"
* "He Says He's Not Dead"
* "The missing child"

==Backports implemented from 2.1==
The following lists the backported features pulled from 2.1 into 2.0.10RC1

* Add /modcount command - Joshua Bodine
* Implemented Confine Mouse for Windows platforms - Daniel Remenak
* Implemented fullscreen->windowed mode toggle on Windows - Daniel Remenak
* Jitter Kick - Thomas Stauer
* Fixed cross-platform and 64-bit network protocol bug - Andrew McNabb
* Packetloss Kick - Thomas Stauer
* First map no longer ignored in Start Server menu - Ravu al Hemio
* Updated zlib to version 1.2.3 - Sean Morrison
* Added optional delay before the countdown gets resumed - Thomas Stauer

==Current Change Log==
* Fix bug where users get locked into autopilot mode - Joshua Bodine
* Fix bug where poll results would not be announced - Joshua Bodine
* Fix antikill notice bug - Joshua Bodine
* Add -adminlagannounce and -lagannounce - Thomas Stauer
* Check for talk permission for part/quit messages - uso
* First map no longer ignored in Start Server menu - Ravu al Hemio
* Implemented Confine Mouse for Windows platforms - Daniel Remenak
* Implemented fullscreen->windowed mode toggle on Windows - Daniel Remenak
* Add the rabidRabbit plugin - LouMan
* Add packet loss kick and related admin commands - Thomas Stauer
* Reclaim lost memory from sound sample - Tupone Alfredo
* Fixed bashism on debian rules - Ryan Kavanagh
* Add the rabbitTimer plugin - L4m3r
* Fix some segfaults when re-joining - Tupone Alfredo
* Compliance with gcc-4.2 - Tupone Alfredo
* Fix the build system to be more distro friendly - Tupone Alfredo
* Plugins get flag resets/spawns/grab/drop/transfer - Jeff Myers, Bernt Hansen
* Fix compiler problem with gcc-4 - Tupone Alfredo
* Fixed high fps problem - Frank Thilo
* Added more info for observers - Jeff Myers, Frank Thilo
* torBlock plugin added - Jeff Myers, blast007
* Use mesh position and height for radar - Thomas Stauer
* Add the regFlag plugin - Bernt Hansen
* Fix memory leak from cURL - blast007
* Add the Phoenix plugin - Jeff Myers
* Add favorite server - Frank Thilo
* SDL sound rate fix - Alfredo Tupone
* add bzID and server status to logDetail plugin - Bernt Hansen
* Add -tkannounce to announce tk on admin channel - Bernt Hansen
* Add the serverControl plugin - Bernt Hansen
* Add keepaway plugin - LouMan
* API calls to reset bzdb - Jeff Myers
* API call to get the player pause state. - Jeff Myers
* API calls to reload bans, and other files - Jeff Myers
* API event for shot ends - Jeff Myers
* API command to move a flag - Jeff Myers
* add API exposure for lag, jitter, and packetloss - Jeff Myers
* Add koth plugin - LouMan
* Add timedctf plugin - LouMan
* Add teamflagreset plugin - LouMan
* Add wwzones plugin - LouMan
* flagStay plugin added - Jeff Myers
* Give everyone notice of pause messages - Jeff Myers
* Fix for /silence command - Skeeve
* Fix mousebox edge positioning - Mark Thomas
* Fixed on spanish localization - xukosky@yahoo.es
* Instructions to fix sound on ALSA added - Tupone Alfredo
* Change filename format for easier location of matches - uso
* Adding jitter kick and related admin commands - Thomas Stauer
* Add optional delay before the countdown gets resumed - Thomas Stauer
* Global banlist reload with local banlist - uso
* Fix to spawned and lag attributes in bz_updatePlayerData - Matthew Marshall
* Ability to change the killer in a PlayerDieEvent - Matthew Marshall
* Added shotID to bz_PlayerDieEventData - Matthew Marshall
* Expose the countdown and game time stuff to the api - Jeff Myers
* Backport the record stop function from 2.1 - Jeff Myers
* Backported WW GMs from 2.1 - Matthew Marshall
* Converts box & pyramids to mesh if required - Anonymous
* Allows leading face specification (x+,x-,y+,y-,z+,z-) - Anonymous
* Authorization is invariant to case - Anonymous

[[Category:Versions]]
[[Category:Releases]]
[[Category:Development]]

BZTourney

2007-10-01T03:18:05Z

Constitution: SVN ViewVC info

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''BZFlagr'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===SVN===
The project uses an SVN repository for managing code, maps, web content, etc. relating to the tournament. Public SVN access is available using the following command:
svn co <nowiki>svn://bztournament.net/bztourney</nowiki>
Commit access to the repository is granted to most project contributers. If you have something to contribute, and desire commit access, please ask on the ##bztourney IRC channel (see above). Web access to the repository is available at [http://bztournament.net/viewvc http://bztournament.net/viewvc].
===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Scoring algorithm===
''Category:'' Plugins/Web

''Description:'' We will need to develop a method for allocating and tracking player scores. This will be especially true for non-FFA games, where points should be allocated for carrying/capturing flags, etc.

''Stage:'' Planning

''Notes:''

''Assigned to:''
*'''AAA'''
===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-10-01T03:14:36Z

Constitution: SVN info

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''BZFlagr'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===SVN===
The project uses an SVN repository for managing code, maps, web content, etc. relating to the tournament. Public SVN access is available using the following command:
svn co <nowiki>svn://bztournament.net/bztourney</nowiki>
Commit access to the repository is granted to most project contributers. If you have something to contribute, and desire commit access, please ask on the ##bztourney IRC channel (see above).
===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Scoring algorithm===
''Category:'' Plugins/Web

''Description:'' We will need to develop a method for allocating and tracking player scores. This will be especially true for non-FFA games, where points should be allocated for carrying/capturing flags, etc.

''Stage:'' Planning

''Notes:''

''Assigned to:''
*'''AAA'''
===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-09-30T21:13:25Z

Constitution: Communication/Planning section

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Communication/Planning==
Discussion and planning for the event takes place on the ##bztourney IRC channel on the Freenode IRC network. A website is under construction, and once configured it will be another resource for collaborating efforts on the event.
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''BZFlagr'''
*'''norang'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===Web Site===
www.bztournament.net
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Scoring algorithm===
''Category:'' Plugins/Web

''Description:'' We will need to develop a method for allocating and tracking player scores. This will be especially true for non-FFA games, where points should be allocated for carrying/capturing flags, etc.

''Stage:'' Planning

''Notes:''

''Assigned to:''
*'''AAA'''
===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-09-29T08:23:57Z

Constitution: Scoring algorithm from AAA

BZTourney is a potential collaborative tournament put on by the combined efforts of several server networks. It is currently planned to be a one-time event.
==Overview==
Plans for how the tournament will be organized, which gamestyles will be used (or new ones to be created), how scores will be attributed and judged, etc. are currently underway. Please feel free to contribute ideas!
==Server Organizations==
The following server organizations have agreed to be named as sponsors of this tournament. Please add your server organization name here if you plan to contribute.
*'''[[BZFX]]'''
*'''Divibox'''
*'''BZFlagr'''

==Oversight/Administration==
Oversight of the planning and development proccess will take place under the watchful eyes of the leaders of the member server organizations. There are currently no plans to have ''one person'' be given ultimate authority over the project.

In-game administrative privileges will be granted to the project leaders and to those admins who are most-trusted (as agreed upon by the project leaders). Due to the importance of selecting admins with integrity that will not act inappropriately in the middle of the tournament, only
admins who are highly-trusted will be selected.
==Maps==
According to the current plan, one or more maps will be created from scratch for this tournament. We are hoping to acquire the skills of four or five (or more!) mappers to create these maps, and will be looking for users to test them once they've reached the appropriate stage.
==Infrastructure==
A project like this will require a lot of work to setup. The following are some ideas for features we'd like to see in these categories.
===Web Site===
Web site.
===Plugins===
Plugins
===Scripting===
Scripting.
==Task List==
''If you think something needs to be done, please add it here. To sign up to help with something, please add your name below it. All entries should be in the following format:''

===Scoring algorithm===
''Category:'' Plugins/Web

''Description:'' We will need to develop a method for allocating and tracking player scores. This will be especially true for non-FFA games, where points should be allocated for carrying/capturing flags, etc.

''Stage:'' Planning

''Notes:''

''Assigned to:''
*'''AAA'''
===Sample Idea===
''Category:'' Mapping/Plugins/Scripting/Web/etc.

''Description:'' Description of idea.

''Stage:'' Planning/Implementing/Completed

''Notes:'' Any notes.

''Assigned to:''
*'''Contributer1'''
*'''Contributer2'''

BZTourney

2007-09-28T22:58:39Z

Constitution: Initial edit

BZFlag 2.0.10

2007-09-08T07:38:29Z

Constitution: issues were in 2.0.8, not 2.0.10

BZFlag version 2.0.10 is a future version of the BZFlag game that is hoped to be released in October of 2007. It is primarily intended to fix a number of small issues that have been found in 2.0.8 and provide good binary packages for the various Linux distributions.

==Proposed back ports from 2.1==

To help on merging see the [http://my.bzflag.org/~atupone/CommitList-2.1 2.1 commit list]

===Implemented===
* Implemented Confine Mouse for Windows platforms - Daniel Remenak
* Implemented fullscreen->windowed mode toggle on Windows - Daniel Remenak
* Jitter Kick - Thomas Stauer
* Fixed cross-platform and 64-bit network protocol bug - Andrew McNabb
* Packetloss Kick - Thomas Stauer
* First map no longer ignored in Start Server menu - Ravu al Hemio
* Updated zlib to version 1.2.3 - Sean Morrison

===Approved===
* fixed issues on some SMP Linux systems due to bad timekeeping - A. W. Wright
* Fixed framerate jitter-inducing bug on SMP systems - Sean Morrison
* Researched and updated BZFlag contributors documentation - Sean Morrison
* Callsign bans are now handled case-insensitively - Sean Morrison

===Possible===
* Anti-aliased rendering option - Snick
* Fixed map line ending parse bug for flag zones - Jeff Myers
* Added optional delay before the countdown gets resumed - Thomas Stauer
* increased joystick button support to 32 buttons - Markus\
* framerate independent keyboard turn dampening - Sean Morrison, randomparticle
* improved French localization - Christophe Henry

==Current Change Log==
* Add the rabidRabbit plugin - LouMan
* Add /packetlosswarn and /packetlossdrop - Thomas Stauer
* Fixed memory loss for sound sample - Tupone Alfredo
* Fixed invalid kick speed - Tupone Alfredo
* Add packet loss kick - Thomas Stauer
* Fix a segfault when re-joining - Tupone Alfredo
* Add the rabbitTimer plugin - L4m3r
* Fix a segfault when re-joining from observer - Tupone Alfredo
* Fix the build system to be more distro friendly - Tupone Alfredo
* Fixed high fps problem - Frank Thilo
* API calls to reset bzdb - Jeff Myers
* API call to get the player pause state. - Jeff Myers
* API calls to reload bans, and other files - Jeff Myers
* API event for shot ends - Jeff Myers
* API command to move a flag - Jeff Myers
* add API exposure for lag, jitter, and packetloss - Jeff Myers
* Add koth plugin - LouMan
* Add timedctf plugin - LouMan
* Add teamflagreset plugin - LouMan
* Add keepaway plugin - LouMan
* Add wwzones plugin - LouMan
* fix compiler problem with gcc-4 - Tupone Alfredo
* torBlock plugin added - Jeff Myers
* flagStay plugin added - Jeff Myers
* Give everyone notice of pause messages - Jeff Myers
* Fix for /silence command - Skeeve
* Fix mousebox edge positioning - Mark Thomas
* Fixed on spanish localization - xukosky@yahoo.es
* Instructions to fix sound on ALSA added - Tupone Alfredo
* Change filename format for easier location of matches - uso
* Adding jitterdrop - Thomas Stauer
* Adding jitterkick - uso
* Global banlist reload with local banlist - uso
* Added more info for observers - Jeff Myers
* Fix to spawned and lag attributes in bz_updatePlayerData - Matthew Marshall
* Ability to change the killer in a PlayerDieEvent - Matthew Marshall
* Added shotID to bz_PlayerDieEventData - Matthew Marshall
* Expose the countdown and game time stuff to the api - Jeff Myers
* Backport the record stop function from 2.1 - Jeff Myers
* Backported WW GMs from 2.1 - Matthew Marshall
* Converts box & pyramids to mesh if required - Anonymous
* Allows leading face specification (x+,x-,y+,y-,z+,z-) - Anonymous
* Authorization is invariant to case - Anonymous

[[Category:Versions]]
[[Category:Releases]]
[[Category:Development]]

BZFS in a chroot jail

2007-04-21T04:37:50Z

Constitution: correct capitalization

BZFS in a chroot jail is a concept where a [[BZFS]] server is run on a host computer in a very secure environment, preventing it from having access to any other parts of the host system.

==Overview==
Installing the BZFLAG Server (bzfs) in a ‘sandbox’ or a ‘jail’ on Linux by using the features provided with chroot is an advanced method for setting up a server. It offers additional security for the hosting server. For general information on setting up a server see [[Creating A Server]].

This method has been tested on Redhat 8 and 9 systems. Other Linux distributions should work in a similar manner.

==Background==
Before attempting to set up BZFS in a chroot jail it is best to have a little background in using the chroot command. The best place to start is reading the man page
man chroot
but the basic concept is to run a program in a directory and force it to think that it is the root (the top) of the filesystem (the ‘sandbox’ or ‘jail’), so that if the application was ever compromised, only it’s folder would be accessible to the attacker and not the entire filesystem. User root, or any program with root privileges can break out of a chroot jail. Users should be ware that a badly configured chroot jail might even be a larger security problem then not running one. The application jk_check from http://olivier.sessink.nl/jailkit does checks to verify if your chroot jail is safe.

Before a program can be run in a jail, the user must make sure that the program has all dependencies that it may need. This means creating a smaller copy of the root filesystem so that the program can access the files that it needs, and knows where to find them. This means that if a program requires a library in /lib, then we will need a lib directory with those libraries in our jail. (if this is confusing – hang in there, you will see an example below).

== Just tell me how to do it!! ==

Let’s say we have already compiled and installed (via RPM or source) bzflag in /usr/share/bzflag (or wherever you installed it), and we want to have it run in a jail.

I like to create a folder in the root of the filesystem called chroot, and then place folders in there for everything that I am running in a jail. This helps me to keep track of which programs/services/applications I am running in a jail easily. I also don’t like creating jails in system directories (in this case it would be /usr/share or wherever you installed it).

I would, for example, create a folder like /chroot/bzflag.
I would then copy the actual executable in a bin folder. So know we have:
/chroot/bzflag/
/chroot/bzflag/bin
/chroot/bzflag/bin/bzfs (the bzfs executable in the jail’s bin directory).
Now we need the dependency files – how do we know which files bzfs depends on? Run ‘ldd –v /usr/bin/bzfs’ (or where ever you installed bzfs to when you compiled it. NOTE: that this is the real one and not the one you copied to the jail) and you should get something like (on Redhat 9 systems):
$ ldd -v bzfs
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40034000)
libm.so.6 => /lib/tls/libm.so.6 (0x400e7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40109000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Version information:
./bzfs:
libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
libstdc++.so.5 (CXXABI_1.2) => /usr/lib/libstdc++.so.5
libstdc++.so.5 (GLIBCPP_3.2) => /usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5:
libgcc_s.so.1 (GCC_3.0) => /lib/libgcc_s.so.1
libc.so.6 (GLIBC_2.2) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/tls/libc.so.6
/lib/tls/libm.so.6:
libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
/lib/libgcc_s.so.1:
libc.so.6 (GLIBC_2.2.4) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/tls/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6
/lib/tls/libc.so.6:
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2}}}
This is where the ‘mini root’ filesystem comes in. For every file listed in the output of the ldd command – copy those files to the jail into the appropriate directory. The jailkit package at http://olivier.sessink.nl/jailkit/ contains a utility jk_cp that can be used to automatically copy all dependencies of a file into a jail.
mkdir /chroot/
jk_cp /chroot/ /bin/bzfs

Make sure you get all of them or bzfs will complain that it is missing something later on. On Redhat 9 there is a /lib/tls directory, on Redhat 8 these same libraries were in /lib/i686 – so you will have to substitute the proper directories here for wherever your system expects them. Use the exact same path as outputted by ldd. So you should copy something similar to (create the directories as needed):
/chroot/bzflag/usr/lib/libstdc++.so.5 (copied from /usr/lib)
/chroot/bzflag/lib/libgcc_s.so.1 (copied from /lib)
/chroot/bzflag/lib/tls/libm.so.6 (copied from /lib/tls)
/chroot/bzflag/lib/tls/libc.so.6 (copied from /lib/tls)
/chroot/bzflag/lib/ld-linux.so.2 (copied from /lib)

BZFS also needs libraries to resolve DNS names to IP addresses (to register itself with the list server), and so you will need these extra libraries that are not reported through ldd (copy from /lib to your corresponding jail directory):
/lib/libnss_dns.so.2 -> /chroot/bzflag/lib/libnss_dns.so.2
/lib/libresolv.so.2 -> /chroot/bzflag/lib/libresolv.so.2

You will also need an etc directory with the resolv.conf file in it so that the above libraries know which DNS server they need to contact in order to resolve things, so copy from /etc into your corresponding jail directory:
/etc/resolv.conf -> /chroot/bzflag/etc/resolv.conf

and now the hard part is done…

Again this bit can be done easier using jailkit:
jk_init /chroot/ netbasics

Here is the complete listing of what your jail should look like or be similar to (in the case of the lib directory which will change from Linux version/distro I am sure – it already changed just from Redhat 8 to 9):
$ ls -alFR ./bzflag/
./bzflag/:
total 24
drwxr-xr-x 6 root root 4096 Jul 12 08:12 ./
drwxr-xr-x 3 root root 4096 Jul 12 07:24 ../
drwxr-xr-x 2 root root 4096 Jul 12 07:25 bin/
drwxr-xr-x 2 root root 4096 Jul 12 08:29 etc/
drwxr-xr-x 3 root root 4096 Jul 12 08:34 lib/
drwxr-xr-x 3 root root 4096 Jul 12 08:26 usr/

./bzflag/bin:
total 188
drwxr-xr-x 2 root root 4096 Jul 12 07:25 ./
drwxr-xr-x 6 root root 4096 Jul 12 08:12 ../
-rwsr-sr-x 1 nobody nobody 179160 Jul 12 07:25 bzfs*

./bzflag/etc:
total 12
drwxr-xr-x 2 root root 4096 Jul 12 08:29 ./
drwxr-xr-x 6 root root 4096 Jul 12 08:12 ../
-rw-r--r-- 1 root root 54 Jul 12 08:29 resolv.conf

./bzflag/lib:
total 252
drwxr-xr-x 3 root root 4096 Jul 12 08:34 ./
drwxr-xr-x 6 root root 4096 Jul 12 08:12 ../
-rwxr-xr-x 1 root root 103044 Jul 12 08:20 ld-linux.so.2*
-rwxr-xr-x 1 root root 30324 Jul 12 08:20 libgcc_s.so.1*
-rwxr-xr-x 1 root root 18416 Jul 12 08:25 libnss_dns.so.2*
-rwxr-xr-x 1 root root 76552 Jul 12 08:23 libresolv.so.2*
drwxr-xr-x 2 root root 4096 Jul 12 08:16 tls/

./bzflag/lib/tls:
total 1740
drwxr-xr-x 2 root root 4096 Jul 12 08:16 ./
drwxr-xr-x 3 root root 4096 Jul 12 08:34 ../
-rwxr-xr-x 1 root root 1549556 Jul 12 08:16 libc.so.6*
-rwxr-xr-x 1 root root 211876 Jul 12 08:16 libm.so.6*

./bzflag/usr:
total 80
drwxr-xr-x 3 root root 4096 Jul 12 08:26 ./
drwxr-xr-x 6 root root 4096 Jul 12 08:12 ../
drwxr-xr-x 2 root root 69632 Jul 12 08:02 lib/

./bzflag/usr/lib:
total 776
drwxr-xr-x 2 root root 69632 Jul 12 08:02 ./
drwxr-xr-x 3 root root 4096 Jul 12 08:26 ../
-rwxr-xr-x 1 root root 710608 Jul 12 08:02 libstdc++.so.5*
== More Security ==

Since you have to execute chroot as root, bzfs will run as root – which is not what we want. We can force bzfs to run as nobody by changing his ownership to nobody, and setting the sticky bit on him. This way, when root executes /chroot/bzflag/bin/bzfs – it is executed as nobody, and therefore has very little privileges on the system.

This is how we do that:
chown nobody.nobody /chroot/bzflag/bin/bzfs
chmod +s /chroot/bzflag/bin/bzfs

But this changes only the effective user id, not the real user id. A safer way to do this is to make use of the jk_chrootlaunch utility in jailkit (http://olivier.sessink.nl/jailkit/), it will drop all privileges, and then execute as user nobody, without any possibility to regain root privileges, because both the effective AND the real user id are now changed to nobody.

jk_chrootlaunch -j /chroot/bzflag/ -x /bin/bzfs –d –d –d –d –public TestServer –publicaddr <your_public_ip_address:port>

== Testing ==

Run a command like the following (as root),
chroot /chroot/bzflag/ /bin/bzfs –d –d –d –d –public TestServer –publicaddr <your_public_ip_address:port>

It will log any errors to /var/log/daemon.log

This is where all the magic of chroot happens. And this command should make sense to you as you read the man page, right :) If not, the command basically takes 2 arguments. The first is the "new root" (/chroot/bzflag/). The second is the command to run. Notice that we specify /bin/bzfs to run bzfs, and not /chroot/bzflag/bin.

You should see something similar to:
$ chroot /chroot/bzflag/ /bin/bzfs -d -d -d -d -public test -publicaddr 65.39.216.149:5155
style: 0
Opening List Server 0
listening on 0.0.0.0:5155

ADD 65.39.216.149:5155 2 BZFS107e 000000c800010000000000000000000000c800c800c800c800c800000000000000000000 test

Closing List server 0
Player [0] accept() from 208.186.182.172:47076 on 7
Player [0] shutdownAcceptClient: close(7)

If you don’t or get an error like “failed http ...” – then a resolv/dns library or the resolv.conf in etc can’t be found – copy them again check your spelling and any paths and try again…

The next thing to verify is that bzfs is really running as nobody and not as root. Start bzfs in the background this time ($ chroot /chroot/bzflag/ /bin/bzfs -d -d -d -d -public test -publicaddr <your_public_ip_address_here>:<your_server_port> &), and then ‘ps aux | grep –i bz’ and look for at the user bzfs is running as.

You should see something like:
$ ps aux | grep -i bz
nobody 2930 0.1 1.3 3032 1668 pts/1 S 09:49 0:00 [bzfs]
root 2932 0.0 0.5 3568 628 pts/1 S 09:49 0:00 grep -i bz

if all this works, then you are done.

You might also want to double check that your server did register itself with the main listserver – there are 2 ways to do this.

The first is through bzflag – open the client and browse through the servers with the “find server” otion, and see if yours is listed.

The second – and the method I prefer as it is faster, is to just open a web browser up to the list server. The current one is http://208.186.182.172:5156/. You should see your server listed in this list when you start (register) and stop (unregister) your bzfs server. I keep this open in a browser and just refresh it when stopping and starting the bzfs server.

== Misc ==

I use config files for each server that I run, and keep all the download the maps in separate directories.

I keep all my config file in a conf dir. For example /chroot/bzflag/conf/

I also keep all my (not mine, but the ones I downloaded :) ) in a map dir like: /chroot/bzflag/maps

You may want to create some startup scripts that start your server up automatically in case it reboots. I use a separate rc file for this for simplicity. One could create an init script and then use chkconfig to call it in rc3.d, but I am lazy and haven’t done that.

I simply declared in my rc.local (which is loaded last anyways and as such all network systems will be available when it is called) to execute rc.bzfs which I have in /etc/rc.d/rc.bzfs.

In my rc.bzfs, I have sections for each server I am running. One such section I have looks like:
#FreeForAll config
echo >>/var/log/bzfsFFA.log
echo >>/var/log/bzfsFFA.log
echo `date` >>/var/log/bzfsFFA.log
chroot /chroot/bzflag/ /bin/bzfs -d -conf /conf/q-net.conf >> /var/log/bzfsFFA.log 2>&1 &

This way I can ‘tail –f’ the log file in /var/log, and see what’s going on as all output (errors, standard output – everything) is directed to this file. This will also start it up in the background, and so it will keep going even when you log off. Every time I kill the process and start it using this script, I get 2 empty lines and the date when I issued the command in the log file – this way I can trace it and see. I also start bzfs using the –d option. This outputs more stuff, but not too much, to the log files. I get to see who connected and their current IP’s so if I get a complaint about a person cheating, I can see their callsign and their last IP and monitor it. I can also see who issues the /password command and know if my admin password is compromised.

The weakness that this rc.bzfs startup file has is that you can’t just shut down one server (if you host multiple servers on your box) and start it back up again easily. I have started creating sub scripts for this reason. One script for each server that I run. That way all I have to do is to kill the process and run that one script and everything is OK. I keep these scripts in the bin folder of the jail along with bzfs and make them executable. Since they all call bzfs, you don’t have to make their owner nobody.nobody or have their sticky bit set..

== The End ==
I hope this is useful to people out there, as a bit of time went into it to figure out just which files are needed to run bzfs in a jail. I started out with the entire /lib copied over, and got it working with the minimal files listed above.

==See also==
[[BZFS]]

==External Links==
http://olivier.sessink.nl/jailkit

[[Category:Server]]
[[Category:Server Security]]