BZFlagWiki - User contributions [en]

DevelopmentPlans/2.3

2011-05-25T00:34:41Z

Trepan: /* 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.

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

Observer Mode

2010-08-28T04:43:18Z

Trepan: Mention mouse controls and /forceradar

{{Stub}}
[[Image:Observer_selection.png|right|thumb|300px|Selecting the observer mode]]
==Overview==

The observer mode can be used to watch other players or team flags. It can also be used to freely roam around the map.

==Controls==

The default controls for observer mode are as follows:
{|{{Prettytable}}
|Control Binding
|Action
|-
|L
|Display a label just under each tank listing their name.
|-
|Arrow Keys
|Navigates the camera around with tank-driving style controls.
|-
|Ctrl+Arrow Keys
|Pans and tilts the camera without moving the position.
|-
|Shift+Arrow Keys
|Moves the camera position up and down vertically, and left and right horizontally.
|-
|Alt+Arrow Keys
|Strafe side to side.
|-
|F6/F7
|Previous/Next target in the current display mode. Does not have any effect in the roaming mode.
|-
|F8
|Cycles through various observer modes: roaming, driving with a tank, following a tank, tracking a tank, and tracking a team flag.
|-
|F9/F10
|Sets narrow/wide viewing angle, allows you to see more or less of the field
|-
|F11
|Resets viewing angle to default
|-
|A
|Toggles momentum on the camera movement.
|}

==/roampos Command==

This is an extra command for use in roaming mode that enables you to define the camera position and rotation. 
/roampos ["reset" | degrees | {x y z [theta [phi [ zoom ]]] } | "send"]

==/forceradar Command==
The /forceradar command was added in v2.0.16. It allows observers to see
the radar on "no-radar" worlds.

==Mouse Controls==
Mouse observer controls were added in v2.0.16. By using various combinations of
the left/middle/right mouse buttons, you can change the location and orientation
of your viewpoint. You can also change the observer mode and target using the
mouse wheel.

V3RCChecklist

2010-05-14T06:00:30Z

Trepan: BufferedNetworkManager is dead - removed the critical task

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

==RC Critical fixes.==
# Dead-reckoning / lag-compensation testing / message loop / lag
# MsgPause fix

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

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

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

==Notes==

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

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

V3RCChecklist

2010-05-14T05:58:21Z

Trepan: removed the network-data-order / motto critical fix

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

==RC Critical fixes.==
# Dead-reckoning / lag-compensation testing / message loop / lag
# MsgPause fix

==RC Critical Tasks==
# Remove Buffered Network Manager, and just fix NetHandler's buffers.
# Linux Package review (new files in the right places )
# Mac installer review (check it in)
# Readme Updates
# Docs for V3 changes (-a missing, caps on server, lag comp, etc..)
# API review (spelling, consistency)

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

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

==Notes==

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

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

V3RCChecklist

2010-04-13T00:38:30Z

Trepan: rearrangement

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

==RC Critical fixes.==
# Dead-reckoning / lag-compensation testing / message loop / lag
# Network data is being received or processed by the client in the opposite order causing many odd bugs, such as the motto not being displayed, and possibly causing players' flags from not showing up when you join.
# MsgPause fix

==RC Critical Tasks==
# Remove Buffered Network Manager, and just fix NetHandler's buffers.
# Linux Package review (new files in the right places )
# Mac installer review (check it in)
# Readme Updates
# Docs for V3 changes (-a missing, caps on server, lag comp, etc..)
# API review (spelling, consistency)

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

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

==Notes==

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

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

V3RCChecklist

2010-04-12T21:04:17Z

Trepan:

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

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

==RC Critical Tasks==
# Remove Buffered Network Manager, and just fix NetHandler's buffers.
# Implement map features to define proper "flag pass" behavior in maps that want it
# Linux Package review (new files in the right places )
# Mac installer review (check it in)
# Readme Updates
# Docs for V3 changes (-a missing, caps on server, lag comp, etc..)
# API review (spelling, consistency)
# Dead-reckoning / lag-compensation testing / message loop / lag

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

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

==Notes==

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

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

BZFlag 2.99

2009-10-08T14:06:05Z

Trepan: /* Release Date */

BZFlag version 3.0 is the next planned release of BZFlag.

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

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

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

==Features==
v3.0 has a number of features that make for a much improved gameplay experience.

===Fonts===
The font system has been replaced and now uses standard TrueType fonts([http://en.wikipedia.org/wiki/TrueType TTF]). This offers a number of advantages over the older bitmap based font system, including support for unicode character sets.

Users can now set the default fonts that they wish to use on a per-locale basis so they can use the best fonts for their character set. (More info on how?)

===Server Side Logic===
A number of gameplay features have been moved from the client to the server, to ensure more consistent gameplay over the internet, including;
* Flag operations (pickup, capture, identify, etc)
* Pause/unpause
* Shot type

===Game state and security checks===
Many changes and enhancements have been made to the network protocol to prevent errors in the network message stream or shared game state.

===BZW Format===
*Links can now be included in groups, with relative naming.
*Mesh faces can now be used as teleportation link sources (with numerous options)
*Mesh faces can now be used as team bases (must be flat tops).
*Mesh faces can now be used as zones (must be flat tops).
*Meshes can now contain weapon objects.
*World Text objects have been added (with numerous options)
*Dynamic Colors now use a simpler format.
*Solid objects can now specify the 'ricochet' property individually.

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

The new Experimental mode includes new shot and flag graphics.

===New Server List===
The list of servers has been enhanced to allow tabbed browsing as well as improved searching and sorting.

===HUD Markers===
If HUD markers showing flag position, GM lockon are now shown to players. THe name and team of the closest target is also shown, helping prevent teamkills. Servers can turn off this feature for all players if desired.

===BZFS API===
The [[BZFS API]] has been reviewed and re-factored for 3.0 and includes a number of new events and functions.

====Server Side Players====
The API has experimental support for server side players (bots).

====Custom Flag Names====
The API may define new custom flag names using any strings desired. The ammount of logic that can be processed for custom flags is limited.

====HTTP based plug-ins====
The networking system for BZFS now allows for the support of HTTP (and other ) connections. A number of plugins have been made to take advantage of this new feature, such as;
* [[Fastmap]]
* [[Webadmin]]
* [[Webreport]]
* [[Webstats]]

====BZFS API Versioning====
The versioning system in the BZFS API has been redone, and now event data classes are versioned for forward computability. Custom plug-ins that were written for v2.0.x must be updated to use the new classnames before they will work with v3.0.x. This should only be a one time change as the new classes are versioned and will remain the same in future releases. All standard plug-ins that ship with the bzflag source code have been updated.

===Lua BZFS API===
The lua scripting language (http://lua.org), is now built into the bzfs executable, and exposes almost all of the features from the C++ BZFS API (and a few that the C++ API does not have). It has the advantages of being easier to learn and write than comparable C++ code, and it can be embedded in world files. The main disadvantage is that it is not as fast as native c++ code.

===Server Administration===
Some changes have been made to help you server administrators.

The [[Webadmin]] plug-in allows server owners to manage many aspects of the server from a standard web browsers.

====Local Authentication====
Local authentication ( '''/identify''' ), has been removed from the game, servers can use global authentication services for all authentication needs.

===Gameplay Changes===
A number of changes have been made to the game that will subtly affect gameplay.
====Acceleration====
Tank acceleration is now always on. The "-a" server option has been removed, and the acceleration values are pulled from BZDB variables. These variables are _inertiaLinear and _inertiaAngular.

====Lag Compensation====
Clients now use a synced timestmap and attempt to compensate tank positions for lag. This can change the way the game feels for players that are used to "leading" the target based on its lag.

====Hit Volume====
The volume that defines a "hit" on a tank has been changed. It is now a box around the tank that can be adjusted by the server using BZDB variables.

====No TK Option====
A server can define an option that will allow players to not be killed if a team-mates shot hits them

===Build System===
Much effort has been put into making the bzflag source tree easier to compile on various OSs. The makefile build system has been updated and attempts to detect as many items as possible from the host System. The windows build system has been updated to be compatible with Visual Studio 2008 Express Edition that is freely available. When possible, copies of third party libraries are included with the source code.

===Bug Fixes===
A student is being paid as part of the Google Summer of Code program to evaluate and fix the backlog of reported bugs in the software. This will have the overall effect of increasing the stability of the game.

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

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

==Release Date==
As is always the case for major updates to BZFlag, '''''3.0 will be released when it is done'''''. It is possible that the release will occur in the fourth quarter of 2009, the first quarter of 2010, or the third quarter of 2020.

==Misconceptions about V3.0==
There have been a few misconceptions in the community regarding what this new version will and will not do. Most of this is simply due to the exceptionally long development time, or comments being taken out of context.

'''V3 will do everything Server Side, including shots'''

This is untrue. While more things have been moved to the server, shoots and hits are still handled by the client. Shots and hits will not be moved to the server until the code can be shown to maintain the level of response time that players have come to expect.

'''V3 will use more bandwith and be laggy'''

V3 does a better job of handling network traffic to and from players. Many messages have been reduced in size. Server side handling of some events, (like flag grabs) have actually removed some messages from the network stream. Network performance should be similar to V2.x. In some cases, lag compensation may even improve apparent performance.

==See also==
[[Versions]]

[[V3RCChecklist]]

[[Category:Versions]]

Server authentication

2009-07-26T13:01:36Z

Trepan: align with the bzfs warning

==Overview==
Version 3.0 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.

BZFlag 2.99

2009-07-11T04:12:19Z

Trepan: noted the 'ricochet' keyword

BZFlag version 3.0 is the next planned release of BZFlag.

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

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

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

==Features==
v3.0 has a number of features that make for a much improved gameplay experience.

===Fonts===
The font system has been replaced and now uses standard TrueType fonts([http://en.wikipedia.org/wiki/TrueType TTF]). This offers a number of advantages over the older bitmap based font system, including support for unicode character sets.

Users can now set the default fonts that they wish to use on a per-locale basis so they can use the best fonts for their character set. (More info on how?)

===Server Side Logic===
A number of gameplay features have been moved from the client to the server, to ensure more consistent gameplay over the internet, including;
* Flag operations (pickup, capture, identify, etc)
* Pause/unpause
* Shot type

===Game state and security checks===
Many changes and enhancements have been made to the network protocol to prevent errors in the network message stream or shared game state.

===BZW Format===
*Links can now be included in groups, with relative naming.
*Mesh faces can now be used as teleportation link sources (with numerous options)
*Mesh faces can now be used as team bases (must be flat tops).
*Mesh faces can now be used as zones (must be flat tops).
*Meshes can now contain weapon objects.
*World Text objects have been added (with numerous options)
*Dynamic Colors now use a simpler format.
*Solid objects can now specify the 'ricochet' property individually.

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

The new Experimental mode includes new shot and flag graphics.

===New Server List===
The list of servers has been enhanced to allow tabbed browsing as well as improved searching and sorting.

===HUD Markers===
If HUD markers showing flag position, GM lockon are now shown to players. THe name and team of the closest target is also shown, helping prevent teamkills. Servers can turn off this feature for all players if desired.

===BZFS API===
The [[BZFS API]] has been reviewed and re-factored for 3.0 and includes a number of new events and functions.

====Server Side Players====
The API has experimental support for server side players (bots).

====Custom Flag Names====
The API may define new custom flag names using any strings desired. The ammount of logic that can be processed for custom flags is limited.

====HTTP based plug-ins====
The networking system for BZFS now allows for the support of HTTP (and other ) connections. A number of plugins have been made to take advantage of this new feature, such as;
* [[Fastmap]]
* [[Webadmin]]
* [[Webreport]]
* [[Webstats]]

====BZFS API Versioning====
The versioning system in the BZFS API has been redone, and now event data classes are versioned for forward computability. Custom plug-ins that were written for v2.0.x must be updated to use the new classnames before they will work with v3.0.x. This should only be a one time change as the new classes are versioned and will remain the same in future releases. All standard plug-ins that ship with the bzflag source code have been updated.

===Lua BZFS API===
The lua scripting language (http://lua.org), is now built into the bzfs executable, and exposes almost all of the features from the C++ BZFS API (and a few that the C++ API does not have). It has the advantages of being easier to learn and write than comparable C++ code, and it can be embedded in world files. The main disadvantage is that it is not as fast as native c++ code.

===Server Administration===
Some changes have been made to help you server administrators.

The [[Webadmin]] plug-in allows server owners to manage many aspects of the server from a standard web browsers.

====Local Authentication====
Local authentication ( '''/identify''' ), has been removed from the game, servers can use global authentication services for all authentication needs.

===Gameplay Changes===
A number of changes have been made to the game that will subtly affect gameplay.
====Acceleration====
Tank acceleration is now always on. The "-a" server option has been removed, and the acceleration values are pulled from BZDB variables.

====Lag Compensation====
Clients now use a synced timestmap and attempt to compensate tank positions for lag. This can change the way the game feels for players that are used to "leading" the target based on it's lag.

====Hit Volume====
The volume that defines a "hit" on a tank has been changed. It is now a box around the tank that can be adjusted by the server using BZDB variables.

====No TK Option====
A server can define an option that will allow players to not be killed if a team-mates shot hits them

===Build System===
Much effort has been put into making the bzflag source tree easier to compile on various OSs. The makefile build system has been updated and attempts to detect as many items as possible from the host System. The windows build system has been updated to be compatible with Visual Studio 2008 Express Edition that is freely available. When possible, copies of third party libraries are included with the source code.

===Bug Fixes===
A student is being paid as part of the Google Summer of Code program to evaluate and fix the backlog of reported bugs in the software. This will have the overall effect of increasing the stability of the game.

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

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

==Release Date==
As is always the case for major updates to BZFlag, '''''3.0 will be released when it is done'''''. At present, a major effort is being made to release sometime in the third quarter of the year.

==Misconceptions about V3.0==
There have been a few misconceptions in the community regarding what this new version will and will not do. Most of this is simply due to the exceptionally long development time, or comments being taken out of context.

'''V3 will do everything Server Side, including shots'''

This is untrue. While more things have been moved to the server, shoots and hits are still handled by the client. Shots and hits will not be moved to the server until the code can be shown to maintain the level of response time that players have come to expect.

'''V3 will use more bandwith and be laggy'''

V3 does a better job of handling network traffic to and from players. Many messages have been reduced in size. Server side handling of some events, (like flag gabs) have actually removed some messages from the network stream. Network performance should be similar to V2.x. In some cases, lag compensation may even improve apparent performance.

==See also==
[[Versions]]

[[V3RCChecklist]]

[[Category:Versions]]

BZFlag 2.99

2009-07-11T04:09:24Z

Trepan: s/API/BZFS API/, noted the lua bzfs api addition, added some BZW Format changes

BZFlag version 3.0 is the next planned release of BZFlag.

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

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

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

==Features==
v3.0 has a number of features that make for a much improved gameplay experience.

===Fonts===
The font system has been replaced and now uses standard TrueType fonts([http://en.wikipedia.org/wiki/TrueType TTF]). This offers a number of advantages over the older bitmap based font system, including support for unicode character sets.

Users can now set the default fonts that they wish to use on a per-locale basis so they can use the best fonts for their character set. (More info on how?)

===Server Side Logic===
A number of gameplay features have been moved from the client to the server, to ensure more consistent gameplay over the internet, including;
* Flag operations (pickup, capture, identify, etc)
* Pause/unpause
* Shot type

===Game state and security checks===
Many changes and enhancements have been made to the network protocol to prevent errors in the network message stream or shared game state.

===BZW Format===
*Links can now be included in groups, with relative naming.
*Mesh faces can now be used as teleportation link sources (with numerous options)
*Mesh faces can now be used as team bases (must be flat tops).
*Mesh faces can now be used as zones (must be flat tops).
*Meshes can now contain weapon objects.
*World Text objects have been added (with numerous options)
*Dynamic Colors now use a simpler format.

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

The new Experimental mode includes new shot and flag graphics.

===New Server List===
The list of servers has been enhanced to allow tabbed browsing as well as improved searching and sorting.

===HUD Markers===
If HUD markers showing flag position, GM lockon are now shown to players. THe name and team of the closest target is also shown, helping prevent teamkills. Servers can turn off this feature for all players if desired.

===BZFS API===
The [[BZFS API]] has been reviewed and re-factored for 3.0 and includes a number of new events and functions.

====Server Side Players====
The API has experimental support for server side players (bots).

====Custom Flag Names====
The API may define new custom flag names using any strings desired. The ammount of logic that can be processed for custom flags is limited.

====HTTP based plug-ins====
The networking system for BZFS now allows for the support of HTTP (and other ) connections. A number of plugins have been made to take advantage of this new feature, such as;
* [[Fastmap]]
* [[Webadmin]]
* [[Webreport]]
* [[Webstats]]

====BZFS API Versioning====
The versioning system in the BZFS API has been redone, and now event data classes are versioned for forward computability. Custom plug-ins that were written for v2.0.x must be updated to use the new classnames before they will work with v3.0.x. This should only be a one time change as the new classes are versioned and will remain the same in future releases. All standard plug-ins that ship with the bzflag source code have been updated.

===Lua BZFS API===
The lua scripting language (http://lua.org), is now built into the bzfs executable, and exposes almost all of the features from the C++ BZFS API (and a few that the C++ API does not have). It has the advantages of being easier to learn and write than comparable C++ code, and it can be embedded in world files. The main disadvantage is that it is not as fast as native c++ code.

===Server Administration===
Some changes have been made to help you server administrators.

The [[Webadmin]] plug-in allows server owners to manage many aspects of the server from a standard web browsers.

====Local Authentication====
Local authentication ( '''/identify''' ), has been removed from the game, servers can use global authentication services for all authentication needs.

===Gameplay Changes===
A number of changes have been made to the game that will subtly affect gameplay.
====Acceleration====
Tank acceleration is now always on. The "-a" server option has been removed, and the acceleration values are pulled from BZDB variables.

====Lag Compensation====
Clients now use a synced timestmap and attempt to compensate tank positions for lag. This can change the way the game feels for players that are used to "leading" the target based on it's lag.

====Hit Volume====
The volume that defines a "hit" on a tank has been changed. It is now a box around the tank that can be adjusted by the server using BZDB variables.

====No TK Option====
A server can define an option that will allow players to not be killed if a team-mates shot hits them

===Build System===
Much effort has been put into making the bzflag source tree easier to compile on various OSs. The makefile build system has been updated and attempts to detect as many items as possible from the host System. The windows build system has been updated to be compatible with Visual Studio 2008 Express Edition that is freely available. When possible, copies of third party libraries are included with the source code.

===Bug Fixes===
A student is being paid as part of the Google Summer of Code program to evaluate and fix the backlog of reported bugs in the software. This will have the overall effect of increasing the stability of the game.

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

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

==Release Date==
As is always the case for major updates to BZFlag, '''''3.0 will be released when it is done'''''. At present, a major effort is being made to release sometime in the third quarter of the year.

==Misconceptions about V3.0==
There have been a few misconceptions in the community regarding what this new version will and will not do. Most of this is simply due to the exceptionally long development time, or comments being taken out of context.

'''V3 will do everything Server Side, including shots'''

This is untrue. While more things have been moved to the server, shoots and hits are still handled by the client. Shots and hits will not be moved to the server until the code can be shown to maintain the level of response time that players have come to expect.

'''V3 will use more bandwith and be laggy'''

V3 does a better job of handling network traffic to and from players. Many messages have been reduced in size. Server side handling of some events, (like flag gabs) have actually removed some messages from the network stream. Network performance should be similar to V2.x. In some cases, lag compensation may even improve apparent performance.

==See also==
[[Versions]]

[[V3RCChecklist]]

[[Category:Versions]]

V3RCChecklist

2009-07-03T07:55:44Z

Trepan:

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

==RC Critical fixes.==
# MsgPause fix '''<trepan>'''
# 32-bit teleporter-vs-box bug '''<BulletCatcher ? >'''

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

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

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

Material

2009-02-05T01:21:22Z

Trepan: Transparency => Translucency

A material is used in a BZFlag world to define a new look for otherwise regular objects, such as [[Meshbox|meshboxes]].

==Code==
To put a material in your map, first it must be defined:
{|
|
material
name example_material
texture filename
addtexture filename
notextures
notexcolor
notexalpha
texmat -1
dyncol -1
ambient 0.0 0.0 0.0 1.0
diffuse 1.0 1.0 1.0 1.0
color 1.0 1.0 1.0 1.0
specular 0.0 0.0 0.0 1.0
emission 0.0 0.0 0.0 1.0
shininess 0.0
resetmat
spheremap
noradar
noshadow
noculling
nosorting
nolighting
alphathresh 0.0
groupalpha
occluder
end
|}
Valid parameters for a Material are:
<properties>
name=name for reference
texture=set the texture (must be .png but don't include the extension unless on the Internet)
addtexture=add a texture (again, no extension is needed)
notextures=don't use textures.
notexcolor=don't apply the [[Color(BZW)|color]] to the texture
notexalpha=don't use the texture's alpha channel
texmat=specify a [[TextureMatrix|texture matrix]]. -1 for no texture matrix. (addtexture must be used before texmat)
dyncol=specify a [[DynamicColor|dynamic color]]. -1 for no dynamic color.
ambient=ambient color
diffuse=diffuse (main)[[Color(BZW)|color]]
[[Color(BZW)|color]]=synonym for diffuse
specular=specular [[Color(BZW)|color]]
emission=emission [[Color(BZW)|color]]
shininess=shiny!
resetmat=restore default values
spheremap=use spherical texture coordinate mapping
noradar=do not display on radar (except normal mode)
noshadow=do not render shadows
noculling=do not cull by face winding (double-sided)
nosorting=do not do front-to-back alpha sorting
nolighting=disable lighting
alphathresh=alpha thresholding value
groupalpha=sort translucent faces as a group
occluder=faces with this material will occlude
</properties>
To actually apply a material, you must use some sort of reference in an object, like so:
{|
|
meshbox
position 0 0 10
rotation 0
size 10 10 5
matref example_material
end
|}

==Translucency==
Material translucency is enabled by setting the alpha component of a material's [[Color(BZW)|color]] to a value less than one. Translucent objects should be sparingly, because everything behind them must always be rendered. In addition, very large translucent objects may be sorted and drawn in the wrong order. This is caused by the fact that the Z-buffer cannot be used because it would allow another translucent object to cover the translucent object, which would not look right. Thus, the translucent elements are instead sorted by determining the distance to a point in the center, which works well as long as there are not too many large translucent objects.
The same applies to textures that have translucent sections.

==Magic Material Names==
===General===
[[GroundMaterial]] 
WaterMaterial 
LinkMaterial For Teleporter Links 
TeleMaterial For Teleporter Frame (BZFlag version 3.0)

===Skybox===
[[LeftSkyboxMaterial]] 
[[RightSkyboxMaterial]] 
[[FrontSkyboxMaterial]] 
[[BackSkyboxMaterial]] 
[[TopSkyboxMaterial]] 
[[BottomSkyboxMaterial]] 

==History==
Materials were added in [[BZFlag 2.0.0]].

==Editor Support==
Materials are supported in [[Blender]] with [[BZWTools]], [[pyBZEdit]], and [[Wings3D]] with the [[BZW Exporter for Wings3D]]. Materials are NOT supported in [[BZEdit]], [[BZFed]] or IBZEdit.

==A note about textures==
A material can be composed of colors and textures. Textures are .png files that are either in the client directory or on the Internet. The terms ''material'' and ''texture'' are often confused and misunderstood, so bear the above in mind.

[[category:Map_Objects]]
[[category:Map Making]]

Material

2009-02-05T01:16:38Z

Trepan: specified Links for LinkMaterial

A material is used in a BZFlag world to define a new look for otherwise regular objects, such as [[Meshbox|meshboxes]].

==Code==
To put a material in your map, first it must be defined:
{|
|
material
name example_material
texture filename
addtexture filename
notextures
notexcolor
notexalpha
texmat -1
dyncol -1
ambient 0.0 0.0 0.0 1.0
diffuse 1.0 1.0 1.0 1.0
color 1.0 1.0 1.0 1.0
specular 0.0 0.0 0.0 1.0
emission 0.0 0.0 0.0 1.0
shininess 0.0
resetmat
spheremap
noradar
noshadow
noculling
nosorting
nolighting
alphathresh 0.0
groupalpha
occluder
end
|}
Valid parameters for a Material are:
<properties>
name=name for reference
texture=set the texture (must be .png but don't include the extension unless on the Internet)
addtexture=add a texture (again, no extension is needed)
notextures=don't use textures.
notexcolor=don't apply the [[Color(BZW)|color]] to the texture
notexalpha=don't use the texture's alpha channel
texmat=specify a [[TextureMatrix|texture matrix]]. -1 for no texture matrix. (addtexture must be used before texmat)
dyncol=specify a [[DynamicColor|dynamic color]]. -1 for no dynamic color.
ambient=ambient color
diffuse=diffuse (main)[[Color(BZW)|color]]
[[Color(BZW)|color]]=synonym for diffuse
specular=specular [[Color(BZW)|color]]
emission=emission [[Color(BZW)|color]]
shininess=shiny!
resetmat=restore default values
spheremap=use spherical texture coordinate mapping
noradar=do not display on radar (except normal mode)
noshadow=do not render shadows
noculling=do not cull by face winding (double-sided)
nosorting=do not do front-to-back alpha sorting
nolighting=disable lighting
alphathresh=alpha thresholding value
groupalpha=sort translucent faces as a group
occluder=faces with this material will occlude
</properties>
To actually apply a material, you must use some sort of reference in an object, like so:
{|
|
meshbox
position 0 0 10
rotation 0
size 10 10 5
matref example_material
end
|}

==Transparency==
The transparency effect is created by setting the alpha component of a material's [[Color(BZW)|color]] to a value less than one.
Transparent objects should be sparingly, because everything behind them must always be rendered. In addition, very large transparent objects may be sorted and drawn in the wrong order. This is caused by the fact that the Z-buffer cannot be used because it would allow another transparent object to cover the transparent object, which would not look right. Thus, the transparent elements are instead sorted by determining the distance to a point in the center, which works well as long as there are not too many large transparent objects.
The same applies to textures that have transparent sections.

==Magic Material Names==
===General===
[[GroundMaterial]] 
WaterMaterial 
LinkMaterial For Teleporter Links 
TeleMaterial For Teleporter Frame (BZFlag version 3.0)

===Skybox===
[[LeftSkyboxMaterial]] 
[[RightSkyboxMaterial]] 
[[FrontSkyboxMaterial]] 
[[BackSkyboxMaterial]] 
[[TopSkyboxMaterial]] 
[[BottomSkyboxMaterial]] 

==History==
Materials were added in [[BZFlag 2.0.0]].

==Editor Support==
Materials are supported in [[Blender]] with [[BZWTools]], [[pyBZEdit]], and [[Wings3D]] with the [[BZW Exporter for Wings3D]]. Materials are NOT supported in [[BZEdit]], [[BZFed]] or IBZEdit.

==A note about textures==
A material can be composed of colors and textures. Textures are .png files that are either in the client directory or on the Internet. The terms ''material'' and ''texture'' are often confused and misunderstood, so bear the above in mind.

[[category:Map_Objects]]
[[category:Map Making]]