BZFlagWiki - User contributions [en]

Talk:BZFX

2013-11-12T04:12:25Z

Bullet Catcher: Reverted edits by 178.150.106.88 (talk) to last revision by JeffM2501

== DonnyBaker's page removal ==

I don't see why BZFX can't have extended information. It is relevant to BZFlag and a major server network. It's also in a convenient place to find - not everyone knows about the BZFX web-site. --[[User:A Meteorite|A Meteorite]] 18:47, 5 April 2007 (EDT)

As I stated in my rollback. The information you have is suited for a BZFX website, not BZFlag. The 'majorness' of your network is pretty much an opinion, yours. I will do the same to any other "Network" that posts information that belongs on their own website. --[[User:DonnyBaker|DonnyBaker]] 20:52, 5 April 2007 (EDT)

The 'majorness' of your network is pretty much an opinion, yours. I will do the same to any other "Network" that posts information that belongs on their own website. [[User:DonnyBaker|DonnyBaker]] 20:52, 5 April 2007 (EDT)

Wait, what? Opinion? Rules are not opinion. Group information is not opinion. Those are all things BZFX and BZFX rules, which are facts '''to BZFX''' (which is what the article is '''about'''). I never say BZFX is a major server network on the wiki page either, because that is opinion. The other stuff is facts to BZFX. Plus some of this is important information and might possibly only get the exposure it needs on this wiki. --[[User:A Meteorite|A Meteorite]] 21:59, 5 April 2007 (EDT)

:Any network should be treated as if it were a league - basic information only (website, irc channel...etc). On the leagues page it does not go into full explanation of what the league is; just the basics. -[[User:Tanner|Tanner]] 22:30, 5 April 2007 (EDT)

::If I so choose to have more information about BZFX, why not? Information is good. The more the merrier. If this is because BZFX's page has more info than a league page, that is really lame. The league owners - or even players - could add more info so as long as it's not opinion. --[[User:A Meteorite|A Meteorite]] 22:44, 5 April 2007 (EDT)

:[[User:A Meteorite|A Meteorite]] the information you present adds nothing to BZFlag... it is valuable to BZFX and therefore belongs on the BZFX web page. You are more than welcome to put the link to that site here (which you did). If people are interested in your rules and who your admins/cops are they can go to your website where you have full control of the content. As for the opinion comment, and I quote: "[[User:A_Meteorite|A Meteorite]] believed that no well-created and managed unified BZFlag server network existed. He believed he could do it better, and others have believed in him and BZFX. Since BZFX has been founded and taken off, several pieces of software has been in development for the higher furthering of BZFlag servers." Sounds like a bunch of chest beating to me, and that is not what the wiki is for. There are several "Networks", as you call them and they will get the same treatment if and when they post items like this. The fight is over, the page is protected and is noted on the page. --[[User:DonnyBaker|DonnyBaker]] 06:06, 6 April 2007 (EDT)

"[[User:A_Meteorite|A Meteorite]] believed that no well-created and managed unified BZFlag server network existed. He believed he could do it better, and others have believed in him and BZFX. Since BZFX has been founded and taken off, several pieces of software has been in development for the higher furthering of BZFlag servers."
::That part can be removed, if is what it takes to be able to have rules and such. --[[User:A Meteorite|A Meteorite]] 01:06, 7 April 2007 (EDT)

I am hard pressed to see how the rules of your server and the admins adds something for the BZFlag community. This is great information for '''your''' website, but not here. Keep it on your website so that anyone who might be interested can find it. The groups are bound to be dynamic as you add and remove people and having them on your server gives you one place to manage it. As for how you enforce '''your''' rules, again that is for '''your''' web site. The link has been established between the wiki and your site, that is what is necessary. The wiki is a place for information the affects the entire community and the documentation of BZFlag, your rules and admins affect your servers only and don't really belong here. --[[User:DonnyBaker|DonnyBaker]] 07:26, 7 April 2007 (EDT)

The wiki is not a replacement for an informational website. IT should contain basic information on the network, server, whatever, and then links to where to get more info. The article can contain historical facts that may be of interest. Mostly the server/network articles are here to provide links for users to get more info. They are not duplicates for ease of use. Met, chill, Donny, when you have user issues please contact the project administration first before you begin to discuss resolutions. - [[User:JeffM2501]] 12:15, 8 April 2007 (PST)

== Before any further edits to this page: ==

Before anyone else edits this article, they should read the [[Content Policy]] for the wiki.
This page is not to be an advertisement, for BZFX, it is simply to contain descriptive information about the network, and links to further information about it.

Master-ChildAccountSystem

2013-02-13T05:28:48Z

Bullet Catcher: spelling, grammar, note a BZID complication

{{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 the 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 deleted and all saved data flushed from the system.

Master accounts will have the option of creating a limited 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? What about when they turn 13?). 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 shown 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]]

Development RoadMap

2012-08-05T21:32:06Z

Bullet Catcher: /* 2.4.0 (Wake the dead) */ 2.4 -> 2.4.0

==Overview==
This document discusses the general development road-map for Future BZFlag Releases.

===Features===
Individual features may move up or down the roadmap depending on how/when they get done. Entire releases may be pushed up the roadmap or merged depending on how development goes.

==Current Development Target==
The current development target (trunk) is the [[DevelopmentPlans/2.4.2|2.4.2]] release

==2.4==
'''Goals:''' Get a release out

2.4 will be the next release of BZFlag and is protocol incompatible with all previous versions.
===2.4.0 (Wake the dead)===
Released on 2011/07/03 [[BZFlag 2.4.0]]

===2.4.2===
[[DevelopmentPlans/2.4.2|Planning page for 2.4.2]]

2.4.2 will be the first maintenance release of the 2.4.x compatibility line. It does contain some bug fixes but it's primary function is to provide an updated package for the debian system. It does include non breaking items that were not ready during the initial release including:

* Fastmap
* Ensure bzadmin on Windows gets built with PDCurses

===2.4.4===
[[DevelopmentPlans/2.4.4|Planning page for 2.4.4]]

2.4.4 will be a bug fix maintenance release of the 2.4.x compatibility line. Its primary function is to fix bugs found in the 2.4.0/2 releases and to include non breaking items that were not ready during the initial release including:

* All the horrible things we missed
* BZFScron
* Push Stats
* Joystick fixes
* CIDR/subnet bans from Filter.cxx

===2.4.6===
* New Death effects
* HTTP Management plugins
* Bug fixes
* New Font System
* New Server List
* New Translations
* Download Authorization Dialog
* GM lock-on markers on the radar.
* Fix mac .app build system (make it just use a script not xcode?)
* Sever side IP/Host/callsign (not perm base) mute
* Graphic tank on radar at high zoom
* Evaluate rabbit logic.
* how to deal with third party libs in plugins, specialy ones we build optionaly.
* command line options that have -set <name> <value> equivalents should be reviewed and possibly eliminated
* bzfs should error out if no users or groups have SPAWN
* Teach Roger not to drive into deadly physics drivers
* Test anti permissions.
* Translation update push.
* Set app icon for as many OSs as possible (SDL does not do this)
* Case insensitive bans.
* Block spamers on rejoin (using BZID?)
* Max chat rate (using filters?) with auto scilence. (maybe a plugin?)
* Windows BZAdmin cleanup ( eval if it works the same as linux)
* Sanity check list server input ( players over limit, etc..)
* Extend player name cycling (like on /kick and /ban) to /poll kick and /poll ban
* When game is over, autoboot everyone after some time, so server cannot be blocked forever by one player just sitting there.

===2.4.x (Maintenance)===
Continuing releases to fix critical bugs. New features should go into 2.6 at this point.

==2.6 (Next Breaking Release)==
'''Goals:''' Continue Development and cleanup gameplay.

This version may be rolled into the 3.0 release if that code base is still usable. If the code is extended from 2.4 it may have these features;
* Lua (Client side)
* Acceleration changes
* Flag Drop "Zone" feature
* XFire ?
* OpenAL/Support, OGG, Hardware mixing and 3d (replace platform audio?)
* Solution for dropped shots (TCP? confirm message? logging?)
* Tank parts? Customization? [[CustomTanks]]
* Team After Join?
* More colors in OFFA?
* Dialogs and prompts?
* Eval ID and ID label markers (MMO style? Always show teammates?)
* Graphics settings cleanup, optimize for GF2 or newer. Make low good for GMA chipsets.
* List server indication of game options that are per object or zone ( rico, jump, etc..)
* Server List showing that games require ID ( cool little icon?)
* Use BZID for all saved user identifiers not names.
* Cleanup MOTD into optimal system ( using db?).
* Grouping for links (with relative and absolute names)
* Grouping for weapons and entry zones (with transforms)
* Grouping for physics drivers (with transforms and copying)
* Grouping for texture matrices, dynamic color, xforms, and materials
* Extern cleanup
* Vector class use instead of float[3]
* Incorporate the player's handicap value and physic drivers into the check calculations.
* Decide what a GM is and how it should behave when guided when the user has or does not have the flag, and how the lock should work with ST and CL
* -noSelfKills server option at [https://sourceforge.net/tracker/?func=detail&aid=3537226&group_id=3248&atid=353248 tracker]

==3.0 (Next Major)==
'''Goals:''' Get back to where V3 wanted to be.

Using the 2.99 continuing branch, or the 2.6 branch with a lot of back-ports depending on code-base stability.

* Have BZFS convert all world objects into mesh representations for consistent client collisions.
* Point in Polyhedron tests to remove inside/outside points.
* New Simulation
* Shot Type/Flag Type split
* Things added in previous versions that were not back-ported from the codebase this release uses.
* Lobby
* Support additional map objects inside definitions ([https://sourceforge.net/tracker/?func=detail&aid=2938335&group_id=3248&atid=103248 SF Bug 2938335])

===3.0.2===
'''Goals:''' End user experience

Compatible release ( if possible ) that makes the game easier for new users to play and for servers to manage players.
* UI Cleanup
* New Group and User Management.
* In game registration
* Tutorials
* Option to kick to observer.
* Make the texture manager give out IDs and have everyone use the ID, not the image pointer, as it can change. Or make the image pointer self updating.
* Binding keys to multiple actions (lua macros?)

==3.2==
'''Goals:''' Modernization

Goals for this release are to bring the game's networking and simulation system up to par with modern games.
* Lag compensation
* Threaded Networking
* Threaded Simulation
* UI customization
* General Resource Updates and Downloads (sounds, scripts etc..)?
* HTF as real mode
* IPV 6

==3.4==
'''Goals:''' Server State

* Server Side Radar
* Server Side Shots (Iterative octree cell shot collision detection)
* Server Side Deaths
* Server Side Bot API and good bot samples
* Removal of Client Side Logic
* Generic Simulation serialization for recordings that are independent of network format.
* Third party networking?

==4.0==
'''Goals:''' Graphics Upgrades

* Third party graphics engine? Ogre? Irrlicht? lightfeather?
* Patching?
* Shader/Material Support?
* OpenGL 2+?
* Better Lighting, light objects in maps ( shaders or projected textures?)
* A library of "smart server side bots"

==5.0==
'''Goals:''' Extensibility

* Server defined game logic and settings
* Game mode plug-ins/scripts on the server
* Server defined graphics elements ( shots, models, etc)
* List server separation by game mode
* Require Registration and limit server choices until verified?
* Social Components for players ( player ratings, facebooklike stuff?)
* League Integration

DevelopmentPlans/2.3

2012-08-05T21:30:47Z

Bullet Catcher: 2.4 -> 2.4.0

=Note=
2.3 was released as [[BZFlag_2.4.0|2.4.0]], the documentation contained here was just a worksheet and does not represent the final list of features released.

==Overview==
BZFlag 2.3 was the development version released as 2.4.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.

==Release==
[[BZFlag_2.4.0|2.4.0]] was released on July 3, 2011 and will be maintained as per the [[Development_RoadMap]]

==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==
* Move trunk to a v2_99_branch. '''Complete'''
* Copy v2_0branch to trunk and change protocol number. '''Complete'''
* Change the version docs to make compatibility be the minor version number. '''Complete'''
* 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. '''Complete'''
* When proposals are in and accepted by consensus, start the 1-month countdown clock.'''Complete'''
* Implement accepted proposals and test.'''In progress'''
* Document server upgrade process for the many server owners. '''In progress''' ''Thumper by 6/20/2011''
* If release is not stable by 6/17/2011 revert changes that made it unstable.
* Public beta on 6/20/2011
* Public RC on 6/27/2011
* Release on 6/30/2011

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

===Assignments and tracking===
Task tracking is managed via a google spread sheet that can be found here.

https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0Agca59DESlNKdC1CSUtUMUhiSldrOVVPSHcwQUNzOUE&output=html

Developers with assigned tasks can request edit access to the document on IRC.

===Timeline===
Project must be completed by June 14th 2011 or they will be rolled back and excluded from the release.

===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. Not all items were implemented in 2.4, check [[BZFlag_2.4.0|2.4.0]] release document for final release list.

* 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 '''Pimpinella'''
* [[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) '''JeffM'''
* Windows project cleanup '''JeffM'''
* New make system '''BulletCatcher'''
* New source docs (authors etc...) '''Constitution'''
* Server-side handicap '''Thumper'''
* Guided Missile shot checks '''Pimpinella'''
* 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''' (r14997, r15162, r15832)
* Message protection (ensure network messages are valid) '''A_Meteorite'''
* Add message types so that actions (/me) are properly implemented '''blast007''' (r19833)
* New artwork '''JeffM''' [[2.3_NewEffects|Effects Updates]]
* 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'''
* bzfs: Allow -time to have an ending time '''blast007'''

====New Changes====
* Round Robin for services '''JeffM'''
* 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'''
* Import client customization settings from the 2.0 config.cfg file to the 2.4 version
* Implement new version numbering system into code. (/src/date/buildDate.cxx and DEVINFO at least, there might be more places where it is needed)

===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 '''mdskpr'''
* HTTP plugins '''JeffM'''
* New API events '''JeffM'''
* Custom flag system '''DTRemenak'''
* BZFSCron '''Thumper'''
* Server Side Players '''JeffM'''
* Bug fixes not in notes '''Thumper'''
* Hunter as proper team '''mdskpr (grabbed by DTRemenak)'''
* bzfs -publickey '''trepan'''
* push stats as default

====New Changes====
* Countdown/reload timer position fix for when showCoordinates is enabled '''mdskpr'''
* SVN props cleanup '''BulletCatcher'''
* 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.

* New flags
* Network buffering
* 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)
* Website changes.

==Known Issues==
===Empty Flag Types===
When you start BZFS with +f good{2} the server will generate 8 "empty" flag IDs in addition to all normal good flags (no flag type.)
This can be seen by doing '/flag show'. You can also '/flag give' the empty flag types, although all it seems to do is say "user: grabbed flag " in chat and make the flag pick-up noise - it doesn't actually give you a flag.

[[Category:Versions]]

2.4 Releases

2012-08-05T21:25:41Z

Bullet Catcher: /* Articles in category "Releases" */ 2.4 -> 2.4.0, add 2.4.2

Pages related to various releases of BZFlag.

== Articles in category "Releases" ==
These are the 37 releases of BZFlag, starting with the earliest.

* [[BZFlag 1.7c-1]]
* [[BZFlag 1.7c-2]]
* [[BZFlag 1.7c-2-1]]
* [[BZFlag 1.7c-2-2]]
* [[BZFlag 1.7c-2-3]]
* [[BZFlag 1.7d-1]]
* [[BZFlag 1.7d-2]]
* [[BZFlag 1.7d-3]]
* [[BZFlag 1.7d-4]]
* [[BZFlag 1.7d-5]]
* [[BZFlag 1.7d-6]]
* [[BZFlag 1.7d-7]]
* [[BZFlag 1.7d-8]]
* [[BZFlag 1.7d-9]]
* [[BZFlag 1.7e]]
* [[BZFlag 1.7e1]]
* [[BZFlag 1.7e2]]
* [[BZFlag 1.7e4]]
* [[BZFlag 1.7e6]]
* [[BZFlag 1.7g0]]
* [[BZFlag 1.7g2]]
* [[BZFlag 1.10.0]]
* [[BZFlag 1.10.2]]
* [[BZFlag 1.10.4]]
* [[BZFlag 1.10.6]]
* [[BZFlag 1.10.8]]
* [[BZFlag 2.0.0]]
* [[BZFlag 2.0.2]]
* [[BZFlag 2.0.4]]
* [[BZFlag 2.0.6]]
* [[BZFlag 2.0.8]]
* [[BZFlag 2.0.10]]
* [[BZFlag 2.0.12]]
* [[BZFlag 2.0.14]]
* [[BZFlag 2.0.16]]
* [[BZFlag 2.4.0]]
* [[BZFlag 2.4.2]]
[[Category:History]]

Versions

2012-08-05T21:23:11Z

Bullet Catcher: /* Released versions of BZFlag */ 2.4 -> 2.4.0, add 2.4.2

BZFlag 2.4.2

2012-08-05T21:18:38Z

Bullet Catcher: Fix link to page with previous version

BZFlag version 2.4.2 '''"Doomsday Edition"''' is the current maintenance version of the BZFlag game for Windows, Mac OS X, and Linux. It was released on 07/28/2012 and contains some new features that are compatible with the [[BZFlag 2.4.0]] release.

==Change Log==
The new features include:

*server UPnP support
*thiefControl plugin
*fairCTF plugin
*autoFlagReset plugin
*Fastmap plugin
*combined leading and lagging radar shot lines
*option for chat on the left and radar on the right
*joystick hat support

The full change log can be found at http://bzflag.svn.sourceforge.net/svnroot/bzflag/tags/v2_4_2/ChangeLog .

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

BZFlag 2.4.0

2012-08-05T21:15:48Z

Bullet Catcher: moved BZFlag 2.4 to BZFlag 2.4.0: Use the complete version number in the page name.

BZFlag version 2.4.0 '''"Wake the Dead"''', is the current maintenance version of the BZFlag game for Windows, Apple OSX, and Linux. It was released on 07/03/2011 after a long period of development inactivity.

This new version is incompatible with previous versions of the game. The primary goals of the release were to fix a number of bugs that required changes to the gaming protocol and clients as well as to get development moving again. It should be noted that this is the first version of BZFlag that had a development plan and release schedule.

The version contains a number of new features.

==Change Log==
Some of the major features include:

*The ability to turn off teamkilling on the server
*The OpenFFA game mode which is a teamless FFA, meaning you can shoot anyone regardless of color
*Per-object ricochet, which lets map authors selectively enable ricochet for individual objects
*Removal of local authentication
*Ability for the server to force flags to be hidden on the radar
*Fog can not be turned off
*The screenshot code does not lag the client badly anymore
*The ID flag identification was moved to the server
*Public servers must have a -publickey
*Polls only count users that are able to vote

The full changelog can be found at https://bzflag.svn.sourceforge.net/svnroot/bzflag/tags/v2_4_0/ChangeLog

==Upgrades==
2.4 has requires server owners to take note of a few upgrade steps in order to move from 2.0.x to 2.4

A general overview of the upgrade procedure can be found on the [[BZFS 2.4 Upgrade]] page.

===API===
The [[BZFS API]] received a major overhaul in 2.4 and is incompatible with older plug-ins, upgrade information can be found on the [[BZFS API 2.4 Upgrade]] page.

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

BZFlag 2.4.2

2012-08-05T21:14:05Z

Bullet Catcher: Created page with "BZFlag version 2.4.2 '''"Doomsday Edition"''' is the current maintenance version of the BZFlag game for Windows, Mac OS X, and Linux. It was released on 07/28/2012 and contains s..."

BZFlag version 2.4.2 '''"Doomsday Edition"''' is the current maintenance version of the BZFlag game for Windows, Mac OS X, and Linux. It was released on 07/28/2012 and contains some new features that are compatible with the [[BZFlag 2.4]] release.

==Change Log==
The new features include:

*server UPnP support
*thiefControl plugin
*fairCTF plugin
*autoFlagReset plugin
*Fastmap plugin
*combined leading and lagging radar shot lines
*option for chat on the left and radar on the right
*joystick hat support

The full change log can be found at http://bzflag.svn.sourceforge.net/svnroot/bzflag/tags/v2_4_2/ChangeLog .

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

Category:Leagues

2011-12-09T21:05:11Z

Bullet Catcher: the Pillbox and Fun leagues are defunct

== Active Leagues ==

To join a league click on one of the links below and register your callsign. Some leagues may require that you be added to a list by an admin before you are allowed to talk/spawn on match servers. Please use the same callsign for matching that you have register on the league site. Most of the IRC channels for each league are situated on the [http://freenode.net/ freenode] network. Please refer to [[BZFlag on IRC]] for help on using IRC.

=== Ducati League ===
Website: [http://league.bzflag.org/ http://league.bzflag.net/]

IRC Channel: [irc://irc.freenode.net/##ducleague ##ducleague]

Match Length: 15, 20 or 30 minutes

Rules: 2 shots, no jumping, ricochet, CTF, randomly generated map.

=== [[GU League]] ===
Website: [http://www.guleague.org/ http://www.guleague.org/]

IRC Channel: [irc://irc.freenode.net/##guleague ##guleague]

Match Length: 30 minutes.

Rules: 3 shots, jumping, ricochet, CTF, [[HiX]] map.

=== Open League ===
Website: [http://openleague.net/ http://openleague.net/]

IRC Channel: [irc://irc.freenode.net/#openleague.net ##openleague]

Match Length: 15, 20, 30, 45 or 60 minutes.

Rules: 3 shots, jumping , ricochet, CTF, [[babel]] or a map that changes every week (which can have different rules).

=== 1vs1 League ===
Website: [http://1vs1.bzflag.net/ http://1vs1.bzflag.net/]

IRC Channel: None.

Match Length: First to 10 kills.

Rules:
:classic & fancy style: -> FFA mode, 2 shots, ricochet, no jumping, no superflags, small randomly generated map
:hix style -> FFA mode, 3 shots, ricochet, jumping, no superflags, hix map

== Defunct Leagues ==

=== Pillbox League ===
Website: [http://pillbox.bzleague.com/ http://pillbox.bzleague.com/]

IRC Channel: [irc://irc.freenode.net/#pillbox #pillbox]

Match Length: 15, 20 or 30 minutes.

Rules: 3 shots, no jumping, no ricochet, CTF, pillbox map.

=== Fun League ===
Website: [http://fun.bzleague.com/ http://fun.bzleague.com/]

IRC Channel: None.

Match Length: Depends on which map you play on.

Rules: Depends on which map you play on.

=== BZSoccer League ===

Website: [http://bzsoccer.bzleague.com/ http://bzsoccer.bzleague.com/] *Note* Website has many bugs and will be fixed soon.

IRC Channel: ##divi

Match length: 15 minutes

Rules: 2 shots, jumping, ricochet, soccer field map.

Please note that this league is inactive. The league will be revived when the website is fixed.

=== Plosileague ===

Website: [http://bzfx.net/league/ http://bzfx.net/league/]

IRC Channel: [irc://irc.freenode.net/#plosileague #plosileague]

Match Length: 30 minutes or first to 5 caps and ahead of the other team by at least 2 caps

Rules: 3 shots, jumping, ricochet, CTF, [[overlord]] or [[babel]] map.

=== LavaHiX League ===
Website: [http://lavahix.wtwrp.de/ http://lavahix.wtwrp.de/]

IRC Channel: None.

Match Length: 15 minutes.

Rules: 3 shots, jumping, ricochet, CTF, [[HiX]] map with "lava" ground.

Events (API)

2011-11-10T05:08:03Z

Bullet Catcher: /* Events */ spell bz_eNetDataReceiveEvent correctly

{{BZFS_API_Doc}}
==Overview==
API events are callbacks that a [[Plug-ins|plug-in]] can install into [[BZFS]] to be called in response to specific actions or state changes in the server side game world. Events are the primary method of communication from BZFS to installed plug-ins. Specific events exist for nearly all logical actions that can happen during a game of BZFlag.

==Installation and Removal==
The callbacks for events are typically installed during the [[bz_Load]] (2.0.x) or [[Init]] (2.4+) entry point in a plug-in, so they can be active when a plug-in is first loaded.

The plug-in must call the function;

2.0.x
BZF_API bool [[bz_registerEvent]] ( bz_eEventType eventType, [[bz_EventHandler]]* eventHandler );

2.4+
Register ( bz_eEventType );

The plug-in registers and event callback derived from [[bz_EventHandler]] (2.0.x) or [[bz_Plugin]] (2.4+) for each specific event types it wishes to monitor.

When a plug-in no longer needs to monitor an event, or when it is unloaded in the [[bz_Unload]] (2.0.x) or [[Cleanup]] (2.4+) entry point, the plug-in must remove the installed callback by calling the function;

2.0.x
BZF_API bool [[bz_removeEvent]] ( bz_eEventType eventType, [[bz_EventHandler]]* eventHandler );

2.4+
Flush();

In BZFlag 2.4, events are no longer removed individually but instead they are all removed automatically by calling on the 'Flush()' method.

==Event Handler==
The plug-in must define a class that is derived from [[bz_EventHandler]] (2.0.x) or [[bz_Plugin]] (2.4+) and pass a pointer to an object of that class when ever it registers an event callback.

When ever a specific event is triggered, BZFS will call the 'process' (2.0.x) or 'Event' (2.4+) method of the installed callback class.

2.0.x
virtual void process ( bz_EventData *eventData ) = 0;

2.4+
virtual void Event ( bz_EventData *eventData ) = 0;

==Event Data==
With each call to the 'process' method of the installed event handler, BZFS will pass the plug-in a pointer to a class that contains all the data provided by the event. Each event derives a specific data class from [[bz_EventData]] that contains the specific member variables that contain the data. The base class [[bz_EventData]] contains the data member;
bz_eEventType eventType;
This data member allows a plug-in to identify the specific event and cast the 'bz_EventData' pointer to the appropriate specific data class. This is usefull for plug-ins that use the same 'bz_EventHandler' to process more then one specific message.

Please see the descriptions of each specific event for information and descriptions of the data classes for each event. Some specific events allow plug-ins to change the values of data members in the data class and will use the modified values instead.

Plug-ins should never delete or free the memory for a data class. BZFS will manage all pointers passed to plug-ins.

==Events==
The following list contains all the event types currently supported by BZFS version 2.99

[[bz_eAllowAutoPilotChangeEvent]]
[[bz_eAllowCTFCaptureEvent]]
[[bz_eAllowFlagGrabEvent]]
[[bz_eAllowKillCommandEvent]]
[[bz_eAllowPlayer]]
[[bz_eAllowSpawn]]
[[bz_eAnointRabbitEvent]]
[[bz_eAutoPilotChangeEvent]]
[[bz_eBZDBChange]]
[[bz_eBanEvent]]
[[bz_eCaptureEvent]]
[[bz_eFilteredChatMessageEvent]]
[[bz_eFlagDroppedEvent]]
[[bz_eFlagGrabbedEvent]]
[[bz_eFlagResetEvent]]
[[bz_eFlagTransferredEvent]]
[[bz_eGameStartEvent]]
[[bz_eGameStartEvent|bz_eGameEndEvent]]
[[bz_eGetAutoTeamEvent]]
[[bz_eGetPlayerInfoEvent]]
[[bz_eGetPlayerSpawnPosEvent]]
[[bz_eGetWorldEvent]]
[[bz_eHostBanModifyEvent]]
[[bz_eHostBanNotifyEvent]]
[[bz_eIdBanEvent]]
[[bz_eIdleNewNonPlayerConnection]]
[[bz_eKickEvent]]
[[bz_eKillEvent]]
[[bz_eListServerUpdateEvent]]
[[bz_eLogingEvent]]
[[bz_eLuaDataEvent]]
[[bz_eMessageFilteredEvent]]
[[bz_eNetDataReceiveEvent]]
[[bz_eNetDataSendEvent]]
[[bz_eNewNonPlayerConnection]]
[[bz_eNewRabbitEvent]]
[[bz_eNullEvent]]
[[bz_ePlayerAuthEvent]]
[[bz_ePlayerCollision]]
[[bz_ePlayerCustomDataChanged]]
[[bz_ePlayerDieEvent]]
[[bz_ePlayerJoinEvent]]
[[bz_ePlayerPartEvent]]
[[bz_ePlayerPauseRequestEvent]]
[[bz_ePlayerPausedEvent]]
[[bz_ePlayerSentCustomData]]
[[bz_ePlayerSpawnEvent]]
[[bz_ePlayerTeamChangeEvent]]
[[bz_ePlayerUpdateDoneEvent]]
[[bz_ePlayerUpdateEvent]]
[[bz_eRawChatMessageEvent]]
[[bz_eReloadEvent]]
[[bz_eReportFiledEvent]]
[[bz_eServerMsgEvent]]
[[bz_eShotEndedEvent]]
[[bz_eShotExpiredEvent]]
[[bz_eShotFiredEvent]]
[[bz_eShotRicochetEvent]]
[[bz_eShotStoppedEvent]]
[[bz_eShotTeleportEvent]]
[[bz_eSlashCommandEvent]]
[[bz_eTeleportEvent]]
[[bz_eTickEvent]]
[[bz_eUnknownSlashCommand]]
[[bz_eWorldFinalized]]
[[bz_eZoneEntryEvent]]
[[bz_eZoneExitEvent]]

The following list contains all the event types currently supported by BZFS version 2.4
[[bz_eAllowCTFCaptureEvent]]
[[bz_eAllowPlayer]]
[[bz_eAllowSpawn]]
[[bz_eBanEvent]]
[[bz_eBZDBChange]]
[[bz_eCaptureEvent]]
[[bz_eFilteredChatMessageEvent]]
[[bz_eFlagDroppedEvent]]
[[bz_eFlagGrabbedEvent]]
[[bz_eFlagTransferredEvent]]
[[bz_eGameEndEvent]]
[[bz_eGameStartEvent]]
[[bz_eGetAutoTeamEvent]]
[[bz_eGetPlayerInfoEvent]]
[[bz_eGetPlayerMotto]]
[[bz_eGetPlayerSpawnPosEvent]]
[[bz_eGetWorldEvent]]
[[bz_eHostBanModifyEvent]]
[[bz_eKickEvent]]
[[bz_eKillEvent]]
[[bz_eListServerUpdateEvent]]
[[bz_eLoggingEvent]]
[[bz_eMsgDebugEvent]]
[[bz_eMessageFilteredEvent]]
[[bz_eNetDataReceiveEvent]]
[[bz_eNetDataSendEvent]]
[[bz_eNewNonPlayerConnection]]
[[bz_ePlayerAuthEvent]]
[[bz_ePlayerDieEvent]]
[[bz_ePlayerJoinEvent]]
[[bz_ePlayerPartEvent]]
[[bz_ePlayerPausedEvent]]
[[bz_ePlayerScoreChanged]]
[[bz_ePlayerSpawnEvent]]
[[bz_ePlayerUpdateEvent]]
[[bz_ePluginLoaded]]
[[bz_ePluginUnloaded]]
[[bz_eRawChatMessageEvent]]
[[bz_eReportFiledEvent]]
[[bz_eServerMsgEvent]]
[[bz_eShotEndedEvent]]
[[bz_eShotFiredEvent]]
[[bz_eSlashCommandEvent]]
[[bz_eTeamScoreChanged]]
[[bz_eTickEvent]]
[[bz_eUnknownSlashCommand]]
[[bz_eWorldFinalized]]
[[bz_eZoneEntryEvent]]
[[bz_eZoneExitEvent]]

There exists one additional event in the 'bz_eEventType' enumeration in 'bzfsAPI.h', ''bz_eLastEvent''. This event is simply used by BZFS to assist in the counting of the total number of events, it will never be called and can not be installed.

==See also==
[[BZFS API]]

[[plug-ins]]

[[Category:BZFS_API_Events]]

UsageQuestions

2011-10-17T06:05:03Z

Bullet Catcher: Add statistics about the number of league matches played.

==Overview==
Given the decline in players and development a number of questions should be answered to find out where the major failings of the project are. The answers can help determine what direction should be taken.

Answers to these questions must cite sources and have data to backup the answer. Guesses are not acceptable.

==General Usage==
How many players (unique) play every week(month)?

How many players are playing on average at various times in the day?

How long does the average player play in a session?

How many separate games (join/part) does a player play a day/week?

How many official league games are there a week/month?

* [[GU League]]
** 15 official matches were played during the 7 days from 10-16 October 2011.
** 102 official matches were played during the month from 17 September through 16 October 2011. [http://www.guleague.org/Matches/]
* [http://league.bzflag.net/ Ducati League]
** 12 official matches were played during the 7 days from 10-16 October 2011.
** 76 official matches were played during the month from 17 September through 16 October 2011. [http://league.bzflag.net/Matches/]
** A [http://league.bzflag.net/Teams/stats.php chart] shows the number of Ducati league matches played each month for the last 12 months.

How many players play in official league games in a week/month?

==Player Retention==
How many people register then play less then 5 games? 1 game?

How many players stop playing after 24 hours? 2 weeks?

==Website questions==
How many people who hit the site, download the game?

How many people who hit the screenshots page look at a screenshot?

How many people leave the site with no download once they see the screenshots page?

[[Category:Usage]]

BZFS API 2.4 Upgrade

2011-08-01T01:32:50Z

Bullet Catcher: /* Upgrade */ replace bz_PlayerRecord with bz_BasePlayerRecord

==Overview==
For version 2.4 the [[BZFS_API]] has undergone some restructuring. This document will go over the changes a plug-in developer must make in order to update to this new release.

==Compatibility==
In order to gain forward compatibility the API had to be changed in a way that broke backwards compatibility. This means that all plug-ins written for 2.0.x will not load in version 2.3.4 or later.

===API Version Numbers===
In the past the API version number represented the newest version of the API that the plug-in would run under. This caused plug-ins to have to be recompiled every time the API version changed.

In the new API the version number represents the minimum version required. This will ensure that plug-ins can be loaded in future versions. This also prevents plug-ins from running in versions older then they were written for. Due to the uni-directional nature of software upgrades this is a more useful feature.

==Spelling Changes==
Spelling errors and grammatical inconsistencies in the API have been fixed.

===BZ string and list classes===
The [[bzApiString]] and other associated ''basic'' types have been renamed to [[bz_ApiString]] to be more consistent with the rest of the API.

===Player Records===
The [[bz_PlayerRecord]] has been replaced with [[bz_BasePlayerRecord]] to allow for future derivation. Some of it's members have been changed, mostly notably the player position information is now part of the '''lastKnownState''' member of type [[bz_PlayerUpdateState]]. This structure contains much more information about the player state.

==Entry Points==
The main entry points for the API have changed. The following entry points are no longer used.

BZF_PLUGIN_CALL int [[bz_Load]] ( const char* command );
BZF_PLUGIN_CALL int [[bz_Unload]] ( void );
BZF_PLUGIN_CALL int [[bz_GetVersion]] ( void );

The entry points are replaced with the following new items.

BZF_PLUGIN_CALL [[bz_Plugin]]*[[bz_getPlugin]] ( void );
BZF_PLUGIN_CALL void [[bz_freePlugin]] ( [[bz_Plugin]]*);
BZF_PLUGIN_CALL int [[bz_GetMinVersion]] ( void );

[[bz_GetMinVersion]] is called first to get the minimum API version. If the current BZFS supports this verison then the plug-in will be loaded and [[bz_getPlugin]] will be called. This function returns the '''Plug-in Class''' that BZFS will use to interact with the plug-in. When a plug-in is unloaded the function [[bz_freePlugin]] will be called.

A set of macros are provided in the bzAPI.h Header to simplify the calls for a plug-in.

The plugin can simply call the '''BZ_PLUGIN(n)''' macro and provide a classname that is derived from [[bz_Plugin]]. This will create and free a plug-in class automatically and return the version of the API that the plug-in was compiled with.

===Plug-in Class===

The plug-in class is defined by the base class [[bz_Plugin]]. It contains 2 methods that each plug-in must implement in a derived class,

virtual const char* Name () = 0;
virtual void Init(const char* config) = 0;

'''Name''' returns the human readable name for the plug-in as a null terminated ASCII string.

'''Init''' is called by BZFS after the plug-in is loaded and serves the same function as the [[bz_Load]] entry point in previous versions.

The derived class may also optionally provide versions of these additional methods

virtual void Cleanup() {Flush();}
virtual void Event(bz_EventData* /*eventData*/) { return; }

'''Cleanup''' is called when a plug-in is unloaded and replaces the [bz_Unload]] function in previous versions. By default Cleanup will automatically remove any events that the plug-in has registered.

'''Event''' is called whenever BZFS executes an event that the plug-in has requested to be informed of. This function replaces the [[bz_EventHandler]] class in older versions.

==Events==
Every plug-in now has a single callback method for all events that it registers. The functions [[bz_registerEvent]] and [[bz_removeEvent]] have been removed from the API. In there place the [[bz_Plugin]] class now implements it's own '''Register''' and '''Remove''' methods.

These methods only take an event type and do not need a separate handler class, they will always use the '''Event''' method of the calling class.

A new method, '''Flush''' is provided to remove all events that the plug-in has registered. This method is automatically called by the default '''Cleanup''' method.

===Event Data Classes===
In addtion to the new Event handler system, all the event data classes have been changed. Each event data class is now versioned with a number in the class name, such as [[bz_PlayerSpawnEventData_V1]]. These event classes will never change and new versions will be derived from them with a higher version number. This allows a plug-in to always get the data it knows about, even as the BZAPI is enhanced to include more data for each event.

The base class for the Event Data Classes has also changed. [[bz_EventData]] now includes a timestamp for when the event was triggered in the ''eventTime'' data member.

====Class Changes====
Many of the events that returned some player data now simply return a [[bz_BasePlayerRecord]]. This player record will be automaticly freed when the event finishes and the plug-in does not have to call[[ bz_freePlayerRecord]] on the pointer.

The events affected are
* [[bz_ePlayerJoinEvent]]
* [[bz_ePlayerPartEvent]]

==Callbacks==
In order to reduce the number of callback classes that had name conflicts, call callback classes that used the '''handle''' method have had there methods renamed to be descriptive of the callback type. This is in order to make the use of multiple inheritance for callbacks simpler.

==Idle Time==
The function [[bz_setMaxWaitTime]] has been removed from the API. [[bz_Plugin]] contains a MaxWaitTime data member that can be set by each plug-in individually. BZFS will use the smallest time required by any plug-in. Setting the value to a negative number will indicate that the plug-in has no specific idle time needs.

==Inter Plug-in Communication==
[[bz_pluginExists]] and [[bz_getPlugin]] are provided to allow plug-ins to transfer data between themselves. the [[bz_Plugin]] class contains the [[GeneralCallback]] that can be used to call functions from one plug-in to the other.

==Upgrade==
Developers should take the following general steps to upgrade a plug-in from 2.0.x to 2.3/2.4; Individual results may vary depending on how different the plug-in is from the sample template.

* Open the '''.def'' file for the plug-in and replace the exported functions with the following
bz_GetPlugin
bz_FreePlugin
bz_GetMinVersion

* Open the main file for the plug-in and remove the call to '''BZ_GET_PLUGIN_VERSION'''
* Find the main event handler class and derive it from '''bz_Plugin''' instead of '''bz_EventHandler'''. If there is more then one event handler class, pick one to be the main class and delete the other classes.
* Change the '''process''' method in your event handler to '''Event''', the calling parameters are identical.
* Add the following methods to your plug-in class
virtual const char* Name (){return "NAME";}
virtual void Init ( const char* config);
* Replace the word '''NAME''' with the human readable name for your plug-in. This name will appear when a user types '''/listplugins''' while in the game.
* Remove any global instances of your Plug-in object and replace it with a call to the '''BZ_PLUGIN(n)''' macro. There is no need to instantiate the object, the macro will do it for you.
* Change the '''handle''' method in any bz_CustomSlashCommandHandler to '''SlashCommand'''
* Change the '''handle''' method in any bz_CustomMapObjectInfo to '''MapObject'''
* Find the bz_Load callback and replace it with the '''Init''' method from the plug-in class.
* Replace calls to '''bz_registerEvent''' with calls to '''Register''', and remove the second parameter.
* If the plug-in used custom slash commands or custom map objects that need to be cleaned up then implement the '''Cleanup''' method for the plug-in class and replace the bz_Unload Callback with it. Calls to '''bz_removeEvent''' can be removed, and the method Flush can be called once for all events. If the plug-in only registers events then the bz_Unload callback can be removed.
* Replace the following.
# '''bzApiString''' with '''bz_ApiString'''
# '''bzAPIIntList''' with '''bz_APIIntList'''
# '''bzAPIFloatList''' with '''bz_APIFloatList'''
# '''bzAPIStringList''' with '''bz_APIStringList'''
# '''bz_PlayerRecord''' with '''bz_BasePlayerRecord'''

* Add '''_V1''' to all event data classes, and adjust calls to members as needed, time to eventTime, etc...
* If you had multiple event handler classes, have your main plug-in's '''Event''' method check the event type and call the required code.
* Compile the plug-in and see what has been missed.

==Assistance==

If you require help with the upgrade please feel free to join the BZFlag developers on the development [[IRC]] channel. JeffM and Thumper will be more then willing to assist you in the upgrade.

==Samples==
All of the plug-ins in the source code distribution have been updated to the new format and can be used as examples.

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

DevelopmentPlans/2.4.2

2011-07-16T04:48:21Z

Bullet Catcher: /* Secondary */ SF bug 3368415 is now closed

==Overview==
2.4.2 will be the first maintenance release of the 2.4.x compatibility line. Its primary function is to fix bugs found in the 2.4.0 release and to include non breaking items that were not ready during the initial release

==Tasks==

===Bug Fixes===

===Introduced in previous release===
* "ST" autopilot 'issue' https://sourceforge.net/tracker/?func=detail&aid=3368248&group_id=3248&atid=103248

====Primary====
* Filter title text for servers https://sourceforge.net/tracker/?func=detail&aid=3368247&group_id=3248&atid=103248
* Flag Spawning After Death https://sourceforge.net/tracker/?func=detail&aid=3021884&group_id=3248&atid=103248
* teamflags do not follow groups with zoneflag https://sourceforge.net/tracker/?func=detail&aid=2938335&group_id=3248&atid=103248

====Secondary====
* Observer movement controls seems to get locked-up https://sourceforge.net/tracker/?func=detail&aid=3368413&group_id=3248&atid=103248
* timeout does not work with multiple team flags https://sourceforge.net/tracker/?func=detail&aid=3368409&group_id=3248&atid=103248
* time limiter and agility https://sourceforge.net/tracker/?func=detail&aid=3368408&group_id=3248&atid=103248
* z buffer issues https://sourceforge.net/tracker/?func=detail&aid=3368245&group_id=3248&atid=103248
* filter -publictitle https://sourceforge.net/tracker/?func=detail&aid=3368247&group_id=3248&atid=103248
* line numbers in drawinfo errors https://sourceforge.net/tracker/?func=detail&aid=2139541&group_id=3248&atid=103248
* stats not tracking https://sourceforge.net/tracker/?func=detail&aid=1433676&group_id=3248&atid=103248
* eval "configure should test and enable the fudged acosf atanf asinf" from old TODO.

===Features===
* BZFScron (implement as backport from 2.99)
* Fastmap ( make work )
* Push Stats ( finish backend )
* Joystick fixes (DTR?)
* CIDR/subnet bans from Filter.cxx (Make a common ban check/resolution function/class?)

[[Category:Development Plans]]

DevelopmentPlans/2.3

2011-05-16T01:51:38Z

Bullet Catcher: /* New Changes */ import 2.0 config settings

==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==
* Move trunk to a v2_99_branch. '''Complete'''
* Copy v2_0branch to trunk and change protocol number. '''Complete'''
* Change the version docs to make compatibility be the minor version number. '''Complete'''
* 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.
* Implement accepted proposals and test.
* 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?
* Tag trunk 2.4.0.0 for release.

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

===Assignments and tracking===
Task tracking is managed via a google spread sheet that can be found here.

https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0Agca59DESlNKdC1CSUtUMUhiSldrOVVPSHcwQUNzOUE&output=html

Developers with assigned tasks can request edit access to the document on IRC.

===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 '''Pimpinella'''
* [[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) '''JeffM'''
* Windows project cleanup '''JeffM'''
* New make system '''BulletCatcher'''
* 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''' (r14997, r15162, r15832)
* Message protection (ensure network messages are valid) '''A_Meteorite'''
* Add message types so that actions (/me) are properly implemented '''blast007''' (r19833)
* 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'''
* bzfs: Allow -time to have an ending time '''blast007'''

====New Changes====
* Round Robin for services '''JeffM'''
* 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''
* Import client customization settings from the 2.0 config.cfg file to the 2.4 version

===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 ''mdskpr''
* HTTP plugins ''JeffM''
* New API events ''JeffM''
* Custom flag system ''DTRemenak''
* BZFSCron ''Thumper''
* Server Side Players ''JeffM''
* Bug fixes not in notes ''Thumper''
* Hunter as proper team ''mdskpr (grabbed by DTRemenak)''
* bzfs -publickey
* Lua

====New Changes====
* Countdown/reload timer position fix for when showCoordinates is enabled ''mdskpr''
* SVN props cleanup '''Bullet Catcher'''
* 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.

* New flags
* Network buffering
* 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)
* Website changes.

[[Category:Versions]]

BZFlag SVN

2011-05-14T20:59:14Z

Bullet Catcher: Update URL for 2.0 branch.

BZFlag SVN, is the [http://en.wikipedia.org/wiki/Subversion_(software) Subversion Revision Control System] used by the development team to maintain and store the [[BZFlag Source]] code. The SVN system is hosted by [http://www.sourceforge.net SourceForge] and is accessible by anyone with the proper software. The SVN system replaces the [[BZFlag CVS]] system that was used in the past.

==SVN clients==
To access the source code via SVN , you will need a SVN client. Most unix/linux type operating systems have the command line SVN client as an installable option. Windows users must download the Windows native [http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 SVN command line utility] or a third party SVN client, such as [http://tortoisesvn.tigris.org/ the Tortoise Graphical SVN Client] (highly recommended). SVN is also available to Windows users via [http://cygwin.com/ Cygwin] with SVN and other common Devel tools selected during installation.

==Getting code from SVN Access==
===Command line===
The simplest way to get the bzflag source code is to use the URL for the current ( or TRUNK ) bzflag module.

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag</nowiki>

This will get you the current bzflag source code for the development version.

If you want the SVN code for the 2.0.x compatible version use the URL

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/release_maint/v2_0/bzflag</nowiki>

If you wish to get all of our source code in one step, you can get the entire repository with the command.

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag</nowiki> bzflag

This will get all modules, branches, tags, and subdirs. Beware! This is a very large amount of data (make sure you have at least 2.7 GB of disk space available) and will take a while and will be rather useless, as it is the code for every version of bzflag. Most users will only need the code for one specific version.

The '''best''' way, is to only get the subdir for the module you are interested in. This is much more efficient and suitable for most users. The most common module to get is the bzflag module, as it is the actual game.

Please see the sections below for more information about the URLs to use for branches and modules.

===TortoiseSVN===

Windows users that use the Tortoise Graphical SVN Client simply enter the URL of the SVN path they wish to check out in the field marked ''URL of repository''. For the current version of all modules simply use the /trunk path. Note, if you want your code to be checked out into a new folder, be sure to enter that folder name in the ''Checkout directory'' field.

If you wish to get only a single module subdir, or a revision, simply use the URL specified in the sections below.

==Committing Code to SVN==

Project developers that need write access to the source code to make changes ( or [[commits]] ) need to provide their sourceforge username and password when doing a SVN commit. A sourceforge account is required for developer access, as well as approval from a project administrator.

Please make sure that your svn config file includes the correct [[Auto-props]]. If you get a [[Mime-types]] error, you either didn't enable the correct auto-props setting in your subversion config file or you need to manually set file properties.

===Command Line===
Using the command
svn commit
in a directory that has code changes will commit any changed code back to the repository. The svn client will prompt you for your username and password.

===TortoiseSVN===
Windows users that use the Tortoise Graphical SVN Client can simply choose the SVN commit item, and enter their username and password when prompted.

Tortoise users may set auto-props from the General Settings property page; click the Edit button and paste the auto-props into the correct section, then un-comment the "enable-auto-props = yes" line above it.

==Updating code from SVN to the current version==

===Command Line===
Using the command
svn up
in the directory that has checked out code will cause subversion to update that code to the current version for that branch.

===TortoiseSVN===
Windows users that use the Tortoise Graphical SVN Client can simply choose the SVN update item from their right click menus.

==Reverting local code to the server's version==

===Command Line===
Using the command
svn revert
svn up
in the directory that has checked out code will cause subversion to set flags on all modified local files, then update the code to match the code on the server. NOTE: This has the effect of wiping out all local changes, so use with caution!

===TortoiseSVN===
Right click on the file or directory you would like to revert and from the TortoiseSVN submenu, select '''Revert...'''. The menus is context sensitive, so there must be code that has been modified for the menu choice to be available.

==Module sub directories==

The source code in SVN is broken up into a number of modules for ease of use and management. When requesting the source code from the SVN system a sub-directory may be specified to limit the code that is accessed.

The current SVN modules are:
*bzflag : The main module that includes the game [[BZFlag 2.0.8|client]], [[BZFS|server]], [[plug-ins]], and [[BZAdmin]].
*admin : The [[Master Ban]] list
*bzedit : The linux version of the BZFlag map editor [[BZEdit]]
*bzeditw32 : The windows version of the BZFlag map editor [[BZEditWin32]]
*web : The main website at http://www.bzflag.org
*db : Files related to the website http://my.bzflag.org and the [[Global Registration]] system.
*pybzflag : an abandoned python implementation of BZFlag
*bzworkbench : The source code for [[BZWorkBench]]
*bzwgen: The source code for the automatic city generator.

to get the current version of a module, you would add
/trunk/MODULE_NAME
after the normal SVN URL.

so to get the current version of just the bzflag module, the URL would be

<nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/</nowiki>

From the command line

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag</nowiki>

==Branches==
Branches in subversion are simply subfolders.
All branches are in the /branches subdirectory off the root level of the SVN tree, listed [http://bzflag.svn.sourceforge.net/viewvc/bzflag/branches/ here].
To get the code in a branch, you simply use the branch URL in your svn client.

To get the 2.0.x branch of the BZFlag module, you'd use the following URL.
https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/release_maint/v2_0/bzflag/

==Useful Tools==

===Windows===

'''Tortoise Graphical SVN Client''': integrates subversion into the windows explorer shell. http://tortoisesvn.tigris.org/

'''Ankh Subversion''': integrates subversion into Visual C++ as a native source control provider. http://ankhsvn.tigris.org/

'''WinMerge''': visual merge and diff tool for windows. http://winmerge.org/

==See also==
[[Versions]]

==External Links==
[http://sourceforge.net/svn/?group_id=3248 SourceForge SVN Access page]

[http://bzflag.svn.sourceforge.net/viewvc/bzflag/ BZFlag SVN Tree]

[[Category:Development]]
[[Category:Compiling]]
[[Category:Versions]]

DevelopmentPlans/2.3

2011-05-14T20:54:06Z

Bullet Catcher: Add page to Versions category

==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==
* Move trunk to a v2_99_branch. '''Complete'''
* Copy v2_0branch to trunk and change protocol number. '''Complete'''
* Change the version docs to make compatibility be the minor version number. '''Complete'''
* 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.
* Implement accepted proposals and test.
* 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?
* Tag trunk 2.4.0.0 for release.

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

===Assignments and tracking===
Task tracking is managed via a google spread sheet that can be found here.

https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0Agca59DESlNKdC1CSUtUMUhiSldrOVVPSHcwQUNzOUE&output=html

Developers with assigned tasks can request edit access to the document on IRC.

===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 '''Pimpinella'''
* [[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) '''JeffM'''
* Windows project cleanup '''JeffM'''
* New make system '''BulletCatcher'''
* 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''' (r14997, r15162, r15832)
* Message protection (ensure network messages are valid) '''A_Meteorite'''
* Add message types so that actions (/me) are properly implemented '''blast007''' (r19833)
* 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'''
* bzfs: Allow -time to have an ending time '''blast007'''

====New Changes====
* Round Robin for services '''JeffM'''
* 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 ''mdskpr''
* HTTP plugins ''JeffM''
* New API events ''JeffM''
* Custom flag system ''DTRemenak''
* BZFSCron ''Thumper''
* Server Side Players ''JeffM''
* Bug fixes not in notes ''Thumper''
* Hunter as proper team ''mdskpr (grabbed by DTRemenak)''
* bzfs -publickey
* Lua

====New Changes====
* Countdown/reload timer position fix for when showCoordinates is enabled ''mdskpr''
* SVN props cleanup '''Bullet Catcher'''
* 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.

* New flags
* Network buffering
* 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)

[[Category:Versions]]

DevelopmentPlans/2.3

2011-05-13T16:08:12Z

Bullet Catcher: /* Backports */ BC tackles the make system

==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==
* Move trunk to a v2_99_branch. '''Complete'''
* Copy v2_0branch to trunk and change protocol number. '''Complete'''
* Change the version docs to make compatibility be the minor version number. '''Complete'''
* 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.
* Implement accepted proposals and test.
* 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?
* Tag trunk 2.4.0.0 for 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 '''Pimpinella'''
* [[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) '''JeffM'''
* Windows project cleanup '''JeffM'''
* New make system '''BulletCatcher'''
* 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''' (r14997, r15162, r15832)
* Message protection (ensure network messages are valid)
* Add message types so that actions (/me) are properly implemented '''blast007''' (r19833)
* 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'''
* bzfs: Allow -time to have an ending time '''blast007'''

====New Changes====
* Round Robin for services '''JeffM'''
* 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
* Hunter as proper team
* bzfs -publickey

====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-12T16:26:18Z

Bullet Catcher: redistribute general idea section, add release candidate

==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.
* When proposals are in and accepted by consensus, start the 1-month countdown clock.
* Move trunk to a V3_FAIL tag.
* 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)
* New GUI elements
* Server-side scoring
* Segmented simulation loop (to prevent wallwalking)
* Server-side flag ID and pickup
* New shot graphics (geolaser/geothief)
* HUD markers
* Removal of low graphics, promotion of experimental to high.
* Server list from GSoC
* BZFS API rework
* Remove local authentication (the /identify command)
* Windows project cleanup
* New make system
* New source docs (authors etc...)
* Server-side handicap
* Guided Missile shot checks
* Stealth fixes for rabbit
* Asynchronous screenshot compression so client won't freeze up during screenshots
* BZFlag update notification
* Wings velocity change (additive flap instead of instant upward velocity)
* Message protection (ensure network messages are valid)
* Add message types so that actions (/me) are properly implemented
* New artwork
* Server option to disable teamkills
* OpenFFA
* Download URL change (to force just images.bzflag.org, not any .org or .bz)
* Remove option to turn off fog
* Require OpenGL 1.2
* Only allow a single end shot credit for holding the shield flag
* Only players with POLL permission are eligible to take part in a vote
* Remove the /identify command
* Add the /serverdebug command

====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

===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
* New API events
* BZFSCron
* Server Side Players
* Bug fixes not in notes
* New flags
* Rabbit as proper team

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

===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-12T15:15:14Z

Bullet Catcher: fix spelling and grammar, minor content 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.

==General Overview and Idea of Project==
* 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.
** server list backport?
** Cloaked Shot flag (hoping for better than this)
* anti-cheating
** Only allow a single end shot credit for holding the shield flag
** Only players with POLL permission are eligible to take part in a vote
* Fix the protocol bug that version [[BZFlag 2.0.16|2.0.16]] was a band-aid for.
* Command changes
** Remove the /identify command.
** Backport the /serverdebug command

==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.
* When proposals are in and accepted by consensus, start the 1-month countdown clock.
* Move trunk to a V3_FAIL tag.
* 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.
* After 1 month, revert any changes that have caused unfixed regressions.
* Update version docs and make trunk into 2.4.0.0 for release.
* Tag Trunk to 2_4branch and release.

==Projects==
These are the things that are in "the plan".

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

* Connection header change (HTTP-style)
* New GUI elements
* Server-side scoring
* Segmented simulation loop (to prevent wallwalking)
* Server-side flag ID and pickup
* New shot graphics (geolaser/geothief)
* HUD markers
* Removal of low graphics, promotion of experimental to high.
* Server list from GSOC
* BZFS API rework
* Remove local authentication (the /identify command)
* Windows project cleanup
* New make system
* New source docs (authors etc...)
* Server-side handicap
* Guided Missile shot checks
* Stealth fixes for rabbit
* Asynchronous screenshot compression so client won't freeze up during screenshots
* BZFlag update notification
* Wings velocity change (additive flap instead of instant upward velocity)
* Message protection (ensure network messages are valid)
* Add message types so that actions (/me) are properly implemented
* New artwork
* Server option to disable teamkills
* OpenFFA
* Download URL change (to force just images.bzflag.org, not any .org or .bz)
* Remove option to turn off fog
* Require OpenGL 1.2

====New Changes====
* Round Robin for services

===To Evaluate===
These items should be evaluated to see if they can be or should be moved back, but are not critical. These may exist as code or patches.

====Backports====
* Map changes
* HTTP plugins
* New API events
* BZFSCron
* Server Side Players
* Bug fixes not in notes
* New flags
* Rabbit as proper team

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

===Exclusions===
These items should not be done or backported due to stability issues. 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-11T19:04:00Z

Bullet Catcher: new plan for a new release

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: the game version number that 2.3 would be released as has not been chosen yet.

==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 v2_0branch to v2_3branch 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.
* Choose a version number for the release.
* Rename v2_3branch to vN_Nbranch and release.

==Proposals==
TBD

V3RCChecklist

2011-05-10T18:55:29Z

Bullet Catcher: /* RC Critical fixes. */ add flag and font items

==Overview==
V3.0 has some major problems that prevent it from being close to a release candidate. This page will list the remaining items that need to be addressed before an RC can be made.

==RC Critical fixes.==
# Dead-reckoning / lag-compensation testing / message loop / lag.
# MsgPause fix.
# Team flag disappears while the tank that was carrying it is dead.
# Some letters are not rendered in certain font sizes.

==RC Critical Tasks==
# Linux Package review (new files in the right places )
# Mac installer review (check it in)
# Readme Updates
# Docs for V3 changes (-a missing, caps on server, lag comp, etc..)
# API review (spelling, consistency)

==RC 'really nice' features ==
# Implement map features to define proper "flag pass" behavior in maps that want it
# Ask user to accept non bzflag.org images
# Ask user to join non bzflag.org servers (MsgJoinServer)
# Parity mesh checks to replace inside/outside points

==RC 'really nice' Fixes/Tasks==
# Webadmin template review ( for style )

==Notes==

===Flag "pass" issues===
The current method of using the flag respawn on drop to pass a team flag was never a defined 'feature' of the game. Many maps have been designed to turn this into a gameplay feature. In order to be able to maintain this type of gameplay a real feature has to be implemented to support it. Current development code has already "broken" teleporter passing by improving the definitions of the teleporter geometry and making no longer a "bad" place to put a flag. Similar enhancements are expected to be made in other parts of the world that would break other types of passing.

To properly support the desired behavior a set of map defined zones or faces needs to be implemented that can detect when specific flags are dropped on them and define a respawn target zone or area. This will allow maps to fully define pass zones in an arbitrary way for any flag. Defining the a real feature will prevent new code from changing the defined behavior in adverse ways.

BZFlag on IRC

2010-09-18T07:04:08Z

Bullet Catcher: /* Other projects and unofficial channels */ new GU league URLs

=FreeNode=
The official BZFlag org. and its associated communities use the [http://freenode.net/ freenode IRC network] for communication and collaboration.

==Channels==
===Official channels===
BZFlag maintains 2 official channels run by the org.
====#bzflag====
The [irc://irc.freenode.net/bzflag #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'''

====#bzflag-chat====
The #bzflag-chat channel is a more informal channel designated for player community discussions.

===Other projects and unofficial 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)
* #badgerking (Official Channel for Badgerking's FFA)
* #BoomBZ (Team Channel for GU team [BoOm])
* ##bz-inc (DUCLeague team, [http://my.bzflag.org/league/index.php?link=teaminfo&id=689/ Bz-Incorporated])
* ##bzexcess (Support channel for the [http://bzexcess.com BZExcess.com servers.])
* ##bzflagr (Support channel for the [http://bzflagr.net BZFlagr.net servers.]) - closed down
* #bzfx (Support channel for the bzfx.net BZFlag servers)
* ##bzpod (Channel to discuss the BZFlag podcast, BZPod)
* ##bzpro (Support channel for the [http://bzpro.net BZPro.net servers.])
* ##bztank (Unofficial support channel for the [http://bztank.net BZTank.net servers].)
* #bztraining (Official support channel for the [http://bztraining.org BZTraining server network] and for [http://bznetwork.googlecode.com BZNetwork])
* ##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://www.guleague.org/Teams/?profile=10 GULeague Team])
* ##guleague (Support channel for [http://www.guleague.org/ GamesUnited League (GULeague)])
* ##hepcat (Support channel for borrego.hepcat.org BZFlag server)
* ##icf (Support channel for [http://www.guleague.org/Teams/?profile=112 Invasive Chaotic Frenzies, (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]) ''defunct''
* #silvercat (Support channel for [http://silvercat.bzflag.org/ Silvercat BZFlag servers]) ''defunct''
* ##t42 ([http://www.guleague.org/Teams/?profile=39 GULeague team])
* ##untamed ([http://my.bzflag.org/league/index.php?link=teaminfo&id=909 DUCLeague team])
* #powerbzedit (Support channel for [http://pbzewiki.doenemeier.de/wiki/ PowerBZEdit])

When the Freenode Group Management System is implemented, channels with a single # will need to either register their organization with Freenode or rename to begin with ## (a "reference" channel, one that holds no legal claim to the name).

=stormcenter.net=
An unofficial bzflag channel is run on irc.stormcenter.net
* #bzflag (official support channel for [http://www.bztank.net BZtank] servers)

=IRC Clients=
To access the IRC network you need to use an IRC client. [http://irchelp.org/ http://irchelp.org/] is an excellent resource for more information on general IRC.

=External links=
*[http://irchelp.org/ IRC help docs]

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

Category:Leagues

2010-09-18T06:54:44Z

Bullet Catcher: /* GU League */ new web site URL, fix IRC channel name

== BZFlag Leagues ==

To join a league click on one of the links below and register your callsign. Some leagues may require that you be added to a list by an admin before you are allowed to talk/spawn on match servers. Please use the same callsign for matching that you have register on the league site. Most of the IRC channels for each league are situated on the [http://freenode.net/ freenode] network. Please refer to [[BZFlag on IRC]] for help on using IRC.

== Ducati League ==
Website: [http://league.bzflag.org/ http://league.bzflag.net/]

IRC Channel: [irc://irc.freenode.net/##ducleague ##ducleague]

Match Length: 15, 20 or 30 minutes

Rules: 2 shots, no jumping, ricochet, CTF, randomly generated map.

== [[GU League]] ==
Website: [http://www.guleague.org/ http://www.guleague.org/]

IRC Channel: [irc://irc.freenode.net/##guleague ##guleague]

Match Length: 30 minutes.

Rules: 3 shots, jumping, ricochet, CTF, [[HiX]] map.

== Pillbox League ==
Website: [http://pillbox.bzleague.com/ http://pillbox.bzleague.com/]

IRC Channel: [irc://irc.freenode.net/#pillbox #pillbox]

Match Length: 15, 20 or 30 minutes.

Rules: 3 shots, no jumping, no ricochet, CTF, pillbox map.

== [[Open League]] ==
Website: [http://openleague.net/ http://openleague.net/]

IRC Channel: [irc://irc.freenode.net/#openleague.net ##openleague]

Match Length: 15, 20, 30, 45 or 60 minutes.

Rules: 3 shots, jumping , ricochet, CTF, [[babel]] or a map that changes every week (which can have different rules).

== 1vs1 League ==
Website: [http://1vs1.bzleague.com/ http://1vs1.bzleague.com/]

IRC Channel: None.

Match Length: First to 10 kills.

Rules:
:classic & fancy style: -> FFA mode, 2 shots, ricochet, no jumping, no superflags, small randomly generated map
:hix style -> FFA mode, 3 shots, ricochet, jumping, no superflags, hix map

== Fun League ==
Website: [http://fun.bzleague.com/ http://fun.bzleague.com/]

IRC Channel: None.

Match Length: Depends on which map you play on.

Rules: Depends on which map you play on.

== BZSoccer League ==

Website: [http://bzsoccer.bzleague.com/ http://bzsoccer.bzleague.com/] *Note* Website has many bugs and will be fixed soon.

IRC Channel: ##divi

Match length: 15 minutes

Rules: 2 shots, jumping, ricochet, soccer field map.

Please note that this league is inactive. The league will be revived when the website is fixed.

== Defunct Leagues ==

=== Plosileague ===

Website: [http://bzfx.net/league/ http://bzfx.net/league/]

IRC Channel: [irc://irc.freenode.net/#plosileague #plosileague]

Match Length: 30 minutes or first to 5 caps and ahead of the other team by at least 2 caps

Rules: 3 shots, jumping, ricochet, CTF, [[overlord]] or [[babel]] map.

=== LavaHiX League ===
Website: [http://lavahix.wtwrp.de/ http://lavahix.wtwrp.de/]

IRC Channel: None.

Match Length: 15 minutes.

Rules: 3 shots, jumping, ricochet, CTF, [[HiX]] map with "lava" ground.

GU League

2010-09-18T06:51:17Z

Bullet Catcher: new league web site URLs, update official servers list

[[Image:GUMatch.jpg|right|thumb|300px|A GU match in progress. ]]

=GU League Info=

===General Info===

The GU League is currently the most successful and active BZFlag league. It launched on January 23rd 2005, and since then has recorded over [http://www.guleague.org/Matches/ 21,100 matches]. There are currently [http://www.guleague.org/Teams/ 28 teams], 20 of which are active. There are over [http://www.guleague.org/Players/ 350 players] representing 47 different countries. All matches are played on the [[Hix]] map. (Statistics as of June 2, 2010)

The GU League offers challenging competition and includes some of the top BZFlag players. New players learn fast by getting involved in fun matches and by watching other players. People from all age groups play and many are willing to help new players get started.

Make sure to visit the [http://my.bzflag.org/bb/viewforum.php?f=103 official GU League forum] and read the "sticky" threads at the top of the page. They contain a lot of important information.

=Playing in GU=

For players that are new to BZFlag, it is recommended to check out the [[Getting_Started|Getting Started]] page. A [[Getting_Started#Registering_a_callsign.28Optional.29|globally registered name]] is required for league play.

A player can then [http://www.guleague.org/Login/ register in the league] using the same name. One of the [http://www.guleague.org/Contact/ GU League Admins] must be contacted with a request to be added to the [http://my.bzflag.org/bb/memberlist.php?mode=group&g=20506 gu.league spawnlist] on the BZBB forums. This will allow the player to spawn and talk on league servers.

==Rules and Guidelines==

The league keeps very high standards of behavior and sportsmanship. So check these rules before doing anything else:

*Match disturbance, player harassment, language, cheat accusations in public (1 day -7 days ban)
*Using cheats on public servers or in other leagues (6-9 months)
*Using cheats in the GU league (1 year to life)

These are subject to change, so please always check the [http://www.guleague.org/Rules/ GU Rules page] directly.

===Fun Matches===

A good way to get started in the league is to play fun matches (typically abbreviated as 'fm'). These types of matches are very popular. Only official matches are entered into the website, so there is less pressure during a fun match. Players do not have to be in a team, and players from specific league teams don't have to play on the same color.

Fun matches can also have additional players join during play. Make sure that the current players don't mind before joining a match. Players should '''self-kill''' by shooting while facing a wall or self-destructing with the delete key. This ensures there is not an unfair advantage due to initially spawning on the team base. The phrase "sk please" is used quite often to request that someone self-kills.

Fun matches are not to be reported.

===Teams, Matching & Reporting===

So, you've registered and want to get some action? First of all, you're going to need a team. You can join a team by visiting the [http://www.guleague.org/Teams/ teams] page and hitting the "Join" button next to the team, that is, if the team is open to anyone. Most teams however, are closed and can only be joined by invitation sent from the team leader.
Usually you will always find some teams that are interested in new and active players. If you want to contact the leader of a team or the team itself, use the "BZMail" option that can be found at the top or bottom of any Team/Player profile page.
Don't be discouraged if the first couple of requests get turned down, most teams like to get to know the players before they accept them into their team. But it's easy to establish yourself within the GU community. You can get to know players best by playing fun matches, spending time on the various public servers and talking to others in Observer during matches. It's a learning by doing system.

Once you've found and joined a team you like you can immediately start matching! There are some rules you should take into account before doing so though.

===Official Matches===

Basic commands needed during official matches:

* '''/countdown''' - Start the 30 minute match timer.
* '''/countdown pause''' - Pause the match timer. Should not be abused and should only be used when necessary. (E.g. a player has to stop for a moment, etc.)
* '''/countdown resume''' - Resume the match timer and allow the match to continue.
* '''/gameover''' - This will abruptly end the match at any given time. (Do not abuse! Ending a match with out any notice will most certainly lead to a ban.)

Guidelines:

* Do not start the match timer before all participating players are ready and make sure everyone has agreed on playing an official match.
* Make sure all players agree with opponents lag before starting the match. It is frowned upon to start a match and realize half way in that the lag is unplayable.
* Everyone participating should either able to finish the match or have a substitute available in case.
* Make sure the server is an official GU League match server.
* If a player goes [NR] (which means they are 'Not Responding', thus have lost their connection to the server somehow), pause the match and wait for a substitute or for the player to rejoin
* Make sure everyone is ready for a substitute before it happens to prevent major chaos in the match.
* If two more players want to join from the respective teams, make sure everyone is prepared and has said yes to the addition of players.
* Pick a server closest to the majority of players. If it is a half/half case, just agree on one.

If for some reason a match has to be canceled, make sure a player of both teams somehow saves score, remaining time, position of flags/players. (Easiest by taking a screenshot - hit F5)
When the match can be resumed later, adjust the timer to the remaining time the match was stopped at. Use the /timelimit <minutes go here> command to adjust the timer before a match.

===Entering/Reporting official matches===

After you've successfully played an official match, you need to either report the match to one of the [http://www.guleague.org/Contact/ referees (aka 'refs') or admins] by BZMail on the GU site, or just have a present ref/admin enter it. When reporting by BZMail, you '''must''' include: Teams, Score, Time, Date.

==Official league servers==

It is very important that you only play official matches on the official league servers.

Here is a list of the servers and their respective locations.

'''Europe:'''

* brad.guleague.org: 5158
* bzf.guleague.org: 5157 and 5158
* dub.guleague.org: 59997
* longdon.guleague.org: 5158
* destroyer.guleague.org: 5158

'''America:'''

* quol.guleague.org: 5157 and 5158 (Quebec, Canada)
* my.inexplicably.org: 5158 (Texas, USA)
* brl.arpa.net: 5158 (California, USA)

'''New Zealand:'''

* bzflag.enuffsaid.co.nz: 5158

The replay servers can be found on port 5159, except for dub.guleague.org: 59996

If a match is not played on one of these servers, than it cannot be counted as official.

===Replays===

Every match, official or fun, is automatically recorded and saved to the respective replay server. Some servers have websites where the replay file, time, date and players are posted.

* http://longdon.guleague.org/
* http://destroyer.guleague.org/
* http://bzf.guleague.org/matchlist.html
* http://quol.bzflag.bz/bzmatches/ (New design!)

You can find help on how to get a replay start and running on the servers but here's a quick summary:

#Find the replay file you want by either using the above mentioned web-sites or by using
##/replay list -n (if possible, will display a list of recent replays in chronological order)
##/replay list *10042009* (will show you all replays played on April 10th, 2009)

#Once you've found your replay file
##/replay load #index number

Use /replay skip + or - <amount of seconds> to navigate within a replay
Use /replay pause and /replay resume to pause and resume a replay

===Public Servers===

Along with the various official servers, there are quite a few public servers set up using either identical or similar settings to the league. Players usually meet up there to get warm and just shoot around before or after a match. Anyone can play there, regardless of being registered in the league or not. All of these public servers are running the HiX map, some are CTF and some are just FFA.

List of popular HiX public servers:

* bzf.bzflag.net:5154 [FFA - HiX map]
* bzf.bzflag.net:5155 [4-Team CTF HiX]
* bzf.bzflag.net:5160 [2-Team CTF HiX]
* quol.guleague.org:5156 [2-Team CTF HiX]

=Settings and Options=

A big part of the GU league, is being able to compete. But the premise for that, is having good settings that will make things like dodging, shooting and jumping a lot easier. A very large amount of the GU players use mouse and only a dozen keyboard. If you are just starting out, I would recommend you try playing with mouse first, as many things will be easier to do later on.
In this game, it's impossible to become the best dodger, jumper and shooter at the same time. These are two if not three completely different types of playing that require many different settings.

Most of the setting adjustment is done by the [[Config_File]], as you can not exercise all your possibilities in the GUI options. You can find a lot of detailed information by using the [http://my.bzflag.org/bb/search.php Search option on BZBB]. Many players have posted their personal configs and other tips there.

For mouse players, these individual playing styles, also mean individual mouse settings. Mousebox size, mouse DPI, mouse sensitivity are all crucial. Usually slower mouse settings and a big mouseboxsize, will enable you to be a better jumper and or shooter, while fast, sensitive, precise mouse settings and a small to even negative mouseboxsize will be enable you to dodge better.
Next to all the native options, some players use mouse enhancement applications, see [http://my.bzflag.org/bb/viewtopic.php?f=103&t=13245 Whitelist] for further info.

Very experienced players however, are known to be able to jump, shoot and dodge with extreme precision. So, no setting in the world is going to help, if you don't practice and play enough.

=Stats=

You might have asked yourself how you're supposed to find other players online if you want to arrange a match.
There are some very useful BZStats and Player checkers that are have been useful to the whole community for years.

#The general BZStats checker that Strayer coded shows a massive amount of information on everything BZFlag related.
##http://bzstats.strayer.de
##http://bzstats.strayer.de/leagues/gu/online/?lang=en (that shows all current GU players that are online)

#The second checker is Saturos' GU League Checker
##http://guc.saturos.de (V.1)
##http://guc.phago.de (Beta V.2, this version is still in the makes but already has many features and fixes that V.1 does not)
The GUC displays all main Public and Official GU League servers with scores, players, timer and teams. (Very useful for following matches without opening a client)

=Abbreviations you should know=

As mentioned already above, there are some abbreviations used very often in the league. If you haven't already, check out [[Jargon]] for more non-league specific abbreviations and Jargon. Below are some league specific abbreviations. Note that this is not a complete list, just the most common terms you should know in order to prevent confusion between players or in a match.

<properties>
offi=Referring to an official match. ("offi?" means somebody wants to play an official match)
fm=Referring to fun match. ("fm?" means somebody wants to play a fun match)
sk=Selfkill. (Expression often used when new players join an already running fun match. New players should kill themselves once immediately after spawning.)
tk=Teamkill. (More frequently used outside of league play too)
def=Defense. Your flag is under immediate attack or about to be taken. Watch out for yours!
att=Attack. Focus on getting your opponents flag.
gs, ns, n1, g1=Good shot, nice shot, nice one, good one. Frequently used when a player does something that the other regards as nice or skillfull.
ty, thx=Thank you. Thanks.
hf, gl=Have fun, good luck.Usually always said to the opposing team before a match starts
gg=Good game. Usually said by all participating players after a match has ended.
</properties>

[[Category:Leagues]]

Versions

2010-07-03T21:07:47Z

Bullet Catcher: /* Released versions of BZFlag */ add 2.0.16 to the list

==Version Numbering Systems==
===History===
BZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows: the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" triplet system currently in place. The information in follwoing regarding BZFlag's versioning scheme pertains to the "new" triplet system currently in use.

===Current System===
Ever since the unreleased 1.9 development revision, BZFlag has been using a '''MAJOR.MINOR.PATCH''' version numbering scheme that is familiar to many open source software projects. In this triplet version numbering scheme, the '''MAJOR''' number implies predominant backwards software compatibility; the '''MINOR''' number represents feature additions and enhancements; and the '''PATCH''' number is iterated releases of that given '''MAJOR.MINOR''' version. Each number in that triplet is independent and is not necessarily just a single digit for each either (e.g., 1.10 is ''not'' the same as 1.1.0 nor 1.0.10). For brevity, releases since 2.0 can generally be referred to only using the '''MAJOR.MINOR''' revision, leaving the '''PATCH''' version number off.

In order to "encourage" upgrades and facilitate making enhancements and bug fixes to the game, BZFlag's developers (intentionally) break the game protocol from time to time where new clients are released that will not work with previous releases. Starting with BZFlag version 2.0, the '''MAJOR''' number in BZFlag's versioning triplet '''''represents backwards-compatibility'''''. That is to say that all clients with a version number starting with a 2 will (only) work with others of that 2 series.

===Development Versions and Release Versions===
''Development of a new '''MAJOR''' version of BZFlag occurs as the previous '''MAJOR''' version number's '''99th''' '''MINOR''' revision. (e.g., 2.99 becomes 3.0, 3.99 becomes 4.0)'' The '''99th''' development revision is necessarily treated special and generally not compatible with anything but itself.

As compatible releases and enhancements are made to the game, they are released with an ''even-numbered'' '''MINOR''' version number (e.g. 3.'''0''' or 1.'''10''' or 3.'''2'''.6 etc). Versions of the game with an ''odd-numbered'' '''MINOR''' version number represents development-only versions that should not be used by non-developers under any circumstances ''(i.e., you're on your own, no support or guarantees are offered)''. Again, revisions with an '''''odd''''' second number represent '''''developer revisions''''' and those with an '''''even''''' second number are the '''''public revisions'''''.

The '''PATCH''' number in the version triplet counts publicly posted revisions for a given '''MAJOR.MINOR''' version. Since the BZFlag developers do intentionally provide (pre-release, alpha, beta) versions the game before a ''final'' post is made, those releases merely have the '''PATCH''' number incremented. Basically, the '''PATCH''' number can be looked at as how many times files have been publicly posted for a given '''MAJOR.MINOR''' version.

===Release Candidates===
Labels and comments that a given release is an ''RC'' (Release Candidate) version or that it's a ''beta'' or an ''alpha'' release are merely inteded to describe the stability of a given version but are '''not''' part of the version itself. Lower patch numbers on a developer revision (where the '''MINOR''' number is an ''odd-number'') tend to imply less stability whereas higher patch numbers tend to imply greater stability. On non-developer releases, the number is generally only incremented and reposted if there was something deficient with the version already posted.

==(Current) Revision number examples==

2.99.0 is a developer revision that will become the next 3.0 major release. Only developers should be using this revision.

2.99.27 is the 28th developer revision of 2.99, perhaps approaching some sort of beta or release-candidate status for the 3.0 release. Only developers and testers should be using this revision.

3.0.0 is a new release of a BZFlag client that is incompatible with all previous versions. This revision is for everyone.

3.0.9 is the 10th release of the 3.0 client, only providing minor bug and build fixes. This revision is for everyone.

3.1.0 is a developer revision of the 3 series, compatible with other version 3 clients and a pre-release candidate for the 3.2 release. Only developers should be using this revision.

3.12.4 is the 5th patch update of the 3.12 public release intended for everyone. There were six compatible versions released prior to this version: 3.0, 3.2, 3.4, 3.6, 3.8, and 3.10

3.2.5 is the 6th publicly posted release of version 3.2, serving enhanced functionality over the previous 3.0 clients while remaining compatible with other 3 series clients. This revision is for everyone.

3.99.0 is a developer revision that will become the next 4.0 major release. Only developers should be using this revision

== Released versions of BZFlag ==
There are currently 34 open source versions of BZFlag. Versions earlier then 1.7c-X were closed source.

The versions in chronological order are;

* [[BZFlag 1.7c-1]]
* [[BZFlag 1.7c-2]]
* [[BZFlag 1.7c-2-1]]
* [[BZFlag 1.7c-2-2]]
* [[BZFlag 1.7c-2-3]]
* [[BZFlag 1.7d-1]]
* [[BZFlag 1.7d-2]]
* [[BZFlag 1.7d-3]]
* [[BZFlag 1.7d-4]]
* [[BZFlag 1.7d-5]]
* [[BZFlag 1.7d-6]]
* [[BZFlag 1.7d-7]]
* [[BZFlag 1.7d-8]]
* [[BZFlag 1.7d-9]]
* [[BZFlag 1.7e]]
* [[BZFlag 1.7e1]]
* [[BZFlag 1.7e2]]
* [[BZFlag 1.7e4]]
* [[BZFlag 1.7e6]]
* [[BZFlag 1.7g0]]
* [[BZFlag 1.7g2]]
* [[BZFlag 1.10.0]]
* [[BZFlag 1.10.2]]
* [[BZFlag 1.10.4]]
* [[BZFlag 1.10.6]]
* [[BZFlag 1.10.8]]
* [[BZFlag 2.0.0]]
* [[BZFlag 2.0.2]]
* [[BZFlag 2.0.4]]
* [[BZFlag 2.0.6]]
* [[BZFlag 2.0.8]]
* [[BZFlag 2.0.9]]
* [[BZFlag 2.0.10]]
* [[BZFlag 2.0.12]]
* [[BZFlag 2.0.14]]
* [[BZFlag 2.0.16]]
* [[BZFlag 3.0]]
* [[BZFlag SVN]]

[[Category:History]]

Main Page

2010-02-15T22:07:34Z

Bullet Catcher: /* Google Summer of Code */ change to past tense now that it is over

__NOTOC__
[[Image:BZFlag_2010_shiny.png|center]]
{|style="width:100%;margin-top:+.7em;background-color:#fcfcfc;border:1px solid #ccc"
|style="width:56%;color:#000"|
{|style="width:280px;border:solid 0px;background:none"
|-
|style="width:280px;text-align:center;white-space:nowrap;color:#000" |
[[Image:Bzflag-48x48.png|left]]
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">Welcome to the BZFlag Wiki,</div>
<div style="top:+0.2em;font-size: 95%">The source for community information on most things related to BZFlag!</div>
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">The BZFlag Wiki motto: [[BZFlagWiki:Be_bold|'''Be Bold!!''']]</div>
<div id="articlecount" style="width:100%;text-align:center;font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles available</div>
|}
|style="width:15%;font-size:95%"|
[[Image:Bzflag-48x48.png|right]]
*[http://my.bzflag.org/bb The Forums]
*[http://my.bzflag.org BZFlag Stats]
*[http://sourceforge.net/projects/bzflag/ BZFlag on SourceForge]

|}
Welcome to the BZFlag Wiki. The number of articles is growing, but there is much more to do. Please see the section '''Things To Do''' at the bottom of this page if you would like to help. The intention of this site is to draw together all of the great information about BZFlag and BZFlag related items that is currently scattered in many different places. Bringing all of this information together will make it easier for people to understand and answer all of the questions they have about running a server (options, permissions, set-up, etc.), configuring their client, coding plug-ins, compiling the source code, and anything else they can think of. All are welcome to contribute and may edit most pages. With everyone's help we can make this site a great resource to the BZFlag community. Please remember the BZFlag Wiki's new motto, [[BZFlagWiki:Be_bold|'''Be Bold''']] (click the link for a full explanation of the motto), when editing articles.

If you are unsure of how to edit or add pages, there is always a link to the [[Help:Contents|'''Help''']] section on the links to the left no matter where you are on the site. Don't be shy; give editing the site a try and be proud of your contributions! You can edit whether or not you have an account created. The advantage of having an account is that you will be credited with the contribution on the ''History'' link/tab of the page. Please take a look at the [[BZFlagWiki:Content Policy|Content Policy]] page for an overview of adding articles.

==Google Summer of Code ==
BZFlag was a mentor organization in the 2009 Google Summer of Code. For details, please see the [[Google Summer of Code/2009|2009 Summer of Code wiki page]].

==General Information==
*[[Getting Started|Quick Start]]
*[[Getting Help]]
*[[:Category:BZFlagWiki_Policy|BZFlag Wiki Policy]]

==Areas of Interest==
*[[:Category:Client|Client]]
*[[:Category:Compiling|Compiling]]
*[[:Category:Concepts|Concepts]]
*[[:Category:Development|Development]]
*[[:Category:Gameplay|Gameplay]]
*[[:Category:Installing|Installing]]
*[[:Category:Leagues|Leagues]]
*[[:Category:Map Making|Map Making]]
*[[:Category:Maps|Maps]]
*[[:Category:Plug-Ins|Plug-ins]]
*[[Releases]]
*[[:Category:Server|Server]]
*[[:Category:Support|Support]]
*[[:Category:Tactics|Tactics]]
*[[Versions]]

==Things To Do==
*[[:Category:Stubs|Stubs]] These are short pages. You can help by expanding the content and adding more detail.
*[[:Special:Wantedpages|Wanted pages]] These are pages which don't exist yet but are pointed to from other pages. You can help by creating them.
*[[:Category:Items to be merged|Pages to merge]] These are pages which are similar. It is suggested that similar pages be merged. You can help by reviewing the pairs of pages and commenting on any proposals by using the "Discussion" tab at the top of each page.
*[[:Category:Old|Pages with old info]] You can help by updating these pages.
*[[:Category:Inaccurate|Inaccurate pages]] You can help by updating these pages.
*[[:Category:Pending Deletions|Pending deletions]] These are pages which have been nominated for deletion. You can help by reviewing these pages and commenting on any proposals by using the "Discussion" tab at the top of each page.

Getting Started

2010-02-15T21:34:49Z

Bullet Catcher: /* Registering a callsign(Optional) */ remove SID from registration link, clean up wording

This article covers the basics of getting started with BZFlag. It is intended for new players who have just found the game and require assistance. More detailed help can be found on our [[Getting Help]] page.

==Getting Started==
These simple steps have been designed to allow new users to begin playing the game as quickly as possible.

===Downloading and installing the game===

The main thing users need to play is the game software. Users can [[Download]] the software for a number of different [http://en.wikipedia.org/wiki/Operating_system|operating systems].

====Windows====
The most common operating system for players is Microsoft Windows. A simple installer can be found at http://sourceforge.net/projects/bzflag/files/bzflag%20win32/2.0.14/bzflag-2.0.14.exe/download . Simply double click the downloaded file to install the game.

====Mac OSX====
The next most popular system for players is Apple's MacOS X for the Macintosh family of computers. The version for macs can be found at http://sourceforge.net/projects/bzflag/files/bzflag%20Mac%20OS%20X/2.0.14/BZFlag-2.0.14.dmg/download . Simply drag the BZFlag icon from the mounted DMG to your Applications folder to install the game.

====Linux====
The project does not distribute a premade binary package for linux, but many linux distrobutions have BZFlag in their package management systems ( APT, YUM, emerge, etc.. ). Linux users can always build the game from the source code. Please see the [[Download|downloads]] page for more information.

===Registering a callsign(Optional)===
It is not mandatory to register a callsign ( the name a player uses in-game), but it is highly recommended.

A few of the benefits of registering are:

* The callsign is reserved, and can not be used by any other player.
* Registered users can post on the BZFlag forums.
* Registered users can join leagues and global groups.
* Many servers require registration to play.

Users that wish to register can do so at the [http://my.bzflag.org/bb/ucp.php?mode=register BZFlag forums registration page].

===Running the game===

Once the game is installed, it must be run to play.

====Windows====
Windows users that have installed the game with the provided installer will find a shortcut to the game in the start menu, under program files. Users simply have to click this shortcut to start the game.

====Mac OS X====
Macintosh users simply have to double click the BZFlag icon that they dragged to their Applications folder to start the game.

====Linux====
Linux, and other unix based platforms can start the game by typing the command '''bzflag''' in a terminal.

===Joining a game===
When the game is first started it will show the main menu screen. Users navigate the menu by using the Up and Down arrow keys to highlight a menu item, and using the enter key to select and activate the highlighted item. The red tank on the left visually depicts what command line is the current focus.

{|
|-
|
====Main Menu====
The main menu includes a number of menu items that lead to sub menus. The most important menu for new players is the '''Join Game''' item.
|[[Image:MainMenu.png|right|thumb|300px|The Main Menu]]
|-
|

====Join Game Menu====
Users wishing to join an internet game in progress should choose the '''Join Game''' item from the main menu.

On the first run of the game software all the fields in the '''Join Game''' Menu will be empty. Players need to use the arrow keys to highlight the '''Callsign''' item and input a player name. This name will be how other players see the user. Registered users should use the same callsign that they registered when playing. Registered users should also enter in their password into the item marked '''Password'''. This password is only used for to verify your identity and is NEVER sent to the game server. The '''E-mail''' entry is optional and is usually used to put a personalized message, like a signature, by many users.

Once the callsign, password, and optional email sections have been filled out, the up and down arrows should be used to move up to the '''Find Server''' that is on top of this page. This is how you choose an existing, running server to play on. The '''Start Server''' option on the bottom of this page is for running a server off your own machine, generally for more advanced users. Hitting enter on '''Find Server''' will give you a list of BZ Flag games that are hosted on the internet by other users. There are often over 300 servers to choose from. The various types of games are explained in the objectives section below.

|[[Image:JoinGame.png|right|thumb|300px|]]
|-
|

====Server List====
The server list menu shows a listing of all publicly available internet games. The list is sorted by the number of players on each server at any time, and will dynamically change over time. The servers with the highest player counts will always be at the top of the list.

The various servers can be highlighted using the arrow keys, and additional information about the highlighted game will be shown at the top of the screen. Once the user has chosen a server to join they must hit the enter key to select the server and return to the Join Game Menu.

|[[Image:ServerList.png|right|thumb|300px|The Serverlist]]
|-
|

====Entering a Game====
When a server is choosen from the Server List, it's information will be automatically entered into the appropriate fields in the Join Game menu. The user may then choose a team color, or leave the setting on automatic if they wish the server to assign them to a team.

When all the information is entered, the user simply has to choose connect menu item, and they will join the game. If additional textures or resources are needed to join the game, they will be downloaded automatically.
|-
|

====Playing BZFlag====
Once the user has joined the game they will be able to enjoy the gameplay that has made BZFlag one of the most popular open source games in history.
|-
|

=====Controls=====
The basic controls for the game are rather simple.

By default the mouse is used for movement. Moving the mouse up and down will move the tank forwards and backwards, while moving the mouse left and right will cause the tank to turn in that direction. Returning the mouse to the center of the screen will cause the tank to stop moving.

The left mouse button is used to fire the tank's weapon.

Optionally the keyboard can be used. The arrow keys control movement in the same way as the mouse, and the space bar is used to drop the flag you are carrying. The 'enter' key is used to fire the tanks weapon

Some servers offer a feature that allows tanks to jump. The ''tab'' key is used to start a small jump into the air. When jumping a tank normally can not change its speed or direction until it lands. Depending on the map, it may be possible for tanks to jump and land on various world objects and continue to fight.
|-
|

=====Objective=====
BZFlag is a team game, and has various objectives depending on the game type.

The default game type is '''Free For All''', commonly abbreviated as ''FFA''. This mode is similar to a team death match in other first person shooting type games. The objective is to destroy as many tanks as possible on other teams, while minimizing your own losses. Tanks are destroyed by being shot, in most cases one shot is all it takes to kill an enemy tank.

'''Capture the Flag''', commonly abbreviated as ''CTF'', is another common game type. Its objective is to pick up the flag from an opposing team's base and return it to your base. This is known as capping, where all the members of the team whose flag you are capping are destroyed when you return their flag and land on your home base. Just as in the Free for All game, you shoot at the opposing teams tanks.

The least common type of game is '''Rabbit Hunt'''. In this game mode, one user is a white-colored '''rabbit''' tank, and everyone else is a orange-colored '''hunter''' tank. The '''hunter''' tank(s) must chase and kill the rabbit tank. The '''hunter''' tank which kills the '''rabbit''' tank then becomes the '''rabbit''' tank, although there is the rarer randomly generated '''rabbit''', particularly when the '''rabbit''' and '''hunter''' are destroyed at the same time.

There are also a variety of games designed to practice some particular skill. A few of these are jumping/climbing skills, wings/flying skills, mazes with puzzles to figure out, racing courses, and dodging bullets without jumping allowed.
|-
|

=====Non-Standard Teams=====

Usually, you may not shoot members of your own team. But, there is one exception to this rule, called the '''rogue''' team. '''Rogue''' tanks are black in the view window, and yellow on the radar. They may shoot their "teammates", and gain points for it. This is because '''rogue''' tanks are each on a one-man team of their own. '''Rogue''' tanks are usually found on '''Free For All''' maps, but are occasionally found on '''CTF''' maps.
|-Rogue.
|

=====Flags=====
There are four different kinds of flags on an average server:
* Team flags are colored to correspond with the teams on the map. The idea is to grab the other team's flag and bring it back to your base.
* Superflags are "power ups" for your tank. Some examples of superflags can be '''Guided Missile''' (Allows your tank to lock onto and shoot others), '''laser''' (Allows your tank to shoot an infinitely fast and long laser beam), and '''Stealth''' (Your tank does not appear on radar).
* Bad Flags restrict the movement or actions of your tank. Some bad flags are ''''No Jumping, Obesity, Trigger Happy,''' and '''Left turn only.'''
* Antidote flags are flags that appear only when you have a bad flag. Driving over an antidote flag removes the bad flag from your tank.
|-
|

=====Customizing Controls=====
You can alter most of the controls in the menu (or, if you prefer, by editing the BZFlag config file.)
In the menu it is located at Options > Input settings > Key mapping

To assign a keystroke, mouse button or joystick button to a particular command select the command with Up or Down arrows, press Enter and press the keystroke or button you wish to associate with that command.
You can assign two different keystrokes/buttons to a given command, by repeating the assignment process.

Note: you can assign a keystroke or button already in use for a different command, but if you do remember that the old command will be unmapped..

To delete an assignment select the command with Up or Down arrows and press Delete.
If the command has two assignments, the first (leftmost) assignment is deleted, and the second (rightmost) assignment takes its place.

|-
|

=====Interface Elements=====
Most of the interface elements can be changed in the GUI settings, or by editing the config file.
|-
|

======Scoreboard======
Once a player has joined a server, they should notice a number of things, including the scoreboard.

Internet games commonly feature between 5 and 20 players. The names of these players will be listed in the scoreboard on the left hand side of the screen. The scoreboard can be hidden and shown by using the ''S'' key. The scoreboard is usually set up to show a players name, score, teamkills, email string, flag, kills/deaths, and the amount of kills/deaths you have scored against that player. For example, in this scoreboard, player "Andrey" has a score of 2, 0 teamkills, and email string of "Andrey@andreypc", has the SW (shock wave) flag, has 8 kills, 6 deaths, and has been killed by player "me1" 0 times, and has killed player "me1" once. Flags whose names are in white are powerful flags. Team flags are always the color of that team on the scoreboard. Other flags are just the same color as the player using them.

|[[Image:Scoreboard.jpg|right|thumb|300px|The Scoreboard]]
|-
|
======Team Scoreboard======
There is also a scoreboard for team scores. In FFA this shows the kills, deaths, and overall score. In CTF this shows the amount of flags that team has captured, and the amount of times their flag was captured, and the score. Also, to the right is the amount of players on that team. The rogue team is never included on the team scoreboard.
|[[Image:Teamscoreboard.jpg|right|thumb|300px|The Team Scoreboard]]
|-
|

======Radar======
The [[Radar]] (In the bottom left), shows a bird's eye, 2d view of the map. This is useful for dodging bullets, and seeing where other players are in relation to the users' tank. The user's tank is displayed in the center of the radar, in white. Two lines from the user's "blip" on the radar represent the user's FOV (Field of view). The user's bullets are also displayed in white. Other teams are shown on the radar in their respective color, red shown in red, green shown in green, etc. The rogue team is shown in yellow. Flags are shown as little x's, and team flags as colored x's. A square is also around each radar "blip." This represents height. The larger the square, the higher something is. If a "blip" has an X through it, that tank has a flag.

|[[Image:Radar.jpg|right|thumb|300px|The Radar]]
|-
|

====Sportsmanship====

When playing BZFlag, it is important to keep a few simple rules in mind:

* Players should never shoot tanks on their own team (except for the rogue players).
* Players should be civil to other players in all respects.

|[[Image:Screenshot1.jpg|right|thumb|300px|A Screenshot of a standard 2.0.9 client playing on Missile War 2]]
|}

Getting Started

2010-02-15T20:48:03Z

Bullet Catcher: update direct links to Windows and Mac software

This article covers the basics of getting started with BZFlag. It is intended for new players who have just found the game and require assistance. More detailed help can be found on our [[Getting Help]] page.

==Getting Started==
These simple steps have been designed to allow new users to begin playing the game as quickly as possible.

===Downloading and installing the game===

The main thing users need to play is the game software. Users can [[Download]] the software for a number of different [http://en.wikipedia.org/wiki/Operating_system|operating systems].

====Windows====
The most common operating system for players is Microsoft Windows. A simple installer can be found at http://sourceforge.net/projects/bzflag/files/bzflag%20win32/2.0.14/bzflag-2.0.14.exe/download . Simply double click the downloaded file to install the game.

====Mac OSX====
The next most popular system for players is Apple's MacOS X for the Macintosh family of computers. The version for macs can be found at http://sourceforge.net/projects/bzflag/files/bzflag%20Mac%20OS%20X/2.0.14/BZFlag-2.0.14.dmg/download . Simply drag the BZFlag icon from the mounted DMG to your Applications folder to install the game.

====Linux====
The project does not distribute a premade binary package for linux, but many linux distrobutions have BZFlag in their package management systems ( APT, YUM, emerge, etc.. ). Linux users can always build the game from the source code. Please see the [[Download|downloads]] page for more information.

===Registering a callsign(Optional)===
It is not mandatory to register a callsign ( the name a player uses in-game), but it is highly recommended.

A few of the benefits of registering are:

* The callsign is reserved, and can not be used by any other player.
* Registered users post on the BZFlag forums
* Registered users can join global groups, and leagues.
* Many servers require registration to play.

Users that wish to register can simply do so on the BZFlag forums at [http://my.bzflag.org/bb/ucp.php?mode=register&sid=61d6ebbc0f4e1763d94200a18619c0d4 my.bzflag.org/bb]

===Running the game===

Once the game is installed, it must be run to play.

====Windows====
Windows users that have installed the game with the provided installer will find a shortcut to the game in the start menu, under program files. Users simply have to click this shortcut to start the game.

====Mac OS X====
Macintosh users simply have to double click the BZFlag icon that they dragged to their Applications folder to start the game.

====Linux====
Linux, and other unix based platforms can start the game by typing the command '''bzflag''' in a terminal.

===Joining a game===
When the game is first started it will show the main menu screen. Users navigate the menu by using the Up and Down arrow keys to highlight a menu item, and using the enter key to select and activate the highlighted item. The red tank on the left visually depicts what command line is the current focus.

{|
|-
|
====Main Menu====
The main menu includes a number of menu items that lead to sub menus. The most important menu for new players is the '''Join Game''' item.
|[[Image:MainMenu.png|right|thumb|300px|The Main Menu]]
|-
|

====Join Game Menu====
Users wishing to join an internet game in progress should choose the '''Join Game''' item from the main menu.

On the first run of the game software all the fields in the '''Join Game''' Menu will be empty. Players need to use the arrow keys to highlight the '''Callsign''' item and input a player name. This name will be how other players see the user. Registered users should use the same callsign that they registered when playing. Registered users should also enter in their password into the item marked '''Password'''. This password is only used for to verify your identity and is NEVER sent to the game server. The '''E-mail''' entry is optional and is usually used to put a personalized message, like a signature, by many users.

Once the callsign, password, and optional email sections have been filled out, the up and down arrows should be used to move up to the '''Find Server''' that is on top of this page. This is how you choose an existing, running server to play on. The '''Start Server''' option on the bottom of this page is for running a server off your own machine, generally for more advanced users. Hitting enter on '''Find Server''' will give you a list of BZ Flag games that are hosted on the internet by other users. There are often over 300 servers to choose from. The various types of games are explained in the objectives section below.

|[[Image:JoinGame.png|right|thumb|300px|]]
|-
|

====Server List====
The server list menu shows a listing of all publicly available internet games. The list is sorted by the number of players on each server at any time, and will dynamically change over time. The servers with the highest player counts will always be at the top of the list.

The various servers can be highlighted using the arrow keys, and additional information about the highlighted game will be shown at the top of the screen. Once the user has chosen a server to join they must hit the enter key to select the server and return to the Join Game Menu.

|[[Image:ServerList.png|right|thumb|300px|The Serverlist]]
|-
|

====Entering a Game====
When a server is choosen from the Server List, it's information will be automatically entered into the appropriate fields in the Join Game menu. The user may then choose a team color, or leave the setting on automatic if they wish the server to assign them to a team.

When all the information is entered, the user simply has to choose connect menu item, and they will join the game. If additional textures or resources are needed to join the game, they will be downloaded automatically.
|-
|

====Playing BZFlag====
Once the user has joined the game they will be able to enjoy the gameplay that has made BZFlag one of the most popular open source games in history.
|-
|

=====Controls=====
The basic controls for the game are rather simple.

By default the mouse is used for movement. Moving the mouse up and down will move the tank forwards and backwards, while moving the mouse left and right will cause the tank to turn in that direction. Returning the mouse to the center of the screen will cause the tank to stop moving.

The left mouse button is used to fire the tank's weapon.

Optionally the keyboard can be used. The arrow keys control movement in the same way as the mouse, and the space bar is used to drop the flag you are carrying. The 'enter' key is used to fire the tanks weapon

Some servers offer a feature that allows tanks to jump. The ''tab'' key is used to start a small jump into the air. When jumping a tank normally can not change its speed or direction until it lands. Depending on the map, it may be possible for tanks to jump and land on various world objects and continue to fight.
|-
|

=====Objective=====
BZFlag is a team game, and has various objectives depending on the game type.

The default game type is '''Free For All''', commonly abbreviated as ''FFA''. This mode is similar to a team death match in other first person shooting type games. The objective is to destroy as many tanks as possible on other teams, while minimizing your own losses. Tanks are destroyed by being shot, in most cases one shot is all it takes to kill an enemy tank.

'''Capture the Flag''', commonly abbreviated as ''CTF'', is another common game type. Its objective is to pick up the flag from an opposing team's base and return it to your base. This is known as capping, where all the members of the team whose flag you are capping are destroyed when you return their flag and land on your home base. Just as in the Free for All game, you shoot at the opposing teams tanks.

The least common type of game is '''Rabbit Hunt'''. In this game mode, one user is a white-colored '''rabbit''' tank, and everyone else is a orange-colored '''hunter''' tank. The '''hunter''' tank(s) must chase and kill the rabbit tank. The '''hunter''' tank which kills the '''rabbit''' tank then becomes the '''rabbit''' tank, although there is the rarer randomly generated '''rabbit''', particularly when the '''rabbit''' and '''hunter''' are destroyed at the same time.

There are also a variety of games designed to practice some particular skill. A few of these are jumping/climbing skills, wings/flying skills, mazes with puzzles to figure out, racing courses, and dodging bullets without jumping allowed.
|-
|

=====Non-Standard Teams=====

Usually, you may not shoot members of your own team. But, there is one exception to this rule, called the '''rogue''' team. '''Rogue''' tanks are black in the view window, and yellow on the radar. They may shoot their "teammates", and gain points for it. This is because '''rogue''' tanks are each on a one-man team of their own. '''Rogue''' tanks are usually found on '''Free For All''' maps, but are occasionally found on '''CTF''' maps.
|-Rogue.
|

=====Flags=====
There are four different kinds of flags on an average server:
* Team flags are colored to correspond with the teams on the map. The idea is to grab the other team's flag and bring it back to your base.
* Superflags are "power ups" for your tank. Some examples of superflags can be '''Guided Missile''' (Allows your tank to lock onto and shoot others), '''laser''' (Allows your tank to shoot an infinitely fast and long laser beam), and '''Stealth''' (Your tank does not appear on radar).
* Bad Flags restrict the movement or actions of your tank. Some bad flags are ''''No Jumping, Obesity, Trigger Happy,''' and '''Left turn only.'''
* Antidote flags are flags that appear only when you have a bad flag. Driving over an antidote flag removes the bad flag from your tank.
|-
|

=====Customizing Controls=====
You can alter most of the controls in the menu (or, if you prefer, by editing the BZFlag config file.)
In the menu it is located at Options > Input settings > Key mapping

To assign a keystroke, mouse button or joystick button to a particular command select the command with Up or Down arrows, press Enter and press the keystroke or button you wish to associate with that command.
You can assign two different keystrokes/buttons to a given command, by repeating the assignment process.

Note: you can assign a keystroke or button already in use for a different command, but if you do remember that the old command will be unmapped..

To delete an assignment select the command with Up or Down arrows and press Delete.
If the command has two assignments, the first (leftmost) assignment is deleted, and the second (rightmost) assignment takes its place.

|-
|

=====Interface Elements=====
Most of the interface elements can be changed in the GUI settings, or by editing the config file.
|-
|

======Scoreboard======
Once a player has joined a server, they should notice a number of things, including the scoreboard.

Internet games commonly feature between 5 and 20 players. The names of these players will be listed in the scoreboard on the left hand side of the screen. The scoreboard can be hidden and shown by using the ''S'' key. The scoreboard is usually set up to show a players name, score, teamkills, email string, flag, kills/deaths, and the amount of kills/deaths you have scored against that player. For example, in this scoreboard, player "Andrey" has a score of 2, 0 teamkills, and email string of "Andrey@andreypc", has the SW (shock wave) flag, has 8 kills, 6 deaths, and has been killed by player "me1" 0 times, and has killed player "me1" once. Flags whose names are in white are powerful flags. Team flags are always the color of that team on the scoreboard. Other flags are just the same color as the player using them.

|[[Image:Scoreboard.jpg|right|thumb|300px|The Scoreboard]]
|-
|
======Team Scoreboard======
There is also a scoreboard for team scores. In FFA this shows the kills, deaths, and overall score. In CTF this shows the amount of flags that team has captured, and the amount of times their flag was captured, and the score. Also, to the right is the amount of players on that team. The rogue team is never included on the team scoreboard.
|[[Image:Teamscoreboard.jpg|right|thumb|300px|The Team Scoreboard]]
|-
|

======Radar======
The [[Radar]] (In the bottom left), shows a bird's eye, 2d view of the map. This is useful for dodging bullets, and seeing where other players are in relation to the users' tank. The user's tank is displayed in the center of the radar, in white. Two lines from the user's "blip" on the radar represent the user's FOV (Field of view). The user's bullets are also displayed in white. Other teams are shown on the radar in their respective color, red shown in red, green shown in green, etc. The rogue team is shown in yellow. Flags are shown as little x's, and team flags as colored x's. A square is also around each radar "blip." This represents height. The larger the square, the higher something is. If a "blip" has an X through it, that tank has a flag.

|[[Image:Radar.jpg|right|thumb|300px|The Radar]]
|-
|

====Sportsmanship====

When playing BZFlag, it is important to keep a few simple rules in mind:

* Players should never shoot tanks on their own team (except for the rogue players).
* Players should be civil to other players in all respects.

|[[Image:Screenshot1.jpg|right|thumb|300px|A Screenshot of a standard 2.0.9 client playing on Missile War 2]]
|}

BZFlag 2.0.14

2010-02-14T23:27:45Z

Bullet Catcher: /* Change Log */ include final 2.0.14 changelog

BZFlag version 2.0.14 '''"This isn't the release you are looking for"''', is the current maintenance version of the BZFlag game for Windows, Apple OSX, and Linux. It was released on 02/15/2010.
It is being released primarily to fix a number of small issues that have been found in 2.0.12, and to replace the fonts due to licensing issues. The version is also being used to provide a set of binary updates for Windows and OSX, most notably support for Intel based Macintosh computers.

The version contains no new major features, but does have a few bugfixes and back-ports from Version 3.

==Change Log==
* Add Options -> Display -> AntiFlicker option - trepan
* Add Options -> Input -> Confine Mouse (MotionBox) - trepan
* Adjust advanced ground rendering for texture flicker - trepan
* Change the default stencil bitplanes to 1 to fix stencil shadows and various other stencil features - trepan
* Backport fix for /idbanlist and /hostbanlist crashes - trepan
* Add support for gcc-4.4 and libtool-2.2 - Jeff Makey
* Update to Microsoft Visual C++ 9 from 8.0 - Jeff Myers
* Update to directInput 8 from 7 - Jeff Myers
* Fix player ghosting failure - Steven Mertens
* Provide API support for using bz_moveFlag on team flags - Scott Wichser
* Add pushstats plugin for future statistics gathering system - Jeff Myers
* Increase restrictions on incompletely joined players - Jeff Myers, Scott W.
* Announce saved file name in recordmatch plugin - Jeff Makey
* Fix buffer overflow in menu subsystem - Jeff Myers
* Fully support glob-style wildcards in hostbans and make name comparisons case insensitive - Bryan Jennings
* Properly limit maximum message size in /showgroup command - Jeff Makey
* Reset team scores in case of a capture during a countdown - Jeff Makey
* Block spoofed /me messages - Scott Wichser
* Keep flags within the world boundary - Jeff Makey
* Add the "roamView" BZDB variable - trepan
* Change fonts to DejaVu - Jeff Myers, Tim Riker
* Source cleanup - Tim Riker

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

Fastmap

2009-11-13T18:27:43Z

Bullet Catcher: minor clarification, link to the correct HTTPServer page

When the BZFlag client downloads a server map via its usual TCP connection, the speed is limited by the server to 1 KB per frame. This can cause large maps to take many seconds to download, straining the patience of eager players.

The fastmap plugin provides for the transfer of the server's BZW map file in a separate HTTP connection, allowing much faster download (hence the name, fastmap). No changes to the map file are required to take advantage of this.

This plugin requires the [[HTTPServer]] plugin to either be in the same directory as fastmap.so, or to be previously loaded. Unlike other HTTP server plugins, fastmap does not create a virtual directory.

Fastmap

2009-11-12T18:27:39Z

Bullet Catcher: substantial rewrite for clarity

When the BZFlag client downloads a server map via its usual TCP connection, the speed is limited by the server to 1 KB per frame. This can cause large maps to take many seconds to download, straining the patience of eager players.

The fastmap plugin provides for the transfer of the server's BZW map file in a separate HTTP connection, allowing much faster download (hence the name, fastmap). No changes to the map file are required to take advantage of this.

This plugin requires the [[HTTPServer plugin]] to either be in the same directory as fastmap.so, or to be previously loaded. Unlike other HTTPD plugins, Fastmap does not create a virtual directory.

Replay Server

2009-11-12T00:14:26Z

Bullet Catcher: /* Recording Setup */ put sample code in italics

"Replay" is a feature that allows admins to record a match to a circular buffer and optionally store a portion of the recording to a file.

== Recording Setup ==
To prepare your server to allow recording to a file, make sure to specify ''-recdir /path/to/record/dir'', make sure /path/to/record/dir is writable by the same user that bzfs is running as. Without the ''-recdir'' option, replay files will be saved in a directory named ''recordings'' in the parent directory above your [[Config File]] (''~/.bzf/recordings'' on Linux systems, for example).

It may also be a good idea to limit the size of the record buffer (this is taken from RAM), and will also automatically start the record buffer with the specified size (in Megabytes). For instance ''-recbuf 16''.

== Replay Setup ==
Although you could restart your server in replay mode each time you'd like to playback a match, its recommended that you run a separate server on a separate port as a replay server. Again, you must specify ''-recdir /path/to/record/dir'', but for replay mode also specify the ''-replay'' command line option. If you want this to be a public server, consider using the ''-advertise'' option to advertise only to your admin group(s).

== How to Record ==
If during the game, you see something you'd like to record, first you must be in a group with the '''RECORD''' privilege. Use the ''/record save <filename> [seconds]'' command. [seconds] is how many seconds you'd like to go back into the buffer to save to disk. If this recording is for administrative purposes, it may be a good idea to use a descriptive name for the filename. Try using playername.offense.ipaddress. This will help others who view the file know who they should be watching during playback. If it is for a league match, try using team1name.vs.team2name.

== How to Playback ==
Once you've made your recording, log into your playback server, and use the ''/replay list'' command, which will give you a directory listing of the directory you specified with ''-recdir''. Once you see the file you'd like to lay back, take note of the filename, or the #index, then use the ''/replay load filename'' or ''/replay load #index'' to load the file. If you load a file that isn't compatible with the map currently loaded on the server, you'll get a message like this:
{|
|
SERVER: An incompatible recording has been loaded
SERVER: Please rejoin or face the consequences (client crashes)
|}
If you see this message, simply rejoin. If you don't your client will close/crash. If that happens, don't fret, just start it back up and it'll work fine. When you're ready to start do ''/replay play''.

== Command Reference ==

The instructions above will get you started, but there are many more commands that may prove useful. Below is an explanation of each.
{|{{Prettytable}}
| {{Hl3}} | '''Command'''
| {{Hl3}} | '''Description'''
|-
|'''/record list '''
|List all files in the recordings directory
|-
|'''/record start '''
|Start recording into the memory buffer
|-
|'''/record stop '''
|Stop recording into the memory buffer
|-
|'''/record size <megabytes> '''
|Set the size of the recording memory buffer
|-
|'''/record rate <seconds> '''
|Set the time between game state updates stored in the recording. This will affect the granularity of the 'skips' you can do while replaying a file. It will also make the recording files bigger if it is set to a faster update rate.
|-
|'''/record stats '''
|Display the statistics for the current recording (file or buffered)
|-
|'''/record file <filename> '''
|Start recording directly to a file
|-
|'''/record save <filename> [seconds] '''
|Save the recording buffer into a file. If seconds is specified, then only save that many previous seconds into the file.
|-
|'''/replay list '''
|List all files in the recordings directory
|-
|'''/replay load <nowiki><filename|#index></nowiki>'''
|Load the specified recording file by name, or by index (same indices as produced by the 'replay list' command)
|-
|'''/replay loop'''
|Same as ''/replay play'' except recording will wrap at the end and play in a loop
|-
|'''/replay pause'''
|Pause the replay. When you use this, the recording appears to all go [nr] (not responding), to unpause, use the '''/replay play''' command. ''(undocumented in game)''
|-
|'''/replay play '''
|Start playing the recording. This will oftentimes require that all players connected to the server rejoin (to reload the map, etc...)
|-
|'''/replay skip [+/- seconds] '''
|If seconds is specified, then skip that amount of time in the recording. Otherwise, skip forwards until there is activity.
|}

== Replay File Contents ==

In addition to all of the movement information necessary to recreate a game, saved replay files include all of the commands sent by clients. This means that team chat, private messages, and any /password commands are all there to be seen by anyone with access to a replay file. Please be careful when sharing replay files to avoid unwanted exposure of private conversations or the server password.

[[Category:Server]]

Replay Server

2009-11-12T00:11:34Z

Bullet Catcher: /* Recording Setup */ tell where to find replay files in the absence of -recdir

"Replay" is a feature that allows admins to record a match to a circular buffer and optionally store a portion of the recording to a file.

== Recording Setup ==
To prepare your server to allow recording to a file, make sure to specify ''-recdir /path/to/record/dir'', make sure /path/to/record/dir is writable by the same user that bzfs is running as. Without the -recdir option, replay files will be saved in a directory named "recordings" in the parent directory above your [[Config File]] (~/.bzf/recordings on Linux systems, for example).

It may also be a good idea to limit the size of the record buffer (this is taken from RAM), and will also automatically start the record buffer with the specified size (in Megabytes). For instance ''-recbuf 16''.

== Replay Setup ==
Although you could restart your server in replay mode each time you'd like to playback a match, its recommended that you run a separate server on a separate port as a replay server. Again, you must specify ''-recdir /path/to/record/dir'', but for replay mode also specify the ''-replay'' command line option. If you want this to be a public server, consider using the ''-advertise'' option to advertise only to your admin group(s).

== How to Record ==
If during the game, you see something you'd like to record, first you must be in a group with the '''RECORD''' privilege. Use the ''/record save <filename> [seconds]'' command. [seconds] is how many seconds you'd like to go back into the buffer to save to disk. If this recording is for administrative purposes, it may be a good idea to use a descriptive name for the filename. Try using playername.offense.ipaddress. This will help others who view the file know who they should be watching during playback. If it is for a league match, try using team1name.vs.team2name.

== How to Playback ==
Once you've made your recording, log into your playback server, and use the ''/replay list'' command, which will give you a directory listing of the directory you specified with ''-recdir''. Once you see the file you'd like to lay back, take note of the filename, or the #index, then use the ''/replay load filename'' or ''/replay load #index'' to load the file. If you load a file that isn't compatible with the map currently loaded on the server, you'll get a message like this:
{|
|
SERVER: An incompatible recording has been loaded
SERVER: Please rejoin or face the consequences (client crashes)
|}
If you see this message, simply rejoin. If you don't your client will close/crash. If that happens, don't fret, just start it back up and it'll work fine. When you're ready to start do ''/replay play''.

== Command Reference ==

The instructions above will get you started, but there are many more commands that may prove useful. Below is an explanation of each.
{|{{Prettytable}}
| {{Hl3}} | '''Command'''
| {{Hl3}} | '''Description'''
|-
|'''/record list '''
|List all files in the recordings directory
|-
|'''/record start '''
|Start recording into the memory buffer
|-
|'''/record stop '''
|Stop recording into the memory buffer
|-
|'''/record size <megabytes> '''
|Set the size of the recording memory buffer
|-
|'''/record rate <seconds> '''
|Set the time between game state updates stored in the recording. This will affect the granularity of the 'skips' you can do while replaying a file. It will also make the recording files bigger if it is set to a faster update rate.
|-
|'''/record stats '''
|Display the statistics for the current recording (file or buffered)
|-
|'''/record file <filename> '''
|Start recording directly to a file
|-
|'''/record save <filename> [seconds] '''
|Save the recording buffer into a file. If seconds is specified, then only save that many previous seconds into the file.
|-
|'''/replay list '''
|List all files in the recordings directory
|-
|'''/replay load <nowiki><filename|#index></nowiki>'''
|Load the specified recording file by name, or by index (same indices as produced by the 'replay list' command)
|-
|'''/replay loop'''
|Same as ''/replay play'' except recording will wrap at the end and play in a loop
|-
|'''/replay pause'''
|Pause the replay. When you use this, the recording appears to all go [nr] (not responding), to unpause, use the '''/replay play''' command. ''(undocumented in game)''
|-
|'''/replay play '''
|Start playing the recording. This will oftentimes require that all players connected to the server rejoin (to reload the map, etc...)
|-
|'''/replay skip [+/- seconds] '''
|If seconds is specified, then skip that amount of time in the recording. Otherwise, skip forwards until there is activity.
|}

== Replay File Contents ==

In addition to all of the movement information necessary to recreate a game, saved replay files include all of the commands sent by clients. This means that team chat, private messages, and any /password commands are all there to be seen by anyone with access to a replay file. Please be careful when sharing replay files to avoid unwanted exposure of private conversations or the server password.

[[Category:Server]]

Replay Server

2009-11-11T23:58:02Z

Bullet Catcher: add Replay File Contents section

"Replay" is a feature that allows admins to record a match to a circular buffer and optionally store a portion of the recording to a file.

== Recording Setup ==
To prepare your server to allow recording to a file, make sure to specify ''-recdir /path/to/record/dir'', make sure /path/to/record/dir is writable by the same user that bzfs is running as. It may also be a good idea to limit the size of the record buffer (this is taken from RAM), and will also automatically start the record buffer with the specified size (in Megabytes). For instance ''-recbuf 16''.

== Replay Setup ==
Although you could restart your server in replay mode each time you'd like to playback a match, its recommended that you run a separate server on a separate port as a replay server. Again, you must specify ''-recdir /path/to/record/dir'', but for replay mode also specify the ''-replay'' command line option. If you want this to be a public server, consider using the ''-advertise'' option to advertise only to your admin group(s).

== How to Record ==
If during the game, you see something you'd like to record, first you must be in a group with the '''RECORD''' privilege. Use the ''/record save <filename> [seconds]'' command. [seconds] is how many seconds you'd like to go back into the buffer to save to disk. If this recording is for administrative purposes, it may be a good idea to use a descriptive name for the filename. Try using playername.offense.ipaddress. This will help others who view the file know who they should be watching during playback. If it is for a league match, try using team1name.vs.team2name.

== How to Playback ==
Once you've made your recording, log into your playback server, and use the ''/replay list'' command, which will give you a directory listing of the directory you specified with ''-recdir''. Once you see the file you'd like to lay back, take note of the filename, or the #index, then use the ''/replay load filename'' or ''/replay load #index'' to load the file. If you load a file that isn't compatible with the map currently loaded on the server, you'll get a message like this:
{|
|
SERVER: An incompatible recording has been loaded
SERVER: Please rejoin or face the consequences (client crashes)
|}
If you see this message, simply rejoin. If you don't your client will close/crash. If that happens, don't fret, just start it back up and it'll work fine. When you're ready to start do ''/replay play''.

== Command Reference ==

The instructions above will get you started, but there are many more commands that may prove useful. Below is an explanation of each.
{|{{Prettytable}}
| {{Hl3}} | '''Command'''
| {{Hl3}} | '''Description'''
|-
|'''/record list '''
|List all files in the recordings directory
|-
|'''/record start '''
|Start recording into the memory buffer
|-
|'''/record stop '''
|Stop recording into the memory buffer
|-
|'''/record size <megabytes> '''
|Set the size of the recording memory buffer
|-
|'''/record rate <seconds> '''
|Set the time between game state updates stored in the recording. This will affect the granularity of the 'skips' you can do while replaying a file. It will also make the recording files bigger if it is set to a faster update rate.
|-
|'''/record stats '''
|Display the statistics for the current recording (file or buffered)
|-
|'''/record file <filename> '''
|Start recording directly to a file
|-
|'''/record save <filename> [seconds] '''
|Save the recording buffer into a file. If seconds is specified, then only save that many previous seconds into the file.
|-
|'''/replay list '''
|List all files in the recordings directory
|-
|'''/replay load <nowiki><filename|#index></nowiki>'''
|Load the specified recording file by name, or by index (same indices as produced by the 'replay list' command)
|-
|'''/replay loop'''
|Same as ''/replay play'' except recording will wrap at the end and play in a loop
|-
|'''/replay pause'''
|Pause the replay. When you use this, the recording appears to all go [nr] (not responding), to unpause, use the '''/replay play''' command. ''(undocumented in game)''
|-
|'''/replay play '''
|Start playing the recording. This will oftentimes require that all players connected to the server rejoin (to reload the map, etc...)
|-
|'''/replay skip [+/- seconds] '''
|If seconds is specified, then skip that amount of time in the recording. Otherwise, skip forwards until there is activity.
|}

== Replay File Contents ==

In addition to all of the movement information necessary to recreate a game, saved replay files include all of the commands sent by clients. This means that team chat, private messages, and any /password commands are all there to be seen by anyone with access to a replay file. Please be careful when sharing replay files to avoid unwanted exposure of private conversations or the server password.

[[Category:Server]]

Recordmatch

2009-10-30T16:45:38Z

Bullet Catcher: /* Usage */ Link to instructions for setting up recording.

Recordmatch is a standard [[Plug-ins|plug-in]] that is shipped with the [[BZFlag Source|source code]]. It allows for match games, such as league matches, to be recorded onto the server to be replayed later. It will automatically record when a game (match) is started, and it will record with a filename given by the current date and time. Recordmatch is included in [[BZFlag 2.0.6|v2.0.6]] and later releases.

==Usage==
Before trying to use this plug-in, [[Replay_Server#Recording_Setup|configure]] bzfs to support recording.

When the recordmatch plug-in is loaded, it waits for a match game to be started. When a game is started, it will create a new file to store the recording, named with the current date and time. When the game is ended, it will stop recording and close the file. The plug-in is loaded in the same way as any other and takes no parameters:

-loadplugin "/path/to/the/plugin/recordmatch"

or with the in game commands if the server is already running:

/loadplugin "/path/to/the/plugin/recordmatch"

The "-loadplugin" syntax is used in the [[sample conf|server configuration]] file or at the command line when invoking a game [[BZFS|server]].

Be sure that you have in the configuration file:
* -time X (Where X is the number of seconds of a match)
* -timemanual

==Commands==
For most match servers for leagues the players will have the following commands:

* /countdown "Will start the match"
* /gameover "Will end the match immediately.
* /timelimit X "Allows player to change the time limit to X, where X is the number of seconds"

==History==
The BZFS API was changed in the development of [[BZFlag 2.0.6|v2.0.6]] to allow for recordings to be started. Recordmatch is the first plug-in to use the newly-added capability.

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

BZFlag on IRC

2009-10-14T05:35:22Z

Bullet Catcher: /* Other projects and unofficial channels */ #hepcat -> ##hepcat

=FreeNode=
The official BZFlag org. and its associated communities use the [http://freenode.net/ freenode IRC network] for communication and collaboration.

==Channels==
===Official channels===
BZFlag maintains 2 official channels run by the org.
====#bzflag====
The [irc://irc.freenode.net/bzflag #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'''

====#bzflag-chat====
The #bzflag-chat channel is a more informal channel designated for player community discussions.

===Other projects and unofficial 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)
* #badgerking (Official Channel for Badgerking's FFA)
* #BoomBZ (Team Channel for GU team [BoOm])
* ##bz-inc (DUCLeague team, [http://my.bzflag.org/league/index.php?link=teaminfo&id=689/ Bz-Incorporated])
* ##bzexcess (Support channel for the [http://bzexcess.com BZExcess.com servers.])
* ##bzflagr (Support channel for the [http://bzflagr.net BZFlagr.net servers.]) - closed down
* #bzfx (Support channel for the bzfx.net BZFlag servers)
* ##bzpod (Channel to discuss the BZFlag podcast, BZPod)
* ##bzpro (Support channel for the [http://bzpro.net BZPro.net servers.])
* ##bztank (Unofficial support channel for the [http://bztank.net BZTank.net servers].)
* #bztraining (Official support channel for the [http://bztraining.org BZTraining server network] and for [http://bznetwork.googlecode.com BZNetwork])
* ##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 Invasive Chaotic Frenzies, (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]) ''defunct''
* #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])

When the Freenode Group Management System is implemented, channels with a single # will need to either register their organization with Freenode or rename to begin with ## (a "reference" channel, one that holds no legal claim to the name).

=stormcenter.net=
An unofficial bzflag channel is run on irc.stormcenter.net
* #bzflag (official support channel for [http://www.bztank.net BZtank] servers)

=IRC Clients=
To access the IRC network you need to use an IRC client. [http://irchelp.org/ http://irchelp.org/] is an excellent resource for more information on general IRC.

=External links=
*[http://irchelp.org/ IRC help docs]

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

Plug-ins

2009-09-05T22:35:20Z

Bullet Catcher: /* Third Party Plug-ins */ provide instructions for compiling

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 a simpler way to apply modifications to the game, as they do not require the server owner to modify or recompile his/her BZFS application. By using the [[BZFS API]] plug-ins are also able to be mixed and matched in an easy way.

==Overview==
Plug-ins are compile 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'''
# To save time type ''ctrl/c'' to stop the command when it says "Running autogen.sh, please wait..."
# 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 run '''autogen.sh''', '''configure''', and '''make''' as usual

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

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

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

Plug-ins

2009-09-05T22:11:15Z

Bullet Catcher: /* Standard plug-ins */ update the list

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 a simpler way to apply modifications to the game, as they do not require the server owner to modify or recompile his/her BZFS application. By using the [[BZFS API]] plug-ins are also able to be mixed and matched in an easy way.

==Overview==
Plug-ins are compile 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].

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

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

V3RCChecklist

2009-09-03T18:28:42Z

Bullet Catcher: /* RC Critical fixes. */ 32-bit teleporter problem is not critical, and no fix is in sight

==Overview==
V3.0 is very close to a release candidate. This page will list the remaining items that need to be addressed before an RC can be made.

==RC Critical fixes.==
# MsgPause fix '''<trepan>'''
# Network data is being received or processed by the client in the opposite order causing many odd bugs, such as the motto not being displayed, and possibly causing players' flags from not showing up when you join.

==RC Critical Tasks==
# Windows installer review (install VC9 runtimes etc..)
# Linux Package review (new files in the right places )
# Mac installer review (check it in)
# Readme Updates
# Docs for V3 changes (-a missing, caps on server, lag comp, etc..)
# API review (spelling, consistency)
# Dead-reckoning / lag-compensation testing '''<JeffM ? >'''

==RC 'really nice' features ==
# Ask user to accept non bzflag.org images '''<trepan>'''
# Ask user to join non bzflag.org servers (MsgJoinServer) '''<trepan>'''
# Parity mesh checks to replace inside/outside points '''<trepan>'''

==RC 'really nice' Fixes/Tasks==
# Webadmin template review ( for style )

Auto-props

2009-08-18T05:14:54Z

Bullet Catcher: Add Subversion property specification for .def extension.

Developers should make sure their Subversion auto-props are set correctly before committing to [[SVN]]. This helps preserve the correct line endings across platforms. This is the "standard" auto-props section we are using (you may of course set your own if you prefer). You'll need to edit your config file(s), which varies depending on platform and Subversion client.

For UNIX-like platforms, edit your ''~/.subversion/config'' file to set the auto-props. For Windows Vista, the path is ''C:\Users\YOUR_USERNAME\AppData\Roaming\Subversion\config'' And for Windows XP, the path is ''C:\Documents and Settings\YOUR_USERNAME\Application Data\Subversion\config'' Also, please be sure that you uncomment the '''enable-auto-props''' option and set it to yes.

<pre>
### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.cxx = svn:eol-style=native
*.def = svn:eol-style=native
*.h = svn:eol-style=native
*.pl = svn:eol-style=native
*.py = svn:eol-style=native
*.php = svn:eol-style=native

*.po = svn:eol-style=native
*.am = svn:eol-style=native
*.ac = svn:eol-style=native
*.in = svn:eol-style=native
*.m4 = svn:eol-style=native

*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sln = svn:eol-style=CRLF
*.vcproj = svn:eol-style=CRLF
*.nsi = svn:eol-style=CRLF
*.manifest = svn:eol-style=CRLF

*.sh = svn:eol-style=native;svn:executable
*.bat = svn:eol-style=native;svn:mime-type=text/plain

*.txt = svn:eol-style=native;svn:mime-type=text/plain
README = svn:eol-style=native;svn:mime-type=text/plain
*.html = svn:eol-style=native;svn:mime-type=text/html
*.css = svn:eol-style=native;svn:mime-type=text/css
*.xml = svn:eol-style=native;svn:mime-type=text/xml
*.bzw = svn:eol-style=native

*.xpm = svn:eol-style=native;svn:mime-type=image/x-xpm
*.svg = svn:eol-style=native;svn:mime-type=image/svg+xml
*.bmp = svn:mime-type=image/bmp
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.ogg = svn:mime-type=application/ogg
*.wav = svn:mime-type=audio/x-wav
*.ttf = svn:mime-type=application/octet-stream
*.ico = svn:mime-type=application/octet-stream
*.rgb = svn:mime-type=image/x-rgb
</pre>

[[Category:Development]]

Auto-props

2009-06-03T14:34:38Z

Bullet Catcher: Add Subversion property specification for .svg extension.

Developers should make sure their Subversion auto-props are set correctly before committing to [[SVN]]. This helps preserve the correct line endings across platforms. This is the "standard" auto-props section we are using (you may of course set your own if you prefer). You'll need to edit your config file(s), which varies depending on platform and Subversion client.

For UNIX-like platforms, edit your ''~/.subversion/config'' file to set the auto-props. For Windows Vista, the path is ''C:\Users\YOUR_USERNAME\AppData\Roaming\Subversion\config'' And for Windows XP, the path is ''C:\Documents and Settings\YOUR_USERNAME\Application Data\Subversion\config'' Also, please be sure that you uncomment the '''enable-auto-props''' option and set it to yes.

<pre>
### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.cxx = svn:eol-style=native
*.h = svn:eol-style=native
*.pl = svn:eol-style=native
*.py = svn:eol-style=native
*.php = svn:eol-style=native

*.po = svn:eol-style=native
*.am = svn:eol-style=native
*.ac = svn:eol-style=native
*.in = svn:eol-style=native
*.m4 = svn:eol-style=native

*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sln = svn:eol-style=CRLF
*.vcproj = svn:eol-style=CRLF
*.nsi = svn:eol-style=CRLF
*.manifest = svn:eol-style=CRLF

*.sh = svn:eol-style=native;svn:executable
*.bat = svn:eol-style=native;svn:mime-type=text/plain

*.txt = svn:eol-style=native;svn:mime-type=text/plain
README = svn:eol-style=native;svn:mime-type=text/plain
*.html = svn:eol-style=native;svn:mime-type=text/html
*.css = svn:eol-style=native;svn:mime-type=text/css
*.xml = svn:eol-style=native;svn:mime-type=text/xml
*.bzw = svn:eol-style=native

*.xpm = svn:eol-style=native;svn:mime-type=image/x-xpm
*.svg = svn:eol-style=native;svn:mime-type=image/svg+xml
*.bmp = svn:mime-type=image/bmp
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.ogg = svn:mime-type=application/ogg
*.wav = svn:mime-type=audio/x-wav
*.ttf = svn:mime-type=application/octet-stream
*.ico = svn:mime-type=application/octet-stream
*.rgb = svn:mime-type=image/x-rgb
</pre>

[[Category:Development]]

Auto-props

2009-04-11T05:58:11Z

Bullet Catcher: Update MIME types for .bmp, .ico, and .ttf files. Add settings for .bat and .css files.

Developers should make sure their Subversion auto-props are set correctly before committing to [[SVN]]. This helps preserve the correct line endings across platforms. This is the "standard" auto-props section we are using (you may of course set your own if you prefer). You'll need to edit your config file(s), which varies depending on platform and Subversion client.

For UNIX-like platforms, edit your ''~/.subversion/config'' file to set the auto-props. For Windows Vista, the path is ''C:\Users\YOUR_USERNAME\AppData\Roaming\Subversion\config'' And for Windows XP, the path is ''C:\Documents and Settings\YOUR_USERNAME\Application Data\Subversion\config'' Also, please be sure that you uncomment the '''enable-auto-props''' option and set it to yes.

<pre>
### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.cxx = svn:eol-style=native
*.h = svn:eol-style=native
*.pl = svn:eol-style=native
*.py = svn:eol-style=native
*.php = svn:eol-style=native

*.po = svn:eol-style=native
*.am = svn:eol-style=native
*.ac = svn:eol-style=native
*.in = svn:eol-style=native
*.m4 = svn:eol-style=native

*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sln = svn:eol-style=CRLF
*.vcproj = svn:eol-style=CRLF
*.nsi = svn:eol-style=CRLF
*.manifest = svn:eol-style=CRLF

*.sh = svn:eol-style=native;svn:executable
*.bat = svn:eol-style=native;svn:mime-type=text/plain

*.txt = svn:eol-style=native;svn:mime-type=text/plain
README = svn:eol-style=native;svn:mime-type=text/plain
*.html = svn:eol-style=native;svn:mime-type=text/html
*.css = svn:eol-style=native;svn:mime-type=text/css
*.xml = svn:eol-style=native;svn:mime-type=text/xml
*.bzw = svn:eol-style=native

*.xpm = svn:eol-style=native;svn:mime-type=image/x-xpm
*.bmp = svn:mime-type=image/bmp
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.ogg = svn:mime-type=application/ogg
*.wav = svn:mime-type=audio/x-wav
*.ttf = svn:mime-type=application/octet-stream
*.ico = svn:mime-type=application/octet-stream
*.rgb = svn:mime-type=image/x-rgb
</pre>

[[Category:Development]]

Google Summer of Code: 2009

2009-04-03T05:49:36Z

Bullet Catcher: /* Mentors */ Add myself to the 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)

[[Category: Development]]

Google Summer of Code: 2009:OrgApplication

2009-03-13T18:37:34Z

Bullet Catcher: /* What steps will you take to encourage contributors to interact with your community */ Don't say "last year". Other wordsmithing.

= Description =
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional spirit, mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for more than 19000 registered players and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our existing developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Indiana University researchers worked with our staff in 2007 to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. Past participation in GSoC has stimulated our project development activities and forced us to become more organized, collaborative, and deliberate in our focus. Our community members have great ideas for improving the game and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? =

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear, the administrator will relay this status to Google after repeated attempts to contact the student fail.

Students are expected to commit changes very frequently. Our philosophy is that if they're not committing, then they are not working (at least not effectively). Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to "commit early, commit often."

If the student is not around or is not working as much as needed, we will have discussions with them, see what's going on, and do so proactively. We learned from one student who was in serious danger of failing that a simple change in accountability can have a massive impact on motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and prompt responses to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It is a very organic process and we don't believe that there is one answer for all students.

The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance.

= What is your plan for dealing with disappearing members? =

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that prevents a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors are selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive". Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game. "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

For student applicants we have a specific checklist of tasks to help them prepare to engage in routine development. These steps include introducing themselves to our IRC channel, having a SourceForge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see.

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to quickly get new developers familiar and interested in development directions. Thanks to our previous involvement with GSoC, we have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well in 2007 was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a sense of belonging and a sense of appreciation for the hard work they put into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student but other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.

Google Summer of Code: 2009:OrgApplication

2009-03-13T18:25:35Z

Bullet Catcher: /* What is your plan for dealing with disappearing contributors? */ Don't say "last year". Other wordsmithing.

= Description =
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional spirit, mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for more than 19000 registered players and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our existing developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Indiana University researchers worked with our staff in 2007 to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. Past participation in GSoC has stimulated our project development activities and forced us to become more organized, collaborative, and deliberate in our focus. Our community members have great ideas for improving the game and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? =

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear, the administrator will relay this status to Google after repeated attempts to contact the student fail.

Students are expected to commit changes very frequently. Our philosophy is that if they're not committing, then they are not working (at least not effectively). Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to "commit early, commit often."

If the student is not around or is not working as much as needed, we will have discussions with them, see what's going on, and do so proactively. We learned from one student who was in serious danger of failing that a simple change in accountability can have a massive impact on motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and prompt responses to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It is a very organic process and we don't believe that there is one answer for all students.

The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance.

= What is your plan for dealing with disappearing members? =

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that prevents a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors are selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive". Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game. "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

Before the program, we have a specific checklist of tasks that we have prepared to give them definitive actions that they need to perform. These steps include introducing themselves to our IRC channel, having a Sourceforge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see.

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to get new developers familiar and interested in development directions quickly. Given our involvement with GSoC last year, we now also have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well last year was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a sense of belonging and a sense of appreciation for the hard-work they are putting into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student but other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.

Google Summer of Code: 2009:OrgApplication

2009-03-13T18:08:50Z

Bullet Catcher: /* Why is your group applying to participate? */ Use absolute time references. Be more concise.

= Description =
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional spirit, mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for more than 19000 registered players and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our existing developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Indiana University researchers worked with our staff in 2007 to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. Past participation in GSoC has stimulated our project development activities and forced us to become more organized, collaborative, and deliberate in our focus. Our community members have great ideas for improving the game and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? =

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear without notice, the administrator will relay this status with Google after repeated attempts to contact the student fail.

Also, as a learned measure from last year, the students are going to be required to make very frequent commits. If they're not committing, then they are not working. At least they won't be working effectively. Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to "commit early, commit often".

If the student is not around or is not working as much as they need to be, we will have discussions with them, see what's going on, and do so proactively. We learned from one of our students last year when they were in serious danger of failing that a simple change in their accountability can have a massive impact on their motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and near immediate response to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It's a very organic process and we don't believe that there is one answer for all students. The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance, as was done last year.

= What is your plan for dealing with disappearing members? =

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that prevents a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors are selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive". Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game. "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

Before the program, we have a specific checklist of tasks that we have prepared to give them definitive actions that they need to perform. These steps include introducing themselves to our IRC channel, having a Sourceforge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see.

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to get new developers familiar and interested in development directions quickly. Given our involvement with GSoC last year, we now also have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well last year was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a sense of belonging and a sense of appreciation for the hard-work they are putting into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student but other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.

Google Summer of Code: 2009:OrgApplication

2009-03-13T17:44:39Z

Bullet Catcher: Use less precision for the number of registered players.

= Description =
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional spirit, mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for more than 19000 registered players and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to hopefully attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our own developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Just this past year, Indiana University worked with our staff to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. We found out last year that participating in GSoC simulates our project development activities and forces us to become more organized, collaborative, and deliberate in our focus. Our community is simply filled with great ideas on how to improve the game in wide impacting ways and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? =

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear without notice, the administrator will relay this status with Google after repeated attempts to contact the student fail.

Also, as a learned measure from last year, the students are going to be required to make very frequent commits. If they're not committing, then they are not working. At least they won't be working effectively. Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to "commit early, commit often".

If the student is not around or is not working as much as they need to be, we will have discussions with them, see what's going on, and do so proactively. We learned from one of our students last year when they were in serious danger of failing that a simple change in their accountability can have a massive impact on their motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that slip consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and near immediate response to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It's a very organic process and we don't believe that there is one answer for all students. The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance, as was done last year.

= What is your plan for dealing with disappearing members? =

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that incapacitates a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive". Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game. "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

Before the program, we have a specific checklist of tasks that we have prepared to give them definitive actions that they need to perform. These steps include introducing themselves to our IRC channel, having a Sourceforge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see.

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to get new developers familiar and interested in development directions quickly. Given our involvement with GSoC last year, we now also have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well last year was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a sense of belonging and a sense of appreciation for the hard-work they are putting into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student and other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.