BZFlagWiki - User contributions [en]

BZtank

2014-09-26T04:49:10Z

DTRemenak: Reverted edits by 162.195.208.115 (talk) to last revision by 193.104.113.21

BZtank is a BZFlag server network located in London, United Kingdom.

==Background==
BZtank was founded in 2007 by current server owner Benfish to improve the gaming experience for non-North American players, and to create a fun and open online community. BZtank quickly became very popular amongst international BZFlag players due to its central location, providing good ping times to gamers throughout Europe, Asia, and India. Many North American players, however, frequent the server as well, creating a unique player dynamic. The server network hosts several popular maps, and often carries the largest cumulative player load in BZFlag.

==Current Maps==
BZtank currently hosts eight maps:

*01.bztank.net:5154 - [[The Two Tanks]]
*02.bztank.net:5155 - [[Castle Warfare]]
*03.bztank.net:5156 - A*A Bridge Crossing - Can you make it?
*04.bztank.net:5157 - LaserMania - Classic BZflag!
*05.bztank.net:5158 - LouMan's Mystic Valley - Magical!
*06.bztank.net:5159 - Missile War - The Original Four Team CTF!
*07.bztank.net:5160 - Roundabout - Don't get dizzy!
*08.bztank.net:5161 - INCOMING! - Run for your life!

==Community==
In addition to playing BZFlag, many members also actively participate in the BZtank community. The BZtank [http://bztank.net/ forum] is a popular hangout, where players discuss maps, strategy, BZ artwork, and non-game related topics. BZtank also maintains the [irc://irc.stormcenter.net/#bzflag #bzflag IRC channel] on irc.stormcenter.net which can be accessed directly through the BZtank homepage via [http://irc.bztank.net web interface], or with any standard IRC client.

==Admin Staff==
{| class="wikitable" style="width:100%" border="1"
|+ '''Network Owner:''' Benfish, '''Head Admin:''' [[User:DonnyBaker|joevano]], and '''Senior Admin:''' Swigg
! Cops || Admins || Trusted Admins
|-
| Abominable || ahs3 || allejo
|-
| crackhead || ALEX France || Constitution
|-
| Duck Season || Bisque || [[User:Mets|Mets]]
|-
| Jon- || Cruel Dog || [[User:Tedius|Tedius]]
|-
| knock || daniel jackson || temporal distraction
|-
| Murielle || Dexter || think_tank
|-
| || Dodge_This || ukiki
|-
| || drunk driver || Warinthestar
|-
| || ducatiwannabe ||
|-
| || Enigma ||
|-
| || G5 Serenity 2011 ||
|-
| || gnu-sense ||
|-
| || Grand Hustla ||
|-
| || Green Manalishi ||
|-
| || Grumpy Smurf ||
|-
| || High Karate Kitty ||
|-
| || hj ||
|-
| || jadespacy ||
|-
| || jbionic ||
|-
| || LanDing ||
|-
| || Lt-Kirby2007 ||
|-
| || [[User:Mr_Burns|Mr_Burns]] ||
|-
| || Pesky_UK ||
|-
| || PETER ||
|-
| || R3lax ||
|-
| || Rio_Dj_narrow ||
|-
| || Sky King ||
|-
| || sse ||
|-
| || stive ||
|-
| || Teppic ||
|-
| || that exploding tank ||
|-
| || TheOneAndOnly ||
|-
| || War Pig ||
|-
| || Zaphod ||
|-
| || Zelgadis ||
|-
|. || Zen_Master ||
|}

==External Links==
* [http://www.bztank.net BZtank homepage]
[[Category:Server Network]]

DevelopmentPlans/2.3

2011-05-12T21:16:00Z

DTRemenak: mark some things

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

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

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

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

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

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

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

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

====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
* New API events ''JeffM''
* Custom flag system ''DTRemenak''
* BZFSCron ''Thumper''
* Server Side Players ''JeffM''
* Bug fixes not in notes ''Thumper''
* New flags
* Rabbit as proper team

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

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

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

Daniel Remenak

2011-05-11T00:04:35Z

DTRemenak: redirect to appropriate user page

#REDIRECT [[User:DTRemenak]]

DTRemenak

2011-05-11T00:03:15Z

DTRemenak: I wonder if redirects work

#REDIRECT [[User:DTRemenak]]

Auto-props

2010-05-10T07:21:29Z

DTRemenak: include mime types in autoprops

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

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

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

*.po = svn:eol-style=native;svn:mime-type=text/plain
*.am = svn:eol-style=native;svn:mime-type=text/plain
*.ac = svn:eol-style=native;svn:mime-type=text/plain
*.in = svn:eol-style=native;svn:mime-type=text/plain
*.m4 = svn:eol-style=native;svn:mime-type=text/plain

*.dsp = svn:eol-style=CRLF;svn:mime-type=text/plain
*.dsw = svn:eol-style=CRLF;svn:mime-type=text/plain
*.sln = svn:eol-style=CRLF;svn:mime-type=text/xml
*.vcproj = svn:eol-style=CRLF;svn:mime-type=text/xml
*.nsi = svn:eol-style=CRLF;svn:mime-type=text/plain
*.manifest = svn:eol-style=CRLF;svn:mime-type=text/xml

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

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

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

[[Category:Development]]

Google Summer of Code: 2009

2009-04-06T23:23:45Z

DTRemenak: /* Mentors */

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

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

= Promotion Flyers =

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

= Proposal Ideas =

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

==High-Priority Project Ideas==

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

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

'''Difficulty''': variable

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

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

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

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

'''Difficulty''': variable

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

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

'''Difficulty''': medium

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

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

'''Difficulty''': low

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

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

'''Difficulty''': low

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

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

'''Difficulty''': medium

==Additional Project Ideas ==

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

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

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

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

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

'''Difficulty''': high

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

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

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

'''Difficulty''': medium

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

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

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

'''Difficulty''': low

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

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

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

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

'''Difficulty''': low

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

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

'''Difficulty''': medium

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

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

'''Difficulty''': high

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

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

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

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

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

'''Difficulty''': low

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

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

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

'''Difficulty''': low

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

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

'''Difficulty''': low

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

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

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

'''Difficulty''': low

= Mentors =

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

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

[[Category: Development]]

Google Summer of Code: Acceptance

2009-04-02T05:45:20Z

DTRemenak: /* Make a patch */ sure, we'll take more than one patch if you want, but quality > quantity

This page is intended to lay out the basic "'''rules and requirements'''" that the BZFlag project is going to require of all [[Google Summer of Code]] students whose project proposals are accepted. Unless otherwise arranged with the BZFlag GSoC administrator (contact brlcad via IRC on irc.freenode.net), it will be expected that all students comply with the requirements outlined below.

== Application requirements ==

=== Make a patch ===
We want to make sure that you have rudimentary skills in compiling code, reading other people's code, and can even simply get BZFlag to compile. Prepare and submit a patch to our [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Sourceforge patches tracker].

Don't fret. The patch can be almost anything just so long as it is can be applied to the BZFlag sources with very minimal hassle. It should be something actually useful. The patch should ''not'' just be whitespace, indent, or style changes as we automate those periodically. It ''should'' be a functional patch such as fixing a known bug (see our BUGS file or sf bug tracker) or implementing some very minor uncontroversial feature (see our TODO file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos can make an acceptable patch. This is one of several opportunities to impress us, so feel free to be creative.

You are welcome to submit more than one patch if you like. We will review any you submit, but we only require and expect one; remember that quality is far more important than quantity in our reviews.

Be sure to include either a link to the Sourceforge patch tracker item or your Sourceforge username in your application.

=== Play BZFlag with the mentors ===
We will schedule several open gaming gatherings during the application process and ask that serious applicants come play a round of BZFlag with us. You should compile your own client using the latest BZFlag trunk sources (which is incompatible with the latest public release) when you come to the gaming session. We will work out available times to play with you after you've submitted an application.

You should ''play the game'' from a binary you've built yourself before beginning any work. You should do this ''at least once'' before the gathering if not more if you are so inclined. Being able to compile the sources on your own equipment is a very ''basic task'' that is beyond the scope of GSoC and will be an expected unassisted capacity of all students once the summer coding begins. Additionally, understanding the existing player community, what they like and dislike, and seeing how they interact is all '''very important''' for most developers to have at least a basic familiarity with. In the end, your changes will (hopefully) be pushed out to the community and you be cognizant of what that will ''mean''.

We'll be glad to help you the first time if you run into trouble. Talk to the developers.

=== Come talk to us ===
You '''''really''''' should be talking to the BZFlag developers long before submitting your application. Discuss your ideas with us on the IRC channel. Communication is a huge part of our evaluation criteria.

== Participation requirements ==

=== Assign copyright and license under the LGPL ===
Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned to Tim Riker, the project copyright holder.

=== Provide weekly progress reports ===
In addition to any communications you hold with a given mentor, the administrator, or any of the developers, it will be expected of all students that they will ''submit a brief progress report'' on a '''weekly''' basis. These reports won't need to be more than a few sentences (or at most a couple of paragraphs, whatever is appropriate) but the reports should give an indication of your overall progress, things you discover, tasks completed, difficulties encountered, milestones reached, and other similar details on your activities. You will be expected to complete a report every week, at least once a week. More information on the exact method for providing these reports will be provided after the projects commence.

=== List your milestones ===
All projects will be required to submit a '''minimum''' of three and a maximum of ten ''milestones'' for your project. These are not deliverables but, rather, are overall tasks that should be completed throughout the duration of your work. These should be necessary implementation steps and not include any research or familiarity phases. In the end, there is code that must be produced and your milestones should be a (very) rough breakdown for estimating your actual implementation progress. These milestones should be '''published in your first progress report,''' that is, at the beginning of code development (before, on or very soon after May 28).

=== Be available via IRC ===
All students will be expected to '''join the #bzflag IRC channel''' on irc.freenode.net while they are working. Students are expected to '''be on''' the channel so they can be responsive and available to the questions, inquiries, and suggestions of other BZFlag developers. BZFlag development occurs ''entirely'' over IRC as it is the central gathering forum for core development activities, developer discussions, and more. See [http://irchelp.org here] if you are new to IRC and need assistance finding a client (or just do a search). Interaction via IRC is '''required'''.

=== Create a Sourceforge account ===
BZFlag sources live in a Subversion repository on Sourceforge. You will need a Sourceforge account and will be expected to abide by the same coding requirements of the other existing developers. You will similarly be expected to know the basics of how to work with SVN and check in changes, resolve conflicts, and apply patches as needed. SVN has a nearly identical interface to CVS -- if you're familiar with CVS, then you should be fine. If you don't have a Sourceforge account, be sure to get one and familiarize yourself with BZFlag's sourceforge [http://sf.net/projects/bzflag/ account]. Whether students work on a branch or on the mainline will vary depending on the student and the project.

=== Evaluate your performance ===
Particularly for projects that interact with the client or server run-loop or affect networking (but also for others), '''quantitatively evaluate your performance''' and the impact your modifications will make. Don't prematurely optimize and don't over-architect, but also don't make guesses or assumptions either. Use a performance profiler, test your code, add temporary debug timers, have a peer review your approach, etc. Modifications to the game client and network code that detrimentally impact performance in non-optional ways will likely be rejected outright.

=== Write maintainable code ===
This requirement cannot be stressed enough. One of the primary evaluation criteria for all students is how maintainable is the end result. This is not only maintainability from the stand-point of source code longevity as it stands written, but also involves other higher-level maintainability and integration aspects. Does your implementation use interfaces, languages, tools, or techniques that introduce some new requirement to widespread BZFlag development? If so, that choice needs to be discussed and '''justified''' or otherwise mitigated as a concern. Any usage of external dependencies needs to be consensus approved by the core developers. Is your code comprehensive and comprehensible? Well-documented? Organized? You are required to follow BZFlag's [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/DEVINFO existing] developer guidelines, existing code style, and established conventions.

=== Write portable code ===
BZFlag has an extensive heritage of being as portable as reasonably possible with effort continually being taken to make sure the entire codebase works on a vareity of compilation and run-time environments. While each developer's perception of what is ''reasonable'' certainly fluctuates over the years and from developer to developer, the general intention is that code written for BZFlag should function the '''same''' on most moderately popular operating system environments as much as possible including Linux, Mac OS X, and Windows as well as other platforms. It is each developer's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is provided on other maintained platforms. You are expected to interact with other developers when portability issues are raised to resolve any problems. Portability of any dependencies being used must similarly be taken into account and relates to the aforementioned maintainability requirement.

=== Write complete code ===
Perhaps treat each week like it is your last. You should be able to hand over functional code over just about any time during development (within a day or so) to another developer. Focus on completing tasks, completing code features, and working on keeping your code functional at '''all''' stages of development. That way, no matter how far you get on your milestones or deliverable(s), other developers will be able to review, test, and readily integrate your code. Plan your development approach accordingly. You should generally not "stub" code functionality (though comments are good), but instead focus on coding "deep" instead of "wide". It's generally preferred to have 2 features that work fully, than 5 features that half-work or even 20 features that are all 90% complete.

== Pre-Flight Participation Checklist ==

* Read and agree to the above requirements
* Join the #bzflag IRC channel and introduce yourself
* Create a Sourceforge account
* Be familiar with the basics of Subversion (aka SVN).
* Compile and run BZFlag from source
* Prepare a patch
** [http://my.bzflag.org/w/BZFlag_SVN Checkout sources] from SVN
** Familiarize yourself with the basic [http://my.bzflag.org/w/BZFlag_Source source layout]
** Compile
** Play
* Familiarize yourself with BZFlag's on-line websites and services
** http://bzflag.org
** http://my.bzflag.org
** http://my.bzflag.org/bb/
** http://my.bzflag.org/w/
** http://sf.net/projects/bzflag
* Create a list of 3 to 10 milestones
* Document your milestones
* Submit your application
** Include a link to your patch
** Include your IRC handle

Google Summer of Code

2009-03-30T22:24:38Z

DTRemenak: /* 2009 (more details here) */ not just waiting anymore

__NOTOC__

'''For the third year in a row, BZFlag will be participating in the [http://code.google.com/soc Google Summer of Code]!

===See our [[Google_Summer_of_Code/2009|2009 GSoC page]] for details.===

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the projects that are of interest. Student applications will be accepted via the GSoC website between March 23 and April 3.

=Overview=

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

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

'''''Attracting and mentoring new long-term developers is our primary goal.''''' If this interests you, please let us know and submit a GSoC application.

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2009|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|requirements]]
* Read our [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] file
* Join our [[BZFlag on IRC|#bzflag on Freenode]] IRC channel
* Formulate a proposal idea, communicate with devs
* [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Submit a patch]
* Apply!

= Preparing an application =

There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what you intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) you intend to use. C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our '''[[Google_Summer_of_Code/Application_Guidelines|Application Guidelines]]''' for more details.

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

Students should propose what they actually want to work on, how you intend to work on it, what you intend to DO, what you know about that task, some details about yourself, etc. Be detailed and articulate. Brief proposals do not generally do very well. Your ability to perform the task is outright presumed by the nature of submitting a detailed application. Students should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.

You may submit more than one application (one application for each project you would enjoy working on) if you so desire. This can help us when we receive more than one strong proposal for a single project, as generally speaking we will accept only one application for each project. However, please do not submit proposals for work you will not enjoy doing, and please do not sacrifice quality for quantity. One good application makes a much better impression than two half-baked applications.

If you talk with us on IRC about your SoC proposal, be sure to include your IRC nickname somewhere in your proposal.

You should also [http://sourceforge.net/tracker/?group_id=3248&atid=303248 submit a patch] before you submit your application, and be sure to include a link to the tracker item in your proposal submission. See the [[Google Summer of Code Acceptance|development requirements]] for details.

Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, and agree to the [[Google Summer of Code Acceptance|development requirements]] before submitting an application.

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

= The application review process =

Just about every participating GSoC organization receives considerably more project proposals than can be accepted. All the applications are reviewed, evaluated, and critiqued individually. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult (so make sure your application is excellent). ''This cannot be stressed enough.'' It is rather hard for most projects to narrow down the submissions but in the end there are only so many slots to work with and the line eventually has to be drawn. Every application gets read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to see many of you become involved in BZFlag software development regardless of acceptance.

In the end, submissions are selected according to the overall long-term impact that accepting the proposal can make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, how well the student communicates with other developers, the perception that the individual is interested in being a long-term BZFlag developer, and our overall interest in having the proposed modifications made to BZFlag. Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel. Communication is one of the most important criteria.

= BZFlag participation in GSoc =

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

'''''We've been accepted.'''''

We intend to only accept at most three student slots this year. Our focus this year is on quality and cleanup so we can make a major release. Cleaning up and refactoring existing code is much more important to us this year than writing new code.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag continues to participate in the program. We accepted six students, five of which were successfully passed and integrated into our development community.

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

We accepted four students, three of which were successful in their projects.

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

[[Category: Development]]

Google Summer of Code

2009-03-30T21:20:08Z

DTRemenak: rm more if-accepted verbage

__NOTOC__

'''For the third year in a row, BZFlag will be participating in the [http://code.google.com/soc Google Summer of Code]!

===See our [[Google_Summer_of_Code/2009|2009 GSoC page]] for details.===

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the projects that are of interest. Student applications will be accepted via the GSoC website between March 23 and April 3.

=Overview=

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

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

'''''Attracting and mentoring new long-term developers is our primary goal.''''' If this interests you, please let us know and submit a GSoC application.

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2009|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|requirements]]
* Read our [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] file
* Join our [[BZFlag on IRC|#bzflag on Freenode]] IRC channel
* Formulate a proposal idea, communicate with devs
* [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Submit a patch]
* Apply!

= Preparing an application =

There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what you intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) you intend to use. C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our '''[[Google_Summer_of_Code/Application_Guidelines|Application Guidelines]]''' for more details.

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

Students should propose what they actually want to work on, how you intend to work on it, what you intend to DO, what you know about that task, some details about yourself, etc. Be detailed and articulate. Brief proposals do not generally do very well. Your ability to perform the task is outright presumed by the nature of submitting a detailed application. Students should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.

You may submit more than one application (one application for each project you would enjoy working on) if you so desire. This can help us when we receive more than one strong proposal for a single project, as generally speaking we will accept only one application for each project. However, please do not submit proposals for work you will not enjoy doing, and please do not sacrifice quality for quantity. One good application makes a much better impression than two half-baked applications.

If you talk with us on IRC about your SoC proposal, be sure to include your IRC nickname somewhere in your proposal.

You should also [http://sourceforge.net/tracker/?group_id=3248&atid=303248 submit a patch] before you submit your application, and be sure to include a link to the tracker item in your proposal submission. See the [[Google Summer of Code Acceptance|development requirements]] for details.

Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, and agree to the [[Google Summer of Code Acceptance|development requirements]] before submitting an application.

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

= The application review process =

Just about every participating GSoC organization receives considerably more project proposals than can be accepted. All the applications are reviewed, evaluated, and critiqued individually. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult (so make sure your application is excellent). ''This cannot be stressed enough.'' It is rather hard for most projects to narrow down the submissions but in the end there are only so many slots to work with and the line eventually has to be drawn. Every application gets read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to see many of you become involved in BZFlag software development regardless of acceptance.

In the end, submissions are selected according to the overall long-term impact that accepting the proposal can make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, how well the student communicates with other developers, the perception that the individual is interested in being a long-term BZFlag developer, and our overall interest in having the proposed modifications made to BZFlag. Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel. Communication is one of the most important criteria.

= BZFlag participation in GSoc =

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

'''''We've applied! We're waiting.'''''

We intend to only accept at most three student slots this year. Our focus this year is on quality and cleanup so we can make a major release. Cleaning up and refactoring existing code is much more important to us this year than writing new code.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag continues to participate in the program. We accepted six students, five of which were successfully passed and integrated into our development community.

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

We accepted four students, three of which were successful in their projects.

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

[[Category: Development]]

Google Summer of Code: 2009

2009-03-30T21:17:37Z

DTRemenak: remove if-accepted verbage

Main Page

2008-05-31T19:36:09Z

DTRemenak: link to bzwgen page

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

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

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

==Google Summer of Code 2008==
BZFlag is again participating as a mentor organization in the Google Summer of Code this year. For details, please see the [[Google Summer of Code/2008|2008 Summer of Code wiki page]]. The following applications have been accepted:

* [[Enhanced Server Listing]] - [[User:KingofCamelot|David Sanders]], mentored by [[User:DonnyBaker|Joseph Van Overberghe]]
* [[BZAuthd]] - [[User:Wyk3d|Istvan Szakats]], mentored by David Wollner
* Collision code modularization and transfer to server - Joshua Charles Bodine, mentored by [[User:JeffM2501|Jeff Myers]]
* [[LibBZW|Creating and Implementing a libBZW]] - [[User:Lukstr|Luke Rewega]], mentored by [[User:DTRemenak|Daniel Remenak ]]
* [[BZWGen revisited]] - Kornel Kisielewicz, mentored by Julio Jiménez Borreguero
* [[BZFWeb|BZFWeb, a web-based BZFS admin interface]] - [[User:BugQ|Harrison Reiser]], mentored by [[User:Spldart|James R Lawrence]]

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

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

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

Main Page

2008-04-23T20:30:51Z

DTRemenak: /* Google Summer of Code 2008 */

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

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

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

==Google Summer of Code 2008==
BZFlag is again participating as a mentor organization in the Google Summer of Code this year. For details, please see the [[Google Summer of Code/2008|2008 Summer of Code wiki page]]. The following applications have been accepted:

* [[Enhanced Server Listing]] - [[User:KingofCamelot|David Sanders]], mentored by [[User:DonnyBaker|Joseph Van Overberghe]]
* [[BZAuthd]] - [[User:Wyk3d|Istvan Szakats]], mentored by David Wollner
* Collision code modularization and transfer to server - Joshua Charles Bodine, mentored by [[User:JeffM2501|Jeff Myers]]
* [[LibBZW|Creating and Implementing a libBZW]] - [[User:Lukstr|Luke Rewega]], mentored by [[User:DTRemenak|Daniel Remenak ]]
* BZWGen revisited - Kornel Kisielewicz, mentored by Julio Jiménez Borreguero
* [[BZFWeb|BZFWeb, a web-based BZFS admin interface]] - [[User:BugQ|Harrison Reiser]], mentored by [[User:Spldart|James R Lawrence]]

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

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

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

Main Page

2008-04-23T20:30:20Z

DTRemenak: /* Google Summer of Code 2008 */

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

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

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

==Google Summer of Code 2008==
BZFlag is again participating as a mentor organization in the Google Summer of Code this year. For details, please see the [[Google Summer of Code/2008|2008 Summer of Code wiki page]]. The following applications have been accepted:

* [[Enhanced Server Listing]] - [[User:KingofCamelot|David Sanders]], mentored by [[User:DonnyBaker|Joseph Van Overberghe]]
* [[BZAuthD]] - [[User:Wyk3d|Istvan Szakats]], mentored by David Wollner
* Collision code modularization and transfer to server - Joshua Charles Bodine, mentored by [[User:JeffM2501|Jeff Myers]]
* [[LibBZW|Creating and Implementing a libBZW]] - [[User:Lukstr|Luke Rewega]], mentored by [[User:DTRemenak|Daniel Remenak ]]
* BZWGen revisited - Kornel Kisielewicz, mentored by Julio Jiménez Borreguero
* [[BZFWeb|BZFWeb, a web-based BZFS admin interface]] - [[User:BugQ|Harrison Reiser]], mentored by [[User:Spldart|James R Lawrence]]

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

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

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

Google Summer of Code

2008-04-18T06:44:54Z

DTRemenak: /* Preparing an application */ add a note about the appropriateness of multiple applications

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

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

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

'''''Attracting and mentoring new long-term developers is our primary goal.''''' If this interests you, please let us know and submit a GSoC application.

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development requirements]]
* Read our [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] file
* Join our [[BZFlag on IRC|#bzflag on Freenode]] IRC channel
* Formulate a proposal idea, communicate with devs
* [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Submit a patch]
* [http://code.google.com/soc/2008 Apply] between March 24th and '''April 7th''' (was March 31st)

= Preparing an application =

There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what you intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) you intend to use. C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our '''[[Google_Summer_of_Code/Application_Guidelines|Application Guidelines]]''' for more details.

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

Students should propose what they actually want to work on, how you intend to work on it, what you intend to DO, what you know about that task, some details about yourself, etc. Be detailed and articulate. Brief proposals do not generally do very well. Your ability to perform the task is outright presumed by the nature of submitting a detailed application. Students should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.

You may submit more than one application (one application for each project you would enjoy working on) if you so desire. This can help us when we receive more than one strong proposal for a single project, as generally speaking we will accept only one application for each project. However, please do not submit proposals for work you will not enjoy doing, and please do not sacrifice quality for quantity. One good application makes a much better impression than two half-baked applications.

If you talk with us on IRC about your SoC proposal, be sure to include your IRC nickname somewhere in your proposal.

You should also [http://sourceforge.net/tracker/?group_id=3248&atid=303248 submit a patch] before you submit your application, and be sure to include a link to the tracker item in your proposal submission. See the [[Google Summer of Code Acceptance|development requirements]] for details.

Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, and agree to the [[Google Summer of Code Acceptance|development requirements]] before submitting an application.

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

= The application review process =

Just about every participating GSoC organization receives considerably more project proposals than can be accepted. All the applications are reviewed, evaluated, and critiqued individually. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult (so make sure your application is excellent). ''This cannot be stressed enough.'' It is rather hard for most projects to narrow down the submissions but in the end there are only so many slots to work with and the line eventually has to be drawn. Every application gets read multiple times and reviewed in detail. We thank '''everyone''' that submits a proposal and hope to see many of you become involved in BZFlag software development regardless of acceptance.

In the end, submissions are selected according to the overall long-term impact that accepting the proposal can make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, how well the student communicates with other developers, the perception that the individual is interested in being a long-term BZFlag developer, and our overall interest in having the proposed modifications made to BZFlag. Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel. Communication is one of the most important criteria.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

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

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

[[Category: Development]]

Bz eGetWorldEvent

2008-03-30T02:01:36Z

DTRemenak: /* Map file override */ details on worldFile

{{BZFS_API_Doc}}
{{BZFS_API_Events}}

==Overview==
The '''bz_eGetWorldEvent''' is an API event that is called before the [[BZFS]] server defines the world.

==Data==
'''bz_eGetWorldEvent''' returns the '''bz_GetWorldEventData_V1''' data class.

{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value description
|-
|eventType
|[[Event(API)|bz_eEventType]]
|bz_eGetWorldEvent
|-
|generated
|bool
|The value representing the state of the world generation. If another plug-in has generated a world, this value will be set to true. If the plug-in processing this event, adds world geometry using the '''bz_addWorld''' methods ([[bz_addWorldBox]], [[bz_addWorldPyramid]] etc. ) then it must set this value to true.
|-
|ctf
|bool
|This value represents the game state being a Capture the Flag (CTF) type game. Mutually exclusive with other game type setings.
|-
|rabbit
|bool
|This value represents the game state being a Rabbit Hunt type game. Mutually exclusive with other game type setings.
|-
|openFFA
|bool
|This value represents the game state being a [[Free For All]] type game. Mutually exclusive with other game type setings.
|-
|worldBlob
|char*
|A pointer to a memory location from which to read the world stream. Overrides worldFile.
|-
|worldFile
|[[bz_ApiString]]
|The path to the map file that will be used when this event is completed. If the string is zero length, then either a plug-in defined map or a random map will be used.
|-
|eventTime
|double
|Local Server time of the event.
|}

==Uses==
This event is a modification event. It is the primary hook for plug-ins that wish to modify the world. The available options are;

===Map file override ===
If the plug-in wishes to force the server to use a specific map file, it can set the '''worldFile''' member. This member may be set to any valid local path or an http:// or ftp:// URL.

The plug-in may instead use the worldFile member for information only, and write a valid BZW world into a contiguous memory location, passing that pointer back to BZFS via the worldBlob member. It is the caller's responsibility to free this memory; this may be done in the [[bz_eWorldFinalized]] event.

===Game Style overide===
The plug-in may change the game style flags to override the initial game mode.

===Plug-in defined maps===
If the plug-in sets the '''worldFile''' member to a zero length string, it can then make any number of calls to the world definition functions to define a map file programaticly. These functions include;

* [[bz_addWorldBox]]
* [[bz_addWorldPyramid]]
* [[bz_addWorldBase]]
* [[bz_addWorldTeleporter]]
* [[bz_addWorldWaterLevel]]
* [[bz_addWorldWeapon]]
* [[bz_setWorldSize]]

Bz eGetWorldEvent

2008-03-30T01:59:47Z

DTRemenak: /* Map file overide */ doc worldBlob

{{BZFS_API_Doc}}
{{BZFS_API_Events}}

==Overview==
The '''bz_eGetWorldEvent''' is an API event that is called before the [[BZFS]] server defines the world.

==Data==
'''bz_eGetWorldEvent''' returns the '''bz_GetWorldEventData_V1''' data class.

{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value description
|-
|eventType
|[[Event(API)|bz_eEventType]]
|bz_eGetWorldEvent
|-
|generated
|bool
|The value representing the state of the world generation. If another plug-in has generated a world, this value will be set to true. If the plug-in processing this event, adds world geometry using the '''bz_addWorld''' methods ([[bz_addWorldBox]], [[bz_addWorldPyramid]] etc. ) then it must set this value to true.
|-
|ctf
|bool
|This value represents the game state being a Capture the Flag (CTF) type game. Mutually exclusive with other game type setings.
|-
|rabbit
|bool
|This value represents the game state being a Rabbit Hunt type game. Mutually exclusive with other game type setings.
|-
|openFFA
|bool
|This value represents the game state being a [[Free For All]] type game. Mutually exclusive with other game type setings.
|-
|worldBlob
|char*
|A pointer to a memory location from which to read the world stream. Overrides worldFile.
|-
|worldFile
|[[bz_ApiString]]
|The path to the map file that will be used when this event is completed. If the string is zero length, then either a plug-in defined map or a random map will be used.
|-
|eventTime
|double
|Local Server time of the event.
|}

==Uses==
This event is a modification event. It is the primary hook for plug-ins that wish to modify the world. The available options are;

===Map file override ===
If the plug-in wishes to force the server to use a specific map file, it can set the '''worldFile''' member.

The plug-in may instead use the worldFile member for information only, and write a valid BZW world into a contiguous memory location, passing that pointer back to BZFS via the worldBlob member. It is the caller's responsibility to free this memory; this may be done in the [[bz_eWorldFinalized]] event.

===Game Style overide===
The plug-in may change the game style flags to override the initial game mode.

===Plug-in defined maps===
If the plug-in sets the '''worldFile''' member to a zero length string, it can then make any number of calls to the world definition functions to define a map file programaticly. These functions include;

* [[bz_addWorldBox]]
* [[bz_addWorldPyramid]]
* [[bz_addWorldBase]]
* [[bz_addWorldTeleporter]]
* [[bz_addWorldWaterLevel]]
* [[bz_addWorldWeapon]]
* [[bz_setWorldSize]]

Bz eGetWorldEvent

2008-03-30T01:57:30Z

DTRemenak: /* Data */ doc worldBlob

{{BZFS_API_Doc}}
{{BZFS_API_Events}}

==Overview==
The '''bz_eGetWorldEvent''' is an API event that is called before the [[BZFS]] server defines the world.

==Data==
'''bz_eGetWorldEvent''' returns the '''bz_GetWorldEventData_V1''' data class.

{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value description
|-
|eventType
|[[Event(API)|bz_eEventType]]
|bz_eGetWorldEvent
|-
|generated
|bool
|The value representing the state of the world generation. If another plug-in has generated a world, this value will be set to true. If the plug-in processing this event, adds world geometry using the '''bz_addWorld''' methods ([[bz_addWorldBox]], [[bz_addWorldPyramid]] etc. ) then it must set this value to true.
|-
|ctf
|bool
|This value represents the game state being a Capture the Flag (CTF) type game. Mutually exclusive with other game type setings.
|-
|rabbit
|bool
|This value represents the game state being a Rabbit Hunt type game. Mutually exclusive with other game type setings.
|-
|openFFA
|bool
|This value represents the game state being a [[Free For All]] type game. Mutually exclusive with other game type setings.
|-
|worldBlob
|char*
|A pointer to a memory location from which to read the world stream. Overrides worldFile.
|-
|worldFile
|[[bz_ApiString]]
|The path to the map file that will be used when this event is completed. If the string is zero length, then either a plug-in defined map or a random map will be used.
|-
|eventTime
|double
|Local Server time of the event.
|}

==Uses==
This event is a modification event. It is the primary hook for plug-ins that wish to modify the world. The available options are;

===Map file overide ===
If the plug-in wishes to force the server to use a specific map file, it can set the '''worldFile''' member.

===Game Style overide===
The plug-in may change the game style flags to override the initial game mode.

===Plug-in defined maps===
If the plug-in sets the '''worldFile''' member to a zero length string, it can then make any number of calls to the world definition functions to define a map file programaticly. These functions include;

* [[bz_addWorldBox]]
* [[bz_addWorldPyramid]]
* [[bz_addWorldBase]]
* [[bz_addWorldTeleporter]]
* [[bz_addWorldWaterLevel]]
* [[bz_addWorldWeapon]]
* [[bz_setWorldSize]]

Google Summer of Code: 2008

2008-03-25T20:35:26Z

DTRemenak: /* Mentors */ I'm a bit erroneous too

The 2008 Google Summer of Code was announced on February 25, 2008. BZFlag has been accepted again this year as a mentoring organization. Given our enormously successful participation in the program in 2007, we're very excited to be participating again and look forward to seeing the student submissions. BZFlag will accept student project proposals from March 24 to March 31 ending at 5:00 PDT (0:00 April 1 GMT). Further information on our proposal ideas are below. '''''Candidate students should be sure to read our suggestions for [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]].'''''

= Promotion Flyers =

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

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

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

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

= Proposal Ideas =

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

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

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

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

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

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

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

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

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

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

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

Features could include:

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

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

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

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

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

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

= Thanks & Appreciation =

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

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

[[Category: Development]]

Ideas

2008-03-20T19:47:41Z

DTRemenak: randomly drop in some non-vetted ideas that got put on the SoC ideas page where they didn't belong. needs cleanup.

{{Old}}
NOTE: These are just possibilities. We won't be implementing everything here.<br>

Commentary may include personal comments by developers.

= Editing this page =

Feel free to make changes and updates to this page whenever possible. If you have any questions, feel free to [[Getting Help|ask for help]]. If you wish to make major changes to this page (i.e. remove large amounts of old ideas), please warn us ahead of time.

== Adding ideas ==
* Please remember to make sure your idea isn't already here or on the [[Rejected Ideas]] page.
* Flag ideas should be placed on [[Flag Ideas]], not here.
* Add a row to the appropriate category (at the bottom, please) and fill it in with your idea.
* Sign your idea in the third column with three tildes: <nowiki>~~~</nowiki>
* Put the submission date in the fourth column
* Describe in full and make sense!
* Leave the status column white and fill it with (Unknown).

== Adding commentary ==
* Precede your comment with an asterisk: <nowiki>*</nowiki>
* Sign your comment with four tildes: <nowiki>~~~~</nowiki>
* Be nice, polite, and constructive.
* Contribute something when you comment. Saying whether or not you like an idea is pointless if you don't explain yourself.

== Cleaning up ==
To help keep this page current, old ideas should be removed when they're implemented (after each stable release, hence the "SVN" status). If you spot any ideas that were implemented prior to the latest stable release of BZFlag, please remove it.

== My few ideas ==
So hi I am Vytautas (vytautas1987@yahoo.com)
Some stupid some maybe good I just write them all.

=== Allow custom tank skins ===
It would be fun if players would be able to use custom, original images and colors of their tank. Or maybe clans then would be able to have something like military markings on tanks. As disadvantage it wold create more network loads in online games before game start because everyone will have to download all custom skins. <br>Main thing I want to say that now one color tanks are not very beautiful. And this my suggestion was just idea how to improve this.

=== Tank simulation mode ===
Maybe this is quite different way then now and almost idea for new game. But I suggest to create game modification (MOD) which allows simulation mode not arcade like now. So I talk about:
*realistic tank models maybe from WW2 or maybe from nowadays or even both.
**tank skins, models
**real technical parameters
*realistic gun/damage system
**different caliber guns with different damage.
**armor is not same in from of tank and on sides.
**after engine damage tank can not move and etc.
*much more realistic physics engine.
**Tank can destroy buildings, trees...
**Acceleration
*controls like from real tank (only this kind of realistic control implemented still would give a lot of fun)
**not arrows (two separate accelerators for left and right side of wheals)
**separate turret control

=== More game modes ===
*"Battlefiled 1942"-like mode where teem have to capture all checkpoints on the map
*Destroy/Defend target mode
**Escort/Destroy truck convoy

== IDEA 1 ==
I am of this view point that games can also teach something apart from entertaining us all and being an Environment conscious student,i plan to implement some changes which can teach us all some lessons !.As in its a WAR based game,i.e TANKS... so what i propose is to find the pollutants in the game ..say a Tank which is continuously bombarding must trade off with loosing some points,because it is pouring harmful gases in environment,this is in no way decreasing excitement in game,perhaps will ask gamers to be more strategic,in compromise to that bullets/bombs provided will be increased .. loss of vegetation,polluting water etc must be punished...Global Warming issues can be implemented too .. this is just a rough idea ,if asked proper description will be provided by me.
I am ready to work on existing ideas also,its just the one i proposed..looking forward for a mentor..thanking you..
Rajan Vaish
IRC : vaish
GTALK : vaish.rajan@gmail.com

= The list =
<div align="center">
{| cellpadding="10" cellspacing="1" border="1"
|+align="bottom"|''Legend''
|-
|style="background-color:#FF00FF;"|'' ''
|Implemented as a server-side plug-in
|-
|style="background-color:#0080FF;"|'' ''
|SVN (Implemented and will be in next release)
|-
|style="background-color:#00FFFF;"|'' ''
|In progress (Implementing)
|-
|style="background-color:#00FF00;"|'' ''
|Good Idea
|-
|style="background-color:#808080;"|'' ''
|Idea
|-
|style="background-color:#FFFF00;"|'' ''
|Vague, not understood, or in need of work
|-
|style="background-color:#FF8000"|'' ''
|Rejected, but can be implemented as a server plug-in
|-
|style="background-color:#FF0000;"|'' ''
|Rejected
|-
|style="background-color:#FFFFFF"|'' ''
|Unknown (new)
|}
</div>

== General/Gameplay ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Add support for 5 (or more) button mice
|style="background-color:#00FF00;"|Great Idea
|
|(Unknown)
|(Old)
|-
|Better physics
|style="background-color:#00FFFF;"|In progress
|
*Planning, some changes in CVS.
|Unknown
|(Old)
|-
|SELF-DESTRUCT BLAST RADIUS: Self Destruct (delete key) should have a blast radius similar to Shock Wave, perhaps larger. If you get shot during the self-destruct count down, that should also trigger the same blast. If I gotta go, I want to take someone with me.
|(Unknown)
|
*Do it with shockwaveDeath --[[User:Jftsang|Jftsang]] 18:26, 14 March 2008 (EDT)
|BearRiver
|(Old)
|-
|3-second (or however long) 'invulnerability' for incoming tanks - but they can't shoot
|style="background-color:#808080;"|Idea
|
*I could see this backfiring... your spawn attracts opponents to come, wait, and blast you when you lose invincibility. -L4m3r
|MORPH
|(Old)
|-
|Ability to turn off ricochet for laser flag but allow ricochet for bullets... or let them bounce only n times.. OR implement mirror buildings/walls. Should go for some interesting self-kills when combined with the no-radar/bullet bounce
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Smart LockOn for GM - won't lock on to your teammates (configurable in server)
|style="background-color:#808080;"|Idea
|
*I don't like this idea, there should be at least *some* risks to using this weapon. Personally, I think there should be more (not fewer) risks to holding this weapon; I'd like to see the thing overheat and explode (killing the holder) if it's fired too often in a short period of time. -M. Jetleb

*2.99 has an option to disable friendly fire altogether. Close enough. Lock-on could still be looked into, however. [[User:L4m3r|L4m3r]] 01:38, 5 January 2008 (EST)
|MORPH
|(Old)
|-
|Small jumps
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Server option for genocide flag - if you're killed while you have it, your team dies :^)
|style="background-color:#808080;"|Idea
|
*Feasible with a plug-in, too. -L4m3r
|MORPH
|(Old)
|-
|for broadband or LAN connections - voice chat for teams
|style="background-color:#808080;"|Idea
|
*I really think that you can do this with another service; I'm not sure if being part of BZFlag would be a good idea due to size and bandwidth issues.
|MORPH
|(Old)
|-
|Tank avatars (uploadable tank images) - have to think about shapes, though - someone could make a 1x1x1 pixel tank - that would suck - or a tank that looks like a building or pyramid. Clients don't have to accept downloading of avators (just view other tanks in default mode). Or just s-e-l-e-c-t from a certain number of predefined avatars that could come with the bzflag distribution. Or client provides a URL to download their avatar (saves server bandwidth).
|style="background-color:#808080;"|Idea
|*Might not be implemented. Requires discussion; we may want to consider making the computer force a minimum size or something similar.
*How about uploadable flag graphics?
|MORPH
|(Old)
|-
|'Kamikaze' option for players - can take someone out by suicide
|style="background-color:#808080;"|Idea
|
*Server option if implemented.
*Implemented with a plugin by Theme97
|MORPH
|(Old)
|-
|Server option: everyone is radar-stealthed by default unless you get a 'radar' flag. You can still see all buildings, pyramids, teleports, and arena walls, though.
|style="background-color:#00FF00;"|Good idea
|
*Make them use their window. ;)
*Given the fairly narrow field of view out the window and the time it takes to turn a tank all the way around for a look-see, I think this could be frustrating. How about everyone starts out with minimum range radar instead and gets longer ranges with an appropriate flag? -M. Jetleb
*Ideally this could be implemented in the same manner as jumping and ricochet- radar could be enabled by default, or available as a flag. [[User:L4m3r|L4m3r]] 01:38, 5 January 2008 (EST)
|MORPH
|(Old)
|-
|Option for above: if you pick up GM or Laser, you're visible on radar to everyone whether they've got a radar flag or not
|style="background-color:#00FF00;"|Good idea
|
|MORPH
|(Old)
|-
|Selectable 'ricochet' fire - hold down shift key or something and your bullets won't ricochet
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Server option - tanks only have a certain number of times they can jump (gets reset when you get killed)
|style="background-color:#808080;"|Idea
|
*Could be made possible with a plug-in in 2.99. [[User:L4m3r|L4m3r]] 01:38, 5 January 2008 (EST)
|MORPH
|(Old)
|-
|Multiple-shields (server option for shield flags, or can be random - can get hit x number of times)
|style="background-color:#808080;"|Idea
|*This is pretty much moot now. It's been shot down by the devs at least once, and a similar effect can be achieved by setting _shieldFlight to a very small number. This effectively provides as many hits as _maxFlagGrabs. [[User:L4m3r|L4m3r]]
|MORPH
|(Old)
|-
|Configurable 'radarless' and/or 'blind' zones in the arena - can't see what's in there on radar or via visuals
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Tank collisions - why can tanks drive through each other? Weird.
|style="background-color:#00FF00;"|Good Idea
|*Lag could be a big problem here. If implemented, it must be impossible for two tanks to get stuck to each other. [[User:L4m3r|L4m3r]]
|MORPH
|(Old)
|-
|When tanks collide - great opportunity to implement tank damage concept, especially if one of them is moving especially fast, or has momentum flag, etc. Can push a tank off a building if your pushing them from their side.
|style="background-color:#808080;"|Idea
|
*Tank damage won't happen, but the kinetics could be neat, especially for mid-air collisions. It would certainly make "jump dancing" more interesting. [[User:L4m3r|L4m3r]]
|Morph
|(Old)
|-
|If a tank explodes right next to another tank, the other tank can be destroyed or get damaged
|style="background-color:#808080;"|Idea
|
*Somewhat implemented with the [[ShockwaveDeath]] plug-in. It would probably not be too hard to implement something similar (with a plugin) without shockwaves. [[User:L4m3r|L4m3r]]
|MORPH
|(Old)
|-
|Skins or views- In-tank mode, bumper mode, out-of-cab mode, chase mode.
|(Unknown)
|
|MORPH
|(Old)
|-
|Weapon extension packs.
|style="background-color:#FFFF00;"|(Unknown)
|*Huh? Explain, please. [[User:L4m3r|L4m3r]]
|iPod
|(Old)
|-
|The ability to choose tanks, but they all die at one shot. maybe the jump height, speed, turn speed, acceleration, size can be preset.
|(Unknown)
|
*Could be done with a plug-in in 2.99, maybe. [[User:L4m3r|L4m3r]] 01:38, 5 January 2008 (EST)
|iPod
|(Old)
|-
|Option to choose different kinds of tanks. Different tanks could be weighted with different strengths and weaknesses. (almost like having a default flag). Would also need some form of health/damage status measurement, not just single hits. For example, there could be a larger, heavily armored tank that has powerful weapons, but moves slowly, versus a small, light, fast tank which is difficult to hit, but very low armor to protect from hits.
|(Unknown)
|
|Cue
|(Old)
|-
|What about a radar that only covers visible areas (don't passing through buildings/pyramids) ? This would leads to more placement tactics).
|(Unknown)
|
|K<nowiki>'</nowiki>limero
|(Old)
|-
|Always random respawn. Currently in CTF games first respawn is at own base. This can be abused by leaving and rejoining to get near base. This leave/rejoing trick is considered to be a mild form of cheating by many. Always random respawn would make it useless.
|(Unknown)
|
* I believe there is a plug-in for this. [[User:L4m3r|L4m3r]] 22:38, 30 April 2007 (EDT)
|abli
|(Old)
|-
|multiple (3?) jump stengths mini, normal, max...just the thing to confuse the opponents that expect one and you're off doing the other.
|(Unknown)
|
|kitchen
|(Old)
|-
|Anti camping. The ability to add "no camping zones" to areas of a map or to the entire map. Campers would be messaged that they're in a no camping zone, better start moving and have a prescribe number of seconds to move away or die. If a player returns to the same NCZ (no camping zone) and receives x warnings then he's disconnected. NCZs could be marked by a different color shade from a "normal" spot and could be exempt to a single team (like at their flag base). It's just a rough idea.
|(Unknown)
|
*Definitely more suited to a plug-in (and probably doable, too).
|pherris
|(Old)
|-
|Shield Flag Changes: Give Shield flag a radius, and draw it like a moving less opaque blue shockwave. Any tanks inside the shield radius would be protected, until the shield got hit a certain number of times.
|(Unknown)
|
|YHARG
|(Old)
|-
|At our company, we instituted a voluntary policy of dropping flags after 1 kill. Prevents slaughters and keeps things rolling more. It'd be great to be able to have the game do this for us, plus I'd love to see it turned on at external sites.
|(Unknown)
|
|TomMatelich
|(Old)
|-
|Server option: default powers -- flag(s) that everyone in the game automatically has (this wouldn't count as holding a flag). For example, the current Jumping option would == including Jumping as a default power.
|(Unknown)
|
|NebNamwen
|(Old)
|-
|Shot Aiming. Basically the center shot aim box could be moved left and right as far as the edge of the view window. (This would be enabled by default.) If the map is a vertical one a server option could be enabled so that vertical aiming could be enabled (using the same concept as horizontal aiming.) The aiming would be automatically centered by a button or key. These options could be mapped to a second joystick access, mouse scroll wheel or keyboard buttons.
|(Unknown)
|Lateral shooting would basically be the same as a rotating turret, and this idea has been shot down many times. Vertical shooting has been poo-pooed also. [[User:L4m3r|L4m3r]] 01:45, 3 July 2007 (EDT)
|NN
|6/20/07
|-
|Make a tele porter along the game sides that would tele port into other games running on their own servers. This would enable larger more collaborative game board linked together that would distribute loads across multiple servers speeding up game play and making for interesting possibilities.
|(Unknown)
|
|Waban*
|7/31/07
|-
|Make a 'fog of war' where the a player's radar only shows a certain distance of the area around them and their teammates'.
|(Unknown)
|
*This could be done if radar and position data were separated, allowing the server to "filter" radar data for each player.
|Forrest
|8/19/07
|-
|Speed of light becomes a server variable. Tanks travelling near the speed of light have an increased mass and appear distorted from a stationary observer. Lasers travel at speed of light, not at infinite speed. If a tank is travelling near the speed of light, the colour of the tank is redshifted or blueshifted.
|(Unknown)
|
|jftsang
|14/03/08
|}
</div>

== UI ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Make option to show previous players list
|style="background-color:#808080;"|Idea
|
|(Unknown)
|(Old)
|-
|Make ALL server options available from the menus
|style="background-color:#808080;"|Idea
|
*There are a LOT of server options, and this could add quite a bit of clutter. If you need more than a basic game, you should probably learn to start BZFS from the command line anyway. -L4m3r
|MORPH
|(Old)
|-
|Separate windows for player messages & server messages
|style="background-color:#00FF00;"|Good idea.
|
|MORPH
|(Old)
|-
|Message log
|style="background-color:#00FF00;"|Good idea.
|
|MORPH
|(Old)
|-
|Send message to everyone 'but' specified player (crosses team boundaries, or not)
|style="background-color:#808080;"|Idea
|
*Hmm. Everybody BUT a specified player? [M. Jetleb -> as in: "Let's all get the GM guy" without the GM guy knowing he's facing a co-ordinated attack - I like this idea)
|MORPH
|(Old)
|-
|The ability to see what the world is like before connecting to the server.
|(Unknown)
|
|iPod
|(Old)
|-
|Multi-monitor support (i.e., radar on one screen, window on another, chat/event log on a third)
|(Unknown)
|
|bhtooefr
|(Old)
|-
|Make a part in bzflag to put up a real server. 1st screen has the flags you want, next page is to find the MAP file that you created on your hard drive, next page pick if you want jumping etc.
|(Unknown)
|
|Colin
|(Old)
|-
|-
|Add a rear view mirror
|(Unknown)
|
|Sparky1
|1/1/2008
|-
|}
</div>

== Technical ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Better network handling
|style="background-color:#00FFFF;"|In progress
|
|(Unknown)
|(Old)
|-
|Better robot AI
|style="background-color:#808080;"|Idea
|
*Don't know if players would like it or not in multiplayer game. Pluggable or scriptable robot AI , maybe? - Code must be restructured first
*Server side bots are coming! [[User:TD-Linux|TD-Linux]] 17:41, 12 March 2007 (EDT)
|(Unknown)
|(Old)
|-
|Better positioning of tanks
|style="background-color:#808080;"|Idea
|
*BZFlag already does this, but the algorithm is bad. Needs work.
|MORPH
|(Old)
|-
|Serious multithreaded design - shouldn't lock up interface while looking for servers, or doing anything else. This program is way-unstable on Windows
|style="background-color:#00FFFF;"|In Progress
|
*We're working on these problems; many complaints are due to people still using old servers/clients.
|MORPH
|(Old)
|-
|Some type of BZFlag GUID* to ban players who cheat - won't accept players who disable their GUID, etc.

<nowiki>*</nowiki>Global Unique Identifier, sort of like an IP addrss, but permanent. Usually a number. Problem occurs when you lose your GUID (have to reformat your HD, etc. How do you keep someone from hacking their GUID, or setting up a modified BZFlag server for identity theft, etc.
|(Unknown)
|
*I doubt this is even possible, let alone practical. What about people who play from more than one location? And, because this is an open-source game, it would probably be cracked in minutes. Any verification can be spoofed, or at least altered. there is no foolproof way to permanently ban someone. -L4m3r
|MORPH
|(Old)
|-
|To prevent cheating - the server determines what flags & abilities each tank has (possible?)
|style="background-color:#00FFFF;"|In Progress
|
*Seriously being considered. This would also have the advantage of allowing different versions of clients and servers to work together. Yes, it's possible, but this type of change will mean a change in the network protocols.
*Being worked on for 3.0
|MORPH
|(Old)
|-
|BZFlag for mac in separate data and application files.
|(Unknown)
|
|iPod
|(Old)
|-
|J2ME client (allows one to play on a cell phone), would use radar
|(Unknown)
|
|bhtooefr
|(Old)
|-
|Special 'open source' BZFlag version (server and client) which is guaranteed to be compatible with all other BZFlag versions.
|(Unknown)
|
*BZFlag is already open-source, and making a universally-compatible client is not even remotely practical. Incompatibility is part of why the game breaks off new versions in the first place. [[User:L4m3r|L4m3r]]
|Orca
|(Old)
|-
|}
</div>

== Game Modes, Team Play, and Scoring ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Tounament mode
|style="background-color:#808080;"|Idea
|
*Great Idea?
|(Unknown)
|(Old)
|-
|When you shoot someone on your own team, instead of both of you blowing up, neither is destroyed, and their score goes up one, while your's goes down one. This would make teamkilling impossible and greatly discourage traitors as well.
|style="background-color:#808080;"|Idea
|
*But then couldn't cheaters spawn two clients and ramp up their scores by teamkilling their other login? --YHARG
|Trigger Happy Nerd
|(Old)
|-
|A new gameplay mode- Takes two to tank. One to control the (rotating) turret, the other drives. KIA switches positions. "Teamplay" but all in one tank.
|(Unknown)
|
*I see serious lag issues with this... How does Halo do it? ;) -L4m3r
*The main problem with this idea is coordination. If one person were to leave, the tank would be crippled. You COULD solve this by having the person switch to normal mode, but this could cause considerable jerking between modes on a busy server. [[User:F687s|F687s]] 22:13, 20 June 2007 (EDT)
|MORPH
|(Old)
|-
|Turret mode, If enabled by the server (Can be manditory with automatic grouping). One user drives and the other shoots, Turret mode tanks get double points (But onyl take one from the target). lost double points if killed. Have double ammo, And controllable speed (Max = _tankSpeed * 2 Min = _tankSpeed). Plus it takes 2 shots to kill a turret mode tank. Points gained and lost by turret tanks are divided evenly between the users, Unless the server is all turret mode, in h which case two users are displayed as one.
|(Unknown)
|
|Dogbert
|(Old)
|-
|Ability for a team to vote to 'banish' someone from their team
|style="background-color:#808080;"|Idea
|
*Possibly unfair to newer players. [[User:L4m3r|L4m3r]]
*Useful for getting rid of TKers and selfcappers. However you would need a way (e.g. a voting system) and you would need to be able to say to which team he or she should go if rogues are unavailable. Possible, if rogues are allowed, but not otherwise not really a good idea. --[[User:88.108.209.168|88.108.209.168]] 13:13, 24 December 2007 (EST)
|MORPH
|(Old)
|-
|There should be a game of cops and robbers. The teams can change after about 10 mins or so.
|style="background-color:#FFFF00;"|(Unknown)
|
|iPod
|(Old)
|-
|A special FFA Game mode "Team by Flags". This means, same Flag = same Team, so if there is a Tank with Rapid fire, and you pick up Rapid fire, you are automatically handled as Team member (this means, killing the other Tank with Rapid fire will be handled the same way as when killing a team member). YHARG: Funky idea: what about a game mode where teams shared flag abilities? Like, each player on a team's flag applies to the whole team. This could make for some interesting combos...
|(Unknown)
|
|Agonizer
|(Old)
|-
|Make life trickier for the Rogue Team; with a mix of Rogues and Colored Teams, the Rogues have more targets. This should also change the effect of the Masquerade flag - perhaps your tank is invisible to Rogues (like Cloaking)?
|(Unknown)
|
|NickGrim
|(Old)
|-
|A server option to make deaths not affect your score unless they were self-inflicted/team (the method used by many online games). This would encourage more aggressive play, because it's worth going out and blasting. As it is, you've got a very good chance by just phantoming/OOing out of the way and keeping you score at zero to stay in the top three places! It would also help fix the rather unfair situation of spawning just below a building on which someone is GM-camping...there's pretty much no way to escape, so you lose a point.
|(Unknown)
|
|LionsPhil
|(Old)
|-
|Don't show individual score in CTF games. This might help teamplay as it reduces the incentive to run around as if it would be FFA.
|(Unknown)
|
|abli
|(Old)
|-
|Give points to the player how captures flag in CTF. (Say, around 4 or so) After all, it is often a bigger job than killing someone.
|(Unknown)
|
*Maybe the score could be based the number of tanks in the other team, similar to shooting someone w/ geno. This can also discourage people from capturing thier own flag by scoreing the negative number of teamates. I'm not sure if the individual scores of the players of the captured team (other than the one who captures the flag) should be affected however. [[User:Sparky1|Sparky1]] 09:44, 21 May 2007 (EDT)
*Scores can be customized with plug-ins in 3.0. Unfortunately, there's a bug in 2.0.x that prevents the server from setting scores properly. [[User:L4m3r|L4m3r]] 01:46, 5 January 2008 (EST)
|abli
|(Old)
|-
|Ducati/Freestyle "Roles" mode: Make a game mode where players are presented with a list of flag choices (limitable to a few roles, if wanted) at respawn or connect time, and are forced to use this flag for the remainder of their connection/tank life. This would be really useful in the case of stealth vs. seer, where you could choose to be stealth or seer, but couldn't switch between them. Another idea would be high speed vs. quick turn. Or steamroller vs. machine gun... Team play would have the interesting effect of people banding together and people with each role on the team. Especially in stealth vs. seer, where a seer team member could warn the team about enemies! There would be no team flags/bases.
|(Unknown)
|
*Too specialized, use a plug-in (yes, it's possible). [[User:L4m3r|L4m3r]] 01:46, 5 January 2008 (EST)
|YHARG
|(Old)
|-
|New game called tag were someone is it and they shoot someone else and there it and ect.
|(Unknown)
|
|Supermatthew
|(Old)
|-
|Also a new game called "Hide and seek" were everyone is clocked(think thats it, were you don't see them on radar) except one who is it. he needs to find someone and shoot them then hese cloked and who was shot is not. Also when someone is shot there sent back to Ground zero( 0X, 0Y, 0Z ) so they can't shoot who ever just shot them.
|(Unknown)
|
|Supermatthew
|(Old)
|-
|"Cat" game: when a player dies, he/she respawns automaticaly, after 3 secs or so. When they have respawned 9 times, they can no longer spawn, and are observers. The one who lasts the longest wins. Games are timed.
|(Unknown)
|
*Why should the games be timed? I would think that the game should end when there is no more than 1 tank left.--[[User:Sparky1|Sparky1]] 21:55, 17 February 2008 (EST)
*I smell cheating; if players keep rejoining, they have infinite lives --[[User:Jftsang|Jftsang]] 14:22, 15 March 2008 (EDT)
|(Unknown)
|4/20/2007
|-
|A switch-teams function that allows you to swap teams during a game without losing score.
|(Unknown)
|
|jftsang
|10/11/2007
|-
|Rogue team - A mode in which rogues may TK and capture flag.
|(unknown)
|
*Why? [[User:L4m3r|L4m3r]] 01:46, 5 January 2008 (EST)
|jftsang
|10/11/2007
|-
|A Sport Mode: I noticed that there is a lot of recently created cool sport maps. In those maps a team flag is used as a "ball", and bases are used as "goals". I think that there is even more potential for great maps if there would be a game mode where a bullet behaves like a "ball".In that mode when a game starts, or right after a score, a bullet hovers over a specified location (like the center of the map) and no one can shoot. The first tank that touches the bullet "has the ball", in other words only that tank can shoot. If a tank that "has the ball" shoots it, shooting for that tank is disabled, likewise, if a tank is shot by a bullet that tank does not die, but instead it "has the ball", this allows for passing and interception. A tank that "has the ball" should be indcated somehow, perhaps by a unique flag. The "ball" has the color of the last tank that shot it. A new object would have to be created (perhaps called a goal zone?) that resembles a teleporter that results in a ctf if a bullet encounters it. Or instead of a specific object an area/volume on the map could be designated as a "goal zone" which would give more freedom in designing objects that behave like goals. The score would go to the team that has the same color as the bullet that encountered the "goal zone". All tanks would have the Steam Roller power. a tank that touches another tank would not be killed only if that tank is higher at the touch. If a tank that "has the ball" is killed before he can shoot the "ball" then the bullet appears at the tanks position of death and travel at the speed and in the direction the tank had at that point. Maybe a provision could be made where the number of "balls" could be set at a number greater than one to allow for more complex games.
|(Unknown)
|
|[[User:Sparky1|Sparky1]]
|1/21/2008
|-
|}
</div>

== Maps, Mapping, and BZW ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Materials that don't allow OO and PZ to go through
|style="background-color:#808080;"|Idea
|
*Would be nice for multilevel worlds made with the new ability to have objects above the ground.
*Sounds awesome! TD-Linux 17:41, 12 March 2007 (EDT)
*As a special case, there could be Zoned objects (objects that only respond to PZ and maybe OO; normal tanks behave like PZ through these objects). [[User:Sparky1|Sparky1]] 18:05, 21 May 2007 (EDT)
*Would also be nice if there were non-ricochet materials, or only ricochet some shot type materials. --[[User:88.108.209.168|88.108.209.168]] 13:09, 24 December 2007 (EST)
|(Unknown)
|(Old)
|-
|Differently-shaped teleporters (circles, triangles, etc.)
|style="background-color:#808080;"|Idea
|
*probably low priority
|MORPH
|(Old)
|-
|360 degree teleports - hit a spot on the ground or in the air from any direction and you teleport
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Configurable random teleporters - teleports to a different location every time
|style="background-color:#808080;"|Idea
|
*Idea is a bit vague... randomized teles are implemented if you use multiple links. Is this what is meant by this suggestion? -L4m3r
|MORPH
|(Old)
|-
|Triggers in levels
|style="background-color:#FFFF00;"|(Unknown)
|
*Triggers for what? unless you're talking about AI, this could most likely be handled with a server plug-in. [[User:L4m3r|L4m3r]]
|Dragonstar
|(Old)
|-
|wraparound world - radar remains centered on your current position. Internally, objects leaving the north border reappear to the south, but from the user's radar / visible perspective, you just see to the horizon. I believe this is how the original Battlezone worked. There are some implications: laser would need a range limit.
|(Unknown)
|
|nsayer
|(Old)
|-
|As a generalization to the wraparound world concept, how about the option of making a map based on geometry that’s non-Euclidean, for example spherical or hyperbolic. Jumping/flying, the shape of the tanks/objects, and bullet trajectories would also be affected by this global geometry. It would be like a world that has a high gravitational field, or a world situated near a wormhole.
|(Unknown)
|
|[[User:Sparky1|Sparky1]]
|5/21/2007
|-
|-
|Get rid of the PZ flag and replace it w/ special telporters that do the same thing (they could be called "zoners", and should probably look different from regular teleporters). This way superflags, badflags, and team flags can all be zoned (without needing an exception to the restricition against using more than one flag at a time). The above idea of other zoned objects would play a major role here. Zoned flags can only be picked up by zoned tanks. Flags can spawn zoned, or become zoned by being carried by an unzoned tank that becomes zoned by going through a zoner. Likewise, a zonedflag becomes unzoned when a zoned tank carries it through a zoner. Unzoned tanks respond to shots from zoned flags the same way zoned tanks respond to shots from unzoned flags. For example: when zoned, L, WG, geno, and GM do not kill unzoned tanks (zoned GM will still lock onto any tank, and zoned geno would still kill every tank on the same team as the zoned tank that was shot). Although, flags like SW and SB would still kill any tank regardless of thier zoning status. As an extension to this idea one team in a CTF game could start out zoned, i.e. thier base is zoned and they initially spawn zoned. In order for the unzoned team to capture the zoned team's flag, the flag must become unzoned, and vice versa for the zoned team. This way new possibilities exist, like two bases could be superimposed as long as one base is zoned and the other is not. Another possible extension is different kinds of zones (w/ corespondingly different kinds of zoners) for CTF involving more than two teams. The relationship between differently zoned tanks would be the same as the relationship between zoned and unzoned tanks.
|(Unknown)
|
|[[User:Sparky1|Sparky1]]
|5/21/2007
|-
|Change the workings of zones such that a zone may have its own server variables (I wanted to make a Death Castle against a Holy Castle).
|(Unknown)
|
|jftsang
|1/12/2007
|}
</div>

== Server Options, Administration, Plug-ins, and the Plug-in API ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Ability to configure server to turn somethings off or on depending on number of players - for instance, turn off ricochet after a certain number of players are connected, turn off GM & laser if a certain number of players aren't playing (GM & Laser with 2 players is kinda ridiculous)
|style="background-color:#808080;"|Idea
|
|MORPH
|(Old)
|-
|Allow custom-made weapons with a Object-Oriented scripting language (sorta like Liero AI uses: http://helios.et.put.poznan.pl/~sskowron/liero/index.html )
|(Unknown)
|
|Dragonstar
|(Old)
|-
|Preset world weapons that can be fired manually by admins from within BzFlag.
|(Unknown)
|
* Could be done by a plugin [[User:Tanner|Tanner]] 13:42, 12 August 2007 (EDT)
|Dogbert
|(Old)
|-
|}
</div>

== Graphics & Sound ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Sounds of tanks moving.
|(Unknown)
|
|iPod
|(Old)
|-
|Have different tank death scenes for the dying tank point of view. I realize there is some time needed for one to die and respawn, but the jumping effect one sees when killed irritates me to no end! I'd be happier if all faded to black or white or orange and had text across the screen saying ""respawning... please wait"" :) Also, when killed and your tank was moving toward a building, it just falls right thru it until it hits the ground.. wrong physics there! Splatter or tumble or shatter or something :)
|(Unknown)
|
|Robi
|(Old)
|-
|Custom color schemes for rogue players. The turret and body components can be chosen to be one of a predefined set of colors (e.g. red, yellow, black, white, blue, green, purple...). The game prohibits choosing a color scheme that matches a team scheme (e.g. red turret with red body) and the limited set stops someone choosing a shade which is nearly a team color (e.g. 0xFE0000 instead of 0xFF0000) (and also save texture memory, I think).
|(Unknown)
| * Clients are able to define their own colors, and removing the ability to would cause accessibility issues (Colorblind users). --[[User:AAA|AAA]] 13:30, 7 August 2007 (EDT)
|LionsPhil
|(Old)
|-
|Allow a small decal on the back of the top of the tank. (think Half-Life's customizable spraypaint). Possibly also apply it to any held flag?
|(Unknown)
|
|LionsPhil
|(Old)
|-
|I'd like to see something more interesting done with the sky... maybe there could be a little ufo (easter egg) that would fly around occasionally? Tux on a ufo! ;)
|(Unknown)
| This is up to servers. --[[User:AAA|AAA]] 13:30, 7 August 2007 (EDT)
|YHARG
|(Old)
|-
|Flag decals: Each flag would have a little icon/decal showing it's type ONLY when held by a player. It's kind of nice to be able to surprise people with an undercover shockwave, but doesn't make sense to have to right click (identify) or check the user list to see what flag someone has.
|(Unknown)
|
|YHARG
|(Old)
|-
|Background music! : (This can be done with an external media player so it shouldn't be the heighest priority, It would be nice to be able to control your music from within BzFlag)
|(Unknown)
|More usefully, you could just map key combinations to commands, rather than wasting time supporting all the various music players on every OS BZFlag supports. I don't know whether that would work so well on Windows, though. --[[User:77.97.207.100|77.97.207.100]] 10:14, 30 May 2007 (EDT)
|YHARG
|(Old)
|-
|}
</div>

== List Server and Other Global Services ==
<div align="center">
{| cellpadding="2" cellspacing="1" border="1" width="100%"
|- style="background-color:#ffff88;"
!width="40%"|Idea
!width="7%"|Status
!width="40%"|Commentary
!width="7%"|Submitter
!width="6%"|Date
|-
|Multiple list servers, in case bzflag.org goes down (as it happened around feb. 15. 2004)
|style="background-color:#00FFFF;"|In progress
| * Of course someone would need to pay for it. --[[User:BinarySpike|BinarySpike]] 18:10, 10 May 2007 (EDT)
* We now have two servers, and some form of redundancy for the list should follow eventually. [[User:L4m3r|L4m3r]] 15:40, 31 January 2008 (EST)
|abli
|(Old)
|-
|}
</div>

[[Category:Development]]

Google Summer of Code: 2008

2008-03-20T19:46:16Z

DTRemenak: non-vetted ideas go to the ideas page

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

= Promotion Flyers =

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

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

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

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

= Preparing an Application =

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

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

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

= Program Evaluation =

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

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

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

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

= Proposal Ideas =

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

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

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

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

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

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

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

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

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

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

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

Features could include:

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

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

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

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

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

= Thanks & Appreciation =

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

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

[[Category: Development]]

Main Page

2008-03-18T07:19:02Z

DTRemenak: SoC 2008 announcement as per 2007

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

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

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

==Google Summer of Code 2008==
BZFlag is again participating as a mentor organization in the Google Summer of Code this year. If you are a full-time student and 18+ years old, and your application is accepted, Google will pay you to write code for BZFlag. Prospective students are encouraged to submit project proposals that are in line with our [[Google_Summer_of_Code/2008|'''goals''']] for this summer, though proposals for other [[Ideas]] will be considered.

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

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

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

Google Summer of Code: 2008

2008-03-18T07:15:50Z

DTRemenak: accepted for gsoc2008

Google Summer of Code

2008-03-18T07:13:47Z

DTRemenak: accepted for gsoc2008

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

= BZFlag participation =

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

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

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

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

= [[Google_Summer_of_Code/Application_Guidelines|Preparing an application]] =

There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what they intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) are intended to be used. C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our '''[[Google_Summer_of_Code/Application_Guidelines|Application Guidelines]]''' for more details.

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

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

= The application process =

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

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

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

= Integrated development =

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

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

[[Category: Development]]

Google Summer of Code: Application Guidelines

2008-03-10T17:31:21Z

DTRemenak:

There is intentionally no specific format that students need to use to apply to BZFlag. There are, however, several things that you should and should not do when applying.

= Do's =

'''Be Detailed and Articulate.''' Go into detail about what you intend to do and how you intend to do it. Don't have typos and be clear in your writing. Cite academic references if they're relevant to your work. Create diagrams, show prototypes, create mock-up visuals, and provide more information via external links. You don't have to solve everything, but we need to see that you've thought things through. Impress us.

'''Get Involved Early.''' You need to join our IRC channel, play the game, and get involved in our community. Talk to the other developers, find a mentor that likes your proposal idea. Don't forget to mention your IRC nick in your application. We interact with a lot of people so give us a personality that we can recognize when it comes to reviewing the applications. Communicate early, communicate often.

'''Be Bold.''' We love new innovative ideas. You should make sure your idea fits into the scope of our project and is something we're interested in mentoring, but new projects are welcome. If your proposal is for one of our ideas, be innovative and ambitious in your solution.

'''Be Realistic.''' Make sure the scope of your work is feasible and that you will have the necessary skills to implement your project on time. Don't be so bold that you are unrealistic, keep your abilities and time constraints in mind. If you've got another part-time or full-time job, you probably won't be able to put in the effort or time necessary.

'''Be Passionate.''' Show enthusiasm for your idea. Be excited to work with us. Excitement and passion are never a substitute for competence, but they vastly help your chances all other factors being equal. Express your passion and any background information about yourself that reinforces your interests.

= Don'ts =

'''Don't copy/paste our ideas.''' If all you have to say about the idea is what we've said, it will be rejected. They are just meant to be starting points.

'''Don't be brief.''' Anticipate questions, include details. If your application isn't any more than a few hundred words or less, then you're probably not including useful/necessary detail about the project, your plans, or yourself. Brief proposals very quickly get cut, especially when compared to proposals in similar areas that do include detail.

'''Don't forget to tell us about yourself.''' Most of what we know about you and your abilities is going to come from your application. Include details about your background, experience, and anything else relevant to your work. If you have obligations that will impact your proposal, be upfront. You should be interacting with our community on IRC long before you submit your proposal so we have an idea how you interact.

'''Don't be intimidated.''' Your ideas will be questioned and critiqued. We don't all agree, even amongst ourselves often. You will need to be able to openly and publicly talk about your ideas without being defensive. Be open to the ideas and suggestions of others and be willing to amicably engage in discussions.

'''Don't be discouraged.''' During the application process, we receive a lot of applications. Be patient. If we don't respond to your application for more information, it usually means that it's either really bad or really good. Understand that we have a lot to sort through and discuss. It's a very competitive process given we can only accept a limited number of students. If you have specific questions, engage the mentors over IRC.

Talk:Google Summer of Code: 2008

2008-03-07T00:41:01Z

DTRemenak:

This is informational only. There are no wrong answers. This is more just to get a visual on what we're all thinking. Rank what you feel the top five projects ideas from most important to least with a 1, 2, 3, 4, and 5 respectively. Your ranking criteria for determining importance are:

1) projects that are ''needed'' for BZFlag's long-term development
2) projects that are ''wanted'' due to features or capabilities they provide
3) projects that will make the most ''impact'' on our users
4) those that are likely to be ''successfully'' worked on over three months by a student remembering that the scope can be defined/reduced as needed
5) ideas that are of specific interest to you as a dev that warrant involving others in your evil aspirations

'''Only mark your top five'''.

{|- border="1"
! PROJECT
! dtr
! jeff
! jb
! spldart
! blast
! sean
|-
! DR and networking
|
| 2
|
|
|
|
|-
! game logic modularization
|
| 5
|
|
| 4
| 2
|-
! bzauthd
| 2
|
|
|
| 1
| 1
|-
! bzwb continuation
| 3
| 4
|
|
| 3
| 3
|-
! server menu
|
| 3
|
|
|
|
|-
! multiple display support
| 4
|
|
|
|
|
|-
! profiles
|
|
|
|
|
|
|-
! bzfs web interface
| 5
|
|
|
|
|
|-
! network testing framework
|
|
|
|
|
| 5
|-
! global chat
|
|
|
|
| 5
|
|-
! cheat preventions
| 1
| 1
|
|
| 2
| 4
|}

Google Summer of Code: 2008

2008-03-04T02:23:31Z

DTRemenak:

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

= Promotion Flyers =

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

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

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

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

= Preparing an Application =

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

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

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

= Program Evaluation =

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

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

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

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

= Proposal Ideas =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Thanks & Appreciation =

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

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

[[Category: Development]]

Talk:BZFlag Forums

2007-09-26T19:28:09Z

DTRemenak: Reverted edits by 195.55.130.44 (Talk); changed back to last version by Brad

what is the point of this? did you not notice the link to the forums in the menu on the left?
----

Functions (API)

2007-09-25T22:50:01Z

DTRemenak: /* Player Information */ fix links

{{DoDoc|Fill in articles for all API Functions}}

{{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 );

===Player Information===

BZF_API bool [[bz_getPlayerIndexList]] ( [[bz_APIIntList]] *playerList );
BZF_API [[bz_APIIntList]] *[[bz_getPlayerIndexList]] ( void );
BZF_API [[bz_BasePlayerRecord]] *[[bz_getPlayerByIndex]] ( int index );
BZF_API bool [[bz_updatePlayerData]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API bool [[bz_hasPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_grantPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_revokePerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_getAdmin]] ( int playerID );
BZF_API bool [[bz_freePlayerRecord]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API const char* [[bz_getPlayerFlag]] ( int playerID );
BZF_API bool [[bz_getPlayerCurrentState]] ( int playerID, [[bz_PlayerUpdateState]] &state );
BZF_API bool [[bz_isPlayerPaused]] ( int playerID );
BZF_API bool [[bz_setPlayerOperator]] ( int playerId );
BZF_API [[bz_APIIntList]]* [[bz_getPlayerIndexList]] ( void );
BZF_API bool [[bz_canPlayerSpawn]]( int playerID );
BZF_API bool [[bz_setPlayerSpawnable]]( int playerID, bool spawn );
BZF_API bool [[bz_setPlayerLimboText]]( int playerID, const char* text );
BZF_API int [[bz_getPlayerCount]] ( void );
BZF_API bool [[bz_anyPlayers]] ( void );

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

=== 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_sentFetchResMessage]] ( int playerID, const char* URL );

=== 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]] ();

=== 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_localTime]] *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_getBZDBItemPesistent]]( 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]] ( int playerIndex, const char* ip, int durration, const char* reason );
BZF_API bool [[bz_IPUnbanUser]] ( const char* ip );
BZF_API [[bz_APIStringList]]* bz_getReports( void );
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 );

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

===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 [[_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 int [[bz_getWorldObjectCount]]( void );
BZF_API [[bz_APIWorldObjectList]]* [[bz_getWorldObjectList]]( void );
BZF_API void [[bz_releaseWorldObjectList]]( [[bz_APIWorldObjectList]]* list );

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

====Map Definition====
BZF_API bool [[bz_addWorldBox]] ( float *pos, float rot, float* scale, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldPyramid]] ( float *pos, float rot, float* scale, bool fliped, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldBase]]( float *pos, float rot, float* scale, bz_eTeamType team, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldTeleporter]] ( float *pos, float rot, float* scale, float border, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldWaterLevel]]( float level, [[bz_MaterialInfo]] *material );
BZF_API bool [[bz_addWorldWeapon]]( const char* flagType, float *pos, float rot, float tilt, float initDelay, [[bz_APIFloatList]] &delays );
BZF_API bool [[bz_setWorldSize]]( float size, float wallHeight = -1.0 );

===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 [[bz_eTeamType]] [[bz_checkBaseAtPoint]] ( float pos[3] );

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

Bz RegisterCustomFlag

2007-09-25T22:46:05Z

DTRemenak: doc registercustomflag

{{BZFS_API_Doc}}
{{BZFS_API_Funcs}}
==Prototype==
BZF_API bool bz_RegisterCustomFlag ( const char* abbr, const char* name, const char* helpString, bz_eShotType shotType, bz_eFlagQuality quality );

==Parameters==
{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value description
|-
|abbr
|const char*
|The desired flag abbreviation. Must be unique. Must be 1 or 2 characters.
|-
|name
|const char*
|The desired flag name. Max length 32 characters.
|-
|helpString
|const char*
|The desired help string. Max length 128 characters.
|-
|shotType
|bz_eShotType
|The default shot type for the flag.
|-
|quality
|bz_eFlagQuality
|The flag's quality (good/bad).
|}

==Description==
This function registers a custom flag. The registered abbreviation must be unique (that is, may not conflict with existing built-in or API flags).

The registered flag will have no functionality by default (i.e. it will behave like Useless), but it can be used by your plugin by examining player records to see if they hold the flag, and taking appropriate action.

The flag's "stickiness" will be determined by quality; this is roughly consistent with BZFlag's builtin flags. Good flags will be Unstable (that is, when dropped they will disappear and be respawned); bad flags will be Sticky (that is, undroppable).

==Usage==
If you wish to use a custom flag with +/-f or -sl server parameters (including +f good and -f bad), or in flag zones on the map, you must register the flag during init via -loadplugin (or before a call to [[bz_restart]], if using it in a map).

If a plugin registers a flag while there are clients connected, they will automatically recieve the update. However, be aware that there is ''no'' corresponding bz_UnregisterCustomFlag function, so there is a limit to the dynamic capability of this functionality.

==Notes==
Requires BZFS 2.1.16 or newer.

Bz setClientWorldDownloadURL

2007-09-25T20:14:10Z

DTRemenak: correct func name

{{BZFS_API_Doc}}
{{BZFS_API_Funcs}}
==Prototype==
BZF_API void bz_setClientWorldDownloadURL( const char* URL );

==Parameters==
{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value desription
|-
|URL
|const char*
|a pointer to a string to the URL to be sent to connecting clients for the cached map
|}

==Description==
This function sets the current URL used to download a cached world file. It will be sent to clients that connect giving them the option of using that file. This is helpful if the plug-ins have changed the map file during a a call to [[bz_restart]].

Bz setClientWorldDownloadURL

2007-09-25T20:13:31Z

DTRemenak: spelling

Bz setClientWorldDowloadURL

2007-09-25T20:12:29Z

DTRemenak: Bz setClientWorldDowloadURL moved to Bz setClientWorldDownloadURL: spelling

#REDIRECT [[Bz setClientWorldDownloadURL]]

Bz setClientWorldDownloadURL

2007-09-25T20:12:28Z

DTRemenak: Bz setClientWorldDowloadURL moved to Bz setClientWorldDownloadURL: spelling

{{BZFS_API_Doc}}
{{BZFS_API_Funcs}}
==Prototype==
BZF_API void bz_setClientWorldDowloadURL( const char* URL );

==Parameters==
{| border="1" cellpadding="20" cellspacing="0"
!name
!type
!value desription
|-
|URL
|const char*
|a pointer to a string to the URL to be sent to connecting clients for the cached map
|}

==Description==
This function sets the current URL used to download a cached world file. It will be sent to clients that connect giving them the option of using that file. This is helpful if the plug-ins have changed the map file during a a call to [[bz_reload]].

Functions (API)

2007-09-25T20:11:58Z

DTRemenak: /* Map Management */ spelling

{{DoDoc|Fill in articles for all API Functions}}

{{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 );

===Player Information===

BZF_API bool [[bz_getPlayerIndexList ( [[bz_APIIntList]] *playerList );
BZF_API [[bz_APIIntList *[[bz_getPlayerIndexList]] ( void );
BZF_API [[bz_BasePlayerRecord *[[bz_getPlayerByIndex]] ( int index );
BZF_API bool [[bz_updatePlayerData]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API bool [[bz_hasPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_grantPerm ( int playerID, const char* perm );
BZF_API bool [[bz_revokePerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_getAdmin]] ( int playerID );
BZF_API bool [[bz_freePlayerRecord]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API const char* bz_getPlayerFlag]] ( int playerID );
BZF_API bool [[bz_getPlayerCurrentState]] ( int playerID, [[bz_PlayerUpdateState]] &state );
BZF_API bool [[bz_isPlayerPaused]] ( int playerID );
BZF_API bool [[bz_setPlayerOperator]] ( int playerId );
BZF_API [[bz_APIIntList]]* [[bz_getPlayerIndexList]] ( void );
BZF_API bool [[bz_canPlayerSpawn]]( int playerID );
BZF_API bool [[bz_setPlayerSpawnable]]( int playerID, bool spawn );
BZF_API bool [[bz_setPlayerLimboText]]( int playerID, const char* text );
BZF_API int [[bz_getPlayerCount]] ( void );
BZF_API bool [[bz_anyPlayers]] ( void );

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

=== 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_sentFetchResMessage]] ( int playerID, const char* URL );

=== 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]] ();

=== 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_localTime]] *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_getBZDBItemPesistent]]( 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]] ( int playerIndex, const char* ip, int durration, const char* reason );
BZF_API bool [[bz_IPUnbanUser]] ( const char* ip );
BZF_API [[bz_APIStringList]]* bz_getReports( void );
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 );

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

===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 [[_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 int [[bz_getWorldObjectCount]]( void );
BZF_API [[bz_APIWorldObjectList]]* [[bz_getWorldObjectList]]( void );
BZF_API void [[bz_releaseWorldObjectList]]( [[bz_APIWorldObjectList]]* list );

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

====Map Definition====
BZF_API bool [[bz_addWorldBox]] ( float *pos, float rot, float* scale, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldPyramid]] ( float *pos, float rot, float* scale, bool fliped, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldBase]]( float *pos, float rot, float* scale, bz_eTeamType team, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldTeleporter]] ( float *pos, float rot, float* scale, float border, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldWaterLevel]]( float level, [[bz_MaterialInfo]] *material );
BZF_API bool [[bz_addWorldWeapon]]( const char* flagType, float *pos, float rot, float tilt, float initDelay, [[bz_APIFloatList]] &delays );
BZF_API bool [[bz_setWorldSize]]( float size, float wallHeight = -1.0 );

===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 [[bz_eTeamType]] [[bz_checkBaseAtPoint]] ( float pos[3] );

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

Bz getClientWorldDownloadURL

2007-09-25T20:11:21Z

DTRemenak: spelling

{{BZFS_API_Doc}}
{{BZFS_API_Funcs}}
==Prototype==
BZF_API const [[bzApiString]] bz_getClientWorldDownloadURL ( void );

==Parameters==
none.

==Description==
Returns the current string used for the URL of the cached world. This is the URL that will be sent to all clients as an optional download location for the map file.

Bz getClientWorldDowloadURL

2007-09-25T20:10:57Z

DTRemenak: Bz getClientWorldDowloadURL moved to Bz getClientWorldDownloadURL: spelling

#REDIRECT [[Bz getClientWorldDownloadURL]]

Bz getClientWorldDownloadURL

2007-09-25T20:10:57Z

DTRemenak: Bz getClientWorldDowloadURL moved to Bz getClientWorldDownloadURL: spelling

{{BZFS_API_Doc}}
{{BZFS_API_Funcs}}
==Prototype==
BZF_API const [[bzApiString]] bz_getClientWorldDowloadURL ( void );

==Parameters==
none.

==Description==
Returns the current string used for the URL of the cached world. This is the URL that will be sent to all clients as an optional download location for the map file.

Talk:Physics

2007-09-25T19:58:15Z

DTRemenak:

This page has confusing and almost contradictory statements as to which objects can use physics drivers and which can't! Can someone "in the know" tidy it up? [[User:Mr Burns|Mr Burns]]
:Done, but my wording probably needs some help. Also, can we decide on a standardized way to do the code on these objects? such as: linear 0 0 5 #<x y z> angular 0 0 #<x y>[[User:Tedius|Tedius]]
::2.0.9/2.0.10 servers will automatically convert [[box]] and [[pyramid]] objects to [[meshbox]] and [[meshpyr]] when you attempt to use physics drivers (or material references) on them, so you CAN use them. I believe this is covered on the [[box]] and [[pyramid]] pages, though not in any sort of consistent way. -[[User:DTRemenak|DTRemenak]] 15:58, 25 September 2007 (EDT)

Functions (API)

2007-09-24T15:33:08Z

DTRemenak:

{{DoDoc|Fill in articles for all API Functions}}

{{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 );

===Player Information===

BZF_API bool [[bz_getPlayerIndexList ( [[bz_APIIntList]] *playerList );
BZF_API [[bz_APIIntList *[[bz_getPlayerIndexList]] ( void );
BZF_API [[bz_BasePlayerRecord *[[bz_getPlayerByIndex]] ( int index );
BZF_API bool [[bz_updatePlayerData]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API bool [[bz_hasPerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_grantPerm ( int playerID, const char* perm );
BZF_API bool [[bz_revokePerm]] ( int playerID, const char* perm );
BZF_API bool [[bz_getAdmin]] ( int playerID );
BZF_API bool [[bz_freePlayerRecord]] ( [[bz_BasePlayerRecord]] *playerRecord );
BZF_API const char* bz_getPlayerFlag]] ( int playerID );
BZF_API bool [[bz_getPlayerCurrentState]] ( int playerID, [[bz_PlayerUpdateState]] &state );
BZF_API bool [[bz_isPlayerPaused]] ( int playerID );
BZF_API bool [[bz_setPlayerOperator]] ( int playerId );
BZF_API [[bz_APIIntList]]* [[bz_getPlayerIndexList]] ( void );
BZF_API bool [[bz_canPlayerSpawn]]( int playerID );
BZF_API bool [[bz_setPlayerSpawnable]]( int playerID, bool spawn );
BZF_API bool [[bz_setPlayerLimboText]]( int playerID, const char* text );
BZF_API int [[bz_getPlayerCount]] ( void );
BZF_API bool [[bz_anyPlayers]] ( void );

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

=== 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_sentFetchResMessage]] ( int playerID, const char* URL );

=== 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]] ();

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

=== Map Management ===
BZF_API void [[bz_setClientWorldDowloadURL]]( const char* URL );
BZF_API const bzApiString [[bz_getClientWorldDowloadURL]] ( 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_localTime]] *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_getBZDBItemPesistent]]( 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]] ( int playerIndex, const char* ip, int durration, const char* reason );
BZF_API bool [[bz_IPUnbanUser]] ( const char* ip );
BZF_API [[bz_APIStringList]]* bz_getReports( void );
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 );

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

===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 [[_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 int [[bz_getWorldObjectCount]]( void );
BZF_API [[bz_APIWorldObjectList]]* [[bz_getWorldObjectList]]( void );
BZF_API void [[bz_releaseWorldObjectList]]( [[bz_APIWorldObjectList]]* list );

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

====Map Definition====
BZF_API bool [[bz_addWorldBox]] ( float *pos, float rot, float* scale, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldPyramid]] ( float *pos, float rot, float* scale, bool fliped, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldBase]]( float *pos, float rot, float* scale, bz_eTeamType team, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldTeleporter]] ( float *pos, float rot, float* scale, float border, [[bz_WorldObjectOptions]] options );
BZF_API bool [[bz_addWorldWaterLevel]]( float level, [[bz_MaterialInfo]] *material );
BZF_API bool [[bz_addWorldWeapon]]( const char* flagType, float *pos, float rot, float tilt, float initDelay, [[bz_APIFloatList]] &delays );
BZF_API bool [[bz_setWorldSize]]( float size, float wallHeight = -1.0 );

===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 [[bz_eTeamType]] [[bz_checkBaseAtPoint]] ( float pos[3] );

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

File:Tank sizes.png

2007-09-20T01:04:23Z

DTRemenak: uploaded a new version of "Image:Tank sizes.png": 2.08->2.05 as per recent correction

Tank

2007-09-18T23:45:19Z

DTRemenak: /* Dimensions */ back to 2.05 as per jeff's recent commit

The tank is the primary avatar of the player in BZFlag.[[image:Blue_tank_small.png|right]]

==Overview==
The BZFlag tank model has been in the game since it's inception, and been an integral part of game play. The tank has received few graphical upgrades over the years, and looks today much the same as it has since the first version of the game.

The tank model is currently [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instruction in the [[BZFlag Source]] code. The model may not be changed externally with out modifications to the game client itself.

The tank model has been exported from the code, and can be found as a wavefront obj file at http://my.bzflag.org/resources/models/Tank.obj
This can be imported into most 3d modeling packages.

==Appearance==
The tank model has 7 different colors, or "skins", that it can appear in. The color of the tank results from the team in which the tank is playing, or some other game logic (such as Hunters and Rabbits in [[Rabbit Hunt]])
The 7 tank colors are as follows:
<gallery>
image:Red_tank.png‎|Red Team Tank
image:Blue_tank.png‎|Blue Team Tank
image:Green_tank.png‎|Green Team Tank
image:Purple_tank.png‎|Purple Team Tank
image:Black_tank.png‎|Rogue (black) Team Tank
image:Orange_tank.png‎|Hunter Team Tank
image:White_tank.png‎|Rabbit Team Tank
</gallery>

Depending on an individual client's graphical settings, the tank may have animated treads and spinning wheels. The tanks shown are the most basic version of the tank.

==Dimensions==
[[image:Tank_sizes.png|frame|right|Tank dimensions in [[world units]]]]
The Tank's visible model is 8.04 [[world units]] long, 2.8 [[World units|units]] wide, and 2.05 [[World units|units]] tall as shown in the image. If one assumes that one [[World units|world unit]] is equivalent to one real world meter, then the tank would be 26 feet 4.5 inches long, 9 feet 2 inches wide, and 6 feet 10 inches tall.

The tank bounding box (used in collisions with world objects) is 6 [[world units]] long, 2.8 [[World units|units]] wide, and 2.05 [[World units|units]] tall, and does not include the barrel forward of the tip of the treads. The muzzle of the barrel is 1.57 [[World units|world units]] from the ground, meaning that a tank can shoot over a box 1.5 [[World units|units]] high.

==History==
The tank model was originally created by [[Tamar Cohen]] for the first versions of BZFlag and has since been extended and modified by the BZFlag developers.

[[Category:Concepts]]
[[Category:Map Making]]

Tank

2007-09-18T23:34:32Z

DTRemenak: /* Dimensions */

The tank is the primary avatar of the player in BZFlag.[[image:Blue_tank_small.png|right]]

==Overview==
The BZFlag tank model has been in the game since it's inception, and been an integral part of game play. The tank has received few graphical upgrades over the years, and looks today much the same as it has since the first version of the game.

The tank model is currently [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instruction in the [[BZFlag Source]] code. The model may not be changed externally with out modifications to the game client itself.

The tank model has been exported from the code, and can be found as a wavefront obj file at http://my.bzflag.org/resources/models/Tank.obj
This can be imported into most 3d modeling packages.

==Appearance==
The tank model has 7 different colors, or "skins", that it can appear in. The color of the tank results from the team in which the tank is playing, or some other game logic (such as Hunters and Rabbits in [[Rabbit Hunt]])
The 7 tank colors are as follows:
<gallery>
image:Red_tank.png‎|Red Team Tank
image:Blue_tank.png‎|Blue Team Tank
image:Green_tank.png‎|Green Team Tank
image:Purple_tank.png‎|Purple Team Tank
image:Black_tank.png‎|Rogue (black) Team Tank
image:Orange_tank.png‎|Hunter Team Tank
image:White_tank.png‎|Rabbit Team Tank
</gallery>

Depending on an individual client's graphical settings, the tank may have animated treads and spinning wheels. The tanks shown are the most basic version of the tank.

==Dimensions==
[[image:Tank_sizes.png|frame|right|Tank dimensions in [[world units]]]]
The Tank's visible model is 8.04 [[world units]] long, 2.8 [[World units|units]] wide, and 2.08 [[World units|units]] tall as shown in the image. If one assumes that one [[World units|world unit]] is equivalent to one real world meter, then the tank would be 26 feet 4.5 inches long, 9 feet 2 inches wide, and 6 feet 10 inches tall.

The tank bounding box (used in collisions with world objects) is 6 [[world units]] long, 2.8 [[World units|units]] wide, and 2.05 [[World units|units]] tall, and does not include the barrel forward of the tip of the treads. The muzzle of the barrel is 1.57 [[World units|world units]] from the ground, meaning that a tank can shoot over a box 1.5 [[World units|units]] high.

==History==
The tank model was originally created by [[Tamar Cohen]] for the first versions of BZFlag and has since been extended and modified by the BZFlag developers.

[[Category:Concepts]]
[[Category:Map Making]]

Tank

2007-09-18T23:33:43Z

DTRemenak: /* Dimensions */ clarify between the visible model and the box used in collisions

The tank is the primary avatar of the player in BZFlag.[[image:Blue_tank_small.png|right]]

==Overview==
The BZFlag tank model has been in the game since it's inception, and been an integral part of game play. The tank has received few graphical upgrades over the years, and looks today much the same as it has since the first version of the game.

The tank model is currently [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instruction in the [[BZFlag Source]] code. The model may not be changed externally with out modifications to the game client itself.

The tank model has been exported from the code, and can be found as a wavefront obj file at http://my.bzflag.org/resources/models/Tank.obj
This can be imported into most 3d modeling packages.

==Appearance==
The tank model has 7 different colors, or "skins", that it can appear in. The color of the tank results from the team in which the tank is playing, or some other game logic (such as Hunters and Rabbits in [[Rabbit Hunt]])
The 7 tank colors are as follows:
<gallery>
image:Red_tank.png‎|Red Team Tank
image:Blue_tank.png‎|Blue Team Tank
image:Green_tank.png‎|Green Team Tank
image:Purple_tank.png‎|Purple Team Tank
image:Black_tank.png‎|Rogue (black) Team Tank
image:Orange_tank.png‎|Hunter Team Tank
image:White_tank.png‎|Rabbit Team Tank
</gallery>

Depending on an individual client's graphical settings, the tank may have animated treads and spinning wheels. The tanks shown are the most basic version of the tank.

==Dimensions==
[[image:Tank_sizes.png|frame|right|Tank dimensions in [[world units]]]]
The Tank's visible model is 8.04 [[world units]] long, 2.8 [[World units|units]] wide, and 2.08 [[World units|units]] tall as shown in the image. If one assumes that one [[World units|world unit]] is equivalent to one real world meter, then the tank would be 26 feet 4.5 inches long, 9 feet 2 inches wide, and 6 feet 10 inches tall.

The tank bounding box (used in collisions with world objects) is 6 [[world units]] long, 2.8 [[World units|units]] wide, and 2.05 [[World units|units]] tall, and does not include the muzzle forward of the tip of the treads. The muzzle of the barrel is 1.57 [[World units|world units]] from the ground, meaning that a tank can shoot over a box 1.5 [[World units|units]] high.

==History==
The tank model was originally created by [[Tamar Cohen]] for the first versions of BZFlag and has since been extended and modified by the BZFlag developers.

[[Category:Concepts]]
[[Category:Map Making]]

Tank

2007-09-18T23:10:39Z

DTRemenak:

The tank is the primary avatar of the player in BZFlag.[[image:Blue_tank_small.png|right]]

==Overview==
The BZFlag tank model has been in the game since it's inception, and been an integral part of game play. The tank has received few graphical upgrades over the years, and looks today much the same as it has since the first version of the game.

The tank model is currently [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instruction in the [[BZFlag Source]] code. The model may not be changed externally with out modifications to the game client itself.

The tank model has been exported from the code, and can be found as a wavefront obj file at http://my.bzflag.org/resources/models/Tank.obj
This can be imported into most 3d modeling packages.

==Appearance==
The tank model has 7 different colors, or "skins", that it can appear in. The color of the tank results from the team in which the tank is playing, or some other game logic (such as Hunters and Rabbits in [[Rabbit Hunt]])
The 7 tank colors are as follows:
<gallery>
image:Red_tank.png‎|Red Team Tank
image:Blue_tank.png‎|Blue Team Tank
image:Green_tank.png‎|Green Team Tank
image:Purple_tank.png‎|Purple Team Tank
image:Black_tank.png‎|Rogue (black) Team Tank
image:Orange_tank.png‎|Hunter Team Tank
image:White_tank.png‎|Rabbit Team Tank
</gallery>

Depending on an individual client's graphical settings, the tank may have animated treads and spinning wheels. The tanks shown are the most basic version of the tank.

==Dimensions==
[[image:Tank_sizes.png|frame|right|Tank dimensions in [[World units|world units]]]]
The Tank is 8.04 [[World units|world units]] long, 2.8 [[World units|units]] wide, and 2.05 [[World units|units]] tall as shown in the image. The turret is 1.57 [[World units|world units]] from the ground, meaning that a tank can shoot over a box 1.5 [[World units|units]] high. If one assumes that one [[World units|world unit]] is equivalent to one real world meter, then the tank would be 26 feet 4.5 inches long, 9 feet 2 inches wide, and 6 feet 10 inches tall.

==History==
The tank model was originally created by [[Tamar Cohen]] for the first versions of BZFlag and has since been extended and modified by the BZFlag developers.

[[Category:Concepts]]
[[Category:Map Making]]

Server Variables

2007-09-18T22:57:48Z

DTRemenak: various corrections/clarifications.

The BZFlag Server (BZFS) allows administrators to configure a large number of gameplay and configuration settings from within the client. The /set command in-game allows users with the appropriate permissions to change these values. These may also be known as BZDB variables and "/set variables" depending on who you speak with.

Unless otherwise noted, time values are measured in seconds, distances in [[world units]], and speeds in [[world units]] per second.

{{InfoBox|Note|Some of these, such as _worldSize, may require a rejoin before they take effect. It is recommended to apply these in the map file (if they apply specifically to the map, such as _worldSize and _tankSpeed), through the server configuration file, or from the command line. This ensures that all players that join will have the proper gameplay experience.}}
{|{{Prettytable}}
|-
|{{Hl3}}|'''Name'''
|{{Hl3}}|'''Default'''
|{{Hl3}}|'''Description'''
|-
| _agilityAdVel || 2.25 || Multiplies _tankSpeed for tanks holding Agility flag for a specified amount of time (_agilityTimeWindow)
|-
| _agilityTimeWindow || 1 || The amount of time (in seconds)that the tank will have the speed specified by _agilityAdVel
|-
| _agilityVelDelta || 0.3 ||
|-
| _angleTolerance || 0.05 || If a tank has turned more than it was expected to, plus this tolerance, a new update is sent so the other clients are aware of the change in heading
|-
| _angularAd || 1.5 || Multiplies _tankAngVel to determine how fast tanks can turn while holding the Quick Turn flag
|-
| _avenueSize || 2*_boxBase || Space to leave between objects in random maps?
|-
| _baseSize || 60 || Width and Depth (bases have constant height) of the square bases for CTF games
|-
| _boxBase || 30 || Width and Depth of boxes on a random map?
|-
| _boxHeight || 6*_muzzleHeight || Height of boxes on a random map?
|-
| _burrowDepth || 1.32 || Determines how far down tanks drop when they have the Burrow Flag. Making this much lower makes it below the floor, and impossible to kill tank!
|-
| _burrowSpeedAd || .8 || Multiplied by _tankSpeed to determine how fast tanks holding the Burrow Flag move.
|-
| _burrowAngularAd || .55 || Multiplied by _tankAngVel to determine how fast tanks can turn while holding the Burrow flag.
|-
| _coldetDepth || 6 ||
|-
| _coldetElements || 4 ||
|-
| _countdownResumeTime || 5 || This enforces a delay when resuming a paused countdown. If the argument is lower or equal to 0 then resuming is instantly, otherwise it is delayed according to the value (in seconds). ''Available in 2.1 and later''
|-
| _cullDepth || 6 ||
|-
| _cullDist || fog || Far plane culling distance ('fog' uses the fog parameters).
|-
| _cullElements || 16 ||
|-
| _cullOccluders || 0 ||
|-
| _disableBots || none || A value of 1 in this variable does not allow autopilot or bots on the server, equivalent to the old -prohibitbots command line option.
|-
| _drawCelestial || 1 || Draw the stars, sun, and moon.
|-
| _drawClouds || 1 || Draw the clouds.
|-
| _drawGround || 1 || Draw the ground plane.
|-
| _drawMountains || 1 || Draw the mountains.
|-
| _drawSky || 1 || Draw the sky pyramid.
|-
| _explodeTime || 5 || After a tank is killed, this is how long it takes to blow up, and then "respawn". Larger values translates into longer explosions and more client processor time. Note that an explosion is invisible if you are inside it, so large values may make it invisible up close, and extremely large values may make explosions entirely invisible.
|-
| _flagAltitude || 11 || The height that the flag flies up dropped and the height that a flag spawns at.
|-
| _flagEffectTime || 0.64 || The amount of time the flag effect lasts.
|-
| _flagHeight || 10 || The height of the flag (not its pole).
|-
| _flagPoleWidth || 0.025 || The diameter of the flag pole.
|-
| _flagPoleSize || 0.8 || The height of the flag pole.
|-
| _flagRadius || 2.5 || Determines how close a tank must be to a flag to pick it up.
|-
| _fogMode || none || Valid values: linear, exp, or exp2.
|-
| _fogDensity || 0.001 || Used for exp and exp2 fog modes.
|-
| _fogStart || 0.5*_worldSize || Used for linear fog mode, the distance where fog begins to occlude vision.
|-
| _fogEnd || _worldSize || Used for linear fog mode, the distance where the fog occludes everything.
|-
| _fogColor || "0.25 0.25 0.25" || RGB or black, red, blue (alpha is ignored).
|-
| _friction || 0 || Zero is normal friction, the closer to 0 the harder it is to start and stop, and the higher the number the easier it is to start and stop.
|-
| _gmActivationTime || 0.5 || The amount of time (in seconds) it takes for a Guided Missile to become active after it is fired. Any contact under this time will not result in detonation (setting it to low could cause its owner to run into its own GM and be blown up!
|-
| _gmAdLife || 0.95 || Multiplied by _shotRange to determine the distance guided missiles will go.
|-
| _gmTurnAngle || 0.628319 || The angle at which a Guided Missile will turn to follow its target. (Measured in radians)
|-
| _gravity || 9.8 || The rate at which a tank will fall (or be kept from jumping) Measured in [[World units]]/Seconds^2. Setting this to a zero or positive value will result in tanks being unable to stay down and will float away.
|-
| _handicapScoreDiff || 50 || How much of a score difference (from the leader?) there must be for a player to get a handicap
|-
| _handicapVelAd || 2 || Player with handicap will receive this much more (_tankSpeed + _handicapVelAd) velocity than the normal _tankSpeed value.<br>''**Note: These could be factors rather than additions''
|-
| _handicapAngAd || 1.5 || Player with handicap will receive this much more (_angularAd + _handicapAngAd) turning ability than the normal _angularAd. <br>''**Note: These could be factors rather than additions''
|-
| _handicapShotAd || 1.75 || ''**Note: These could be factors rather than additions''
|-
| _identifyRange || 50 || If a flag is this distance or closer to a tank carrying the Identify (ID) flag, it will display the closest flag's type.
|-
| _jumpVelocity || 19 || The speed a tank moves vertically while jumping.
|-
| _laserAdVel || 1000 || The speed at which a laser travels.
|-
| _laserAdRate || 0.5 || Multiplied by _rFireAdRate to determine the firing rate for a laser.
|-
| _laserAdLife || 0.1 || The amount of time (in seconds) that a laser remains after being fired.
|-
| _latitude || 37.5 || The latitude at which the world exists. This affects the timezone.
|-
| _lgGravity|| 12.7 || Modifies the gravity for owners of the Low Gravity flag. Similar to the _gravity variable. ''Available starting in version 2.1''
|-
| _lockOnAngle || 0.15 || Angle (in radians) in relation to tanks heading (positive or negative) that will allow a Guided Missile to lock onto a target.
|-
| _longitude || 122 || The longitude at which the world exists. This affects the timezone.
|-
| _lRAdRate || 0.5 ||
|-
| _maxBumpHeight || 0.33 || Any difference between the surface a tank is on and the top surface of an object the tank runs into that is less than this value will allow the tank to simply move up to the object rather than being stopped by it.
|-
| _maxFlagGrabs || 4.0 || How many times a flag can be dropped before it respawns. Note that on server startup, flags will get a random # of grabs already assigned to them, and flags will always respawn no matter how many flag grabs they have left if it is are over an 'unsafe' zone.
|-
| _maxLOD || 32767 || The max level of detail to allow.
|-
| _mirror || none || Options: '''white''', '''black''', '''red''', '''blue''', '''pink''', '''purple''', '''orange''', etc... ("black 0.75" is a good setting, some invalid options such as '''mirror''' will give a mirror look)
|-
| _momentumLinAcc || 1 || Momentum flag's effect on going forwards and backwards.
|-
| _momentumAngAcc || 1 || Momentum flag's effect on turning.
|-
| _momentumFriction || 0 || Friction (same as _friction) when holding the Momentum flag.
|-
| _mGunAdVel || 1/_mGunAdRate || The speed of the machine gun's bullets.
|-
| _mGunAdRate || 10 || The amount of time required for the machine gun to reload.
|-
| _mGunAdLife || 1.5 || Multiplied by _shotRange to determine the distance machine gun bullets go.
|-
| _muzzleFront || _tankRadius + 0.1 || Location of muzzle of tank (affects bullets and player camera location).
|-
| _muzzleHeight || 1.57 || See _muzzleFront.
|-
| _noClimb || 1 || Allow or disallow climbing on sloped surfaces. A value of 0 allows, 1 disallows.
|-
| _noShadows || 0 || Enables of disables shadows. A value of 0 allows, 1 disallows.
|-
| _noSmallPackets || 0 ||
|-
| _notRespondingTime || 5 || The amount of time (in seconds) the server should wait before reporting a tank as not responding.
|-
| _obeseFactor || 2.5 || Multiplier of normal size that determines how big a tank gets when carrying the Obese flag.
|-
| _pauseDropTime || 15 || The amount of time (in seconds) that a tank needs to be paused before its flag is dropped automatically.
|-
| _positionTolerance || 0.09 ||
|-
| _pyrBase || 4 * _tankHeight || Base size of pyramids generated by the default random map generator.
|-
| _pyrHeight || 5 * _tankHeight || Height of pyramids generated by the default random map generator.
|-
| _radarLimit || _worldSize || The maximum area that the radar can see (when not rotated).
|-
| _rainBaseColor || none || When _rainType = rain, sets color of the bottom of raindrops.
|-
| _rainDensity || none || Determines how many drops of rain are in the space defined by _rainSpread.
|-
| _rainEndZ || none || The height above the ground where rain should stop falling.
|-
| _rainMaxPuddleTime || none || The amount of time (in seconds) a rain puddle should exist before disappearing.
|-
| _rainPuddleSpeed || none || The speed at which puddles should spread out.
|-
| _rainPuddleColor || none || Color of rain puddles. none means no puddle.
|-
| _rainPuddleTexture ||none || Texture of puddles. Best to leave default.
|-
| _rainRoofs || 1 || '''0''' rain falls through everything<br>'''1''' rain hits buildings, but puddles are only on the ground<br>'''2''' rain hits buildings, and creates puddles on them
|-
| _rainSpread || none || The radius from center of map where rain will fall.
|-
| _rainSpeed || none || The speed at which the rain falls.
|-
| _rainSpeedMod || none || Randomizes _rainSpeed by adding/subtracting up to this number from each raindrop's speed
|-
| _rainSpins || none || '''0''' Rain does not spin as it falls<br>'''1''' Rain spins as it falls.
|-
| _rainStartZ || none || The height above ground that rain should fall from.
|-
| _rainTexture || none || The name of the texture in data directory.<br>''Works with _rainTypes of frog, particle, bubble, snow, fatrain''
|-
| _rainTopColor ||none || When _rainType = rain, sets color of the top of raindrops.
|-
| _rainType || none || Adjusts all _rain* and _use* variables automatically<br>Valid Options : '''frog''', '''particle''', '''rain''', '''bubble''', '''snow''', '''fatrain'''
|-
| _rejoinTime || _explodeTime || The number of seconds before clients can rejoin a game, after they leave.
|-
| _reloadTime || _shotRange/_shotSpeed || Time between shot reloads, note that this can cut shot range short.
|-
| _rFireAdVel || 1.5 || Multiplied by _shotSpeed to determine the speed of the rapid fire bullets.
|-
| _rFireAdRate || 2 || The reload time (in seconds) for rapid fire bullets.
|-
| _rFireAdLife || 1/_rFireAdRate || How long the rapid fire bullets last.
|-
| _shieldFlight || 2.7 || The amount of time (in seconds) that a shield flag floats in the air (after you drop it) before coming down again.
|-
| _shockAdLife || 0.2 || The amount of time (in seconds) that a shockwave lasts.
|-
| _shockInRadius || _tankLength || The starting radius of the shockwave. Negative values will make the shockwave shrink and expand.
|-
| _shockOutRadius || 60 || The outer radius of the shockwave. If greater than _shockInRadius, the shockwave expands outward. If less than _shockInRadius, the shockwave starts big and shrinks inward.
|-
| _shotRadius || 0.5 || For collision detection.
|-
| _shotRange || 350 || Range of shots, note that they can be cut short by _reloadTime.
|-
| _shotSpeed || 100 || Speed of shots.
|-
| _shotTailLength || 4 ||
|-
| _shotsKeepVerticalVelocity || 0 || If '''0''', shots always move straight in relation to the ground. If '''1''', shots are affected vertically by the tank's speed, and can fly up and down. Lasers are also affected.
|-
| _skyColor || white || Sets the sky to a specific color.
|-
| _srRadiusMult || 2 || Radius of steamroller effect.
|-
| _squishFactor || 1 || How much tanks squish when landing.
|-
| _squishTime || 1 || How much squishy time you get after falling to the ground.
|-
| _syncTime || 1 || Whether or not to sync the players time with the servers'.
|-
| _syncLocation || 0 || Whether or not to sync the location time with the servers'.
|-
| _tankAngVel || 0.785398 || How fast the tank can turn.
|-
| _tankExplosionSize || 3.5 * _tankLength || How large the tank's explosion is.
|-
| _tankHeight || 2.05 || The height of the tank.
|-
| _tankLength || 6 || The length of the tank.
|-
| _tankRadius || 0.72 * _tankLength || The radius of the tank.
|-
| _tankSpeed || 25 || The speed of the tank
|-
| _tankWidth || 2.8 || The width of the tank.
|-
| _targetingAngle || 0.3|| Something to do with GM...
|-
| _teleportBreadth || 4.48|| Random maps?
|-
| _teleportHeight || 10.08 || See _teleportBreadth.
|-
| _teleportTime || 1 ||
|-
| _teleportWidth || 1.12 || See _teleportHeight.
|-
| _thiefAdLife || 0.05 || The amount of time (in seconds) that a thief shot lasts.
|-
| _thiefAdRate || 12 || The amount of time (in seconds) that the Thief "shot" reloads.
|-
| _thiefAdShotVel || 8 || The speed of thief.
|-
| _thiefTinyFactor || 0.5|| Multiplied by the normal tank size to shrink a tank carrying the thief flag.
|-
| _thiefVelAd || 1.67 || Multiplied by _tankSpeed to determine how fast tanks holding the thief goes.
|-
| _thiefDropTime || reloadTime * 0.5 ||The amount of time you must wait to fire a shot after stealing a flag.
|-
| _tinyFactor || 0.4 || Multiplied by the normal tank size to shrink a tank carrying the tiny flag.
|-
| _trackFade || 3 || The amount of time (in seconds) before track marks fade.
|-
| _updateThrottleRate || 30 ||
|-
| _useLineRain || none || '''0''' Rain is not a vertical line<br>'''1''' Rain is vertical lines, smoothly shaded from _rainTopColor to _rainBaseColor
|-
| _useRainPuddles || none || '''0''' Rain does not create puddles<br>'''1''' Rain creates puddles
|-
| _useRainBillboards || none || '''0''' Rain is lines or polygons<br>'''1''' Rain is billboards, textured and look the same from all angles
|-
| _velocityAd || 1.5 || Multiplies _tankSpeed to determine the speed of a tank carrying the high speed (V) flag
|-
| _wallHeight || 3 * _tankHeight|| The outer wall height.
|-
| _weapons || 1 || Used with world weapons, '''0''' world weapons will not fire<br>'''1''' world weapons will fire
|-
| _wideAngleAng || 1.745329 || The viewing angle when a tank has the Wide Angle bad flag.
|-
| _wingsGravity || _gravity || How much gravity affects tanks with the WG flag.
|-
| _wingsJumpCount || 1 || The number of jumps a tank with the wings flag can do before returning to the ground.
|-
| _wingsJumpVelocity || _jumpVelocity || The initial velocity of a jump with wings, in [[world units]]/sec.
|-
| _wingsSlideTime || 0 || When in the air, the tanks will slide for this long.
|-
| _worldSize || 400 || The size of the world. This should not be set during play, as the walls will not move for currently connected players. Setting this larger will allow tanks to go outside the map, and setting it smaller will cause tanks to be kicked for leaving the world boundaries.
|}

[[Category:Server]]

Server Variables

2007-09-18T22:49:49Z

DTRemenak: world units, not meters

The BZFlag Server (BZFS) allows administrators to configure a large number of gameplay and configuration settings from within the client. The /set command in-game allows users with the appropriate permissions to change these values. These may also be known as BZDB variables and "/set variables" depending on who you speak with.

{{InfoBox|Note|Some of these, such as _worldSize, may require a rejoin before they take effect. It is recommended to apply these in the map file (if they apply specifically to the map, such as _worldSize and _tankSpeed), through the server configuration file, or from the command line. This ensures that all players that join will have the proper gameplay experience.}}
{|{{Prettytable}}
|-
|{{Hl3}}|'''Name'''
|{{Hl3}}|'''Default'''
|{{Hl3}}|'''Description'''
|-
| _agilityAdVel || 2.25 || Multiplies _tankSpeed for tanks holding Agility flag for a specified amount of time (_agilityTimeWindow)
|-
| _agilityTimeWindow || 1 || The amount of time (in seconds)that the tank will have the speed specified by _agilityAdVel
|-
| _agilityVelDelta || 0.3 ||
|-
| _angleTolerance || 0.05 || If a tank has turned more than it was expected to, plus the tolerance, a new update is sent so the other clients are aware of the change in heading
|-
| _angularAd || 1.5 || Multiplies _tankAngVel to determine how fast tanks can turn while holding the Quick Turn flag
|-
| _avenueSize || 2*_boxBase || Space to leave between objects in random maps?
|-
| _baseSize || 60 || Width and Depth (bases have constant height) of the square bases for CTF games
|-
| _boxBase || 30 || Width and Depth of boxes on a random map?
|-
| _boxHeight ||6*_muzzleHeight || Height of boxes on a random map?
|-
| _burrowDepth || 1.32 || Determines how far down tanks drop when they have the Burrow Flag. Making this much lower makes it below the floor, and impossible to kill tank!
|-
| _burrowSpeedAd || .8 || Multiplied by _tankSpeed to determine how fast tanks holding the Burrow Flag move.
|-
| _burrowAngularAd || .55 || Multiplied by _tankAngVel to determine how fast tanks can turn while holding the Burrow flag.
|-
| _coldetDepth || 6 ||
|-
| _coldetElements || 4 ||
|-
| _countdownResumeTime || 5 || This enforces a delay when resuming a paused countdown. If the argument is lower or equal to 0 then resuming is instantly, otherwise it is delayed according to the value (in seconds). ''Available in 2.1 and later''
|-
| _cullDepth || 6 ||
|-
| _cullDist || fog || Far plane culling distance ('fog' uses the fog parameters).
|-
| _cullElements || 16 ||
|-
| _cullOccluders || 0 ||
|-
| _disableBots || none || A value of 1 in this variable does not allow autopilot or bots on the server, equivalent to the old -prohibitbots command line option.
|-
| _drawCelestial || 1 || Draw the stars, sun, and moon.
|-
| _drawClouds || 1 || Draw the clouds.
|-
| _drawGround || 1 || Draw the ground plane.
|-
| _drawMountains || 1 || Draw the mountains.
|-
| _drawSky || 1 || Draw the sky pyramid.
|-
| _explodeTime || 5 || After a tank is killed, this is how long it takes to blow up, and then "respawn". Larger values translates into longer explosions and more client processor time. Note that an explosion is invisible if you are inside it, so large values may make it invisible up close, and extremely large values may make explosions entirely invisible.
|-
| _flagAltitude || 11 || The height that the flag flies up dropped and the height that a flag spawns at.
|-
| _flagEffectTime || 0.64 || The amount of time the flag effect lasts.
|-
| _flagHeight || 10 || The height of the flag (not its pole).
|-
| _flagPoleWidth || 0.025 || The diameter of the flag pole.
|-
| _flagPoleSize || 0.8 || The height of the flag pole.
|-
| _flagRadius || 2.5 || Determines how close a tank must be to a flag to pick it up.
|-
| _fogMode || none || Valid values: linear, exp, or exp2.
|-
| _fogDensity || 0.001 || Used for exp and exp2 fog modes.
|-
| _fogStart || 0.5*_worldSize || Used for linear fog mode, the distance where fog begins to occlude vision.
|-
| _fogEnd || _worldSize || Used for linear fog mode, the distance where the fog occludes everything.
|-
| _fogColor || "0.25 0.25 0.25" || RGB or black, red, blue (alpha is ignored).
|-
| _friction || 0 || Zero is normal friction, the closer to 0 the harder it is to start and stop, and the higher the number the easier it is to start and stop.
|-
| _gmActivationTime || 0.5 || The amount of time (in seconds) it takes for a Guided Missile to become active after it is fired. Any contact under this time will not result in detonation (setting it to low could cause its owner to run into its own GM and be blown up!
|-
| _gmAdLife || 0.95 || Multiplied by _shotRange to determine the distance guided missiles will go.
|-
| _gmTurnAngle || 0.628319 || The angle at which a Guided Missile will turn to follow its target. (Measured in radians)
|-
| _gravity || 9.8 || The rate at which a tank will fall (or be kept from jumping) Measured in [[World units]]/Seconds^2. Setting this to a zero or positive value will result in tanks being unable to stay down and will float away.
|-
| _handicapScoreDiff || 50 || How much of a score difference (from the leader?) there must be for a player to get a handicap
|-
| _handicapVelAd || 2 || Player with handicap will receive this much more (_tankSpeed + _handicapVelAd) velocity than the normal _tankSpeed value.<br>''**Note: These could be factors rather than additions''
|-
| _handicapAngAd || 1.5 || Player with handicap will receive this much more (_angularAd + _handicapAngAd) turning ability than the normal _angularAd. <br>''**Note: These could be factors rather than additions''
|-
| _handicapShotAd || 1.75 || ''**Note: These could be factors rather than additions''
|-
| _identifyRange || 50 || If a flag is this distance or closer to a tank carrying the Identify (ID) flag, it will display the closest flag's type.
|-
| _jumpVelocity || 19 || The speed a tank moves vertically while jumping.
|-
| _laserAdVel || 1000 || The speed at which a laser travels.
|-
| _laserAdRate || 0.5 || Multiplied by _rFireAdRate to determine the firing rate for a laser.
|-
| _laserAdLife || 0.1 || The amount of time (in seconds) that a laser remains after being fired.
|-
| _latitude || 37.5 || The latitude at which the world exists. This affects the timezone.
|-
| _lgGravity|| 12.7 || Modifies the gravity for owners of the Low Gravity flag. Similar to the _gravity variable. ''Available starting in version 2.1''
|-
| _lockOnAngle || 0.15 || Angle (in radians) in relation to tanks heading (positive or negative) that will allow a Guided Missile to lock onto a target.
|-
| _longitude || 122 || The longitude at which the world exists. This affects the timezone.
|-
| _lRAdRate ||0.5 ||
|-
| _maxBumpHeight || 0.33 || Any difference between the surface a tank is on and the top surface of an object the tank runs into that is less than this value will allow the tank to simply move up to the object rather than being stopped by it.
|-
| _maxFlagGrabs || 4.0 || How many times a flag can be dropped before it respawns. Note that on server startup, flags will get a random # of grabs already assigned to them, and flags will always respawn no matter how many flag grabs they have left if it is are over an 'unsafe' zone.
|-
| _maxLOD || 32767 || The max level of detail to allow.
|-
| _mirror || none || Options: '''white''', '''black''', '''red''', '''blue''', '''pink''', '''purple''', '''orange''', etc... ("black 0.75" is a good setting, some invalid options such as '''mirror''' will give a mirror look)
|-
| _momentumLinAcc || 1 || Momentum flag's effect on going forwards and backwards.
|-
| _momentumAngAcc || 1 || Momentum flag's effect on turning.
|-
| _momentumFriction || 0 || Friction (same as _friction) when holding the Momentum flag.
|-
| _mGunAdVel || 1/_mGunAdRate || The speed of the machine gun's bullets.
|-
| _mGunAdRate || 10 || The amount of time required for the machine gun to reload.
|-
| _mGunAdLife || 1.5 || Multiplied by _shotRange to determine the distance machine gun bullets go.
|-
| _muzzleFront || _tankRadius + 0.1 || Location of muzzle of tank (affects bullets and player camera location).
|-
| _muzzleHeight || 1.57 || See _muzzleFront.
|-
| _noClimb || 1 || Allow or disallow climbing on sloped surfaces. A value of 0 allows, 1 disallows.
|-
| _noShadows || 0 || Enables of disables shadows. A value of 0 allows, 1 disallows.
|-
| _noSmallPackets || 0 ||
|-
| _notRespondingTime || 5 || The amount of time (in seconds) the server should wait before reporting a tank as not responding.
|-
| _obeseFactor || 2.5 || Multiplier of normal size that determines how big a tank gets when carrying the Obese flag.
|-
| _pauseDropTime || 15 || The amount of time (in seconds) that a tank needs to be paused before its flag is dropped automatically.
|-
| _positionTolerance || 0.09 ||
|-
| _pyrBase || 4 * _tankHeight || Has to do with random generation of maps?
|-
| _pyrHeight ||5*_tankHeight || See _pyrBase
|-
| _radarLimit || _worldSize || The maximum area that the radar can see (when not rotated).
|-
| _rainBaseColor || none || When _rainType = rain, sets color of the bottom of raindrops.
|-
| _rainDensity || none || Determines how many drops of rain are in the space defined by _rainSpread.
|-
| _rainEndZ || none || The height above the ground where rain should stop falling.
|-
| _rainMaxPuddleTime || none || The amount of time (in seconds) a rain puddle should exist before disappearing.
|-
| _rainPuddleSpeed || none || The speed at which puddles should spread out.
|-
| _rainPuddleColor || none || Color of rain puddles. none means no puddle.
|-
| _rainPuddleTexture ||none || Texture of puddles. Best to leave default.
|-
| _rainRoofs || 1 || '''0''' rain falls through everything<br>'''1''' rain hits buildings, but puddles are only on the ground<br>'''2''' rain hits buildings, and creates puddles on them
|-
| _rainSpread || none || The radius from center of map where rain will fall.
|-
| _rainSpeed || none || The speed at which the rain falls.
|-
| _rainSpeedMod || none || Randomizes _rainSpeed by adding/subtracting up to this number from each raindrop's speed
|-
| _rainSpins || none || '''0''' Rain does not spin as it falls<br>'''1''' Rain spins as it falls.
|-
| _rainStartZ || none || The height above ground that rain should fall from.
|-
| _rainTexture || none || The name of the texture in data directory.<br>''Works with _rainTypes of frog, particle, bubble, snow, fatrain''
|-
| _rainTopColor ||none || When _rainType = rain, sets color of the top of raindrops.
|-
| _rainType || none || Adjusts all _rain* and _use* variables automatically<br>Valid Options : '''frog''', '''particle''', '''rain''', '''bubble''', '''snow''', '''fatrain'''
|-
| _rejoinTime || _explodeTime || The number of seconds before clients can rejoin a game, after they leave.
|-
| _reloadTime || _shotRange/_shotSpeed || Time between shot reloads, note that this can cut shot range short.
|-
| _rFireAdVel || 1.5 || Multiplied by _shotSpeed to determine the speed of the rapid fire bullets.
|-
| _rFireAdRate || 2 || The reload time (in seconds) for rapid fire bullets.
|-
| _rFireAdLife || 1/_rFireAdRate || How long the rapid fire bullets last.
|-
| _shieldFlight || 2.7 || The amount of time (in seconds) that a shield flag floats in the air (after you drop it) before coming down again.
|-
| _shockAdLife || 0.2 || The amount of time (in seconds) that a shockwave lasts.
|-
| _shockInRadius || _tankLength || The starting radius of the shockwave. Negative values will make the shockwave shrink and expand.
|-
| _shockOutRadius || 60 || The outer radius of the shockwave. If greater than _shockInRadius, the shockwave expands outward. If less than _shockInRadius, the shockwave starts big and shrinks inward.
|-
| _shotRadius || 0.5 || For collision detection.
|-
| _shotRange || 350 || Range of shots, note that they can be cut short by _reloadTime.
|-
| _shotSpeed || 100 || Speed of shots.
|-
| _shotTailLength || 4 ||
|-
| _shotsKeepVerticalVelocity || 0 || If '''0''', shots always move straight in relation to the ground. If '''1''', shots are affected vertically by the tank's speed, and can fly up and down. Lasers are also affected.
|-
| _skyColor || white || Sets the sky to a specific color.
|-
| _srRadiusMult || 2 || Radius of steamroller effect.
|-
| _squishFactor || 1 || How much tanks squish when landing.
|-
| _squishTime || 1 || How much squishy time you get after falling to the ground.
|-
| _syncTime || 1 || Whether or not to sync the players time with the servers'.
|-
| _syncLocation || 0 || Whether or not to sync the location time with the servers'.
|-
| _tankAngVel || 0.785398 || How fast the tank can turn.
|-
| _tankExplosionSize || 3.5 * _tankLength || How large the tank's explosion is.
|-
| _tankHeight || 2.05 || The height of the tank.
|-
| _tankLength || 6 || The length of the tank.
|-
| _tankRadius || 0.72 * _tankLength || The radius of the tank.
|-
| _tankSpeed || 25 || The speed of the tank
|-
| _tankWidth || 2.8 || The width of the tank.
|-
| _targetingAngle || 0.3|| Something to do with GM...
|-
| _teleportBreadth || 4.48|| Random maps?
|-
| _teleportHeight || 10.08 || See _teleportBreadth.
|-
| _teleportTime || 1 ||
|-
| _teleportWidth || 1.12 || See _teleportHeight.
|-
| _thiefAdLife || 0.05 || The amount of time (in seconds) that a thief shot lasts.
|-
| _thiefAdRate || 12 || The amount of time (in seconds) that the Thief "shot" reloads.
|-
| _thiefAdShotVel || 8 || The speed of thief.
|-
| _thiefTinyFactor || 0.5|| Multiplied by the normal tank size to shrink a tank carrying the thief flag.
|-
| _thiefVelAd || 1.67 || Multiplied by _tankSpeed to determine how fast tanks holding the thief goes.
|-
| _thiefDropTime || reloadTime * 0.5 ||The amount of time you must wait to fire a shot after stealing a flag.
|-
| _tinyFactor || 0.4 || Multiplied by the normal tank size to shrink a tank carrying the tiny flag.
|-
| _trackFade || 3 || The amount of time (in seconds) before track marks fade.
|-
| _updateThrottleRate || 30 ||
|-
| _useLineRain || none || '''0''' Rain is not a vertical line<br>'''1''' Rain is vertical lines, smoothly shaded from _rainTopColor to _rainBaseColor
|-
| _useRainPuddles || none || '''0''' Rain does not create puddles<br>'''1''' Rain creates puddles
|-
| _useRainBillboards || none || '''0''' Rain is lines or polygons<br>'''1''' Rain is billboards, textured and look the same from all angles
|-
| _velocityAd || 1.5 || Multiplies _tankSpeed to determine the speed of a tank carrying the high speed (V) flag
|-
| _wallHeight || 3 * _tankHeight|| The outer wall height.
|-
| _weapons || 1 || Used with world weapons, '''0''' world weapons will not fire<br>'''1''' world weapons will fire
|-
| _wideAngleAng || 1.745329 || The viewing angle when a tank has the Wide Angle bad flag.
|-
| _wingsGravity || _gravity || How much gravity affects tanks with the WG flag.
|-
| _wingsJumpCount || 1 || The number of jumps a tank with the wings flag can do before returning to the ground.
|-
| _wingsJumpVelocity || _jumpVelocity || The initial velocity of a jump with wings, in [[world units]]/sec.
|-
| _wingsSlideTime || 0 || When in the air, the tanks will slide for this long.
|-
| _worldSize || 400 || The size of the world, this should not be set during play, as the walls will not move. Setting this larger will allow tanks to go outside the map, and setting it smaller will cause tanks to be kicked for leaving the world boundaries.
|}

[[Category:Server]]

World units

2007-09-18T22:46:01Z

DTRemenak: correct jump height and other numbers. include formula for calculating jump heights.

A world unit is the basic unit of measure when dealing with BZFlag. World units have no real-world counterpart, as they are a purely virtual concept, but they can be though of to be equivalent to about 1 meter in length if you assume a roughly real world sized [[tank]].

Many [[Server Variables]] are specified in terms of world units or world units per second.

== Some useful measures at default settings ==
<div align="center">
{| cellpadding="0" cellspacing="0" border="1" width="60%"
|-
|width="60%"|Jump height limit (next to impossible)
|width="20%"|See below
|width="10%"|18.42
|-
|Doable jump height
|See below
|17.0
|-
|Tank length
|_tankLength
|8.04
|-
|Tank width
|_tankWidth
|2.8
|-
|Tank height
|_tankHeight
|2.05
|-
|Barrel height
|_muzzleHeight
|1.57
|-
|Drivable bump height
|_bumpHeight
|0.33
|-
|}
</div>

== Calculating jump height ==
Jump height is determined by the gravity and jump velocity settings on the server (see [[Server Variables]] for details). Note that the jump velocity and gravity may be altered by flags including [[Low Gravity]] and [[Wings]].

:Max jump height = -(_jumpVelocity)<sup>2</sup> / (2 * (_gravity))

A typical BZFlag player can reliably jump a bit more than 90% of the maximum jump height.

[[Category:Map Making]]
[[Category:Concepts]]

Tank

2007-09-18T21:27:05Z

DTRemenak: /* History */

The tank is the primary avatar of the player in BZFlag.[[image:Blue_tank_small.png|right]]

==Overview==
The BZFlag tank model has been in the game since it's inception, and been an integral part of game play. The tank has received few graphical upgrades over the years, and looks today much the same as it has since the first version of the game.

The tank model is currently [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instruction in the [[BZFlag Source]] code. The model may not be changed externally with out modifications to the game client itself.

The tank model has been exported from the code, and can be found as a wavefront obj file at http://my.bzflag.org/resources/models/Tank.obj
This can be imported into most 3d modeling packages.

==Appearance==
The tank model has 7 different colors, or "skins", that it can appear in. The color of the tank results from the team in which the tank is playing, or some other game logic (such as Hunters and Rabbits in [[Rabbit Hunt]])
The 7 tank colors are as follows:
<gallery>
image:Red_tank.png‎|Red Team Tank
image:Blue_tank.png‎|Blue Team Tank
image:Green_tank.png‎|Green Team Tank
image:Purple_tank.png‎|Purple Team Tank
image:Black_tank.png‎|Rogue (black) Team Tank
image:Orange_tank.png‎|Hunter Team Tank
image:White_tank.png‎|Rabbit Team Tank
</gallery>

Depending on an individual client's graphical settings, the tank may have animated treads and spinning wheels. The tanks shown are the most basic version of the tank.

==Dimensions==
[[image:Tank_sizes.png|frame|right|Tank dimensions in [[World units|world units]]]]
The Tank is 8.04 [[World units|world units]] long, 2.8 [[World units|units]] wide, and 2.08 [[World units|units]] tall as shown in the image. The turret is 1.6 [[World units|world units]] from the ground, meaning that a tank can shoot over a box 1.5 [[World units|units]] high. If one assumes that one [[World units|world unit]] is equivalent to one real world meter, then the tank would be 26 feet 4.5 inches long, 9 feet 2 inches wide, and 6 feet 10 inches tall.

==History==
The tank model was originally created by [[Tamar Cohen]] for the first versions of BZFlag and has since been extended and modified by the BZFlag developers.

[[Category:Concepts]]
[[Category:Map Making]]

Sean Morrison

2007-09-17T22:41:50Z

DTRemenak: +cat

Sean Morrison aka, Brlcad or Learner is a developer and [[Project_Administrators|system administrator]] for the project.

[[Category:Developer]]

BZFlag 2.0.10

2007-09-17T21:44:47Z

DTRemenak: /* Proposed Names */ well, I like this one (credit to bryjen [and MP] though)

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

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

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

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

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

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

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