BZFlagWiki - User contributions [en]

DevelopmentPlans/2.4.2

2011-07-31T20:01:42Z

Thumper: /* Features */

==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 To Be Fixed===

====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) (BTH)
* Fastmap ( Fixed : 7/30/11 JAM )
* Push Stats ( finish backend )
* Joystick fixes (DTR?)
* CIDR/subnet bans from Filter.cxx (Make a common ban check/resolution function/class?)

==Known Bugs==

[[Category:Development Plans]]

DevelopmentPlans/2.3

2011-07-04T03:22:35Z

Thumper: Fix link to BZFlag 2.4

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

==Release==
[[BZFlag_2.4|2.4.0.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.

* 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 '''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.

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

DevelopmentPlans/2.3

2011-07-04T03:20:20Z

Thumper: Fix link to the development roadmap

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

==Release==
[[BZFlag_2.4.0|2.4.0.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.

* 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 '''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.

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

BZFS API 2.4 Upgrade

2011-07-01T02:30:00Z

Thumper: Fix names for 2.0.x register event and remove event methods

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

* 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]]

BZFS API 2.4 Upgrade

2011-07-01T02:19:06Z

Thumper: typo fix

==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_registerEventHandler''' 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_removeEventHandler''' 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'''

* 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]]

BZFS 2.4 Upgrade

2011-06-16T00:00:46Z

Thumper: Add details of r21903 for group changes

Stub for BZFS 2.0.x to 2.4 server upgrade path

==Overview==

For version 2.4 there are new requirements for your server to be listed on the
BZFlag hosted server list.

This page documents user visible changes to the BZFlag server for the 2.4 release of [[BZFlag]].

=== Short Version for the impatient ===

* '''-public''' changed to '''-publictitle'''
* '''-publickey''' specifies your server key for including your server on the server list
* '''-utc''' logs server timestamps in UTC instead of localtime
* '''-passdb''' removed
* '''-requireudp''' removed
* '''-offa''' selects teamless free-for-all game style
* '''-time''' can specify end time for timed games
* Groups can now be referenced in the groupdb before they are defined

==Getting your server listed on the server list==

===Generating and managing server keys===
You need to generate a public server key for your BZFlag server which matches your
server host. If you have multiple server hosts you need a separate key per host.
You can generate and manage your server keys at http://my.bzflag.org/listkeys/

===Starting your BZFlag server using your server key===
After generating a server key you need to provide the key to your bzfs server so it can
authenticate with the list server. Only servers with valid public keys will be shown
on the BZFlag list server.

Keys are shown at http://my.bzflag.org/listkeys like this:

{|
|+ KEYS listed from http://my.bzflag.org/listkeys
|-
!Host
!Key
!
|-
| my.bzflag.server.host
| 1234567890123456789
| [Delete]
|-
|}

You need to provide the key value to the bzfs server option '''''-publickey''''' like this

$ bzfs -public "Map name goes here" -publickey 1234567890123456789

The '''''-publicaddr''''' and '''''-p''''' parameters have not changed from 2.0.x and are used to
provide the hosting server address and port respectively.

More information about the public key option can be found at
[[ServerAuthentication]]

==Upgrading third party plugins==

The API for plugins has changed in the 2.4 release. See
[[BZFS_API_2.4_Upgrade]] for details on upgrading your server plugins.

==BZFlag server commandline option changes==

=== Removed options ===
* Local password databases are no longer supported for authentication
** '''-passdb''' has been removed as a command line option
* UDP is on by default
** '''-requireudp''' has been removed as a command line option

=== Changed options ===
* The option for specifying the map name on the server list has changed
** '''-public''' changed to '''-publictitle'''
* Timed games can now specify the end time in either seconds or end time
** '''-time''' now takes either the number of seconds or an end time as an option (format hh:mm or hh:mm:ss)

=== New options ===
* New game mode for teamless free-for-all
** '''-offa''' added as an option to select this mode
* bzfs server timestamps can now be output in UTC instead of the local time
** Specifying '''-utc''' outputs all times in UTC and implies '''-ts'''
* Public keys are required to have your server included on the BZFlag server list
** '''-publickey''' is used to specify your key. See [[BZFS_2.4_Upgrade#Getting your server listed on the server list|Getting your server listed on the server list]] for details

==Server Groups==
With this release BZFlag groups defined in the ''groupdb'' can now be referenced before they are defined.

Permissions provided by existing server groups will work with no modifications as long as no forward references to
groups exist in your ''groupdb''.

If your group files reference other groups that were not yet defined the permissions provided by
those forward-referenced groups will now be granted to your group members.

We recommend that you review your server ''groupdb'' settings.

BZFS 2.4 Upgrade

2011-06-15T23:48:53Z

Thumper:

Stub for BZFS 2.0.x to 2.4 server upgrade path

==TODO==

* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong

==Overview==

For version 2.4 there are new requirements for your server to be listed on the
BZFlag hosted server list.

This page documents user visible changes to the BZFlag server for the 2.4 release of [[BZFlag]].

=== Short Version for the impatient ===

* '''-public''' changed to '''-publictitle'''
* '''-publickey''' specifies your server key for including your server on the server list
* '''-utc''' logs server timestamps in UTC instead of localtime
* '''-passdb''' removed
* '''-requireudp''' removed
* '''-offa''' selects teamless free-for-all game style
* '''-time''' can specify end time for timed games

==Getting your server listed on the server list==

===Generating and managing server keys===
You need to generate a public server key for your BZFlag server which matches your
server host. If you have multiple server hosts you need a separate key per host.
You can generate and manage your server keys at http://my.bzflag.org/listkeys/

===Starting your BZFlag server using your server key===
After generating a server key you need to provide the key to your bzfs server so it can
authenticate with the list server. Only servers with valid public keys will be shown
on the BZFlag list server.

Keys are shown at http://my.bzflag.org/listkeys like this:

{|
|+ KEYS listed from http://my.bzflag.org/listkeys
|-
!Host
!Key
!
|-
| my.bzflag.server.host
| 1234567890123456789
| [Delete]
|-
|}

You need to provide the key value to the bzfs server option '''''-publickey''''' like this

$ bzfs -public "Map name goes here" -publickey 1234567890123456789

The '''''-publicaddr''''' and '''''-p''''' parameters have not changed from 2.0.x and are used to
provide the hosting server address and port respectively.

More information about the public key option can be found at
[[ServerAuthentication]]

==Upgrading third party plugins==

The API for plugins has changed in the 2.4 release. See
[[BZFS_API_2.4_Upgrade]] for details on upgrading your server plugins.

==BZFlag server commandline option changes==

=== Removed options ===
* Local password databases are no longer supported for authentication
** '''-passdb''' has been removed as a command line option
* UDP is on by default
** '''-requireudp''' has been removed as a command line option

=== Changed options ===
* The option for specifying the map name on the server list has changed
** '''-public''' changed to '''-publictitle'''
* Timed games can now specify the end time in either seconds or end time
** '''-time''' now takes either the number of seconds or an end time as an option (format hh:mm or hh:mm:ss)

=== New options ===
* New game mode for teamless free-for-all
** '''-offa''' added as an option to select this mode
* bzfs server timestamps can now be output in UTC instead of the local time
** Specifying '''-utc''' outputs all times in UTC and implies '''-ts'''
* Public keys are required to have your server included on the BZFlag server list
** '''-publickey''' is used to specify your key. See [[BZFS_2.4_Upgrade#Getting your server listed on the server list|Getting your server listed on the server list]] for details

BZFS 2.4 Upgrade

2011-06-15T23:46:20Z

Thumper: Add details about -publictitle and reformat

Stub for BZFS 2.0.x to 2.4 server upgrade path

==TODO==

* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong

==Overview==

For version 2.4 there are new requirements for your server to be listed on the
BZFlag hosted server list.

This page documents user visible changes to the BZFlag server for the 2.4 release of [[BZFlag]].

=== Short Version for the impatient ===

* '''-public''' changed to '''-publictitle'''
* '''-publickey''' specifies your server key for including your server on the server list
* '''-utc''' logs server timestamps in UTC instead of localtime
* '''-passdb''' removed
* '''-requireudp''' removed
* '''-offa''' selects teamless free-for-all game style
* '''-time''' can specify end time for timed games

==Getting your server listed on the server list==

===Generating and managing server keys===
You need to generate a public server key for your BZFlag server which matches your
server host. If you have multiple server hosts you need a separate key per host.
You can generate and manage your server keys at http://my.bzflag.org/listkeys/

===Starting your BZFlag server using your server key===
After generating a server key you need to provide the key to your bzfs server so it can
authenticate with the list server. Only servers with valid public keys will be shown
on the BZFlag list server.

Keys are shown at http://my.bzflag.org/listkeys like this:

{|
|+ KEYS listed from http://my.bzflag.org/listkeys
|-
!Host
!Key
!
|-
| my.bzflag.server.host
| 1234567890123456789
| [Delete]
|-
|}

You need to provide the key value to the bzfs server option '''''-publickey''''' like this

$ bzfs -public "Map name goes here" -publickey 1234567890123456789

The '''''-publicaddr''''' and '''''-p''''' parameters have not changed from 2.0.x and are used to
provide the hosting server address and port respectively.

More information about the public key option can be found at
[[ServerAuthentication]]

==Upgrading third party plugins==

The API for plugins has changed in the 2.4 release. See
[[BZFS_API_2.4_Upgrade]] for details on upgrading your server plugins.

==BZFlag server commandline option changes==

=== Options no longer supported ===
* Local password databases are no longer supported for authentication
** '''-passdb''' has been removed as a command line option
* UDP is on by default
** '''-requireudp''' has been removed as a command line option

=== Command line options changes ===
* The option for specifying the map name on the server list has changed
** '''-public''' changed to '''-publictitle'''
* Timed games can now specify the end time in either seconds or end time
** '''-time''' now takes either the number of seconds or an end time as an option (format hh:mm or hh:mm:ss)

=== New commandline options ===
* New game mode for teamless free-for-all
** '''-offa''' added as an option to select this mode
* bzfs server timestamps can now be output in UTC instead of the local time
** Specifying '''-utc''' outputs all times in UTC and implies '''-ts'''
* Public keys are required to have your server included on the BZFlag server list
** '''-publickey''' is used to specify your key. See [[BZFS_2.4_Upgrade#Getting your server listed on the server list|Getting your server listed on the server list]] for details

BZFS 2.4 Upgrade

2011-06-15T16:27:28Z

Thumper: Demote the heading levels

Stub for BZFS 2.0.x to 2.4 server upgrade path

==TODO==

* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong
* -public is now -publictitle

==Overview==

For version 2.4 there are new requirements for your server to be listed on the
BZFlag hosted server list.

This page documents user visible changes to the BZFlag server for the 2.4 release of [[BZFlag]].

==Getting your server listed on the server list==

===Generating and managing server keys===
You need to generate a public server key for your BZFlag server which matches your
server host. If you have multiple server hosts you need a separate key per host.
You can generate and manage your server keys at http://my.bzflag.org/listkeys/

===Starting your BZFlag server using your server key===
After generating a server key you need to provide the key to your bzfs server so it can
authenticate with the list server. Only servers with valid public keys will be shown
on the BZFlag list server.

Keys are shown at http://my.bzflag.org/listkeys like this:

{|
|+ KEYS listed from http://my.bzflag.org/listkeys
|-
!Host
!Key
!
|-
| my.bzflag.server.host
| 1234567890123456789
| [Delete]
|-
|}

You need to provide the key value to the bzfs server option '''''-publickey''''' like this

$ bzfs -public "Map name goes here" -publickey 1234567890123456789

The '''''-publicaddr''''' and '''''-p''''' parameters have not changed from 2.0.x and are used to
provide the hosting server address and port respectively.

More information about the public key option can be found at
[[ServerAuthentication]]

==Upgrading third party plugins==

The API for plugins has changed in the 2.4 release. See
[[BZFS_API_2.4_Upgrade]] for details on upgrading your server plugins.

==BZFlag server commandline option changes==

{|
! bzfs Commandline Switch
! Notes
|-
| -offa
| New, teamless free-for-all game mode
|-
| -passdb
| Removed
|-
| -requireudp
| Removed
|-
| -time
| Modified, Specify end time in seconds or ending time (hh:mm:ss)
|-
| -utc
| New, Make server time stamps in UTC instead of local time
|-
| -publickey <key>
| New, Required for including your server on the server list
|}

BZFS 2.4 Upgrade

2011-06-15T16:23:41Z

Thumper: Move the TODO items up front so they are more visible

Stub for BZFS 2.0.x to 2.4 server upgrade path

= TODO =

* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong
* -public is now -publictitle

= Overview =

For version 2.4 there are new requirements for your server to be listed on the
BZFlag hosted server list.

This page documents user visible changes to the BZFlag server for the 2.4 release of [[BZFlag]].

= Getting your server listed on the server list =

== Generating and managing server keys ==
You need to generate a public server key for your BZFlag server which matches your
server host. If you have multiple server hosts you need a separate key per host.
You can generate and manage your server keys at http://my.bzflag.org/listkeys/

== Starting your BZFlag server using your server key ==
After generating a server key you need to provide the key to your bzfs server so it can
authenticate with the list server. Only servers with valid public keys will be shown
on the BZFlag list server.

Keys are shown at http://my.bzflag.org/listkeys like this:

{|
|+ KEYS listed from http://my.bzflag.org/listkeys
|-
!Host
!Key
!
|-
| my.bzflag.server.host
| 1234567890123456789
| [Delete]
|-
|}

You need to provide the key value to the bzfs server option '''''-publickey''''' like this

$ bzfs -public "Map name goes here" -publickey 1234567890123456789

The '''''-publicaddr''''' and '''''-p''''' parameters have not changed from 2.0.x and are used to
provide the hosting server address and port respectively.

More information about the public key option can be found at
[[ServerAuthentication]]

= Upgrading third party plugins =

The API for plugins has changed in the 2.4 release. See
[[BZFS_API_2.4_Upgrade]] for details on upgrading your server plugins.

= BZFlag server commandline option changes =

{|
! bzfs Commandline Switch
! Notes
|-
| -offa
| New, teamless free-for-all game mode
|-
| -passdb
| Removed
|-
| -requireudp
| Removed
|-
| -time
| Modified, Specify end time in seconds or ending time (hh:mm:ss)
|-
| -utc
| New, Make server time stamps in UTC instead of local time
|-
| -publickey <key>
| New, Required for including your server on the server list
|}

BZFS 2.4 Upgrade

2011-06-15T15:22:58Z

Thumper: Reference the ServerAuthentication page for more details

Server authentication

2011-06-15T15:20:29Z

Thumper: -publickey starts in version 2.4

==Overview==
Version 2.4 and later of the BZFlag server ([[BZFS]]) require an authentication key in order to list on the global public list server.

==Authentication==
Authentication is required in order to provide players and project staff members a point of contact for any issues or problems that may arise with the server when it is being run publicly.

Any server that uses the -public option and contacts the project's public list server (http://my.bzflag.org/db/) will be required to provide an authentication key in order to show up on the list.

===The Key===
The authentication key is automatically generated by the Key management site, and is tied to a specific domain name, or IP address. Server owners simply have to log into the Key Manager and they can generate as many keys as they need. The key is effectively tied to a single server machine, but can be used with any number of BZFS instances on any number of ports.

Servers that do not have static IPs or domain names, should look at using one of the many free DNS name services that are available such as http://www.no-ip.com. Dynamic IPs will need new keys every time the address changes if a domain name is not used.

The key is numeric and will be completely unique. Keys are not valid for domain names or IP address that they were not created with.

===Key Management===
Key Management is handled by the website: http://my.bzflag.org/listkeys/. After logging in with a global username and password (forum login) server owners can enter as many domain names or IP addresses as they wish. Provide the key to bzfs using the "-publickey <key>" option.

==Questions==
'''Q)''' What happens if my key gets out?

'''A)''' Not much, the key is only valid for your server machine, so unless the user also has access to the same computer they can not use it.

'''Q)''' What if I run BZFS instances for other people?

'''A)''' Then you have 2 choices.
1) You can give out your key to your people and they can use it. This will make all servers show up as belonging to you.
2) You can tell your users to generate there own keys using the server address or domain name. Then each BZFS instance will be owned by each person.

'''Q)''' Does 2.0.x need a key?

'''A)''' No, 2.0.x servers do not need a key.

BZFS 2.4 Upgrade

2011-06-15T00:17:37Z

Thumper:

BZFS 2.4 Upgrade

2011-06-14T23:25:15Z

Thumper: Fix the link

Stub for BZFS 2.0.x to 2.4 server upgrade path

== TODO ==

* document -publickey and how to generate them
* document changes in command line options
* reference plugin upgrade for 2.0.x to 2.4 [[BZFS_API_2.4_Upgrade]]
* put document on the wiki
* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong

BZFS 2.4 Upgrade

2011-06-14T23:21:54Z

Thumper: New page: Stub for BZFS 2.0.x to 2.4 server upgrade path == TODO == * document -publickey and how to generate them * document changes in command line options * reference plugin upgrade for 2.0.x t...

Stub for BZFS 2.0.x to 2.4 server upgrade path

== TODO ==

* document -publickey and how to generate them
* document changes in command line options
* reference plugin upgrade for 2.0.x to 2.4 [BZFS_API_2.4_Upgrade]]
* put document on the wiki
* document r21903
** should not change for well defined groups
** may change behaviour if the group definitions were wrong

DevelopmentPlans/2.3

2011-06-14T16:38:58Z

Thumper: Own the server side handicap backport

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

* 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
* 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 '''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.

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

Development RoadMap

2011-06-07T18:40:24Z

Thumper: Fixup typos and grammar

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

==2.4.0 (Wake the dead)==
2.4 will be the next release of BZFlag and is protocol incompatible with all previous versions.
The development goals are listed here [[BZFlag 2.3]]

==2.4.2 (What was once lost)==
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 including:

* BZFScron
* Fastmap

==2.4.4 (Making the stride)==
* New Death effects
* HTTP Management plugins
* Push Stats
* Bug fixes

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

==3.0 (Next Major)==
* Make world meshes internally.
* New Simulation
* Things added in V3 that were not back-ported.

==3.2 (Modernization)==
* UI Cleanup
* Lag compensation
* New Group and user Management.

DevelopmentPlans/2.3

2011-05-28T13:26:34Z

Thumper: Be bolder

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

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

* 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''' [[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 '''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.

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

DevelopmentPlans/2.3

2011-05-17T02:27:28Z

Thumper: /* Backports */

==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 '''trepan'''
* Lua
* push stats as default

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

Functions (API)

2011-05-14T20:01:07Z

Thumper:

{{DoDoc|
Fill in articles for all API Functions<br>
Finish updating to 2.3.x
}}

{{BZFS_API_Doc}}

== Overview ==

The BZFS API provides a number of functions to plug-ins for use in querying the current game state. Functions are used both to get information about the game, and to trigger in game actions, such as activating a world weapon.

== Function Groups ==
Functions are broken into a series of groups based on the type of action or information they deal with.

=== Event Registration ===
BZF_API bool [[bz_registerEvent]] ( [[Events(API)|bz_eEventType]] eventType, [[Events(API)|bz_EventHandler]]* eventHandler );
BZF_API bool [[bz_removeEvent]] ( [[Events(API)|bz_eEventType]] eventType, [[Events(API)|bz_EventHandler]]* eventHandler );

=== Non-Player Connections ===
BZF_API bool [[bz_registerNonPlayerConnectionHandler]] ( int connectionID, [[bz_NonPlayerConnectionHandler]]* handler );
BZF_API bool [[bz_removeNonPlayerConnectionHandler]] ( int connectionID, [[bz_NonPlayerConnectionHandler]]* handler );
BZF_API bool [[bz_sendNonPlayerData]] ( int connectionID, const void *data, unsigned int size );
BZF_API bool [[bz_disconectNonPlayerConnection]] ( int connectionID );
BZF_API unsigned int [[bz_getNonPlayerConnectionOutboundPacketCount]] ( int connectionID );
BZF_API const char* [[bz_getNonPlayerConnectionIP]] ( int connectionID );
BZF_API const char* [[bz_getNonPlayerConnectionHost]] ( int connectionID );

=== Player Information ===
==== Player Information ====
BZF_API bool [[bz_hasPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_getAdmin]] ( int playerID );
BZF_API bz_eTeamType [[bz_getPlayerTeam]] ( int playerID );
BZF_API const char* [[bz_getPlayerCallsign]] ( int playerID );
BZF_API const char* [[bz_getPlayerIPAddress]] ( int playerID );
BZF_API const char* [[bz_getPlayerReferrer]] ( int playerID );
BZF_API const char* [[bz_getPlayerCustomData]] (int playerID, const char* key );
BZF_API const char* [[bz_getPlayerFlag]] ( int playerID );

==== Player State Information ====
BZF_API bool [[bz_getPlayerPosition]] ( int playerID, float pos[3], bool extrapolate );
BZF_API bool [[bz_getPlayerRotation]] ( int playerID, float *rot, bool extrapolate );
BZF_API bool [[bz_getPlayerVelocity]] ( int playerID, float vel[3] );
BZF_API bool [[bz_getPlayerAngVel]] ( int playerID, float *angvel );
BZF_API bool [[bz_getPlayerPhysicsDriver]] ( int playerID, int* phydrv );
BZF_API bool [[bz_isPlayerPaused]] ( int playerID );
BZF_API bool [[bz_canPlayerSpawn]]( int playerID );
BZF_API bool [[bz_getPlayerCurrentState]] ( int playerID, bz_PlayerUpdateState &state );

==== Player Lists and Records ====
BZF_API [[bz_BasePlayerRecord]] *[[bz_getPlayerByIndex]] ( int index );
BZF_API [[bz_BasePlayerRecord]] *[[bz_getPlayerByCallsign]] ( const char* name );
BZF_API [[bz_BasePlayerRecord]] *[[bz_getPlayerByBZID]] ( int BZID );
BZF_API bool [[bz_updatePlayerData]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API bool [[bz_freePlayerRecord]] ( [[bz_BasePlayerRecord]] *playerRecord );

BZF_API [[bz_APIIntList]] *[[bz_newIntList]] ( void );
BZF_API [[bz_APIIntList]] *[[bz_getPlayerIndexList]] ( void );
BZF_API bool [[bz_getPlayerIndexList]] ( [[bz_APIIntList]] *playerList );
BZF_API void [[bz_deleteIntList]] ( [[bz_APIIntList]] *l);

==== Player Management ====
BZF_API bool [[bz_grantPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_revokePerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_validAdminPassword]] ( const char* passwd );
BZF_API bool [[bz_setPlayerOperator]] ( int playerId );
BZF_API bool [[bz_setPlayerSpawnable]]( int playerID, bool spawn );
BZF_API bool [[bz_setPlayerLimboMessage]]( int playerID, const char* text );
BZF_API bool [[bz_setPlayerCustomData]] (int playerID, const char* key, const char* data );

=== Team Management ===
BZF_API unsigned int [[bz_getTeamPlayerLimit]] ( bz_eTeamType team )
BZF_API int [[bz_getTeamCount]] ([[bz_eTeamType]] team );
BZF_API int [[bz_getTeamScore]] ([[bz_eTeamType]] team );
BZF_API int [[bz_getTeamWins]] ([[bz_eTeamType]] team );
BZF_API int [[bz_getTeamLosses]] ([[bz_eTeamType]] team );
BZF_API void [[bz_setTeamWins]] ([[bz_eTeamType]] team, int wins );
BZF_API void [[bz_setTeamLosses]] ([[bz_eTeamType]] team, int losses );
BZF_API void [[bz_resetTeamScore]] ([[bz_eTeamType]] team );
BZF_API void [[bz_resetTeamScores]] ( void );
BZF_API void [[bz_changeTeam]]( int player, [[bz_eTeamType]] team );

=== Score Management ===
BZF_API bool [[bz_setPlayerWins]] ( int playerId, int wins );
BZF_API bool [[bz_setPlayerLosses]] ( int playerId, int losses );
BZF_API bool [[bz_setPlayerTKs]] ( int playerId, int tks );
BZF_API bool [[bz_resetPlayerScore]] ( int playerId );
BZF_API int [[bz_getPlayerWins]] ( int playerId );
BZF_API int [[bz_getPlayerLosses]] ( int playerId );
BZF_API int [[bz_getPlayerTKs]] ( int playerId );
BZF_API float [[bz_getPlayerRank]] ( int playerId );

=== Latency Information ===
BZF_API int [[bz_getPlayerLag]] ( int playerId );
BZF_API int [[bz_getPlayerJitter]] ( int playerId );
BZF_API float [[bz_getPlayerPacketloss]] ( int playerId );

=== Permission Group Management ===
BZF_API [[bz_APIStringList]]* [[bz_getGroupList]] ( void );
BZF_API [[bz_APIStringList]]* [[bz_getGroupPerms]] ( const char* group );
BZF_API bool [[bz_groupAllowPerm]] ( const char* group, const char* perm );

=== Chat Messages ===
BZF_API bool [[bz_sendTextMessage]] (int from, int to, const char* message);
BZF_API bool [[bz_sendTextMessage]] (int from, [[bz_eTeamType]] to, const char* message);
BZF_API bool [[bz_sendTextMessagef]] (int from, int to, const char* fmt, ...);
BZF_API bool [[bz_sendTextMessagef]] (int from, [[bz_eTeamType]] to, const char* fmt, ...);
BZF_API bool [[bz_sendFetchResMessage]] ( int playerID, const char* URL );
BZF_API bool [[bz_sendJoinServer]] ( int playerID, const char* address, int port, int team, const char* referrer, const char* message );
BZF_API bool [[bz_sendLuaData]] ( int dstPlayerID, int dstScriptID, int statusBits, const char* data, int len,
int srcPlayerID = 0, int srcScriptID = 0 );

=== Server Management ===
BZF_API bool [[bz_restart]] ( void );
BZF_API void [[bz_shutdown]] ();
BZF_API void [[bz_superkill]] ();
BZF_API void [[bz_gameOver]] ( int playerID, bz_eTeamType = eNoTeam );
BZF_API void [[bz_reloadLocalBans]] ();
BZF_API void [[bz_reloadMasterBans]] ();
BZF_API void [[bz_reloadGroups]] ();
BZF_API void [[bz_reloadUsers]] ();
BZF_API void [[bz_reloadHelp]] ();
BZF_API int [[bz_getPlayerCount]] ( void );
BZF_API bool [[bz_anyPlayers]] ( void );

=== Rabbit Hunt ===
BZF_API void [[bz_newRabbit]] ( int player, bool swap );
BZF_API void [[bz_removeRabbit]] ( int player );

=== Map Management ===
BZF_API void [[bz_setClientWorldDownloadURL]] ( const char* URL );
BZF_API const [[bzApiString]] [[bz_getClientWorldDownloadURL]] ( void );
BZF_API bool [[bz_saveWorldCacheFile]] ( const char* file );

=== Flag Management ===

BZF_API bool [[bz_givePlayerFlag]] ( int playerID, const char* flagType, bool force );
BZF_API bool [[bz_removePlayerFlag]] ( int playerID );
BZF_API void [[bz_resetFlags]] ( bool onlyUnused );
BZF_API unsigned int [[bz_getNumFlags]] ( void );
BZF_API const [[bz_ApiString]] [[bz_getFlagName]] ( int flag );
BZF_API bool [[bz_resetFlag]] ( int flag );
BZF_API int [[bz_flagPlayer]] ( int flag );
BZF_API bool [[bz_getFlagPosition]] ( int flag, float* pos );
BZF_API bool [[bz_moveFlag]] ( int flag, float pos[3], bool reset = true );
BZF_API bool [[bz_RegisterCustomFlag]] ( const char* abbr, const char* name, const char* helpString, bz_eShotType shotType, bz_eFlagQuality quality );

=== Shot Type Control ===
BZF_API bool [[bz_setPlayerShotType]] ( int playerId, [[bz_eShotType]] shotType );

=== World Weapon Management ===
BZF_API bool [[bz_fireWorldWep]] ( const char* flagType, float lifetime, float *pos, float tilt, float direction, int shotID , float dt );
BZF_API int [[bz_fireWorldGM]] ( int targetPlayerID, float lifetime, float *pos, float tilt, float direction, float dt );

=== Server Time ===
BZF_API double [[bz_getCurrentTime]] ( void );
BZF_API float [[bz_getMaxWaitTime]] ( void );
BZF_API void [[bz_setMaxWaitTime]] ( float maxTime );
BZF_API void [[bz_getLocaltime]] ( [[bz_Time]] *ts );
BZF_API void [[bz_getUTCtime]] ( [[bz_Time]] *ts );

=== Global Database Management (BZDB) ===
BZF_API double [[bz_getBZDBDouble]] ( const char* variable );
BZF_API [[bz_ApiString]] [[bz_getBZDBString]] ( const char* variable );
BZF_API bool [[bz_getBZDBBool]] ( const char* variable );
BZF_API int [[bz_getBZDBInt]] ( const char* variable );
BZF_API int [[bz_getBZDBItemPerms]] ( const char* variable );
BZF_API bool [[bz_getBZDBItemPersistent]] ( const char* variable );
BZF_API bool [[bz_BZDBItemExists]] ( const char* variable );
BZF_API bool [[bz_setBZDBDouble]] ( const char* variable, double val, int perms = 0, bool persistent = false );
BZF_API bool [[bz_setBZDBString]] ( const char* variable, const char *val, int perms = 0, bool persistent = false );
BZF_API bool [[bz_setBZDBBool]] ( const char* variable, bool val, int perms = 0, bool persistent = false );
BZF_API bool [[bz_setBZDBInt]] ( const char* variable, int val, int perms = 0, bool persistent = false );
BZF_API int [[bz_getBZDBVarList]] ( bz_APIStringList *varList );
BZF_API void [[bz_resetBZDBVar]] ( const char* variable );
BZF_API void [[bz_resetALLBZDBVars]] ( void );

=== Logging ===
BZF_API void [[bz_debugMessage]] ( int level, const char* message );
BZF_API void [[bz_debugMessagef]] ( int level, const char* fmt, ... )
BZF_API int [[bz_getDebugLevel]] ( void );

=== Server Administration ===
BZF_API bool [[bz_kickUser]] ( int playerIndex, const char* reason, bool notify );
BZF_API bool [[bz_IPBanUser]] ( const char* ipAddress, const char* ip, int durration, const char* reason );
BZF_API bool [[bz_IDBanUser]] ( const char* bzid, const char* bzID , int duration, const char *reason );
BZF_API bool [[bz_HostBanUser]] ( const char* hostmask, const char* source, int duration, const char* reason );
BZF_API bool [[bz_IPUnbanUser]] ( const char* ip );
BZF_API bool [[bz_IDUnbanUser]] ( const char* bzID );
BZF_API bool [[bz_HostUnbanUser]] ( const char* hostmask );

BZF_API int [[bz_getLagWarn]] ( void );
BZF_API bool [[bz_setLagWarn]] ( int lagwarn );
BZF_API bool [[bz_pollActive]] ( void );
BZF_API bool [[bz_pollVeto]] ( void );

=== Reporting ===
BZF_API [[bz_APIStringList]]* [[bz_getReports]] ( void );
BZF_API unsigned int [[bz_getReportCount]] ( void );
BZF_API const char* [[bz_getReportSource]] ( unsigned int id );
BZF_API const char* [[bz_getReportBody]] ( unsigned int id );
BZF_API const char* [[bz_getReportTime]] ( unsigned int id );
BZF_API bool [[bz_clearReport]] ( unsigned int id );
BZF_API bool [[bz_clearAllReports]] ( void );
BZF_API bool [[bz_fileReport]] ( const char* message, const char* from );

=== Timed Game Management ===
BZF_API bool [[bz_setTimeLimit]] ( float timeLimit );
BZF_API float [[bz_getTimeLimit]] ( void );
BZF_API bool [[bz_isTimeManualStart]] ( void );
BZF_API bool [[bz_isCountDownActive]] ( void );
BZF_API bool [[bz_isCountDownInProgress]] ( void );
BZF_API void [[bz_pauseCountdown]] ( const char *pausedBy );
BZF_API void [[bz_resumeCountdown]] ( const char *resumedBy );
BZF_API void [[bz_startCountdown]] ( int delay, float limit, const char *byWho );

=== Custom Text Commands ===
BZF_API bool [[bz_registerCustomSlashCommand]] ( const char* command, [[bz_CustomSlashCommandHandler]] *handler );
BZF_API bool [[bz_removeCustomSlashCommand]] ( const char* command );

=== Plug-in Management ===
BZF_API int [[bz_getLoadedPlugins]] ( bz_APIStringList * list );
BZF_API bool [[bz_loadPlugin]] ( const char* path, const char* params );
BZF_API bool [[bz_unloadPlugin]] ( const char* path );
BZF_API const char* [[bz_pluginBinPath]] ( void );
BZF_API bool [[bz_registerCustomPluginHandler]] ( const char* extension, [[bz_APIPluginHandler]] * handler );
BZF_API bool [[bz_removeCustomPluginHandler]] ( const char* extension, [[bz_APIPluginHandler]] * handler );

=== Public Server Information ===
BZF_API bool [[bz_getPublic]] ( void );
BZF_API [[bz_ApiString]] [[bz_getPublicAddr]] ( void );
BZF_API [[bz_ApiString]] [[bz_getPublicDescription]] ( void );
BZF_API void [[bz_updateListServer]] ( void );

=== HTTP Transfer ===
BZF_API bool [[bz_addURLJob]] ( const char* URL, [[bz_BaseURLHandler]]* handler = NULL, const char* postData = NULL );
BZF_API bool [[bz_removeURLJob]] ( const char* URL );
BZF_API bool [[bz_stopAllURLJobs]] ( void );

=== Callback Functions ===
BZF_API bool [[bz_registerCallBack]] ( const char* name, [[bz_GenericCallback]] *callback );
BZF_API bool [[bz_registerCallBack]] ( const char* name, [[bz_GenericCallbackFunc]] callback );
BZF_API bool [[bz_removeCallBack]] ( const char* name, [[bz_GenericCallback]] *callback );
BZF_API bool [[bz_removeCallBack]] ( const char* name, [[bz_GenericCallbackFunc]] callback );
BZF_API bool [[bz_callCallback]] ( const char* name, void *param );
BZF_API bool [[bz_callbackExists]] ( const char* name );

=== Inter-Plug-in Communications ===
BZF_API bool [[bz_clipFieldExists]] ( const char *name );
BZF_API const char* [[bz_getclipFieldString]] ( const char *name );
BZF_API float [[bz_getclipFieldFloat]] ( const char *name );
BZF_API int [[bz_getclipFieldInt]] ( const char *name );
BZF_API bool [[bz_setclipFieldString]] ( const char *name, const char* data );
BZF_API bool [[bz_setclipFieldFloat]] ( const char *name, float data );
BZF_API bool [[bz_setclipFieldInt]] ( const char *name, int data );
BZF_API bool [[bz_addClipFieldNotifier]] ( const char *name, [[bz_ClipFiledNotifier *cb );
BZF_API bool [[bz_removeClipFieldNotifier]] ( const char *name, [[bz_ClipFiledNotifier *cb );

=== Game Recording ===
BZF_API bool [[bz_saveRecBuf]] ( const char * _filename, int seconds);
BZF_API bool [[bz_startRecBuf]] ( void );
BZF_API bool [[bz_stopRecBuf]] ( void );

=== Map Management ===
==== Map Information ====
BZF_API void [[bz_getWorldSize]] ( float *size, float *wallHeight );
BZF_API unsigned int [[bz_getWorldObjectCount]] ( void );
BZF_API [[bz_APIWorldObjectList]]* [[bz_getWorldObjectList]] ( void );
BZF_API void [[bz_releaseWorldObjectList]] ( [[bz_APIWorldObjectList]] *list );
BZF_API unsigned int [[bz_findWorldObject]] ( const char *name );
BZF_API [[bz_APIBaseWorldObject]]* [[bz_getWorldObjectByID]] ( unsigned int id );
BZF_API bool [[bz_getTeleLinkIDs]] ( const char* teleName, int* frontLink, int* backLink );
BZF_API const char* [[bz_getLinkTeleName]] ( int linkIndex );
BZF_API int [[bz_getPhyDrvID]] ( const char* phyDrvName );
BZF_API const char* [[bz_getPhyDrvName]] ( unsigned int phyDrvID );
BZF_API bool [[bz_SetWorldObjectTangibility]] ( int id, const [[bz_SolidObjectPassableAtributes]] &atribs );
BZF_API bool [[bz_GetWorldObjectTangibility]] ( int id, [[bz_SolidObjectPassableAtributes]] &atribs );
BZF_API void [[bz_ResetWorldObjectTangibilities]] ( void );

==== Map Collisions ====
[[bz_eAPIColType]] [[bz_cylinderInMapObject]] ( float pos[3], float height, float radius, [[bz_APIBaseWorldObject]] **object );
[[bz_eAPIColType]] [[bz_boxInMapObject]] ( float pos[3], float size[3], float angle, [[bz_APIBaseWorldObject]] **object );

==== Custom Map Objects ====
BZF_API bool [[bz_registerCustomMapObject]] ( const char* object, [[bz_CustomMapObjectHandler]] *handler );
BZF_API bool [[bz_removeCustomMapObject]] ( const char* object );

=== Utility ===
BZF_API const char *[[bz_MD5]] ( const char* str );
BZF_API const char *[[bz_MD5]] ( const void* data, size_t size );
BZF_API const char *[[bz_getServerVersion]] ( void );
BZF_API const char *[[bz_getProtocolVersion]] ( void );

=== Misc ===
BZF_API bool [[bz_getStandardSpawn]] ( int playerID, float pos[3], float *rot );
BZF_API bool [[bz_killPlayer]] ( int playerID, bool spawnOnBase, int killerID = -1, const char* flagID = NULL );
BZF_API bool [[bz_sendPlayCustomLocalSound]] ( int playerID, const char* soundName );
BZF_API [[bz_ApiString]] [[bz_filterPath]] ( const char* path );
BZF_API const char *[[bz_format]](const char* fmt, ...)_ATTRIBUTE12;
BZF_API const char *[[bz_toupper]](const char* val );
BZF_API const char *[[bz_tolower]](const char* val );
BZF_API const char *[[bz_urlEncode]](const char* val );
BZF_API [[bz_eGameType]] [[bz_getGameType]]( void );
BZF_API bool [[bz_allowJumping]] ( void );
BZF_API [[bz_eTeamType]] [[bz_checkBaseAtPoint]] ( float pos[3] );
BZF_API int [[bz_APIVersion]] ( void );

=== Server Side Players (Development) ===
BZF_API int [[bz_addServerSidePlayer]] ( [[bz_ServerSidePlayerHandler]] *handler );
BZF_API bool [[bz_removeServerSidePlayer]] ( int playerID, [[bz_ServerSidePlayerHandler]] *handler );

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

[[plug-ins]]

[[Category:BZFS_API_Functions]]

DevelopmentPlans/2.3

2011-05-13T13:25:56Z

Thumper: /* Backports */

==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
* 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
* 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-12T20:01:17Z

Thumper: /* Backports */

DevelopmentPlans/2.3

2011-05-12T19:50:59Z

Thumper: /* Backports */

DevelopmentPlans/2.3

2011-05-12T18:32:58Z

Thumper: /* Backports */

DevelopmentPlans/2.3

2011-05-11T23:10:42Z

Thumper: /* General Overview and Idea of Project */

==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 development on [[BZFlag 3.0]] 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.

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

==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
** graphics quality?
** 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 bandaid for.
* Command changes
** Remove the /identify command.
** Backport the /serverdebug command
* BZBB rank promotions! ;-)

==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.
* Copy trunk to a V3_FAIL tag.
* Copy v2_0branch to trunk and commit a change that requires a new protocol number.
* Implement accepted proposals and test.
* After 1 month, revert any changes that have caused unfixed regressions.
* Update version docs and make trunk into 2.4.0.0 for releease.
* Tag Trunk to 2_4branch trelease.

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

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

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

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

* Map changes.
* HTTP plugins
* New API events
* BZFChron
* Server Side Players
* Bugfixs not in notes
* New flags
* Rabbit as team
* SVN props cleanup
* Countdown/reload timer position fix for when showCoordinates is enabled

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

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

BZFlag CVS

2009-06-07T04:16:22Z

Thumper: Undo revision 5850 by 208.184.6.25 (Talk)

{|style="width:100%;margin-top:+1em;background-color:#FF0000;border:1px solid #ccc;"
|<div style="font-size:162%">'''The CVS system has been replaced by the [[BZFlag SVN]] subversion system. The code in CVS is available for read only. No new code will be put into CVS. The following info is only for historical reference.'''</div>
|}

BZFlag CVS, is the [http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Versions System] that was previously used by the development team to maintain and store the [[BZFlag Source]] code before the move to [[BZFlag SVN|Subversion]]. The CVS system was hosted at [http://www.sourceforge.net SourceForge] and was accessible by anyone with the proper software.

CVS has 2 methods of access, Anonymous ( or anon CVS ) for general users, and a SSH based Developer CVS, for project developers.

==CVS clients==
To access the source code via CVS, you will need a CVS client. Most unix/linux type operating systems have the command line CVS client as an installable option. Windows users must download a third party CVS client, such as [http://www.tortoisecvs.org/ the Tortoise Graphical CVS Client].

==CVS Modules==
The source code in CVS is broken up into a number of modules for ease of use and other reasons. When requesting the source code from the CVS system the module must be specified to the CVS software.

The current CVS modules are:
*bzflag : The main module that includes the game 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.
*tools : an abandoned cross platform version of [[BZEditWin32]]
*pybzflag : an abandoned python implementation of BZFlag

==Anon CVS Access==
===Command line===
[[image:Tort_anon_cvs.png|frame|Tortoise Graphical CVS Client]]
SourceForge allows anonymous access to the CVS system on a read only basis. One does not need a SourceForge account to get a copy of the code via the Anon CVS system.

Users with a command line CVS tool can access the source by running 2 commands
{|
|
cvs -d:pserver:anonymous@bzflag.cvs.sourceforge.net:/cvsroot/bzflag login

|}
and
{|
|
cvs -z3 -d:pserver:anonymous@bzflag.cvs.sourceforge.net:/cvsroot/bzflag co -P '''bzflag'''
|}
If a different module is desired, simply replace '''bzflag''' in the second command with the desired module.

===TortoiseCVS===

Windows users that use the Tortoise Graphical CVS Client, should enter the data shown here.

Again if a different module is desired, simply replace the bzflag module name with the one desired.

==Developer CVS Access==
===Command Line===
Project developers that need read and write access to the source code to make changes ( or [[commits]] ) need to use the SSH developer CVS. A sourceforge account is required for developer access, as well as approval from a project administrator.

Users with a command line CVS tool can access the source by running 2 commands
{|
|
export CVS_RSH=ssh
|}
and
{|
|
cvs -z3 -d:ext:'''developername'''@bzflag.cvs.sourceforge.net:/cvsroot/bzflag co -P '''bzflag'''
|}
The developer must enter there SourceForge username in place of '''developername'''.

===TortoiseCVS===
Windows users that use the Tortoise Graphical CVS Client, should enter the data shown here
[[Image:Tort_dev_cvs.png]]

Again the developer must use there SourceForge username.to login.

==Tags and Branches==
The BZFlag developers make use of '''tags''' and '''branches''' in CVS to separate the code for each version of the game. The current development version is always marked as ''HEAD'' in CVS and is the default code retrieved by a CVS client ([[BZFlag 3.0|v2.99.x]] at present).

===Tags===
Each major release will be marked with a '''tag''' in CVS so that it can be easily retrieved. The tags for each release are in the following format:
{|
|
vX_Y_Z
|}
where,
*X is the Major Version
*Y is the Minor Version
*Z is the Revision

The tag for the last release [[BZFlag 2.0.8|v2.0.8]] is ''v2_0_8''

===Branches===
A branch for continuing development on each Minor version is kept in CVS as well.
The format for the branches is:
{|
|
vX_Ybranch
|}
where again,
*X is the Major Version
*Y is the Minor Version

The branch for the development of 2.0.x is ''v2_0branch'' and is currently marked as version [[BZFlag 2.0.9|2.0.9]].

===Usage in CVS===
To receive the code from a branch or tag, the CVS client must be told what tag or branch to use.

===Command Line===
users of the command line tool should add
{|
|
-r ''TAG''
|}
after the '''co''' portion of the cvs command, but before the module name.

===TortoiseCVS===
Windows users that use the Tortoise Graphical CVS Client, would pick the tag from the revision tab, as shown here.
[[Image:Tort_cvs_tag.png]]

==See also==
[[BZFlag SVN]]

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

[http://bzflag.cvs.sourceforge.net/bzflag/ BZFlag CVS Tree]

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

Master Ban

2009-06-07T04:13:45Z

Thumper: Undo revision 5851 by 208.184.6.25 (Talk)

The Master Ban list is an administration tool used to prevent abuse of the BZFlag server network.

==Overview==
The master ban list is an opt-out system for all public game servers that downloads an additional ban file. This ban file contains the static IPs of a small number of players who have been disruptive to the gaming network as a whole.

==Usage==
A public server does not have to do anything to use the Master Ban list, it is loaded automatically at server start for any server that uses the '''-public''' command line option. Servers that do not wish to use the Master Ban list can add the '''-noMasterBanlist''' option and [[BZFS]] will not attempt to load the list.

==Players on the Master Ban List==
The players on the Master Ban list were added because they engaged in disruptive behavior across a large number of servers, or attempted to disrupt the global network services (such as the [[Global Registration]] System, [[List Server]], or [http://my.bzflag.org/bb Forums]). All members of the Master Ban list have static IP addresses. No user with a dynamic IP address will be added to the Master Ban list, as the possibility of banning an innocent user is too great. An exception to this rule for single addresses in dynamic ranges may be made temporarily during periods of severe disruption at the discretion of the developers.

===Behavior for which you can be Masterbanned (i.e. "Disruptive Behavior" above)===
* Cheating on multiple game servers
* Spamming inappropriate (including, but not exclusively, commercial advertisement, hateful, vulgar, or racist) messages on multiple game servers
* Cracking attempts, denial of service attacks, or exploitation of vulnerabilities against multiple game servers
* Cracking attempts, denial of service attacks, or exploitation of vulnerabilities against network resources (i.e. List server, Bulletin boards, IRC channel, Global authentication servers, Wiki)

===Behavior for which you cannot be Masterbanned===
* Cheating on, attacking, or exploiting a single game server.
** Rationale: fabrication of evidence is too easy (and therefore, possibility of being "framed" or "set up" is too high)
* Violating server rules other than cheating or spamming on game servers (e.g. language violations).
** Rationale: it is not the purpose of the master ban list to enforce local server rules. Bans for this behavior should be handled at the server level
* Violating rules on network resources (i.e. spamming, engaging in personal attacks, or using foul language on the bulletin boards or IRC channels)
** Rationale: if the violations you committed are not related to playing and you do not pose a hazard to the servers, you should be allowed to continue to play. Note, however, that you will still be banned from whatever resources you have abused and potentially others that we feel you are likely to abuse.

==Master Ban List Management==
Write access to the Master Ban list is limited to developers and community members with [[BZFlag SVN|SVN]] commit access. The list is stored in SVN for history tracking. All additions to the list are handled via the SVN system, so they are logged for review. The Master Ban list can be viewed at http://www.bzflag.org/master-bans.txt . All changes to the list can be viewed at http://bzflag.cvs.sourceforge.net/bzflag/admin/master-bans.txt?view=log .

===Getting Off the Master Ban List===
Users who are on the list and feel they should not be, or would like to be removed, should attempt to contact the project administrators as soon as possible. They should be willing to discuss how they got on the list and what they can do to get off the list. If they are guilty of the actions that got them on the list, they should be ready to explain why the administration staff should remove them from the list. They should also remember that playing is a privilege and not a right. The administration staff is willing to discuss Master Ban issues with anyone who is willing to discuss the matter in a civil manner.

===Getting Someone On the Master Ban List===
The list is only intended for network wide abusers with static IP addresses. In all other cases local server bans will take care of the abuser. Comments from server owners are generally the only ones considered when reporting a master ban candidate. Players that feel a user should be master banned should take the issue up with the owners of the servers on which the disruptive behavior has been observed.

==See also==
[[BZFS Command Line Options]]

==External links==
[http://www.bzflag.org/master-bans.txt Master Ban List]

[http://bzflag.cvs.sourceforge.net/bzflag/admin/master-bans.txt?view=log Master Ban Change Log]

[[Category:Server Security]]

Master Ban

2009-06-07T04:13:06Z

Thumper: Undo revision 5852 by 208.184.6.58 (Talk)

The Master Ban list is an administration tool used to prevent abuse of the BZFlag server network.

==Overview==
The master ban list was created by high minded Aspergers intellectuals desperately seeking ways to stop a small cadre of bold revolutionaries from disrupting their motives of spreading subliminal homo-erotic messages intertwined in the game code. The ban list is contained as a ban file locked deep inside Tim Rikers ample colon. This ban file contains the static IPs of a small number of players who have been disruptive to the gaming network as a whole and obstinately refused to play hide-the-salami with Rikers on his male only Mormon retreat in Utah.

==Usage==
A public server does not have to do anything to use the Master Ban list, it is loaded automatically at server start for any server that uses the '''-public''' command line option. Servers that do not wish to use the Master Ban list can add the '''-noMasterBanlist''' option and [[BZFS]] will not attempt to load the list.

==Players on the Master Ban List==
The players on the Master Ban list were added because they engaged in disruptive behavior across a large number of servers, or attempted to disrupt the global network services (such as the [[Global Registration]] System, [[List Server]], or [http://my.bzflag.org/bb Forums]). All members of the Master Ban list have static IP addresses. No user with a dynamic IP address will be added to the Master Ban list, as the possibility of banning an innocent user is too great. An exception to this rule for single addresses in dynamic ranges may be made temporarily during periods of severe disruption at the discretion of the developers.

===Behavior for which you can be Masterbanned (i.e. "Disruptive Behavior" above)===
* Cheating on multiple game servers
* Spamming inappropriate (including, but not exclusively, commercial advertisement, hateful, vulgar, or racist) messages on multiple game servers
* Cracking attempts, denial of service attacks, or exploitation of vulnerabilities against multiple game servers
* Cracking attempts, denial of service attacks, or exploitation of vulnerabilities against network resources (i.e. List server, Bulletin boards, IRC channel, Global authentication servers, Wiki)

===Behavior for which you cannot be Masterbanned===
* Cheating on, attacking, or exploiting a single game server.
** Rationale: fabrication of evidence is too easy (and therefore, possibility of being "framed" or "set up" is too high)
* Violating server rules other than cheating or spamming on game servers (e.g. language violations).
** Rationale: it is not the purpose of the master ban list to enforce local server rules. Bans for this behavior should be handled at the server level
* Violating rules on network resources (i.e. spamming, engaging in personal attacks, or using foul language on the bulletin boards or IRC channels)
** Rationale: if the violations you committed are not related to playing and you do not pose a hazard to the servers, you should be allowed to continue to play. Note, however, that you will still be banned from whatever resources you have abused and potentially others that we feel you are likely to abuse.

==Master Ban List Management==
Write access to the Master Ban list is limited to developers and community members with [[BZFlag SVN|SVN]] commit access. The list is stored in SVN for history tracking. All additions to the list are handled via the SVN system, so they are logged for review. The Master Ban list can be viewed at http://www.bzflag.org/master-bans.txt . All changes to the list can be viewed at http://bzflag.cvs.sourceforge.net/bzflag/admin/master-bans.txt?view=log .

===Getting Off the Master Ban List===
Users who are on the list and feel they should not be, or would like to be removed, should attempt to contact the project administrators as soon as possible. They should be willing to discuss how they got on the list and what they can do to get off the list. If they are guilty of the actions that got them on the list, they should be ready to explain why the administration staff should remove them from the list. They should also remember that playing is a privilege and not a right. The administration staff is willing to discuss Master Ban issues with anyone who is willing to discuss the matter in a civil manner.

===Getting Someone On the Master Ban List===
The list is only intended for network wide abusers with static IP addresses. In all other cases local server bans will take care of the abuser. Comments from server owners are generally the only ones considered when reporting a master ban candidate. Players that feel a user should be master banned should take the issue up with the owners of the servers on which the disruptive behavior has been observed.

==See also==
[[BZFS Command Line Options]]

==External links==
[http://www.bzflag.org/master-bans.txt Master Ban List]

[http://bzflag.cvs.sourceforge.net/bzflag/admin/master-bans.txt?view=log Master Ban Change Log]

[[Category:Server Security]]

Google Summer of Code: 2009

2009-03-28T16:14:40Z

Thumper: /* Mentors */ Added myself to the mentors list

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we are very excited to be participating again. If accepted, BZFlag will be 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, if BZFlag is accepted back, 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_)

[[Category: Development]]

BZFlag on IRC

2009-02-01T21:40:54Z

Thumper: Fix typo

=FreeNode=
The official BZFlag org. and it's 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 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)
* ##bz-inc (DUCLeague team, [http://my.bzflag.org/league/index.php?link=teaminfo&id=689/ Bz-Incorporated])
* ##bzflagr (Support channel for the [http://bzflagr.net BZFlagr.net servers.])
* ##bzpod (Channel to discuss the BZFlag podcast, BZPod)
* ##bzpro (Support channel for the [http://bzpro.net BZPro.net servers.])
* ##bzw (A place to discuss map making for BZFlag, including ideas and help)
* ##ducleague (Support channel for [http://my.bzflag.org/league/ Ducati League (DucLeague)])
* ##guleague (Support channel for [http://gu.bzleague.com/ GamesUnited League (GULeague)])
* ##icf (Support channel for [http://gu.bzleague.com/index.php?link=teaminfo&id=112 Invasive Chaotic Frenzies, (GULeague)])
* ##norang (Support channel for [http://bzflag.norang.ca Norang.ca] BZFlag servers)
* ##planetmofo (Support channel for [http://www.planet-mofo.com planet-mofo.com] servers)
* ##t42 ([http://gu.bzleague.com/index.php?link=teaminfo&id=39 GULeague team])
* ##untamed ([http://my.bzflag.org/league/index.php?link=teaminfo&id=909 DUCLeague team])

Please note that teams,leagues and groups should create channels that begin with ## to follow the freenode "about" channel policy.

=stormcenter.net=
An unofficial bzflag channel is run on irc.stormcenter.net
* #bzflag (unofficial 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.

There is a BZFlag-hosted IRC client at http://my.BZFlag.org/irc/irc.cgi.

=External links=
*[http://my.BZFlag.org/irc/irc.cgi BZFlag.org-hosted IRC client]
*[http://irchelp.org/ IRC help docs]

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

Group Permissions

2007-09-19T23:23:20Z

Thumper:

{{merge|Server Permissions}}

Below is a list of all the available group permissions. They are used by the server to determine what players can and can not do. There is an online [http://groupdb.links-clan.net/ Group File builder] and there is a [[Sample_Group_File|sample group file]] page.

{|{{Prettytable}}
|-
|<b>Permission</b> || <b>Commands</b>
|-
| ACTIONMESSAGE || /me
|-
| ADMINMESSAGERECEIVE || Able to recieve messages on admin channel
|-
| ADMINMESSAGESEND || Able to send messages to admin channel
|-
| ANTIBAN || protected from being banned
|-
| ANTIDEREGISTER || Protected from being deregistered locally
|-
| ANTIKICK || Protected from being kicked
|-
| ANTIPOLL || Protected from being polled against
|-
| ANTIPOLLBAN || Protected from being poll banned
|-
| ANTIPOLLKICK || Protected from being poll kicked
|-
| BAN || /ban /hostban
|-
| BANLIST || /banlist /hostbanlist
|-
| COUNTDOWN || /countdown
|-
| DATE || /date
|-
| ENDGAME || /gameover
|-
| FLAGHISTORY || /flaghistory
|-
| FLAGMASTER || /flag give, /flag take, /flag reset, and /flag up
|-
| FLAGMOD || /flag reset and /flag up
|-
| HIDEADMIN || Does not show the @ symbol by admins
|-
| IDLESTATS || /idlestats
|-
| INFO || Not implemented
|-
| KICK || /kick
|-
| LAGSTATS || /lagstats
|-
| LAGWARN || /lagwarn
|-
| LISTPERMS || Not implemented
|-
| MASTERBAN || /masterban
|-
| PLAYERLIST || /playerlist
|-
| POLL || /poll
|-
| POLLBAN || /poll ban
|-
| POLLKICK || /poll kick
|-
| POLLSET || /poll set
|-
| POLLFLAGRESET || /poll flagreset
|-
| PRIVATEMESSAGE || /privateMessage
|-
| RECORD || /record
|-
| REJOIN || Protects player from the rejoin delay after disconnecting
|-
| REMOVEPERMS || /removegroup
|-
| REPLAY || /replay
|-
| REQUIREIDENTIFY || Requires that the player is identified before playing
|-
| SAY || /say
|-
| SETALL || /reload /deregister /reset /set
|-
| SETPASSWORD || /setpassword
|-
| SETPERMS || /setgroup
|-
| SETVAR || /set /reset
|-
| SHOWOTHERS || /showgroup
|-
| SHORTBAN || /shortBan
|-
| SHUTDOWNSERVER || /shutdownserver
|-
| SPAWN || Allows player to spawn
|-
| SUPERKILL || /superkill
|-
| UNBAN || /unban /hostunban
|-
| VETO || /veto
|-
| VIEWREPORTS || /viewreports
|-
| VOTE || /vote
|-
|}

==External Resources==
[http://groupdb.links-clan.net/ groupdb.links-clan.net Group File builer]
[[Category:Server]]

CommunityAdministrationNetwork/Players

2007-05-10T02:09:06Z

Thumper: typos

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by players to play on servers that are part of the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Players on network servers must only meet 2 requirements.

===Global Registration===
Players must have a valid global user name and login, and play using that name.

===Follow the Rules===
Players are expected to follow the 6 network rules as they are specified in the [[CommunityAdminstrationNetwork/About#Rules|Community Administration Network]] Document. Failure to follow these rules can result in administrative actions.

==Disputes==
Players that have a dispute are expected to work with the administration staff to resolve the dispute in a calm and civil manner in private. The admin staff will gladly work with players to resolve any technical, network, or software issues that may cause violations of any of the rules. The admin staff has a good working relationship with the project developers and will ask them to assist in diagnosing any problems. Players are expected to assist the admin staff in resolving the issues so that everyone can have a fun game.

If a dispute is unable to be resolved by the Field Agents, the player can bring the issue to the attention of the Core Administrators. The Core Administrators can be contacted via the following means.

* <SOME EMAIL ADDRESS WE PICK>
* the ##CommunityAdminNetwork IRC channel on irc.freenode.net:6667
* BZBB PM to any core member ( list them somewhere ).

Issues that players may have with the Core Administration team should be addressed to the Network Administrator directly.

==Questions==

===I would like to help out and be a field agent, what do I do?===
The answer to this question is complex. It is important to understand exactly what a field agent does before a player decides they wish to apply to the network. All users should be aware of the requirements, and expected behaviors of a field agent as well as the full ruleset for the network. The [[CommunityAdminstrationNetwork/Field_Agent|Field Agent]] guide lists the requirements and behaviors. Players should also have a history of good play on one or more member servers before they even think about applying as a field agent.

Once a player has read and understands all the material, they should contact the Administration staff and let them know that they are interested in donating their time as a field agent. The best way to do this is via the IRC channel, or e-mail. Once you have let the staff know, you should simply wait. Field agents are chosen based off of a number of criteria, and need. Pushing, pestering, or bugging people to become an agent, shows that the applicant probably does not meet the behavior needs of field agent. A new field agent must be sponsored by an existing Core Administrator. 3 or more existing field agents can petition the Core Administrators to sponsor a new field agent. Agents are only added if there is a need for more. The network administrator has veto and approval power over all field agents.

When a new field agent is approved, they will be asked to read and agree to the field agent agreement form, and fill in valid contact info, age, and verify that they have read and understand the network rules and administration policy. They will also be trained and tested on the use of the CANAdmin plug-in. After this is completed, the users BZID will be added to the central database as a field agent. Other field agents or the network administration staff may monitor or review any new or existing field agents actions at any time.

CommunityAdministrationNetwork/Players

2007-05-10T01:45:05Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by players to play on servers that are part of the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Players on network servers must only meet 2 requirements.

===Global Registration===
Players must have a valid global user name and login, and play using that name.

===Follow the Rules===
Players are expected to follow the 6 network rules as they are specified in the [[CommunityAdminstrationNetwork/About#Rules|Community Administration Network]] Document. Failure to follow these rules can result in administrative actions.

==Disputes==
Players that have a dispute are expected to work with the administration staff to resolve the dispute in a calm and civil manner in private. The admin staff will gladly work with players to resolve any technical, network, or software issues that may cause violations of any of the rules. The admin staff has a good working relationship with the project developers and will ask them to assist in diagnosing any problems. Players are expected to assist the admin staff in resolving the issues so that everyone can have a fun game.

If a dispute is unable to be resolved by the Field Agents, the player can bring the issue to the attention of the Core Administrators. The Core Administrators can be contacted via the following means.

* <SOME EMAIL ADDRESS WE PICK>
* the ##CommunityAdminNetwork IRC channel on irc.freenode.net:6667
* BZBB PM to any core member ( list them somewhere ).

Issues that players may have with the Core Administration team should be addressed to the Network Administrator directly.

==Questions==

===I would like to help out and be a field agent, what do I do?===
The answer to this question is complex. It is important to understand exactly what a field agent does before a player decides they wish to apply to the network. All users should be aware of the requirements, and expected behaviors of field agent as well as the full ruleset for the network. The [[CommunityAdminstrationNetwork/Field_Agent|Field Agent]] guide lists the requirements and behaviors. Players should also have a history of good play on one or more member servers before they even think about field agents.

Once a player has read and understands all the material, they should contact the Administration staff and let them know that they are interested in donating their time as a field agent. The best way to do this is via the IRC channel, or e-mail. Once you have let the staff know, you should simply wait. Field agents are chosen based off of a number of criteria, and need. Pushing, pestering, or bunging people to become an agent, shows that the applicant probably does not meet the behavior needs of field agent. A new field agent must be sponsored by an existing Core Administrator. 3 or more existing field agents can petition the Core Administrators to sponsor a new field agent. Agents are only added if there is a need for more. The network administrator has veto and approval power over all field agents.

When a new field agent is approved, they will be asked to read and agree to the field agent agreement form, and fill in valid contact info, age, and verify that they have read and understand the network rules and administration policy. They will also be trained and tested on the use of the CANAdmin plug-in. After this is completed, the users BZID will be added to the central database as a field agent. Other field agents or the network administration staff may monitor or review any new or existing field agents actions at any time.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:42:06Z

Thumper: typos

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer the user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation of one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for their call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is the harshest action a Field Agent can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:39:41Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer the user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation of one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for their call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:37:48Z

Thumper: typos

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer the user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation of one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for there call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:34:26Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer the user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for there call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:32:22Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for there call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:28:17Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat there offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for there call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/Field Agent

2007-05-10T01:23:38Z

Thumper: typo

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by Field Agents for the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Requirements==
Field Agents must meet the following requirements.

===Global Registration===
Field Agents must have a valid global name and login, with valid contact info.

===Age===
Field Agents must be at least 17 years of age, or be approved by the network administrator.
Field Agents must report their correct age to the administration staff when asked.

===Record===
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.

===Sponsorship and approval===
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.

==Behavior==
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.

===Follow the Rules===
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).

===Be Civil===
Field Agents are expected to conduct there administration in a calm and civil manner. They should not let anger or personal feelings get in the way of there administration duties, they are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreement with players over administrative issues should happen in private so they will disrupt the play for others as little as possible. Field Agents must remember that it is there job to help all users play the game and have fun.

===Give the benefit of the doubt===
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of there ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat there offenses. Users that abuse this will not be given that courtesy a second time.

===Use the least necessary action to resolve an issue===
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer user to the Core Administrators if a suitable resolution can not be found.

===Use CAN admin abilities only for network violations===
All admin actions on servers must be in response to a violation one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then they must use the server's local administration system to enforce those additional rules, and not the network system.

Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule to include additional language that is not mentioned in the rule, based on personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. For Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4(spamming).

Agents that abuse the network admin features for there own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any any Agent.

==Administrative actions==
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.

===NetWarn===
Usage
'''/NetWarn''' ''Rule'' Player ''Comment''

This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.

===NetActivityList===
Usage
'''/NetActivityList''' Player

This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for there call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.

===NetSilence===
Usage
'''/NetSilence''' ''Rule'' Player ''Comment''
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.

===NetKick===
Usage
'''/NetKick''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.

===NetBan===
Usage
'''/NetBan''' ''Rule'' Player ''Reason''
This action will force the specfied user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is harshest action a Field Agents can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.

===NetBanCritical===
Usage
'''/NetBanCritical''' ''Rule'' Player ''Reason''
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.

CommunityAdministrationNetwork/DisallowedWords

2007-05-10T01:21:40Z

Thumper: typo

{{CommunityAdministrationNetwork}}

== Overview==
This page lists the disallowed words for the network. They are here as a reference. Readers that are easily offended by vulgarity should discontinue reading now.

These words are disallowed as they are most often used in a manner to offend or insult, and have no legitimate bearing on the game.

== Major Words==
Uses of these words, or variations containing them is considered a direct violation.

Fuck
Shit
Asshole
Cunt
Motherfucker
Cock

== Minor Words==
Uses of these words or there variations in most contexts is considered a direct violation.

Nigger
Hitler
Anal
Bitch

CommunityAdministrationNetwork/Server Owners

2007-05-10T01:18:50Z

Thumper: Typos and grammer

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by server owners who are part of the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Membership Requirements==

Membership as a CAN server is rather simple, and requires the server owner to agree to a few small things, and install a single plug-in.

===Publicly List===
CAN is only for public servers. It is not available for private servers, due to it's link with global authentication and web based services.

===Require Global Authentication===
Running a CAN server means that the server owner agrees to only allow registered players to spawn and talk. This is required and enforced by the CANAdmin plug-in, so it can do it's work using BZIDs and does not have to do any form of IP bans or blocks.

===Provide a contact name and e-mail===
The CAN system needs a contact name and e-mail for each server or group of servers that it runs. This is so that the administration staff can contact the server owners if need be, and for the CAN website to send automatically generated usage/action logs every week. Servers with invalid contact information will be removed from the network.

===Provide a valid domain name and port for each server running===
The CAN system needs to know the names and ports of each server that is run in order to verify it's membership in the network.

===Run a minimum version of the BZFS server===
In order for the CANAdmin plug-in to work, it will require a specific version of BZFS. Server owners that can not build there own BZFS simply need to ask, and the network staff can work with you to get a version that is compatible with the required server.

===Understand the service===
It is important that each server owner understand what services are being offered by the network, and what services are not. As well as understanding what responsibilities do and don't come with network membership. Being a CAN member server does not automatically confer any network administration status or abilities to the server owner. While many server owners would make fine field agents or core administrators and may be asked to participate in the network in those positions, they will not be judged for those positions solely on there ownership of a server. Field Agent positions have there own set of criteria for membership and they will be chosen for those alone. Server owners do not loose any local administration ability by becoming a CAN member server.

==Actions that will result in membership termination==

There is a small number of actions that will result in the termination of the membership agreement with a server.

===Modification of the CANAdmin plug-in===
A server owner should never need to modify the plug-in, or change it in any way. Use of a modified plug-in can result in the removal of a server from the network. If a server owner requires additional features from the plug-in, they should contact the administration staff, so the features can be worked into the base plug-in code.

==Disputes with Administration actions==

The administration team is more then happy to work with server owners to resolve any issues or disputes that they may have with the actions of it's agents. Accountability of agent actions is a primary goal of the network. If a server owner has any issue with an action, it is best that they talk to the administration team about it as soon as possible. Issues such as a "rouge agent" or a misplaced ban are taken very seriously by the network and the admin staff will do it's best to have it resolved as soon as possible. If need be, the core administrators can "undo" all the actions of specific agents.

The administration staff asks that server owners not block access to the server for any of its agents except in the worst of circumstances, and that it not override the actions of the administration staff, as it will prevent the network from doing what has been agreed upon. If a server owner feels they must take actions such as these, the admin staff highly recommends opening a dialog as soon as possible.

Server owners are free to unload or remove the CANAdmin plug-in at any time to leave the network at there own discretion. The Core Administrators and the Network Administrator reserve the right to remove any server from the CAN network at any time, with notification.

CommunityAdministrationNetwork/Server Owners

2007-05-10T01:15:14Z

Thumper: Grammar fix

{{CommunityAdministrationNetwork}}

==Overview==
This page describes the information needed by server owners who are part of the [[CommunityAdminstrationNetwork/About|Community Administration Network]].

==Membership Requirements==

Membership as a CAN server is rather simple, and requires the server owner to agree to a few small things, and install a single plug-in.

===Publicly List===
CAN is only for public servers. It is not available for private servers, due to it's link with global authentication and web based services.

===Require Global Authentication===
Running a CAN server means that the server owner agrees to only allow registered players to spawn and talk. This is required and enforced by the CANAdmin plug-in, so it can do it's work using BZIDs and does not have to do any form of IP bans or blocks.

===Provide a contact name and e-mail===
The CAN system needs a contact name and e-mail for each server or group of servers that it runs. This is so that the administration staff can contact the server owners if need be, and for the CAN website to send automatically generated usage/action logs every week. Servers with invalid contact information will be removed from the network.

===Provide a valid domain name and port for each server running===
The CAN system needs to know the names and ports of each server that is run in order to verify it's membership in the network.

===Run a minimum version of the BZFS server===
In order for the CANAdmin plug-in to work, it will require a specific version of BZFS. Server owners that can not build there own BZFS simply need to ask, and the network staff can work with you to get a version that is compatible with the required server.

===Understand the service===
It is important that each server owner understand what services are being offered by the network, and what services are not. As well as understanding what responsibilities do and don't come with network membership. Being a CAN member server does not automatically confer any network administration status or abilities to the server owner. While many server owners would make fine field agents or core administrators and may be asked to participate in the network in those positions, they will not be judged for those positions solely on there ownership of a server. Field Agent positions have there own set of criteria for membership and they will be chosen for those alone. Server owners do not loose any local administration ability by becoming a CAN member server.

==Actions that will result in membership termination==

There is a small number of actions that will result in the termination of the membership agreement with a server.

===Modification of the CANAdmin plug-in===
A server owner should never need to modify the plug-in, or change it in any way. Use of a modified plug-in can result in the removal of a server from the network. If a server owner requires additional features from the plug-in, they should contact the administration staff, so the features can be worked into the base plug-in code.

==Disputes with Administration actions==

The administration team is more then happy to work with server owners to resolve any issues or disputes that they may have with the actions of it's agents. Accountability of agent actions is a primary goal of the network. If a server owner has any issue with an action, it is best that they talk to the administration team about it as soon as possible. Issues such as a "rouge agent" or a misplaced ban are taken very seriously by the network and the admin staff will do it's best to have it resolved as soon as possible. If need be, the core administrators can "undo" all the actions of specific agents.

The administration staff asks that server owners not block access to the server for any of it's agents except in the worst of circumstances, and that it not override the actions of the administration staff, as it will prevent the network from doing what has been agreed upon. If a server owner feels they must take actions such as these, the admin staff highly recommends opening a dialog as soon as possible.

Server owners are free to unload or remove the CANAdmin plug-in at any time to leave the network at there own discression. The Core Administrators and the Network Administrator reserve the right to remove any server from the CAN network at any time, with notification.

CommunityAdministrationNetwork/About

2007-05-10T01:05:51Z

Thumper: Typo

{{CommunityAdministrationNetwork}}

==Overview==
The Community Administration Network is an independent organization of server owners and administrators who have chosen to group together to provide the best possible play experience to BZFlag players.

'''Please note'''
The network is just in it's conceptual stages at this point. Please post any questions, comments, or concerns to the talk page. Also if you are a server owner that would be interested in being a member please also post that to the talk page, we are very interested in knowing who would like to participate.

==Organization==
The Network is made up of servers whose owners have chosen to provide the network administration staff the ability to manage and enforce a specific set of rules on their servers.

Information for users playing on member servers can be found on the [[CommunityAdminstrationNetwork/Players]] page.

The network is made up of the following groups.

===Server Owners===
These are server owner/operators that have chosen to participate in the network. The owners have agreed to the rules for servers and have been accepted into the network. They run the CANAdmin plug-in as part of their server setup. Information on the requirements and expectations of server owners can be found on the [[CommunityAdminstrationNetwork/Server Owners]] page.

===Field Agent===
These are users chosen from the community to do the day-to-day admin actions on network servers. They are normal players that have agreed to the terms and rules for CAN Field Agents. They use the CANAdmin plug-in on network servers to perform their administration actions. All actions by all agents are logged by the network for review. Information on the requirements and expectations of Field Agents can be found on the [[CommunityAdminstrationNetwork/Field Agent]] page.

===Core Administrators===
These are a smaller group of administrators that in addition to the abilities of the field agents, is responsible for arbitrating disputes between players and field agents and for adding or removing field agents when needed. The Core administration team is also responsible for approving and reviewing the servers that make up the network.

===Network Administrator===
The network administrator in addition to being a Core Administrator, is the one person responsible for the entire network. He/she creates the rules to which all other administrators and server owners agree. The network administrator has the power of veto over any action of the other agents but must provide a reasonable explanation, or face the other administrators and agents abandoning the network (making it pointless).

==CANAdmin plug-in==
The network administrators make use of a special plugin that server administrators install to allow network administration. This allows agents to apply network wide warnings, kicks, and bans to users that violate the network rules and regulations. The network agents are only able to enforce the network-specific rules on servers and by default do not have any additional administrative permissions or abilities on any server. A server owner may choose to give network agents additional abilities, but it is not required for network membership.

==Rules==
The network has a very specific set of rules that it applies to servers. This rule set is expected to be a small subset of the rules on any one server. CAN Administrators will only enforce these specific rules by default. Every administrative action (warn, kick, and ban) will be logged with the rule number to which the violation applies, as well as any applicable logs or records needed.

===1) Global Registration===
All users must be globally registered and identified to play. This includes spawning and talking. Violations of this rule never have administrative action, as it is automatically enforced by the CANAdmin plug-in (i.e., unregistered players cannot connect to servers using the plug-in, they are automatically rejected).

===2) No Cheating===
Users must not use modified clients to gain an unfair advantage over other users. This includes any modification that changes the behavior of a player tank from the release version of the game, or any modification that provides additional information or reaction time to the game.
Examples include (but are not limited to):
* God Mode (un-killable)
* Auto-Aim
* Seeing Stealth or Cloak.
* Jump Modification
* Speed modification
* Tank hit size modification
* Shot end modification
Additional items may be added based on the observations of the administrator. If a user is experiencing network or software problems that may appear to be cheats, then it is up to them to work with the Administration staff and/or the project development to rectify the issue as soon as they are warned. The administration staff will be more then happy to work with the users to determine the cause of any software- or network-related issues. If the issues are network-related and cause the disruption of play with other users, network administrators can request that the user discontinue play on a specific server until such time as network conditions improve. The administrators are expected to speak to the players about the behavior before taking any action to determine its cause.

===3) No Exploiting===
Users must not use in-game features or flaws to gain an unfair advantage over other players. This includes using game features or bugs to create artificial lag spikes, tweaks or changes to the input system, or the operating system / drivers to create positional discrepancies or speed changes. If the administration staff asks a user to discontinue an action that is causing a problem, the user is expected to refrain from that action. This includes the use of external applications to modify the game's internal state or network data.

===4) No Griefing===
Users must not engage in behavior that is disruptive to the play of the game. This includes actions such as intentional team-killing, intentional self-genocide, or capturing the user's own team flag in a CTF game. This also includes message spamming. The administration team does understand that isolated accidents do happen. Users warned of this offense are expected to take care to not repeat the actions.

===5) Minimum Language Rules===
Users are expected to adhere to a set of [[CommunityAdminstrationNetwork/DisallowedWords|minimum language rules]] that disallows a set of very specific words when using public or team chat channels. Users are also expected to refrain from attacking or making disparaging remarks about other users, race, creed, or beliefs. The in game chat is for chat about the game while playing. Users who are warned for language violations are expected to discontinue use of the offensive language, and continue to play in a civil manner. It should be noted that individual servers can and will have more strict language polices in place that they may administer locally. The minimum language policy applies to user callsigns, and in game e-mail addresses, as well as chat text.

===6) No disruption of public services===
Users are expected to not take actions that would disrupt any of the network's or project's public services. This includes any websites or forums, IRC channels, or servers operated by the network itself, or the BZFlag project. Actions of this nature are very serious and will not be taken lightly.

==Common Questions and concerns==

===Questions===
====Does the network do range bans?====
All bans are handled by the CANAdmin plug-in and are done based on the BZID of the users. Since a requirement to be a CAN server is to only allow registered users, IP bans of any sort are not needed.

===What the Network Is===
This is a list of items that describe what the network is meant for:

====The CAN is a group of people:====
The network consists of people. People that the server owners have chosen to trust to enforce a set of rules. It is run by people for people. People are human. It is assumed that people can and will make mistakes on both sides. Mistakes can be fixed as long as both parties are willing to work at fixing the problem in a civil manner.

====The CAN is reasonable:====
Administrators are more then willing to listen to anyone who has been kicked or banned, as long as the user is willing to work with them in a reasonable manner. If a user has an issue that can not be resolved with an administrator, they should take it up to the next level of administration as indicated in the organization section above.

====The CAN keeps records, lots of them:====
The CANAdmin plug-in will track all actions done by administrators, and can provide them for review if needed. These records are kept independently of any logging or tracking that server owners choose to do, and are intended to be used by network staff only. This provides a set of checks and accountability for all actions, as well as records of the reasons behind any action.

====The CAN is a team:====
Network administrators work together. Any administrator can work on any problem, regardless of who the issue started with. Administrators are encouraged to work together, with other administrators, and players.

====The CAN works with leagues:====
Since the field agents don't have any control over gameplay commands, and the CANAdmin plug-in doesn't use any of the host servers administration functions, there is no reason why a league server can not also be a CAN member server. The network rules should be compatible as a subset for all leagues.

===What the network is not===

====The CAN is not your mom====
The network does not exist to arbitrate small disagreements in playstyle or behavior. It will not make Billy stop touching your flag. It does not exist to decide what is or isn't fair in games. The rules that the network enforces have nothing to do with gameplay or any specific game ruleset. The CAN will not and can not do such actions as resetting flags, balancing teams, or changing server variables.

====The CAN does not take over a server.====
By default CAN administrators do not have access to a server banlist, groups, passwords, users, or any other abilities. All network actions are applied by the CANAdmin plug-in and do not affect the server settings in any way.

====The CAN is not a democracy.====
The network is a service provided by its administrator and trusted staff. Server owners can choose to allow the CAN onto their servers, or they can choose not to. The network is not designed or run by any sort of committee. It is run following the specific rules set forth in this document.

====The CAN is not the master ban list.====
While some of the network administration staff are also part of the BZFlag project, the network itself is not. Network bans are not part of the global master ban list that is applied by default to all public servers. Actions against the project itself may result in CAN administrative action, but the reverse is not always true.

== See Also==
[[CommunityAdminstrationNetwork/Server Owners]]

[[CommunityAdminstrationNetwork/Field Agent]]

[[CommunityAdminstrationNetwork/Core Administrators]]

[[CommunityAdminstrationNetwork/Players]]

[[CommunityAdminstrationNetwork/CANAdmin Plug-In]]

CommunityAdministrationNetwork/About

2007-05-10T00:55:06Z

Thumper: Typo

{{CommunityAdministrationNetwork}}

==Overview==
The Community Administration Network is an independent organization of server owners and administrators who have chosen to group together to provide the best possible play experience to BZFlag players.

'''Please note'''
The network is just in it's conceptual stages at this point. Please post any questions, comments, or concerns to the talk page. Also if you are a server owner that would be interested in being a member please also post that to the talk page, we are very interested in knowing who would like to participate.

==Organization==
The Network is made up of servers whose owners have chosen to provide the network administration staff the ability to manage and enforce a specific set of rules on their servers.

Information for users playing on member servers can be found on the [[CommunityAdminstrationNetwork/Players]] page.

The network is made up of the following groups.

===Server Owners===
These are server owner/operators that have chosen to participate in the network. The owners have agreed to the rules for servers and have been accepted into the network. They run the CANAdmin plug-in as part of their server setup. Information on the requirements and expectations of server owners can be found on the [[CommunityAdminstrationNetwork/Server Owners]] page.

===Field Agent===
These are users chosen from the community to do the day-to-day admin actions on network servers. They are normal players that have agreed to the terms and rules for CAN Field Agents. They use the CANAdmin plug-in on network servers to perform their administration actions. All actions by all agents are logged by the network for review. Information on the requirements and expectations of Field Agents can be found on the [[CommunityAdminstrationNetwork/Field Agent]] page.

===Core Administrators===
These are a smaller group of administrators that in addition to the abilities of the field agents, is responsible for arbitrating disputes between players and field agents and for adding or removing field agents when needed. The Core administration team is also responsible for approving and reviewing the servers that make up the network.

===Network Administrator===
The network administrator in addition to being a Core Administrator, is the one person responsible for the entire network. He/she creates the rules to which all other administrators and server owners agree. The network administrator has the power of veto over any action of the other agents but must provide a reasonable explanation, or face the other administrators and agents abandoning the network (making it pointless).

==CANAdmin plug-in==
The network administrators make use of a special plugin that server administrators install to allow network administration. This allows agents to apply network wide warnings, kicks, and bans to users that violate the network rules and regulations. The network agents are only able to enforce the network-specific rules on servers and by default do not have any additional administrative permissions or abilities on any server. A server owner may choose to give network agents additional abilities, but it is not required for network membership.

==Rules==
The network has a very specific set of rules that it applies to servers. This rule set is expected to be a small subset of the rules on any one server. CAN Administrators will only enforce these specific rules by default. Every administrative action (warn, kick, and ban) will be logged with the rule number to which the violation applies, as well as any applicable logs or records needed.

===1) Global Registration===
All users must be globally registered and identified to play. This includes spawning and talking. Violations of this rule never have administrative action, as it is automatically enforced by the CANAdmin plug-in (i.e., unregistered players cannot connect to servers using the plug-in, they are automatically rejected).

===2) No Cheating===
Users must not use modified clients to gain an unfair advantage over other users. This includes any modification that changes the behavior of a player tank from the release version of the game, or any modification that provides additional information or reaction time to the game.
Examples include (but are not limited to):
* God Mode (un-killable)
* Auto-Aim
* Seeing Stealth or Cloak.
* Jump Modification
* Speed modification
* Tank hit size modification
* Shot end modification
Additional items may be added based on the observations of the administrator. If a user is experiencing network or software problems that may appear to be cheats, then it is up to them to work with the Administration staff and/or the project development to rectify the issue as soon as they are warned. The administration staff will be more then happy to work with the users to determine the cause of any software- or network-related issues. If the issues are network-related and cause the disruption of play with other users, network administrators can request that the user discontinue play on a specific server until such time as network conditions improve. The administrators are expected to speak to the players about the behavior before taking any action to determine its cause.

===3) No Exploiting===
Users must not use in-game features or flaws to gain an unfair advantage over other players. This includes using game features or bugs to create artificial lag spikes, tweaks or changes to the input system, or the operating system / drivers to create positional discrepancies or speed changes. If the administration staff asks a user to discontinue an action that is causing a problem, the user is expected to refrain from that action. This includes the use of external applications to modify the game's internal state or network data.

===4) No Griefing===
Users must not engage in behavior that is disruptive to the play of the game. This includes actions such as intentional team-killing, intentional self-genocide, or capturing the user's own team flag in a CTF game. This also includes message spamming. The administration team does understand that isolated accidents do happen. Users warned of this offense are expected to take care to not repeat the actions.

===5) Minimum Language Rules===
Users are expected to adhere to a set of [[CommunityAdminstrationNetwork/DisallowedWords|minimum language rules]] that disallows a set of very specific words when using public or team chat channels. Users are also expected to refrain from attacking or making disparaging remarks about other users, race, creed, or beliefs. The in game chat is for chat about the game while playing. Users who are warned for language violations are expected to discontinue use of the offensive language, and continue to play in a civil manner. It should be noted that individual servers can and will have more strict language polices in place that they may administer locally. The minimum language policy applies to user callsigns, and in game e-mail addresses, as well as chat text.

===6) No disruption of pubic services===
Users are expected to not take actions that would disrupt any of the network's or project's public services. This includes any websites or forums, IRC channels, or servers operated by the network itself, or the BZFlag project. Actions of this nature are very serious and will not be taken lightly.

==Common Questions and concerns==

===Questions===
====Does the network do range bans?====
All bans are handled by the CANAdmin plug-in and are done based on the BZID of the users. Since a requirement to be a CAN server is to only allow registered users, IP bans of any sort are not needed.

===What the Network Is===
This is a list of items that describe what the network is meant for:

====The CAN is a group of people:====
The network consists of people. People that the server owners have chosen to trust to enforce a set of rules. It is run by people for people. People are human. It is assumed that people can and will make mistakes on both sides. Mistakes can be fixed as long as both parties are willing to work at fixing the problem in a civil manner.

====The CAN is reasonable:====
Administrators are more then willing to listen to anyone who has been kicked or banned, as long as the user is willing to work with them in a reasonable manner. If a user has an issue that can not be resolved with an administrator, they should take it up to the next level of administration as indicated in the organization section above.

====The CAN keeps records, lots of them:====
The CANAdmin plug-in will track all actions done by administrators, and can provide them for review if needed. These records are kept independently of any logging or tracking that server owners choose to do, and are intended to be used by network staff only. This provides a set of checks and accountability for all actions, as well as records of the reasons behind any action.

====The CAN is a team:====
Network administrators work together. Any administrator can work on any problem, regardless of who the issue started with. Administrators are encouraged to work together, with other administrators, and players.

====The CAN works with leagues:====
Since the field agents don't have any control over gameplay commands, and the CANAdmin plug-in doesn't use any of the host servers administration functions, there is no reason why a league server can not also be a CAN member server. The network rules should be compatible as a subset for all leagues.

===What the network is not===

====The CAN is not your mom====
The network does not exist to arbitrate small disagreements in playstyle or behavior. It will not make Billy stop touching your flag. It does not exist to decide what is or isn't fair in games. The rules that the network enforces have nothing to do with gameplay or any specific game ruleset. The CAN will not and can not do such actions as resetting flags, balancing teams, or changing server variables.

====The CAN does not take over a server.====
By default CAN administrators do not have access to a server banlist, groups, passwords, users, or any other abilities. All network actions are applied by the CANAdmin plug-in and do not affect the server settings in any way.

====The CAN is not a democracy.====
The network is a service provided by its administrator and trusted staff. Server owners can choose to allow the CAN onto their servers, or they can choose not to. The network is not designed or run by any sort of committee. It is run following the specific rules set forth in this document.

====The CAN is not the master ban list.====
While some of the network administration staff are also part of the BZFlag project, the network itself is not. Network bans are not part of the global master ban list that is applied by default to all public servers. Actions against the project itself may result in CAN administrative action, but the reverse is not always true.

== See Also==
[[CommunityAdminstrationNetwork/Server Owners]]

[[CommunityAdminstrationNetwork/Field Agent]]

[[CommunityAdminstrationNetwork/Core Administrators]]

[[CommunityAdminstrationNetwork/Players]]

[[CommunityAdminstrationNetwork/CANAdmin Plug-In]]

Slash Commands

2007-04-10T18:53:49Z

Thumper:

Below is a list of the commands that are available in BZFlag. Access to most of these commands is controlled through [[Server_Permissions|permissions]].

All commands are preceded by a '/' on any chat prompt.
The format for commands that take arguments are provided by the server by issuing the command with no arguments. (ie. `/ban`)

'''Some commands take no arguments''' (eg. ''/shutdownserver'', ''/superkill'') '''and therefore''' do not return the format string for the command but '''execute the command instead.'''

{|{{Prettytable}}
|-
| {{Hl3}} |'''Command'''
| {{Hl3}} |'''Description'''
|-
| ''/?'' || List commands
|-
| ''/ban'' || Ban players using the specified IPs of the player specified for certain length of time from using this server.
|-
| ''/banlist'' || List all of the IPs currently banned from this server. Items from the master ban list on my.bzflag.org/bb have an '(m)' after the IP for masterban. If an argument is specified only bans that match the argument are displayed.
|-
| ''/checkip'' || Check if a specified IP is banned or not and report the results.
|-
| ''/clientquery'' || Retrieve client version info from all users, or just CALLSIGN if given
|-
| ''/countdown'' || Starts the countdown sequence for a timed game. The countdown sequence length can optionally be specified in seconds.
|-
| ''/date'' || Responds with the current server local date and time (same as /time).
|-
| ''/deregister'' || With an argument, it deregisters another user's callsign . Without, it removes your own registration. (only affects local registration)
|-
| ''/endgame'' || Ends the current game
|-
| ''/flag reset'' || Repositions flags. If unused is specified, flags carried by tanks are not affected.
|-
| ''/flag up'' || Removes all flags from the game
|-
| ''/flag show'' || Shows all flags with information.
|-
| ''/flag give'' || Give the specified flag to the specified player. This command spawns the flag directly above the play, so if they are moving the flag will fall on the ground near them. If the flag is not available, it will take a flag from the person who has the flag specified. You cannot give flags that do not exist on the map.
|-
| ''/flag take'' || Will take the flag that the player specified is currently carrying.
|-
| ''/flaghistory'' || Lists what flags players have grabbed in the past.
|-
| ''/gameover'' || Ends a timed game.
|-
| ''/ghost'' || Kicks off an impersonating player or ghost
|-
| ''/grouplist'' || Lists the available user groups
|-
| ''/groupperms'' || Lists the permissions for each group
|-
| ''/help'' || With no argument it displays a lists the help files available. With the argument it displays the contents of the help file.
|-
| ''/hostban'' || Ban players using the specified hostnames for a certain length of time from using this server.
|-
| ''/hostbanlist'' || List all of the host patterns currently banned from this server.
|-
| ''/hostunban'' || Will remove the the specified host from the ban list so that players from that host will be able to blay again.
|-
| ''/idban'' || Ban a player by bzbb id. This will stick even if the player ip changes.
|-
| ''/idbanlist'' || List all bans made with ''/idban''
|-
| ''/identify'' || Log in to a registered callsign
|-
| ''/idlestats'' || Displays the idle time in seconds for each player. A player is idle when he is dead and has not respawned yet.
|-
| ''/idlist'' || Will list the currently banned IDs
|-
| ''/idunban'' || Will remove the ban on the ID specified so that the player may play on the server again.
|-
| ''/kick'' || Kick a named player off the server.
|-
| ''/kill'' || Kill a player (they explode)
|-
| ''/lagdrop'' || With no argument it displays current lagdrop setting, with argument it sets it to the value specified. This specifies the number of warnings a player gets due to high lag before the server kicks the players.
|-
| ''/lagstats'' || Lists network delays, jitter and number of lost (out of order packets) by player.
|-
| ''/lagwarn'' || With no argument it displays current lagwarn setting, with argument it sets it to the value specified. If a players lag is higher that the setting they will be warned, then kicked.
|-
| ''/localset'' || Set local client variables in your configuration file.
|-
| ''/masterban'' || Manipulate the master ban list.
|-
| ''/me'' || This command displays an "action" that is conveyed to another player. It allows for a little more expressivity in the game. For example: "/me is hunting wabbits" turns into a message like "Thumper is hunting wabbits" that gets displayed differently to other players.
|-
| ''/msg'' || This command allows a player to send a message to another player. Similar to using the "," and "." message keys in the game and then selecting your recipient, this will send some message to particular player.
|-
| ''/mute'' || Allows a server admin to remove the ability for a player to communicate with other players. Once muted the player may only talk to admins on the server. This command removes the TALK permission for that user.
|-
| ''/part'' || Leave the server with a goodbye message (same as /quit).
|-
| ''/password'' || Enter server password to gain operator privileges.
|-
| ''/playerlist'' || List player names and IP addresses.
|-
| ''/poll'' || Start a player poll
|-
| ''/quit'' || Leave the server with a goodbye message (same as /part).
|-
| ''/record'' || List all files in the recordings directory
|-
| ''/record start'' || Starts recording
|-
| ''/record stop'' || Stops recording
|-
| ''/record size'' || Specify size of recording buffer in megabytes (MB)
|-
| ''/record rate'' || Specify recording rate in seconds
|-
| ''/record stats'' || Display statistics of recording
|-
| ''/record file'' || Specify a filename for recording instead of using memory
|-
| ''/record save'' || Save an in-memory recording buffer to a file
|-
| ''/register'' || Register your current callsign locally to the specified password. Passwords must be at least 3 characters long, and the callsign may not contain quotes or other non-alphanumeric/space characters. We use global logons and this is not needed.
|-
| ''/reload'' || Reloads the user, group, and password files (for synchronization between multiple servers on the same machine)
|-
| ''/removegroup'' || Remove a user from a group
|-
| ''/replay list'' || List recording files that can be replayed
|-
| ''/replay load'' || Load a recording file for play
|-
| ''/replay play'' || Start playback of the loaded recording
|-
| ''/replay skip'' || Skip forwards or backwards through the recording
|-
| ''/report'' || Write a message to the server administrator
|-
| ''/reset'' || Reset a server variable to it's bzfs default setting.
|-
| ''/say'' || Generate a public message sent by the server. For example "/say This is a server message", will display ''[SERVER:] This is a server message (Thumper)''
|-
| ''/sendhelp'' || Send a help file to a player
|-
| ''/serverquery'' || Report the server version number
|-
| ''/set'' || With no arguments it will list the values of all server variables. With the arguments it will set the variable that is specified to the value that is given.
|-
| ''/setgroup'' || Add a user to a group
|-
| ''/setpass'' || Changes your password (for locally registered users, not globally)
|-
| ''/showgroup'' || Lists the groups that a registered user is a member of
|-
| ''/showperms'' || Show permissions granted to yourself or another player
|-
| ''/shutdownserver'' || Stop serving BZFlag on this server.
|-
| ''/superkill'' || Kick all players off the server.
|-
| ''/time'' || Responds with the current server local date and time (same as /date).
|-
| ''/unban'' || Will remove the IP adress from the banlist, allowing someone from that address to conncet and play BZFlag.
|-
| ''/unmute'' || Allows a server admin to restore the TALK permission to a previously muted player.
|-
| ''/uptime'' || Prints server's current running time in days, hours, mins and secs.
|-
| ''/veto'' || If there is a poll active, this will cancel the poll.
|-
| ''/viewreports'' || View the server's report file.
|-
| ''/vote'' || If there is a poll active, this command will place a vote in favor or in opposition to the poll. Multiple languages are supported as a vote argument in addition to "yes" and "no". By default, you must be registered to vote on a poll.
|}

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

BZFlagWiki:Content Policy

2007-04-09T03:03:58Z

Thumper: Typos and grammer

This page describes the acceptable content policy for articles in this wiki.

== Overview ==
The BZFlag wiki is provided as shared informational resource for the player community. It's intended content is factual information regarding the BZFlag game and it's community. To do this it must maintain a level of impartiality when dealing with that content. Bellow is a set of guidelines for users posting articles here.

== Subjects ==
All articles on the BZflag wiki MUST have a direct bearing on the game itself. Articles that are not directly related to the game will be removed from the wiki.
=== Acceptable Subjects ===
The following are acceptable subjects for BZFlag Wiki Articles.
* Documentation of BZFlag Software.
* Documentation of BZFlag terms and concepts.
* Documentation of tasks specific to the direct use of the BZFlag source code, or software.
* Factual historical references of BZFlag , software, source code, and developers.
* General Information about specific maps, and links to there location.
* General Information about specific servers, and links to there administration and websites.
* General Information about server networks, and links to there administration and websites.

=== Unacceptable Subjects ===
The following subjects should not be addressed in wiki articles.
* Server specific rules and policies.
* Advertisements for specific servers, users, or maps.

== Article contents ==
The contents of articles must be presented in an impartial and factual manner. Wiki articles should be considered descriptive of their subjects, and at all times informational. If a statement can not be backed up with facts, it does not belong in the article. If the fact has no bearing on the subject matter in a descriptive way, it does not belong in the article. Some articles will have more or less factual content following these rules. The further away a subject is from the core game, the less information is applicable to the wiki. The page describing the command line options of the BZFS server will have significantly more applicable information then an article on a network of servers will.

If the article does not deal directly with the BZFlag software or development process, and needs to reference information that is available on other websites, then the article should simply link to them. This includes items such as server rules, and other information that is elsewhere.

Articles should not be written to promote or hinder any one specific server, network, group, or person. No statements should be based on opinion.

== Writing style ==
As previously stated articles should be written to be descriptive. Personal words like "you", "me", "your", etc.. should not be used, as the wiki is not a conversation. If part of the article is a description of steps of action, then they should simply be described as the action taken, not the actions of the specific user.

== Content Disputes ==
As the wiki is user edited, conflicts and edits in the contents or articles can and will occur. When an article is changed, the previous author should read the changes and attempt to understand them before taking any action. Users changing articles should leave descriptive comments with the change indicating why they changed the article. If a previous author disputes the changes, they should attempt to work out an amicable solution on the talk page of the article. The use of the Revert function should not be used in haste, it is primarily intended to assist with article vandalism, or when a change blatantly disregards this policy ( no "revert wars ). Users that are unable to work out acceptable content for an article should contact the Project Administrators and be prepared to explain the issue and how the desired content will follow this policy.