BZFlagWiki - User contributions [en]

Laser

2011-12-25T06:10:22Z

Yosef: eliminate some exclamation points, other grammar

[[Image:Laser.png|right|thumb|300px|A laser being fired and rebounding.]]
When carrying the Laser superflag, a tank will not shoot regular bullets, but instead a very long beam. Any tanks that come into contact with this beam will be destroyed, so it is useful for killing multiple tanks in one shot. The beam usually does not last for very long.

The Laser superflag can be used in many different ways. Lasers can be:
* Rebounded off many surfaces. If ricochet is enabled, a laser can [http://farm4.static.flickr.com/3172/2343441015_18ca5509ee_o.png ricochet off many surfaces to create a very complex beam]. This can be very powerful and kill many tanks, as the more the laser ricochets, the more likely a tank will fall in its path. However, if these kinds of attacks are not planned very well, the laser could end up hitting a teammate or even the tank that fired it.
* Fired through a teleporter to catch unsuspecting players.
* Used to "snipe". This involves using the binocular view (B on keyboard) and targeting unsuspecting players with laser.
* As a camping tool! Sitting in one spot and waiting for players to drive right where the laser will hit is possibly the most popular camping technique on BZFlag.

Players with the [[Cloaking]] superflag are unaffected by lasers. Many Cloaking flags are often added by map makers into a certain area to prevent camping with lasers in the area. Grabbing a Cloaking flag before driving through an area vulnerable to laser attacks is also a wise idea.

Laser

2011-12-25T06:08:28Z

Yosef:

[[Image:Laser.png|right|thumb|300px|A laser being fired and rebounding.]]
When carrying the Laser superflag, a tank will not shoot regular bullets, but instead a very long beam. Any tanks that come into contact with this beam will be destroyed, so it is useful for killing multiple tanks in one shot. The beam usually does not last for very long.

The Laser superflag can be used in many different ways. Lasers can be:
* Rebounded off many surfaces. If ricochet is enabled, a laser can [http://farm4.static.flickr.com/3172/2343441015_18ca5509ee_o.png ricochet off many surfaces to create a very complex beam]. This can be very powerful and kill many tanks, as the more the laser ricochets, the more likely a tank will fall in it's path. However, if these kinds of attacks aren't planned very well, the laser could end up hitting a teammate or even the tank that fired it!
* Fired through a teleporter to catch unsuspecting players.
* Used to "snipe". Using the binocular view (B on keyboard) and targeting unsuspecting players with laser is a powerful way to snipe.
* As a camping tool! Sitting in one spot and waiting for players to drive right where the laser will hit is possibly the most popular camping technique on BZFlag.

Players with the [[Cloaking]] superflag are unaffected by lasers! Many Cloaking flags are often added by map makers into a certain area to prevent camping with lasers in the area. Grabbing a Cloaking flag before driving through an area vulnerable to laser attacks is also a wise idea.

Single Player Mode

2011-12-14T16:35:28Z

Yosef: a few grammar edits

Single Player Mode is a term (misnomer) often used to describe the act of playing BZFlag on a local server using the computer-controlled player (bots) of a client. BZFlag itself is designed to be a multiplayer game.

=Overview=
Using bots on a local server is a way to play the game without an internet connection, or to gain experience in playing without the need for other human players. Bots are currently only run by the game client and can be run on any server. The term "Single Player Mode" is most commonly used to describe a single client that is logged in to a local server with a number of bots. It is mostly used to test maps, as the simple robots do not offer any real gameplay challenge.

Bots can be used on remote servers, but many of the owners of public servers do not allow bots to join with players. Use of bots on public servers is not recommended and can lead to being banned from the server.

=Starting a Single Player Session=
The basic idea behind starting a single player session is the following.
#Start a local server, ether by using the in-game menu, or via the command line.
#Start the game client using the '''-solo'' [[BZFS Command Line Options| command line option]].
#Join the local server using the client and begin play.

==Starting a local server==
The simplest way to start a local server is to use the in-game '''Start Server''' menu. This menu is found on the [[Join Game Menu]] at the very bottom. This menu gives a number of settings for the server, including shot counts, and world options such as [[jumping]] and [[ricochet]]. Specific flags or more advanced options can not be set via the '''Start Server''' menu.

To set additional options one must run [[BZFS]] manually and enter in a number of [[BZFS Command Line Options| command line options]]. See [[Creating A Server|creating a server]] for more options. To keep the server local, do not use the '''-public''' option.

==Starting the client with bots==
The game client must be started with a command-line option to enable bots. Bots can not be enabled from within the game menus.

===Linux and Unix===
On Linux or other Unix-like systems the game client can be started with command line options directly from the terminal.
{|
|
bzflag -solo ##
|}
Where <nowiki>##</nowiki> is the number of bots you want to run.

===Microsoft Windows===
Microsoft Windows users can follow the following steps to create a shortcut that starts the game client with bots.
# Locate the BZFlag shortcut installed in the programs section of the start menu.
# Drag the BZFlag shortcut with the right mouse button on to the desktop.
# Pick the "Copy here" item from the context menu that pops up when the drag is complete.
# Click on the Copied shortcut with the right mouse button and pick the "properties" item.
# Find the "Target" field in the shortcut properties window that is opened, and click in it.
# Use the right arrow key to find the end of the text in the target field. It will end in bzflag.exe".
# After the last quote(") add a space and then '''-solo''' <nowiki>##</nowiki>. Where <nowiki>##</nowiki> is the number of bots you wish to have.
# Save the changes by hitting the OK button at the bottom.

Running this shortcut will now start the server with bot support.

===Mac OS X===
The Mac OS X method for starting the game with bot support is the same as the Linux method, but the path to the bzflag client is required. If you installed BZFlag in your applications folder, then the command that needs to be typed into terminal will be along the lines of:
{|
|
/Applications/BZFlag.app/Contents/MacOS/bzflag -solo <nowiki>##</nowiki>
|}
Where <nowiki>##</nowiki> is the number of bots you want to run.

==Joining the Local Server==
Once the client is started with bot support you must do the following to join the local server
# Go to the Join Game menu.
# Enter "127.0.0.1" in the server name field. This is called "localhost".
# Enter "5154" in the port field.
# Choose the "Connect" item to join the server.

This will connect to the local server with the number of bots specified to with the '''-solo''' option.

=Autopilot=
The aforementioned bot method creates what may be called 'simple' bots, which simply shoot and attempt to dodge bullets.
A feature called autopilot, is activated when you press the "9" key on your keyboard while in-game, although as stated earlier, many servers do not allow this.
Some players may decide they want to open up 5 or 10 clients and place them on autopilot. When they do, it allows them to be able to jump, grab flags, and are slightly smarter than the 'simple' bots.

==See also==
[[Creating A Server]]

[[BZFS Command Line Options]]

[[Category:Concepts]]
[[Category:Client]]
[[Category:Tutorials]]

Tank

2011-12-14T16:30:57Z

Yosef:

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

==2.0.10 and earlier==
This Classic BZFlag tank model has been in the game since its inception, and is an integral part of game play. This tank model 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 classic tank model is [http://en.wikipedia.org/wiki/Hardcoded hard coded] as a series of [http://en.wikipedia.org/wiki/OpenGL OpenGL] instructions in the [[BZFlag Source]] code. The model may not be changed externally without modifications to the game client itself.

The 2.0.10 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 model is licensed under the LGPL as it is pulled from the bzflag sources.
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.

==Future Versions==
The tank model will most likely be redone for a future version. [[Image:3 0 tank test render.png]]

It will be an external loaded model and have the same basic dimensions as the older tank.

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

Network Protocol

2011-11-06T16:12:58Z

Yosef: minor edits - changed email to motto

{{Inaccurate}}
{{DesignDocument}}

= Introduction =

BZFlag uses standard IP (Internet) networking protocols. The code is written to the BSD socket interface, with adjustments for winsock on win32 platforms. Future revisions may centralize the network code into one file, behind a single class interface, to simplify porting to platforms without the BSD socket API.
Most communication is non-blocking. That is, reads and sends return immediately instead of waiting for data to become available or to be sent. That's important since BZFlag is a real-time game. It can't afford to get stuck waiting for a packet to come in. (The one exception to this is when BZFlag connects to a server, and this should get fixed someday.)
Communication is multiplexed using the select() call, which notifies the caller which sockets have data pending for read and/or are ready for sends. Instead of checking for incoming data by trying to read every socket and testing for success, we simply ask the system which sockets have data and read on those only. This also means that we use just a single thread for network communication.
BZFlag uses two distinct transport protocols to communicate with the server. Server communication uses TCP/IP for reliability. Live game data communication uses UDP for speed and efficiency. See the other pages for more details.

= Client/Server Communication =
The BZFlag server manages games. It is the judge and arbiter between clients. It manages game-global resources and information, such as flags and scores. It does not enforce game rules. Clients are trusted to follow the rules, saving the server the trouble of validating kills and client maneuvering.
For example, the server is not told of changes to a client's position on the game board. Therefore the server cannot enforce the rule that players can't drive through walls (without the OO or PH flags). This allows each client to run freely. If it had to wait for the server to okay each movement, it would be impossible to play BZFlag except on fast or dedicated networks.
Furthermore, clients inform the server when they've killed another client player. The server doesn't verify the kill was legal beyond checking to see if someone has already claimed a kill on the same player. If more than one player claims a kill or tries to grab a particular flag, the server decides which player gets the kill or the flag.
Client/server communication is mostly limited to those messages that must be successfully delivered. These include, among others, notifications of players coming alive or being killed, notifications of shots being fired, flags coming or going or being grabbed or dropped.
Client/server communication in BZFlag is through TCP. TCP has the advantages of being bidirectional, reliable, and sequential. Bidirectional means each side of the connection can send to the other. Reliable means that each message will be delivered to the destination. Sequential means that messages (on a particular connection) will be received in the order they were sent.
The main disadvantage of TCP is that it's slow. Reliability may require a given message to be sent several times, until the receiver acknowledges its receipt. While delays can cause problems, there really isn't a way around it. Messages between the client and server are specifically those messages that must not be lost. If we didn't use TCP we'd simply have to implement something that did the same thing, and which would necessarily suffer from the same drawbacks.
There are some instances where client/server communication doesn't use TCP. One example is client attempts to locate servers on the network. Clients send broadcast `pings' which the servers listen for and respond to in kind. These messages are not part of normal game communication.

= Client/Client Communication =
BZFlag clients send certain information to other clients during a game. This information includes: status, position, orientation, and linear and angular velocity. This state can change quickly and getting it late is no better than not getting it at all. So client-to-client packets are sent using UDP, a datagram protocol.
UDP is unreliable, meaning that packets are not guaranteed to be delivered. It's also connectionless, meaning we don't even know if anybody is listening for the message. However, it's also fast because it's so simple. UDP suits our needs because: we need fast delivery; we don't care if a message is lost because another will arrive shortly afterwards; and we don't care if the receiver isn't listening.
BZFlag clients need to send their information to all the other clients. There are several ways to do this. First, each client can send each message to all the other clients. If there are N clients then each message is sent N-1 times. Traffic grows as the square of clients. This is slow and wasteful.
Alternatively, each client can send all messages to one special computer (for example, the server) and that computer can forward the messages to all the other players. This makes life easier on the clients and much harder on the server. It also delays the delivery of each message. And traffic from the server still grows as N squared (though traffic to the server grows linearly).
Another possibility is to broadcast messages. A broadcast message is sent once and received by all computers on a subnet. This scales linearly and minimizes network traffic but broadcast traffic is never routed outside the subnet, so it means only clients on the same subnet of the same local area network could play together.
BZFlag uses the second technique, using the server as a relay system. The server uses the TCP client/server connection to send client traffic that must be reliable and UDP for information that must be timely but does not need to be reliable.

= Protocol =
--> means from client to server
<-- means from server to client

All multi-byte data is in network byte order (aka big endian); that is, the most significant byte comes first followed by successively less significant bytes.
All numbers are integers unless otherwise specified. Integers can be 8, 16, or 32 bit signed 2's compliment or unsigned (encoding is the same in regardless of signed status). Values in this document in byte boxes are given in hexadecimal. Values in the text are given in decimal unless otherwise noted.
Bit fields are encoded as unsigned integers. All floating point numbers are in standard IEEE-754 single precision format. Multi-byte values are *not* necessarily aligned on 2 or 4 byte boundaries.
A client normally follows the following sequence during game play: connect to server get the world database join the game send/receive game messages leave game disconnect from server
common message structures ------------------------- Most messages begin with the length of the message in bytes followed by a 16 bit code. The length is 16 bits and excludes itself and the code, so it's the actual length of the message minus 4.

Player identifiers are 1 byte and are used in many messages.

0 - 243 : Regular Players
244 - 250 : Special Team Ids
251 - 252 : Unused IDs
253 : ServerPlayer (World weapons, etc)
254 : All Players
255 : No Player (Invalid Player)

Flag status is common to a few message types:

u16 flag id
u16 status
u16 type
u8 owner id
float position (x)
float position (y)
float position (z)
float launch (x)
float launch (y)
float launch (z)
float landing (x)
float landing (y)
float landing (z)
float flight time
float flight end time
float initial velocity

`Position,' `launch,' `landing,' `flight time,' `flight end,' and `initial velocity' are all floating point numbers. `Flag id' is the type of flag,enumerated in FlagId.

`Status' gives the current location of the flag:
FlagNoExist -- the flag is not active (i.e. not in the game)
FlagOnGround -- the flag is sitting on the ground ready to get picked up
FlagOnTank -- the flag is on a player's tank
FlagInAir -- the flag is in the air and will fall back down
FlagComing -- the flag just appeared and is falling to the ground
FlagGoing -- the flag was thrown in the air and is disappearing

`Type' indicates the behavior of the flag: FlagNormal means the flag is permanent and can be dropped normally (e.g. a team flag); FlagUnstable means the flag may disappear after use (e.g. a good super flag); FlagSticky means the flag cannot be dropped normally (e.g. a bad super flag).
`Player id' indicates which player has the flag when `status' is FlagOnTank. It isn't used for any other status.
`Position' is the location of the flag on the ground. It only has meaning when `status' is FlagOnGround. The position of a flag when on a tank is the position of the tank (centered on and at the top of the tank)
`Launch' is the location of the flag where it was thrown in the air. `Landing' is the location where the flag will/would touch ground. These are used when `status' is FlagInAir, FlagComing, and FlagGoing. The client should make the flag follow a reasonable flight path (e.g. a parabolic arc) from `launch' to `landing.'
`Flight time' is the time elapsed since the flag was thrown into the air. `Flight end' the time when the flag will reach the ground. `Initial velocity' gives the vertical (z) velocity of the flag when launched. The vertical position of the flag at time t (ranging from 0 to `flight end') is: z = z0 + v * t + 0.5 * g * t * t. z0 = `launch z;' v = `initial velocity;' g = acceleration due to gravity.

== Connecting to a server ==
The [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/misc/bzfquery.php bzfquery.php script] is a nice example of how to connect to a server.

At the beginning you need to open a socket. Beginning with protocol 0048 you need to send "BZFLAG\r\n\r\n" in order to get any reply. At that time you unfortunately don't know the protocol, so send it by default or your client will probably freeze.

--> connect(server port)
--> +----+----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 4C | 41 | 47 | 0D | 0A | 0D | 0A | BZFLAG\r\n\r\n
+----+----+----+----+----+----+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 53 | 31 | 39 | 31 | 30 | FF | BZFS1910 FF
+----+----+----+----+----+----+----+----+----+

Client should verify the version. In old versions the first four bytes indicates a BZFlag server, the next byte indicates the major version number (as an ASCII digit), the two bytes after that are the minor version number (as ASCII digits), and the 7th byte is the revision. Major and minor version number changes indicate incompatible protocol changes. Different revisions of a given version are compatible and usually just indicate client user interface changes. A following FF ends the packet. In new versions the protocol is just a number increased by 1 when the protocol changes.

If the reply was a protocol older than 0048 then bzfs will kick the client connecting to it. In this case we recommend a fallback, not sending BZFLAG\r\n\r\n during connection try:

--> connect(server port)
<-- +----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 53 | 31 | 39 | 31 | 30 | FF | BZFS1910 FF
+----+----+----+----+----+----+----+----+----+

Server owners will see something like the following in the logs if their server(s) use a protocol older than 0048:
Player [0] sent huge packet length (len=16986), possible attack
Player [0] removed at 2007-04-11 15:52:55: large packet recvd

== Message types ==
Read this with caution, as it is very old information not reflecting the current status.

=== Negotiating world flags ===

--> +----+----+----+----+----+----+----+----+----+----+
| length | 6E | 66 | FlagID1 | FlagID2 | ....... | MsgNegotiateFlags
+----+----+----+----+----+----+----+----+----+----+ (List of client flag ids)
<-- +----+----+----+----+----+----+----+----+----+----+
| length | 6E | 66 | FlagID1 | FlagID2 | ....... | MsgNegotiateFlags
+----+----+----+----+----+----+----+----+----+----+ (List of server flag ids, that client doesn't know)

Client sends to the server the two byte representation of all flags known to the client. In the case that a flag is only one letter, (N) for instance, the second byte is null. Otherwise, the null byte is implied at position 3. The server upon receipt of this list, finds all flags that are used by the server, but not known by the client, and sends this list to the client. The client upon receipt of the list, either disallows play, if flags exist, or continues if the list is empty.

=== getting the world hash ===
--> +----+----+----+----+
| 00 | 00 | 77 | 68 | MsgWantWHash
+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+
| length | 77 | 68 | world hash data... | MsgWantWHash
+----+----+----+----+----+----+----+----+

To improve performance World (bzc) files are cached on the client. The name of the cache file is an md5 hash of the file that is computed on the server. this hash is sent to the client, and the client looks for a file by that name in the bz world cache directory. If the hash starts with a 't', the world is a random world. If the hash starts with a 'p' the world is from a world file. If the client can find the file locally, it does not sent the following MsgGetWorld packet.

=== getting the world database ===
--> +----+----+----+----+----+----+
| 00 | 02 | 67 | 77 | offset | MsgGetWorld
+----+----+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+
| length | 67 | 77 |remaining| data... | MsgGetWorld
+----+----+----+----+----+----+----+----+
or
+----+----+----+----+
| 00 | 00 | 73 | 6b | MsgSuperKill
+----+----+----+----+

Client sends MsgGetWorld requests until it has read the entire world database. Clients should send an `offset' of 0 for the first request and increase `offset' by however much data was sent in reply. Each MsgGetWorld reply includes the number of bytes left after the returned block of data in `remaining'. The server returns 0 in `remaining' when there is no more data left to read. In no event will the server return more than MaxPacketLen - 6 bytes of data in one reply (see protocol.h for the definition of MaxPacketLen). The server may return MsgSuperKill at any time during the download of the world database. The client should immediately close the connection to the server. No other messages should be returned by the server as long as the client sends only MsgGetWorld requests.

The `data' has the following encoding:

+----+----+----+----+
| 00 | 1E | 73 | 74 | length of data, WorldCodeStyle
+----+----+----+----+----+----+
| version | worldsize |
+----+----+----+----+----+----+----+----+
| style | mxPlyrs | mxShots | mxFlags |
+----+----+----+----+----+----+----+----+
|linear acceleration|angulr acceleration|
+----+----+----+----+----+----+----+----+
| shake t | shake w | epoch offset |
+----+----+----+----+----+----+----+----+

Values are:
version: version of the bzw format
worldsize: size in meters of world
style: bitfield of game style
maxPlayrs: maximum number of players
maxShots: maximum number of shots at once per player
maxFlags: maximum number of flags that may exist at once
linear acc.: linear acceleration limit (float)
angulr acc.: angular acceleration limit (float)
shake t: time to shake a bad flag (1/10ths of seconds)
shake w: number of wins to shake a bad flag
epoch offset: seconds since midnight Jan 1, 1970 GMT on the server, used when
synchronizing times across clients

The rest of the world database is encoded in individual blocks describing each object. Only permanent immovable objects are included. The encodings for each type of object are:

team base:
+----+----+----+----+
| 00 | 2A | 62 | 61 | length of base data, team code
+----+----+----+----+----+----+
| team id | center (x) |
+----+----+----+----+----+----+----+----+
| center (y) | center (z) |
+----+----+----+----+----+----+----+----+
| angle | size (x) |
+----+----+----+----+----+----+----+----+
| size (y) | size (z) |
+----+----+----+----+----+----+----+----+
| safety (x) | safety (y) |
+----+----+----+----+----+----+----+----+
| safety (z) |
+----+----+----+----+

wall:
+----+----+----+----+
| 00 | 18 | 77 | 6C | length of wall data, wall code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle... |
+----+----+----+----+----+----+----+----+
| width | height |
+----+----+----+----+----+----+----+----+

pyramid:
+----+----+----+----+
| 00 | 1D | 70 | 79 | length of pyramid data, pyramid code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | sdf|
+----+----+----+----+----+

box:
+----+----+----+----+
| 00 | 1D | 62 | 78 | length of box data, box code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | sdf|
+----+----+----+----+----+

teleporter:
+----+----+----+----+
| 00 | 21 | 74 | 65 | length of teleporter data, teleporter code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | border |
+----+----+----+----+----+----+----+----+
| sdf|
+----+

teleporter link:
+----+----+----+----+
| 00 | 04 | 6C | 6E | length of link data, link code
+----+----+----+----+
| from | to |
+----+----+----+----+
end of data:
+----+----+----+----+
| 00 | 00 | 65 | 64 | length of worldcodeend data, worldcodeend code
+----+----+----+----+

The above values are interpreted as follows:

angle (float): in radians from the x-axis in the xy plane
width (float): half width (in xy) measured from center
depth (float): half depth (in xy) measured from center
height (float): full height (in z) measured from bottom
border (float): full size of the square cross section teleporter border
center (float): center in xy, bottom in z
safety (float): safety position for team flags, used when team A drops team B's
flag on team C's base.
from & to: index of teleporter face starting from zero; the N'th teleporter
in the world data has face indices 2*N and 2*N+1. teleporter
links indicate which face teleports to which face; faces may
teleport to themselves.
sdf (byte): bit mask:
drive through is bitmask 0x01
shoot through is bitmask 0x02

== join game ==
Once connected a player normally requests to join the game. The server replies with
MsgSuperKill, MsgReject, or MsgAccept.

--> +----+----+----+----+----+----+----+----+
| length | 65 | 6e | player id... MsgEnter
+----+----+----+----+----+----+----+----+
| type | team |
+----+----+----+----+----+----+----+----+
| call sign (CallSignLen bytes)...
+----+----+----+----+----+----+----+----+
...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
| email address (EmailLen bytes)...
+----+----+----+----+----+----+----+----+
...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
<-- +----+----+----+----+
| 00 | 00 | 61 | 63 | MsgAccept
+----+----+----+----+
or
+----+----+----+----+----+----+
| 00 | 02 | 72 | 6a | code | MsgReject
+----+----+----+----+----+----+
or
+----+----+----+----+
| 00 | 00 | 73 | 6b | MsgSuperKill
+----+----+----+----+

`Type' is one of the enumerations in PlayerType and `team' is one from TeamColor.
The call sign is the player's `handle' during the game; the call sign is used
to identify the player. No attempt is made by the server to prevent the
duplication of call signs during a game. The motto can be anything,
including the email address for human players (e.g. username@hostname).
BZFlag players can choose `anonymous' instead of their motto. The call
sign and email address should be NUL terminated ASCII strings, padded with
NUL's to the required length. `Length' is 12 + CallSignLen + EmailLen.

If the server responds with MsgSuperKill the client should close the connection
immediately. If the server responds with MsgReject, the client has not joined the
game but may keep the server connection open and try again. The reason for rejection
is included with the MsgReject message:

RejectBadRequest -- bogus data in MsgEnter
RejectBadTeam -- invalid team id
RejectBadType -- invalid client type
RejectTeamFull -- no more players allowed on team
RejectServerFull -- no more players allowed on any team

If the server responds with MsgAccept, the player has successfully joined the game.
The server then automatically sends updates about each flag, team, and player. The
client should be prepared to accept these updates in any order. The flag and team
updates are sent as MsgFlagUpdate and MsgTeamUpdate messages, respectively. Player
updates are sent as MsgAddPlayer messages. The client will receive a MsgAddPlayer
for the player it just added, but only after it has received a MsgAddPlayer for each
of the players already joined.

Until it receives the MsgAddPlayer for the player it just added, the client will
only receive the following kinds of messages:

MsgSuperKill
MsgFlagUpdate
MsgTeamUpdate
MsgAddPlayer

Players of type ComputerPlayer are not sent team or flag updates and only get the
MsgAddPlayer for themselves. This probably wasn't a good idea, but there it is.

== Leave game ==
Once entered, a player can leave the game at any time. This should be done by sending
the following message, then closing the connection:

--> +----+----+----+----+
| 00 | 00 | 65 | 78 | MsgExit
+----+----+----+----+

There is no reply. Clients can also leave by simply closing the connection, but
sending MsgExit first is recommended.

== During a game ==
There are several types of messages that are delivered at any time after a player
enters a game. Clients must be prepared to handle them in any order.

MsgSuperKill
<-- +----+----+----+----+
| 00 | 00 | 73 | 6b |
+----+----+----+----+
Client must immediately disconnect from the server.

MsgTimeLeft
<-- +----+----+----+----+----+----+
| 00 | 02 | 74 | 6f |time left|
+----+----+----+----+----+----+
Gives the time remaining in the game. This message is only sent when the
server has time limit configured. If the time remaining is zero, the client
should indicate to the player that the game is over.
`Time left' is in seconds. It is not sent every second so clients will need
to do their own count down between messages.

MsgScoreOver
<-- +----+----+----+----+----+----+----+----+
| 00 | 0a | 73 | 6f | player id...
+----+----+----+----+----+----+----+----+
| team id |
+----+----+----+----+----+----+
Gives the player or team that won the game by reaching the target score.
This message is only sent when the server has a target score configured.
The client should indicate which team or player won and that the game is
over.

If `team id' is NoTeam then `player id' indicates which player has won.
Otherwise `team id' indicates which team won.

MsgAddPlayer
<-- +----+----+----+----+----+----+----+----+
| length | 61 | 70 | player id...
+----+----+----+----+----+----+----+----+
| type | team |
+----+----+----+----+----+----+----+----+
| wins | losses | call sign...
+----+----+----+----+----+----+----+----+
... (CallSignLen bytes)... |
+----+----+----+----+----+----+----+----+
| email address...
+----+----+----+----+----+----+----+----+
... (EmailLen bytes)... |
+----+----+----+----+----+----+----+----+
Sent when another player enters the game and when joining a game if other
players are already joined. `Type' is enumerated in PlayerType, `team'
is enumerated in TeamColor. `Wins' and `losses' give the player's score.
They are unsigned integers; the player's score equals wins minus losses.
`Call sign' and `email address' are NUL terminated ASCII strings. `Length'
is 16 + CallSignLen + EmailLen.

MsgRemovePlayer
<-- +----+----+----+----+----+----+----+----+
| 00 | 08 | 72 | 70 | player id...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+
Sent when another player leaves the game.

MsgFlagUpdate
<-- +----+----+----+----+----+----+----+----+
| 00 | 40 | 66 | 75 |flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | player id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent when a flag's state changes. Also sent to a client when it enters
a game. `Flag num' is the index of the flag. Flags are indexed from
zero up to the maximum number of flags minus one.

Clients must update the flag positions while the flag is in flight (i.e.
`status' is FlagInAir, FlagComing, or FlagGoing. If FlagInAir or
FlagComing then the client should change the flag's status to
FlagOnGround when the flag's flight time equals or exceeds `flight end.'
The position should be set exactly to `landing.' If FlagGoing, the
client should change the flag's status to FlagNoExist when the flight
time equals or exceeds `flight end.'

BZFlag uses the first half of the flight time for FlagComing and the
last half of the flight time for FlagGoing to make the flag appear or
disappear from/to nothing. This allows players to adjust to the
appearance/disappearance of a flag.

MsgTeamUpdate
<-- +----+----+----+----+----+----+----+----+
| 00 | 0a | 74 | 6f | team | size |
+----+----+----+----+----+----+----+----+
| active | wins | losses |
+----+----+----+----+----+----+
Gives the current state of team `team.' `Size' is the number of
players on the team. `Active' is the number of active players on the
team. An active player is one that can participate in the game (e.g.
grab flags, shoot opponents, etc.); a non-active player can only
observe the game. Only active players are considered when deciding
if there are any players on a team (to decide if the team flag should
be inserted or withdrawn from the game). `Wins' and `losses' give the
team's score (wins minus losses).

MsgAlive
<-- +----+----+----+----+----+----+----+----+
| 00 | 20 | 61 | 6c | player id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| forward (x) | forward (y) |
+----+----+----+----+----+----+----+----+
| forward (z) |
+----+----+----+----+
Sent when a player comes alive. A player that has joined is not on the
game board until it sends this message, which declares that it is in
game and gives the starting position and orientation. Players are removed
from the game board when killed and do not reappear until sending this
message again.

--> +----+----+----+----+----+----+----+----+
| 00 | 18 | 61 | 6c | position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| forward (x) | forward (y) |
+----+----+----+----+----+----+----+----+
| forward (z) |
+----+----+----+----+
A player sends this message to enter the game board. Note that this
version of the message differs from the one sent by the server in that
it lacks the player id (which is implicit in the server connection).
Players must send this message to change their state from dead to alive.
Players should not send MsgAlive for a certain penalty period after
being killed (but the server does not enforce a minimum time). The
currently penalty is ExplodeTime.

`Position' gives the location of the player and `forward' gives the
player's forward direction vector.

MsgKilled
<-- +----+----+----+----+----+----+----+----+
| 00 | 12 | 6b | 6c | victim id...
+----+----+----+----+----+----+----+----+
| killer id...
+----+----+----+----+----+----+----+----+
| shot id |
+----+----+----+----+----+----+
Sent by the server when a player is killed by itself or another player.
The victim id is the player that was destroyed and the killer id is the
player credited with the kill. Shot id identifies which of the killer's
shots hit the victim; if the shot isn't a laser or shockwave, other
players may assume the shot has stopped and needn't check themselves
against the shot (or they can wait until the MsgShotEnd message arrives).

--> +----+----+----+----+----+----+----+----+
| 00 | 0a | 6b | 6c | killer id...
+----+----+----+----+----+----+----+----+
| shot id |
+----+----+----+----+----+----+
Sent by the victim when it detects that it's been hit, naming the killer
and which of the killer's shots was the one that hit. Note that the
server does not verify kills in any way so it's trivial to `cheat' by
claiming you've been killed; this is generally unproductive. It's
also easy to cheat by never sending MsgKilled, making you almost
immortal. Don't do this.

MsgGrabFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 48 | 67 | 66 | grabber id...
+----+----+----+----+----+----+----+----+
|flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | owner id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent by the server when a player is allowed to grab a flag. This is
both the notice to the player trying to grab the flag that it succeeded
and the notice to all other players that the flag was grabbed. Note
that `grabber id' is redundant; it's always equal to `owner id.'

`Flag num' is the index of the flag. Flags are indexed from zero up to
the maximum number of flags minus one.

--> +----+----+----+----+----+----+
| 00 | 02 | 67 | 66 |flag num |
+----+----+----+----+----+----+
Sent by a player when it wants to grab a flag. Players should only
send this message when their tank is within FlagRadius of a flag (that's
any part of the tank, not simply the center) and on the ground. The
server will not verify this, but it will verify some other stuff. The
player must not assume it will be able to grab the flag. Instead it has
to wait for a MsgGrabFlag reply.

MsgDropFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 48 | 64 | 66 | dropper id...
+----+----+----+----+----+----+----+----+
|flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | owner id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent by the server when a player is allowed to drop a flag. This is
both the notice to the player trying to drop the flag that it succeeded
and the notice to all other players that the flag was dropped. `Owner
id' is meaningless in this message.

`Flag num' is the index of the flag. Flags are indexed from zero up to
the maximum number of flags minus one.

--> +----+----+----+----+----+----+----+----+
| 00 | 0c | 64 | 66 | position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
Sent by a player when it wants to drop a flag. Players should only
send this message when they have a flag and only when the flag dropping
constraints have been met (i.e. the flag can be dropped at any time, or
the player got the antidote flag, etc.) The player must not assume it
has dropped the flag until it receives a MsgDropFlag in response.

`Position' is in floating point and is the position of the tank that
dropped the flag when it was dropped.

MsgCaptureFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 63 | 66 | capturer id...
+----+----+----+----+----+----+----+----+
|flag num | team id |
+----+----+----+----+----+----+----+----+
Sent by the server when a team's flag has been captured. `Capturer id'
is the player who captured the flag. `Flag num' is the index of the
captured flag. Flags are indexed from zero up to the maximum number of
flags minus one. `Team id' is the id of the team who's flag was
captured. Note that the player who captures the flag may be on the team
that was captured.

The server makes all players on the captured team dead. This message is
the only notice that the players are now dead so clients should act
accordingly. This is also the only notice that the capturer is no longer
carrying a flag.

--> +----+----+----+----+----+----+
| 00 | 02 | 63 | 66 | team id |
+----+----+----+----+----+----+
Sent by a player when it captures a team flag. `Team id' is the id of
the team who's flag was captured. The player should wait until the
server sends back the MsgCaptureFlag response before assuming the
capture was successful. A player should send this message only when
1) its tank is at least halfway inside a team base, 2) the tank is on
the ground, and 3) the player has its own team flag in an enemy base
or the player has another team's flag in its own base. Note that the
server will not enforce any of these requirements.

MsgShotBegin
<--
--> +----+----+----+----+----+----+----+----+
| 00 | 2c | 73 | 62 | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | time
+----+----+----+----+----+----+----+----+
|flag type| lifetime |
+----+----+----+----+----+----+----+----+
Sent by the server when a player has fired a shot. The identical message
is send by a player when it fires a shot. The server does not verify
that the player is allowed to fire a shot.

`Shooter id' identifies the player that did the shooting. `Shot id' is
a number that uniquely identifies to the shooter which shot this is.
`Position,' `velocity,' `time,' and `lifetime' are floating point
numbers. `Position' is the starting position of the shot. `Velocity'
is the starting velocity of the shot. `Time' is the time the shot has
existed (probably 0.0). `Lifetime' is how long the shot exists. `Flag
type' is a FlagId and is the type of flag the shooter had when the shot
was fired.

Clients are expected to compute the flight path of shots (except Guided
Missiles) given the information in MsgShotBegin. That includes handling
ricochets, building impacts, and teleportation, but not tank impacts.
Each player decides if it itself has been hit by a shot at each time step
based on this flight path. Since the path of a guided missile cannot be
predicted, updates to a guided missile's path is sent throughout its
flight by the shooter via MsgGMUpdate messages.

A player should test itself against a shot using whatever algorithm it
likes, but at a minimum should test the line segments the shot moves
along during the time step against a tank aligned bounding box.
Accounting for the linear motion of the tank over the time step is
better and accounting for both the linear and angular motion is better
still. Note that the shot has a certain radius that should be taking
into account during intersection testing. This is particularly
important when testing against a tank with the narrow flag. Ideally,
the shot would be exactly tested against the tank geometry. However,
that's more work than realistically necessary.

MsgShotEnd
<--
--> +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 65 | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | reason |
+----+----+----+----+----+----+----+----+
Sent by the server when a shot has been terminated before its lifetime
has expired. The identical message is sent by the player that
terminates the shot. This is normally the player that has just been
hit by the shot. The server does not verify that the player has or
has not been hit. This message is also sent by the player that fired
a guided missile when the shot hits the ground or a building (note that
guided missiles don't ricochet).

`Shooter id' identifies the player that fired the shot and `shot id'
is the same as in the MsgShotBegin message for the shot. `Reason' is
one if the other players should show an explosion for the shot and
zero otherwise.

MsgScore
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 63 | player id...
+----+----+----+----+----+----+----+----+
| wins | losses |
+----+----+----+----+----+----+----+----+
Sent by the server when a player's score changes. `Player id' is the
player with the new score, and `wins' and `losses' are the new scores.

--> +----+----+----+----+----+----+----+----+
| 00 | 04 | 73 | 63 | wins | losses |
+----+----+----+----+----+----+----+----+
Sent by a player when its score changes.

MsgTeleport
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 63 | player id...
+----+----+----+----+----+----+----+----+
| from | to |
+----+----+----+----+----+----+----+----+
Sent by the server when a player teleports. `From' is the index of the
teleporter face the player entered and `to' is the index of the face
the player exited.

--> +----+----+----+----+----+----+----+----+
| 00 | 04 | 73 | 63 | from | to |
+----+----+----+----+----+----+----+----+
Sent by a player when it passes through a teleporter.

MsgMessage
<-- +----+----+----+----+----+----+----+----+
| length | 6d | 67 | from player id...
+----+----+----+----+----+----+----+----+
| to player id...
+----+----+----+----+----+----+----+----+
| team |message...
+----+----+----+----+----+----+----+----+
...(MessageLen bytes)...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
Sent by the server when one player sends a message to others. `Length'
is the length of the message (18 + MessageLen bytes). `From player id'
is the player sending the message, `to player id' is the player to
receive the message, and `team' is the team to receive the message.
If `to player id' is all zeros then the message is being sent to
everyone on `team'. If `to player id' is all zeros and `team' is
RogueTeam then the message is being sent to all players. If `to player
id' is not all zeros then `team' is ignored and the message is only for
the identified player.

--> +----+----+----+----+----+----+----+----+
| length | 6d | 67 | player id...
+----+----+----+----+----+----+----+----+
| team |message...
+----+----+----+----+----+----+----+----+
...(MessageLen bytes)...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
Sent by player to send a message to other players. `Length' is is the
length of the message (10 + MessageLen bytes). `Player id' is the
player to receive the message (or all zeros for all players on the
given team) and `team' is the team to receive the message (or
RogueTeam for all teams).

MsgPlayerUpdate
+----+----+----+----+----+----+----+----+
| 00 | 2a | 70 | 75 | player id...
+----+----+----+----+----+----+----+----+
| status | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | azimuth
+----+----+----+----+----+----+----+----+
| angular velocity |
+----+----+----+----+----+----+
Sent by players to notify other players of changes in its status,
position, or velocity.

`Status' is the tank's current status. See PlayerStatus for the
meaning of the bit field's bits. The FlagActive bit indicates whether
the player's flag's special powers are active or not. The Phantom
Zone flag is an example of a flag that's active only some of the time.
The CrossingWall bit indicates if the player's tank is intersected by
a wall or teleporter; other players can use this to draw the player
in some special way. CrossingWall could be computed by each player
from other information; it's only provided to save the other players
the trouble.

`Position,' `velocity,' `azimuth,' and `angular velocity' are floating
point numbers. `Azimuth' is the orientation of the tank in radians
(the +x axis is 0.0, +y is pi/2). `Angular velocity' is the change in
azimuth per second. `Position' is the tank position and `velocity' is
the change in tank position per second.

A player normally only sends an update when its position or orientation
as could be predicted by other players differs from its true position
or orientation by a certain tolerance. Other players are expected to
use the last known player data to extrapolate the current position and
orientation. This technique is known as dead reckoning and has two
primary benefits: network traffic is decreased since updates needn't
be sent continuously and players on systems with slower frame rates
appear to move smoothly to players on systems with faster frame rates.

Players that fail to send updates often enough should be considered
to be not responding. Unresponsive players should be ignored until
they start responding again.

MsgGMUpdate
+----+----+----+----+----+----+----+----+
| 00 | 2e | 67 | 6d | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | time
+----+----+----+----+----+----+----+----+
| target id....
+----+----+----+----+----+----+----+----+
|
+----+----+
Sent by players with active guided missiles to notify other players
of changes to the motion of the guided missile.

See MsgShotBegin for the meaning of most items. `Time' is the current
age of the shot (the time since being fired). `Target id' is the
current target of the guided missile or all zeros if there is no target.

Players are expected to use dead reckoning to update the position and
velocity of guided missiles between MsgGMUpdate messages. Since
guided missiles deviate from their predicted course only when the
target changes, these message will be fairly rare. Note that different
players may have different ideas of where the target is and that that
may cause slightly different courses. This is generally not a problem.

MsgLagPing
+----+----+----+----+----+----+
| 00 | 02 | 70 | 69 | seq. no.|
+----+----+----+----+----+----+
Sent by the server to active players every 10s to measure lag. The
client just echoes the message back to the server. The time
between sending and receiving the message in the server is
considered to be the current lag of the respective player.

The two byte sequence number is included to be able to deal with
lost or severely delayed messages. On each ping sent by the server,
the sequence number is incremented (modulo 10000). The server
manages this number on a per player basis.

MsgReplayReset
+----+----+----+----+----+
| 00 | 01 | 72 | 72 | lp |
+----+----+----+----+----+
Sent by the server to active replay observers to remove state
information that they might have regarding players and flags.
The 'lp' value is the last player to be removed. PlayerId's above
'lp' are replay observers, and are not removed.

== UDP negotiation ==

*solo bots don't do this, they should use the existing player's connection

*MsgUDPLinkRequest = 0x6f66; // 'of'

*MsgUDPLinkEstablished = 0x6f67; // 'og'

*if client has udp enabled player sends MsgUDPLinkRequest with player number over udp

*if request has valid player number and is from same address server sends MsgUDPLinkEstablished over tcp to confirm inbound server sends MsgUDPLinkRequest back over udp to test outbound

*player gets MsgUDPLinkEstablished and starts sending udp

*player gets MsgUDPLinkRequest and sends MsgUDPLinkEstablished over udp

*server gets MsgUDPLinkEstablished
server can now send over udp

[[Category:Concepts]]

Network Protocol

2011-11-06T16:05:35Z

Yosef: /* Introduction */

{{Inaccurate}}
{{DesignDocument}}

= Introduction =

BZFlag uses standard IP (Internet) networking protocols. The code is written to the BSD socket interface, with adjustments for winsock on win32 platforms. Future revisions may centralize the network code into one file, behind a single class interface, to simplify porting to platforms without the BSD socket API.
Most communication is non-blocking. That is, reads and sends return immediately instead of waiting for data to become available or to be sent. That's important since BZFlag is a real-time game. It can't afford to get stuck waiting for a packet to come in. (The one exception to this is when BZFlag connects to a server, and this should get fixed someday.)
Communication is multiplexed using the select() call, which notifies the caller which sockets have data pending for read and/or are ready for sends. Instead of checking for incoming data by trying to read every socket and testing for success, we simply ask the system which sockets have data and read on those only. This also means that we use just a single thread for network communication.
BZFlag uses two distinct transport protocols to communicate with the server. Server communication uses TCP/IP for reliability. Live game data communication uses UDP for speed and efficiency. See the other pages for more details.

= Client/Server Communication =
The BZFlag server manages games. It is the judge and arbiter between clients. It manages game-global resources and information, such as flags and scores. It does not enforce game rules. Clients are trusted to follow the rules, saving the server the trouble of validating kills and client maneuvering.
For example, the server is not told of changes to a client's position on the game board. Therefore the server cannot enforce the rule that players can't drive through walls (without the OO or PH flags). This allows each client to run freely. If it had to wait for the server to okay each movement, it would be impossible to play BZFlag except on fast or dedicated networks.
Furthermore, clients inform the server when they've killed another client player. The server doesn't verify the kill was legal beyond checking to see if someone has already claimed a kill on the same player. If more than one player claims a kill or tries to grab a particular flag, the server decides which player gets the kill or the flag.
Client/server communication is mostly limited to those messages that must be successfully delivered. These include, among others, notifications of players coming alive or being killed, notifications of shots being fired, flags coming or going or being grabbed or dropped.
Client/server communication in BZFlag is through TCP. TCP has the advantages of being bidirectional, reliable, and sequential. Bidirectional means each side of the connection can send to the other. Reliable means that each message will be delivered to the destination. Sequential means that messages (on a particular connection) will be received in the order they were sent.
The main disadvantage of TCP is that it's slow. Reliability may require a given message to be sent several times, until the receiver acknowledges its receipt. While delays can cause problems, there really isn't a way around it. Messages between the client and server are specifically those messages that must not be lost. If we didn't use TCP we'd simply have to implement something that did the same thing, and which would necessarily suffer from the same drawbacks.
There are some instances where client/server communication doesn't use TCP. One example is client attempts to locate servers on the network. Clients send broadcast `pings' which the servers listen for and respond to in kind. These messages are not part of normal game communication.

= Client/Client Communication =
BZFlag clients send certain information to other clients during a game. This information includes: status, position, orientation, and linear and angular velocity. This state can change quickly and getting it late is no better than not getting it at all. So client to client packets are sent using UDP, a datagram protocol.
UDP is unreliable, meaning that packets are not guaranteed to be delivered. It's also connectionless, meaning we don't even know if anybody is listening for the message. However, it's also fast because it's so simple. UDP suits our needs because: we need fast delivery; we don't care if a message is lost because another will arrive shortly afterwards; and we don't care if the receiver isn't listening.
BZFlag clients need to send their information to all the other clients. There are several ways to do this. First, each client can send each message to all the other clients. If there are N clients then each message is sent N-1 times. Traffic grows as the square of clients. This is slow and wasteful.
Alternatively, each client can send all messages to one special computer (for example, the server) and that computer can forward the messages to all the other players. This makes life easier on the clients and much harder on the server. It also delays the delivery of each message. And traffic from the server still grows as N squared (though traffic to the server grows linearly).
Another possibility is to broadcast messages. A broadcast message is sent once and received by all computers on a subnet. This scales linearly and minimizes network traffic but broadcast traffic is never routed outside the subnet, so it means only clients on the same subnet of the same local area network could play together.
BZFlag uses the second technique, using the server as a relay system. The server uses the TCP client/server connection to send client traffic that must be reliable and UDP for information that must be timely but does not need to be reliable.

= Protocol =
--> means from client to server
<-- means from server to client

All multi-byte data is in network byte order (aka big endian); that is, the most significant byte comes first followed by successively less significant bytes.
All numbers are integers unless otherwise specified. Integers can be 8, 16, or 32 bit signed 2's compliment or unsigned (encoding is the same in regardless of signed status). Values in this document in byte boxes are given in hexadecimal. Values in the text are given in decimal unless otherwise noted.
Bit fields are encoded as unsigned integers. All floating point numbers are in standard IEEE-754 single precision format. Multi-byte values are *not* necessarily aligned on 2 or 4 byte boundaries.
A client normally follows the following sequence during game play: connect to server get the world database join the game send/receive game messages leave game disconnect from server
common message structures ------------------------- Most messages begin with the length of the message in bytes followed by a 16 bit code. The length is 16 bits and excludes itself and the code, so it's the actual length of the message minus 4.

Player identifiers are 1 byte and are used in many messages.

0 - 243 : Regular Players
244 - 250 : Special Team Ids
251 - 252 : Unused IDs
253 : ServerPlayer (World weapons, etc)
254 : All Players
255 : No Player (Invalid Player)

Flag status is common to a few message types:

u16 flag id
u16 status
u16 type
u8 owner id
float position (x)
float position (y)
float position (z)
float launch (x)
float launch (y)
float launch (z)
float landing (x)
float landing (y)
float landing (z)
float flight time
float flight end time
float initial velocity

`Position,' `launch,' `landing,' `flight time,' `flight end,' and `initial velocity' are all floating point numbers. `Flag id' is the type of flag,enumerated in FlagId.

`Status' gives the current location of the flag:
FlagNoExist -- the flag is not active (i.e. not in the game)
FlagOnGround -- the flag is sitting on the ground ready to get picked up
FlagOnTank -- the flag is on a player's tank
FlagInAir -- the flag is in the air and will fall back down
FlagComing -- the flag just appeared and is falling to the ground
FlagGoing -- the flag was thrown in the air and is disappearing

`Type' indicates the behavior of the flag: FlagNormal means the flag is permanent and can be dropped normally (e.g. a team flag); FlagUnstable means the flag may disappear after use (e.g. a good super flag); FlagSticky means the flag cannot be dropped normally (e.g. a bad super flag).
`Player id' indicates which player has the flag when `status' is FlagOnTank. It isn't used for any other status.
`Position' is the location of the flag on the ground. It only has meaning when `status' is FlagOnGround. The position of a flag when on a tank is the position of the tank (centered on and at the top of the tank)
`Launch' is the location of the flag where it was thrown in the air. `Landing' is the location where the flag will/would touch ground. These are used when `status' is FlagInAir, FlagComing, and FlagGoing. The client should make the flag follow a reasonable flight path (e.g. a parabolic arc) from `launch' to `landing.'
`Flight time' is the time elapsed since the flag was thrown into the air. `Flight end' the time when the flag will reach the ground. `Initial velocity' gives the vertical (z) velocity of the flag when launched. The vertical position of the flag at time t (ranging from 0 to `flight end') is: z = z0 + v * t + 0.5 * g * t * t. z0 = `launch z;' v = `initial velocity;' g = acceleration due to gravity.

== Connecting to a server ==
The [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/misc/bzfquery.php bzfquery.php script] is a nice example of how to connect to a server.

At the beginning you need to open a socket. Beginning with protocol 0048 you need to send "BZFLAG\r\n\r\n" in order to get any reply. At that time you unfortunately don't know the protocol, so send it by default or your client will probably freeze.

--> connect(server port)
--> +----+----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 4C | 41 | 47 | 0D | 0A | 0D | 0A | BZFLAG\r\n\r\n
+----+----+----+----+----+----+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 53 | 31 | 39 | 31 | 30 | FF | BZFS1910 FF
+----+----+----+----+----+----+----+----+----+

Client should verify the version. In old versions the first four bytes indicates a BZFlag server, the next byte indicates the major version number (as an ASCII digit), the two bytes after that are the minor version number (as ASCII digits), and the 7th byte is the revision. Major and minor version number changes indicate incompatible protocol changes. Different revisions of a given version are compatible and usually just indicate client user interface changes. A following FF ends the packet. In new versions the protocol is just a number increased by 1 when the protocol changes.

If the reply was a protocol older than 0048 then bzfs will kick the client connecting to it. In this case we recommend a fallback, not sending BZFLAG\r\n\r\n during connection try:

--> connect(server port)
<-- +----+----+----+----+----+----+----+----+----+
| 42 | 5a | 46 | 53 | 31 | 39 | 31 | 30 | FF | BZFS1910 FF
+----+----+----+----+----+----+----+----+----+

Server owners will see something like the following in the logs if their server(s) use a protocol older than 0048:
Player [0] sent huge packet length (len=16986), possible attack
Player [0] removed at 2007-04-11 15:52:55: large packet recvd

== Message types ==
Read this with caution, as it is very old information not reflecting the current status.

=== Negotiating world flags ===

--> +----+----+----+----+----+----+----+----+----+----+
| length | 6E | 66 | FlagID1 | FlagID2 | ....... | MsgNegotiateFlags
+----+----+----+----+----+----+----+----+----+----+ (List of client flag ids)
<-- +----+----+----+----+----+----+----+----+----+----+
| length | 6E | 66 | FlagID1 | FlagID2 | ....... | MsgNegotiateFlags
+----+----+----+----+----+----+----+----+----+----+ (List of server flag ids, that client doesn't know)

Client sends to the server the two byte representation of all flags known to the client. In the case that a flag is only one letter, (N) for instance, the second byte is null. Otherwise, the null byte is implied at position 3. The server upon receipt of this list, finds all flags that are used by the server, but not known by the client, and sends this list to the client. The client upon receipt of the list, either disallows play, if flags exist, or continues if the list is empty.

=== getting the world hash ===
--> +----+----+----+----+
| 00 | 00 | 77 | 68 | MsgWantWHash
+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+
| length | 77 | 68 | world hash data... | MsgWantWHash
+----+----+----+----+----+----+----+----+

To improve performance World (bzc) files are cached on the client. The name of the cache file is an md5 hash of the file that is computed on the server. this hash is sent to the client, and the client looks for a file by that name in the bz world cache directory. If the hash starts with a 't', the world is a random world. If the hash starts with a 'p' the world is from a world file. If the client can find the file locally, it does not sent the following MsgGetWorld packet.

=== getting the world database ===
--> +----+----+----+----+----+----+
| 00 | 02 | 67 | 77 | offset | MsgGetWorld
+----+----+----+----+----+----+
<-- +----+----+----+----+----+----+----+----+
| length | 67 | 77 |remaining| data... | MsgGetWorld
+----+----+----+----+----+----+----+----+
or
+----+----+----+----+
| 00 | 00 | 73 | 6b | MsgSuperKill
+----+----+----+----+

Client sends MsgGetWorld requests until it has read the entire world database. Clients should send an `offset' of 0 for the first request and increase `offset' by however much data was sent in reply. Each MsgGetWorld reply includes the number of bytes left after the returned block of data in `remaining'. The server returns 0 in `remaining' when there is no more data left to read. In no event will the server return more than MaxPacketLen - 6 bytes of data in one reply (see protocol.h for the definition of MaxPacketLen). The server may return MsgSuperKill at any time during the download of the world database. The client should immediately close the connection to the server. No other messages should be returned by the server as long as the client sends only MsgGetWorld requests.

The `data' has the following encoding:

+----+----+----+----+
| 00 | 1E | 73 | 74 | length of data, WorldCodeStyle
+----+----+----+----+----+----+
| version | worldsize |
+----+----+----+----+----+----+----+----+
| style | mxPlyrs | mxShots | mxFlags |
+----+----+----+----+----+----+----+----+
|linear acceleration|angulr acceleration|
+----+----+----+----+----+----+----+----+
| shake t | shake w | epoch offset |
+----+----+----+----+----+----+----+----+

Values are:
version: version of the bzw format
worldsize: size in meters of world
style: bitfield of game style
maxPlayrs: maximum number of players
maxShots: maximum number of shots at once per player
maxFlags: maximum number of flags that may exist at once
linear acc.: linear acceleration limit (float)
angulr acc.: angular acceleration limit (float)
shake t: time to shake a bad flag (1/10ths of seconds)
shake w: number of wins to shake a bad flag
epoch offset: seconds since midnight Jan 1, 1970 GMT on the server, used when
synchronizing times across clients

The rest of the world database is encoded in individual blocks describing each object. Only permanent immovable objects are included. The encodings for each type of object are:

team base:
+----+----+----+----+
| 00 | 2A | 62 | 61 | length of base data, team code
+----+----+----+----+----+----+
| team id | center (x) |
+----+----+----+----+----+----+----+----+
| center (y) | center (z) |
+----+----+----+----+----+----+----+----+
| angle | size (x) |
+----+----+----+----+----+----+----+----+
| size (y) | size (z) |
+----+----+----+----+----+----+----+----+
| safety (x) | safety (y) |
+----+----+----+----+----+----+----+----+
| safety (z) |
+----+----+----+----+

wall:
+----+----+----+----+
| 00 | 18 | 77 | 6C | length of wall data, wall code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle... |
+----+----+----+----+----+----+----+----+
| width | height |
+----+----+----+----+----+----+----+----+

pyramid:
+----+----+----+----+
| 00 | 1D | 70 | 79 | length of pyramid data, pyramid code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | sdf|
+----+----+----+----+----+

box:
+----+----+----+----+
| 00 | 1D | 62 | 78 | length of box data, box code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | sdf|
+----+----+----+----+----+

teleporter:
+----+----+----+----+
| 00 | 21 | 74 | 65 | length of teleporter data, teleporter code
+----+----+----+----+----+----+----+----+
| center (x) | center (y) |
+----+----+----+----+----+----+----+----+
| center (z) | angle |
+----+----+----+----+----+----+----+----+
| width | depth |
+----+----+----+----+----+----+----+----+
| height | border |
+----+----+----+----+----+----+----+----+
| sdf|
+----+

teleporter link:
+----+----+----+----+
| 00 | 04 | 6C | 6E | length of link data, link code
+----+----+----+----+
| from | to |
+----+----+----+----+
end of data:
+----+----+----+----+
| 00 | 00 | 65 | 64 | length of worldcodeend data, worldcodeend code
+----+----+----+----+

The above values are interpreted as follows:

angle (float): in radians from the x-axis in the xy plane
width (float): half width (in xy) measured from center
depth (float): half depth (in xy) measured from center
height (float): full height (in z) measured from bottom
border (float): full size of the square cross section teleporter border
center (float): center in xy, bottom in z
safety (float): safety position for team flags, used when team A drops team B's
flag on team C's base.
from & to: index of teleporter face starting from zero; the N'th teleporter
in the world data has face indices 2*N and 2*N+1. teleporter
links indicate which face teleports to which face; faces may
teleport to themselves.
sdf (byte): bit mask:
drive through is bitmask 0x01
shoot through is bitmask 0x02

== join game ==
Once connected a player normally requests to join the game. The server replies with
MsgSuperKill, MsgReject, or MsgAccept.

--> +----+----+----+----+----+----+----+----+
| length | 65 | 6e | player id... MsgEnter
+----+----+----+----+----+----+----+----+
| type | team |
+----+----+----+----+----+----+----+----+
| call sign (CallSignLen bytes)...
+----+----+----+----+----+----+----+----+
...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
| email address (EmailLen bytes)...
+----+----+----+----+----+----+----+----+
...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
<-- +----+----+----+----+
| 00 | 00 | 61 | 63 | MsgAccept
+----+----+----+----+
or
+----+----+----+----+----+----+
| 00 | 02 | 72 | 6a | code | MsgReject
+----+----+----+----+----+----+
or
+----+----+----+----+
| 00 | 00 | 73 | 6b | MsgSuperKill
+----+----+----+----+

`Type' is one of the enumerations in PlayerType and `team' is one from TeamColor.
The call sign is the player's `handle' during the game; the call sign is used
to identify the player. No attempt is made by the server to prevent the
duplication of call signs during a game. The email address can be anything,
but should be the email address for human players (e.g. username@hostname).
BZFlag players can choose `anonymous' instead of their email address. The call
sign and email address should be NUL terminated ASCII strings, padded with
NUL's to the required length. `Length' is 12 + CallSignLen + EmailLen.

If the server responds with MsgSuperKill the client should close the connection
immediately. If the server responds with MsgReject, the client has not joined the
game but may keep the server connection open and try again. The reason for rejection
is included with the MsgReject message:

RejectBadRequest -- bogus data in MsgEnter
RejectBadTeam -- invalid team id
RejectBadType -- invalid client type
RejectTeamFull -- no more players allowed on team
RejectServerFull -- no more players allowed on any team

If the server responds with MsgAccept, the player has successfully joined the game.
The server then automatically sends updates about each flag, team, and player. The
client should be prepared to accept these updates in any order. The flag and team
updates are sent as MsgFlagUpdate and MsgTeamUpdate messages, respectively. Player
updates are sent as MsgAddPlayer messages. The client will receive a MsgAddPlayer
for the player it just added, but only after it has received a MsgAddPlayer for each
of the players already joined.

Until it receives the MsgAddPlayer for the player it just added, the client will
only receive the following kinds of messages:

MsgSuperKill
MsgFlagUpdate
MsgTeamUpdate
MsgAddPlayer

Players of type ComputerPlayer are not sent team or flag updates and only get the
MsgAddPlayer for themselves. This probably wasn't a good idea, but there it is.

== leave game ==
Once entered, a player can leave the game at any time. This should be done by sending
the following message then closing the connection:

--> +----+----+----+----+
| 00 | 00 | 65 | 78 | MsgExit
+----+----+----+----+

There is no reply. Clients can also leave by simply closing the connection, but
sending MsgExit first is recommended.

== during a game ==
There are several types of messages that are delivered at any time after a player
enters a game. Clients must be prepared to handle them in any order.

MsgSuperKill
<-- +----+----+----+----+
| 00 | 00 | 73 | 6b |
+----+----+----+----+
Client must immediately disconnect from the server.

MsgTimeLeft
<-- +----+----+----+----+----+----+
| 00 | 02 | 74 | 6f |time left|
+----+----+----+----+----+----+
Gives the time remaining in the game. This message is only sent when the
server has time limit configured. If the time remaining is zero, the client
should indicate to the player that the game is over.
`Time left' is in seconds. It is not sent every second so clients will need
to do their own count down between messages.

MsgScoreOver
<-- +----+----+----+----+----+----+----+----+
| 00 | 0a | 73 | 6f | player id...
+----+----+----+----+----+----+----+----+
| team id |
+----+----+----+----+----+----+
Gives the player or team that won the game by reaching the target score.
This message is only sent when the server has a target score configured.
The client should indicate which team or player won and that the game is
over.

If `team id' is NoTeam then `player id' indicates which player has won.
Otherwise `team id' indicates which team won.

MsgAddPlayer
<-- +----+----+----+----+----+----+----+----+
| length | 61 | 70 | player id...
+----+----+----+----+----+----+----+----+
| type | team |
+----+----+----+----+----+----+----+----+
| wins | losses | call sign...
+----+----+----+----+----+----+----+----+
... (CallSignLen bytes)... |
+----+----+----+----+----+----+----+----+
| email address...
+----+----+----+----+----+----+----+----+
... (EmailLen bytes)... |
+----+----+----+----+----+----+----+----+
Sent when another player enters the game and when joining a game if other
players are already joined. `Type' is enumerated in PlayerType, `team'
is enumerated in TeamColor. `Wins' and `losses' give the player's score.
They are unsigned integers; the player's score equals wins minus losses.
`Call sign' and `email address' are NUL terminated ASCII strings. `Length'
is 16 + CallSignLen + EmailLen.

MsgRemovePlayer
<-- +----+----+----+----+----+----+----+----+
| 00 | 08 | 72 | 70 | player id...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+
Sent when another player leaves the game.

MsgFlagUpdate
<-- +----+----+----+----+----+----+----+----+
| 00 | 40 | 66 | 75 |flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | player id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent when a flag's state changes. Also sent to a client when it enters
a game. `Flag num' is the index of the flag. Flags are indexed from
zero up to the maximum number of flags minus one.

Clients must update the flag positions while the flag is in flight (i.e.
`status' is FlagInAir, FlagComing, or FlagGoing. If FlagInAir or
FlagComing then the client should change the flag's status to
FlagOnGround when the flag's flight time equals or exceeds `flight end.'
The position should be set exactly to `landing.' If FlagGoing, the
client should change the flag's status to FlagNoExist when the flight
time equals or exceeds `flight end.'

BZFlag uses the first half of the flight time for FlagComing and the
last half of the flight time for FlagGoing to make the flag appear or
disappear from/to nothing. This allows players to adjust to the
appearance/disappearance of a flag.

MsgTeamUpdate
<-- +----+----+----+----+----+----+----+----+
| 00 | 0a | 74 | 6f | team | size |
+----+----+----+----+----+----+----+----+
| active | wins | losses |
+----+----+----+----+----+----+
Gives the current state of team `team.' `Size' is the number of
players on the team. `Active' is the number of active players on the
team. An active player is one that can participate in the game (e.g.
grab flags, shoot opponents, etc.); a non-active player can only
observe the game. Only active players are considered when deciding
if there are any players on a team (to decide if the team flag should
be inserted or withdrawn from the game). `Wins' and `losses' give the
team's score (wins minus losses).

MsgAlive
<-- +----+----+----+----+----+----+----+----+
| 00 | 20 | 61 | 6c | player id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| forward (x) | forward (y) |
+----+----+----+----+----+----+----+----+
| forward (z) |
+----+----+----+----+
Sent when a player comes alive. A player that has joined is not on the
game board until it sends this message, which declares that it is in
game and gives the starting position and orientation. Players are removed
from the game board when killed and do not reappear until sending this
message again.

--> +----+----+----+----+----+----+----+----+
| 00 | 18 | 61 | 6c | position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| forward (x) | forward (y) |
+----+----+----+----+----+----+----+----+
| forward (z) |
+----+----+----+----+
A player sends this message to enter the game board. Note that this
version of the message differs from the one sent by the server in that
it lacks the player id (which is implicit in the server connection).
Players must send this message to change their state from dead to alive.
Players should not send MsgAlive for a certain penalty period after
being killed (but the server does not enforce a minimum time). The
currently penalty is ExplodeTime.

`Position' gives the location of the player and `forward' gives the
player's forward direction vector.

MsgKilled
<-- +----+----+----+----+----+----+----+----+
| 00 | 12 | 6b | 6c | victim id...
+----+----+----+----+----+----+----+----+
| killer id...
+----+----+----+----+----+----+----+----+
| shot id |
+----+----+----+----+----+----+
Sent by the server when a player is killed by itself or another player.
The victim id is the player that was destroyed and the killer id is the
player credited with the kill. Shot id identifies which of the killer's
shots hit the victim; if the shot isn't a laser or shockwave, other
players may assume the shot has stopped and needn't check themselves
against the shot (or they can wait until the MsgShotEnd message arrives).

--> +----+----+----+----+----+----+----+----+
| 00 | 0a | 6b | 6c | killer id...
+----+----+----+----+----+----+----+----+
| shot id |
+----+----+----+----+----+----+
Sent by the victim when it detects that it's been hit, naming the killer
and which of the killer's shots was the one that hit. Note that the
server does not verify kills in any way so it's trivial to `cheat' by
claiming you've been killed; this is generally unproductive. It's
also easy to cheat by never sending MsgKilled, making you almost
immortal. Don't do this.

MsgGrabFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 48 | 67 | 66 | grabber id...
+----+----+----+----+----+----+----+----+
|flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | owner id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent by the server when a player is allowed to grab a flag. This is
both the notice to the player trying to grab the flag that it succeeded
and the notice to all other players that the flag was grabbed. Note
that `grabber id' is redundant; it's always equal to `owner id.'

`Flag num' is the index of the flag. Flags are indexed from zero up to
the maximum number of flags minus one.

--> +----+----+----+----+----+----+
| 00 | 02 | 67 | 66 |flag num |
+----+----+----+----+----+----+
Sent by a player when it wants to grab a flag. Players should only
send this message when their tank is within FlagRadius of a flag (that's
any part of the tank, not simply the center) and on the ground. The
server will not verify this, but it will verify some other stuff. The
player must not assume it will be able to grab the flag. Instead it has
to wait for a MsgGrabFlag reply.

MsgDropFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 48 | 64 | 66 | dropper id...
+----+----+----+----+----+----+----+----+
|flag num | flag id |
+----+----+----+----+----+----+----+----+
| status | type | owner id...
+----+----+----+----+----+----+----+----+
| position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
| launch (x) | launch (y) |
+----+----+----+----+----+----+----+----+
| launch (z) | landing (x) |
+----+----+----+----+----+----+----+----+
| landing (y) | landing (z) |
+----+----+----+----+----+----+----+----+
| flight time | flight end |
+----+----+----+----+----+----+----+----+
| initial velocity |
+----+----+----+----+
Sent by the server when a player is allowed to drop a flag. This is
both the notice to the player trying to drop the flag that it succeeded
and the notice to all other players that the flag was dropped. `Owner
id' is meaningless in this message.

`Flag num' is the index of the flag. Flags are indexed from zero up to
the maximum number of flags minus one.

--> +----+----+----+----+----+----+----+----+
| 00 | 0c | 64 | 66 | position (x) |
+----+----+----+----+----+----+----+----+
| position (y) | position (z) |
+----+----+----+----+----+----+----+----+
Sent by a player when it wants to drop a flag. Players should only
send this message when they have a flag and only when the flag dropping
constraints have been met (i.e. the flag can be dropped at any time, or
the player got the antidote flag, etc.) The player must not assume it
has dropped the flag until it receives a MsgDropFlag in response.

`Position' is in floating point and is the position of the tank that
dropped the flag when it was dropped.

MsgCaptureFlag
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 63 | 66 | capturer id...
+----+----+----+----+----+----+----+----+
|flag num | team id |
+----+----+----+----+----+----+----+----+
Sent by the server when a team's flag has been captured. `Capturer id'
is the player who captured the flag. `Flag num' is the index of the
captured flag. Flags are indexed from zero up to the maximum number of
flags minus one. `Team id' is the id of the team who's flag was
captured. Note that the player who captures the flag may be on the team
that was captured.

The server makes all players on the captured team dead. This message is
the only notice that the players are now dead so clients should act
accordingly. This is also the only notice that the capturer is no longer
carrying a flag.

--> +----+----+----+----+----+----+
| 00 | 02 | 63 | 66 | team id |
+----+----+----+----+----+----+
Sent by a player when it captures a team flag. `Team id' is the id of
the team who's flag was captured. The player should wait until the
server sends back the MsgCaptureFlag response before assuming the
capture was successful. A player should send this message only when
1) its tank is at least halfway inside a team base, 2) the tank is on
the ground, and 3) the player has its own team flag in an enemy base
or the player has another team's flag in its own base. Note that the
server will not enforce any of these requirements.

MsgShotBegin
<--
--> +----+----+----+----+----+----+----+----+
| 00 | 2c | 73 | 62 | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | time
+----+----+----+----+----+----+----+----+
|flag type| lifetime |
+----+----+----+----+----+----+----+----+
Sent by the server when a player has fired a shot. The identical message
is send by a player when it fires a shot. The server does not verify
that the player is allowed to fire a shot.

`Shooter id' identifies the player that did the shooting. `Shot id' is
a number that uniquely identifies to the shooter which shot this is.
`Position,' `velocity,' `time,' and `lifetime' are floating point
numbers. `Position' is the starting position of the shot. `Velocity'
is the starting velocity of the shot. `Time' is the time the shot has
existed (probably 0.0). `Lifetime' is how long the shot exists. `Flag
type' is a FlagId and is the type of flag the shooter had when the shot
was fired.

Clients are expected to compute the flight path of shots (except Guided
Missiles) given the information in MsgShotBegin. That includes handling
ricochets, building impacts, and teleportation, but not tank impacts.
Each player decides if it itself has been hit by a shot at each time step
based on this flight path. Since the path of a guided missile cannot be
predicted, updates to a guided missile's path is sent throughout its
flight by the shooter via MsgGMUpdate messages.

A player should test itself against a shot using whatever algorithm it
likes, but at a minimum should test the line segments the shot moves
along during the time step against a tank aligned bounding box.
Accounting for the linear motion of the tank over the time step is
better and accounting for both the linear and angular motion is better
still. Note that the shot has a certain radius that should be taking
into account during intersection testing. This is particularly
important when testing against a tank with the narrow flag. Ideally,
the shot would be exactly tested against the tank geometry. However,
that's more work than realistically necessary.

MsgShotEnd
<--
--> +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 65 | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | reason |
+----+----+----+----+----+----+----+----+
Sent by the server when a shot has been terminated before its lifetime
has expired. The identical message is sent by the player that
terminates the shot. This is normally the player that has just been
hit by the shot. The server does not verify that the player has or
has not been hit. This message is also sent by the player that fired
a guided missile when the shot hits the ground or a building (note that
guided missiles don't ricochet).

`Shooter id' identifies the player that fired the shot and `shot id'
is the same as in the MsgShotBegin message for the shot. `Reason' is
one if the other players should show an explosion for the shot and
zero otherwise.

MsgScore
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 63 | player id...
+----+----+----+----+----+----+----+----+
| wins | losses |
+----+----+----+----+----+----+----+----+
Sent by the server when a player's score changes. `Player id' is the
player with the new score, and `wins' and `losses' are the new scores.

--> +----+----+----+----+----+----+----+----+
| 00 | 04 | 73 | 63 | wins | losses |
+----+----+----+----+----+----+----+----+
Sent by a player when its score changes.

MsgTeleport
<-- +----+----+----+----+----+----+----+----+
| 00 | 0c | 73 | 63 | player id...
+----+----+----+----+----+----+----+----+
| from | to |
+----+----+----+----+----+----+----+----+
Sent by the server when a player teleports. `From' is the index of the
teleporter face the player entered and `to' is the index of the face
the player exited.

--> +----+----+----+----+----+----+----+----+
| 00 | 04 | 73 | 63 | from | to |
+----+----+----+----+----+----+----+----+
Sent by a player when it passes through a teleporter.

MsgMessage
<-- +----+----+----+----+----+----+----+----+
| length | 6d | 67 | from player id...
+----+----+----+----+----+----+----+----+
| to player id...
+----+----+----+----+----+----+----+----+
| team |message...
+----+----+----+----+----+----+----+----+
...(MessageLen bytes)...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
Sent by the server when one player sends a message to others. `Length'
is the length of the message (18 + MessageLen bytes). `From player id'
is the player sending the message, `to player id' is the player to
receive the message, and `team' is the team to receive the message.
If `to player id' is all zeros then the message is being sent to
everyone on `team'. If `to player id' is all zeros and `team' is
RogueTeam then the message is being sent to all players. If `to player
id' is not all zeros then `team' is ignored and the message is only for
the identified player.

--> +----+----+----+----+----+----+----+----+
| length | 6d | 67 | player id...
+----+----+----+----+----+----+----+----+
| team |message...
+----+----+----+----+----+----+----+----+
...(MessageLen bytes)...
+----+----+----+----+----+----+----+----+
|
+----+----+----+----+----+----+----+----+
Sent by player to send a message to other players. `Length' is is the
length of the message (10 + MessageLen bytes). `Player id' is the
player to receive the message (or all zeros for all players on the
given team) and `team' is the team to receive the message (or
RogueTeam for all teams).

MsgPlayerUpdate
+----+----+----+----+----+----+----+----+
| 00 | 2a | 70 | 75 | player id...
+----+----+----+----+----+----+----+----+
| status | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | azimuth
+----+----+----+----+----+----+----+----+
| angular velocity |
+----+----+----+----+----+----+
Sent by players to notify other players of changes in its status,
position, or velocity.

`Status' is the tank's current status. See PlayerStatus for the
meaning of the bit field's bits. The FlagActive bit indicates whether
the player's flag's special powers are active or not. The Phantom
Zone flag is an example of a flag that's active only some of the time.
The CrossingWall bit indicates if the player's tank is intersected by
a wall or teleporter; other players can use this to draw the player
in some special way. CrossingWall could be computed by each player
from other information; it's only provided to save the other players
the trouble.

`Position,' `velocity,' `azimuth,' and `angular velocity' are floating
point numbers. `Azimuth' is the orientation of the tank in radians
(the +x axis is 0.0, +y is pi/2). `Angular velocity' is the change in
azimuth per second. `Position' is the tank position and `velocity' is
the change in tank position per second.

A player normally only sends an update when its position or orientation
as could be predicted by other players differs from its true position
or orientation by a certain tolerance. Other players are expected to
use the last known player data to extrapolate the current position and
orientation. This technique is known as dead reckoning and has two
primary benefits: network traffic is decreased since updates needn't
be sent continuously and players on systems with slower frame rates
appear to move smoothly to players on systems with faster frame rates.

Players that fail to send updates often enough should be considered
to be not responding. Unresponsive players should be ignored until
they start responding again.

MsgGMUpdate
+----+----+----+----+----+----+----+----+
| 00 | 2e | 67 | 6d | shooter id...
+----+----+----+----+----+----+----+----+
| shot id | position
+----+----+----+----+----+----+----+----+
(x) | position (y) | position
+----+----+----+----+----+----+----+----+
(z) | velocity (x) | velocity
+----+----+----+----+----+----+----+----+
(y) | velocity (z) | time
+----+----+----+----+----+----+----+----+
| target id....
+----+----+----+----+----+----+----+----+
|
+----+----+
Sent by players with active guided missiles to notify other players
of changes to the motion of the guided missile.

See MsgShotBegin for the meaning of most items. `Time' is the current
age of the shot (the time since being fired). `Target id' is the
current target of the guided missile or all zeros if there is no target.

Players are expected to use dead reckoning to update the position and
velocity of guided missiles between MsgGMUpdate messages. Since
guided missiles deviate from their predicted course only when the
target changes, these message will be fairly rare. Note that different
players may have different ideas of where the target is and that that
may cause slightly different courses. This is generally not a problem.

MsgLagPing
+----+----+----+----+----+----+
| 00 | 02 | 70 | 69 | seq. no.|
+----+----+----+----+----+----+
Sent by the server to active players every 10s to measure lag. The
client just echoes the message back to the server. The time
between sending and receiving the message in the server is
considered to be the current lag of the respective player.

The two byte sequence number is included to be able to deal with
lost or severely delayed messages. On each ping sent by the server,
the sequence number is incremented (modulo 10000). The server
manages this number on a per player basis.

MsgReplayReset
+----+----+----+----+----+
| 00 | 01 | 72 | 72 | lp |
+----+----+----+----+----+
Sent by the server to active replay observers to remove state
information that they might have regarding players and flags.
The 'lp' value is the last player to be removed. PlayerId's above
'lp' are replay observers, and are not removed.

== UDP negotiation ==

*solo bots don't do this, they should use the existing player's connection

*MsgUDPLinkRequest = 0x6f66; // 'of'

*MsgUDPLinkEstablished = 0x6f67; // 'og'

*if client has udp enabled player sends MsgUDPLinkRequest with player number over udp

*if request has valid player number and is from same address server sends MsgUDPLinkEstablished over tcp to confirm inbound server sends MsgUDPLinkRequest back over udp to test outbound

*player gets MsgUDPLinkEstablished and starts sending udp

*player gets MsgUDPLinkRequest and sends MsgUDPLinkEstablished over udp

*server gets MsgUDPLinkEstablished
server can now send over udp

[[Category:Concepts]]

BZFlag 2.4.0

2011-11-06T15:56:23Z

Yosef: spare me - this is just a minor grammar edit

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

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

The version contains a number of new features.

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

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

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

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

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

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

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

Master Ban

2011-11-06T15:53:07Z

Yosef:

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

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

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

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

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

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

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

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

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

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

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

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

[[Category:Server Security]]

Bloodbath

2011-11-06T15:51:34Z

Yosef:

Bloodbath is an elongated Capture the Flag map by R3lax. It features extremely powerful flags and frequent team-domination, suiting it to the title "Bloodbath".

==Description==
Bloodbath has a limited radar view, custom textures, and interesting yet simple 2.0 objects including cones, arcs, and meshes.
Some specific areas of the map include:
*The stealth hole - can be referred to as "the hole," or simply "in," as in "r ST in" (red stealth) this contains Stealth, Cloaking, Seer, and Masquerade flags
*The tower - sometimes referred to as the "base" or the "castle," as in "bSW is in our base!"(blue Shockwave is in the tower) It is placed in the center behind the team-base and hold Guided Missile, Super-Bullet, and Shockwave flags.
*The tracks - also "transporters" or "highways."
*The middle -or "mid" In the middle is where the Geno flag is found, as well as Narrow, Tiny, Shockwave, and Super-Bullet.
*The crack - This is where the team flag is usually placed since it requires the Narrow flag to retrieve. It is immediately behind the team-base.

==Tactics==
Tactics rely heavily on team support. One player can not be successful alone and it is almost impossible to capture the flag without team coordination.
*Control the middle - the two most important flags are in the middle: Geno and Narrow. The team that dominates the middle usually dominates the map. Because it is usually impossible to capture the flag without the Narrow flag, the action is centered around the middle.
*Sniping is a common tactic, especially to those new to the game. Grab the laser flag, hit the binocular key and support those who are fighting for the middle.
*Beware of the Geno! It is important that everyone on a team is careful not to get hit by a Genocide bullet. Chat is useful here, pay attention when someone says "geno mid" (enemy with Genocide is in the middle). "Hunt" the player with the genocide flag and avoid them. Conversely, allow a teammate carrying the geno flag to shoot an enemy.
*Camping (laser camping, spawn-camping, base-camping) is a part of the game. Although it may be looked on as a lame way to rack up points, direct your energy toward eliminating the camper rather than complaining about them. Again, teamwork is crucial.

==Map History and Information ==
Created by R3laX, the original style of play has changed little in its revisions. The location of the crack and the shape of the stealth hole have been the important changes. The current version is 2.3 featuring a rounded stealth hole and additional Tiny and Masquerade flags.

[[Category:Maps]]
[[Category:CTF_Maps]]

Color(BZW)

2011-11-04T22:29:20Z

Yosef: spelling

A color is used in a BZFlag world ([[BZW]]) as a sub parameter for many parameters, such as [[Material|materials]] and [[DynamicColor|dynamic colors]]. When defining color in materials, it is synonymous with 'diffuse'.

==Format==
===RGBA===
[[Image:RedBox.png|right|frame|300px|Material- color 1 0 0 0.5]]
The basic format of a color is to define the Red Green Blue and Alpha components of a color in the format
Red Green Blue Alpha

As an example to define pure red, the color would be defined as follows:
1 0 0 1
This would define a color of 100% pure red and 100% opacity.

The numeric values for color can range from 0 to 1 and represent the fraction of 100% for each color channel.

===HTML Color format===
Colors can be defined in the HTML RGB format as well using Hex codes. Again pure red would be
#FF0000

===Pre-defined colors===
BZFlag supports a number of pre-defined color names including:
'''ColorName RGB Values'''
snow 1.000000f, 0.980392f, 0.980392f
ghost_white 0.972549f, 0.972549f, 1.000000f
GhostWhite 0.972549f, 0.972549f, 1.000000f
white_smoke 0.960784f, 0.960784f, 0.960784f
WhiteSmoke 0.960784f, 0.960784f, 0.960784f
gainsboro 0.862745f, 0.862745f, 0.862745f
floral_white 1.000000f, 0.980392f, 0.941176f
FloralWhite 1.000000f, 0.980392f, 0.941176f
old_lace 0.992157f, 0.960784f, 0.901961f
OldLace 0.992157f, 0.960784f, 0.901961f
linen 0.980392f, 0.941176f, 0.901961f
antique_white 0.980392f, 0.921569f, 0.843137f
AntiqueWhite 0.980392f, 0.921569f, 0.843137f
papaya_whip 1.000000f, 0.937255f, 0.835294f
PapayaWhip 1.000000f, 0.937255f, 0.835294f
blanched_almond 1.000000f, 0.921569f, 0.803922f
BlanchedAlmond 1.000000f, 0.921569f, 0.803922f
bisque 1.000000f, 0.894118f, 0.768627f
peach_puff 1.000000f, 0.854902f, 0.725490f
PeachPuff 1.000000f, 0.854902f, 0.725490f
navajo_white 1.000000f, 0.870588f, 0.678431f
NavajoWhite 1.000000f, 0.870588f, 0.678431f
moccasin 1.000000f, 0.894118f, 0.709804f
cornsilk 1.000000f, 0.972549f, 0.862745f
ivory 1.000000f, 1.000000f, 0.941176f
lemon_chiffon 1.000000f, 0.980392f, 0.803922f
LemonChiffon 1.000000f, 0.980392f, 0.803922f
seashell 1.000000f, 0.960784f, 0.933333f
honeydew 0.941176f, 1.000000f, 0.941176f
mint_cream 0.960784f, 1.000000f, 0.980392f
MintCream 0.960784f, 1.000000f, 0.980392f
azure 0.941176f, 1.000000f, 1.000000f
alice_blue 0.941176f, 0.972549f, 1.000000f
AliceBlue 0.941176f, 0.972549f, 1.000000f
lavender 0.901961f, 0.901961f, 0.980392f
lavender_blush 1.000000f, 0.941176f, 0.960784f
LavenderBlush 1.000000f, 0.941176f, 0.960784f
misty_rose 1.000000f, 0.894118f, 0.882353f
MistyRose 1.000000f, 0.894118f, 0.882353f
white 1.000000f, 1.000000f, 1.000000f
black 0.000000f, 0.000000f, 0.000000f
dark_slate_gray 0.184314f, 0.309804f, 0.309804f
DarkSlateGray 0.184314f, 0.309804f, 0.309804f
dark_slate_grey 0.184314f, 0.309804f, 0.309804f
DarkSlateGrey 0.184314f, 0.309804f, 0.309804f
dim_gray 0.411765f, 0.411765f, 0.411765f
DimGray 0.411765f, 0.411765f, 0.411765f
dim_grey 0.411765f, 0.411765f, 0.411765f
DimGrey 0.411765f, 0.411765f, 0.411765f
slate_gray 0.439216f, 0.501961f, 0.564706f
SlateGray 0.439216f, 0.501961f, 0.564706f
slate_grey 0.439216f, 0.501961f, 0.564706f
SlateGrey 0.439216f, 0.501961f, 0.564706f
light_slate_gray 0.466667f, 0.533333f, 0.600000f
LightSlateGray 0.466667f, 0.533333f, 0.600000f
light_slate_grey 0.466667f, 0.533333f, 0.600000f
LightSlateGrey 0.466667f, 0.533333f, 0.600000f
gray 0.745098f, 0.745098f, 0.745098f
grey 0.745098f, 0.745098f, 0.745098f
light_grey 0.827451f, 0.827451f, 0.827451f
LightGrey 0.827451f, 0.827451f, 0.827451f
light_gray 0.827451f, 0.827451f, 0.827451f
LightGray 0.827451f, 0.827451f, 0.827451f
midnight_blue 0.098039f, 0.098039f, 0.439216f
MidnightBlue 0.098039f, 0.098039f, 0.439216f
navy 0.000000f, 0.000000f, 0.501961f
navy_blue 0.000000f, 0.000000f, 0.501961f
NavyBlue 0.000000f, 0.000000f, 0.501961f
cornflower_blue 0.392157f, 0.584314f, 0.929412f
CornflowerBlue 0.392157f, 0.584314f, 0.929412f
dark_slate_blue 0.282353f, 0.239216f, 0.545098f
DarkSlateBlue 0.282353f, 0.239216f, 0.545098f
slate_blue 0.415686f, 0.352941f, 0.803922f
SlateBlue 0.415686f, 0.352941f, 0.803922f
medium_slate_blue 0.482353f, 0.407843f, 0.933333f
MediumSlateBlue 0.482353f, 0.407843f, 0.933333f
light_slate_blue 0.517647f, 0.439216f, 1.000000f
LightSlateBlue 0.517647f, 0.439216f, 1.000000f
medium_blue 0.000000f, 0.000000f, 0.803922f
MediumBlue 0.000000f, 0.000000f, 0.803922f
royal_blue 0.254902f, 0.411765f, 0.882353f
RoyalBlue 0.254902f, 0.411765f, 0.882353f
blue 0.000000f, 0.000000f, 1.000000f
dodger_blue 0.117647f, 0.564706f, 1.000000f
DodgerBlue 0.117647f, 0.564706f, 1.000000f
deep_sky_blue 0.000000f, 0.749020f, 1.000000f
DeepSkyBlue 0.000000f, 0.749020f, 1.000000f
sky_blue 0.529412f, 0.807843f, 0.921569f
SkyBlue 0.529412f, 0.807843f, 0.921569f
light_sky_blue 0.529412f, 0.807843f, 0.980392f
LightSkyBlue 0.529412f, 0.807843f, 0.980392f
steel_blue 0.274510f, 0.509804f, 0.705882f
SteelBlue 0.274510f, 0.509804f, 0.705882f
light_steel_blue 0.690196f, 0.768627f, 0.870588f
LightSteelBlue 0.690196f, 0.768627f, 0.870588f
light_blue 0.678431f, 0.847059f, 0.901961f
LightBlue 0.678431f, 0.847059f, 0.901961f
powder_blue 0.690196f, 0.878431f, 0.901961f
PowderBlue 0.690196f, 0.878431f, 0.901961f
pale_turquoise 0.686275f, 0.933333f, 0.933333f
PaleTurquoise 0.686275f, 0.933333f, 0.933333f
dark_turquoise 0.000000f, 0.807843f, 0.819608f
DarkTurquoise 0.000000f, 0.807843f, 0.819608f
medium_turquoise 0.282353f, 0.819608f, 0.800000f
MediumTurquoise 0.282353f, 0.819608f, 0.800000f
turquoise 0.250980f, 0.878431f, 0.815686f
cyan 0.000000f, 1.000000f, 1.000000f
light_cyan 0.878431f, 1.000000f, 1.000000f
LightCyan 0.878431f, 1.000000f, 1.000000f
cadet_blue 0.372549f, 0.619608f, 0.627451f
CadetBlue 0.372549f, 0.619608f, 0.627451f
medium_aquamarine 0.400000f, 0.803922f, 0.666667f
MediumAquamarine 0.400000f, 0.803922f, 0.666667f
aquamarine 0.498039f, 1.000000f, 0.831373f
dark_green 0.000000f, 0.392157f, 0.000000f
DarkGreen 0.000000f, 0.392157f, 0.000000f
dark_olive_green 0.333333f, 0.419608f, 0.184314f
DarkOliveGreen 0.333333f, 0.419608f, 0.184314f
dark_sea_green 0.560784f, 0.737255f, 0.560784f
DarkSeaGreen 0.560784f, 0.737255f, 0.560784f
sea_green 0.180392f, 0.545098f, 0.341176f
SeaGreen 0.180392f, 0.545098f, 0.341176f
medium_sea_green 0.235294f, 0.701961f, 0.443137f
MediumSeaGreen 0.235294f, 0.701961f, 0.443137f
light_sea_green 0.125490f, 0.698039f, 0.666667f
LightSeaGreen 0.125490f, 0.698039f, 0.666667f
pale_green 0.596078f, 0.984314f, 0.596078f
PaleGreen 0.596078f, 0.984314f, 0.596078f
spring_green 0.000000f, 1.000000f, 0.498039f
SpringGreen 0.000000f, 1.000000f, 0.498039f
lawn_green 0.486275f, 0.988235f, 0.000000f
LawnGreen 0.486275f, 0.988235f, 0.000000f
green 0.000000f, 1.000000f, 0.000000f
chartreuse 0.498039f, 1.000000f, 0.000000f
medium_spring_green 0.000000f, 0.980392f, 0.603922f
MediumSpringGreen 0.000000f, 0.980392f, 0.603922f
green_yellow 0.678431f, 1.000000f, 0.184314f
GreenYellow 0.678431f, 1.000000f, 0.184314f
lime_green 0.196078f, 0.803922f, 0.196078f
LimeGreen 0.196078f, 0.803922f, 0.196078f
yellow_green 0.603922f, 0.803922f, 0.196078f
YellowGreen 0.603922f, 0.803922f, 0.196078f
forest_green 0.133333f, 0.545098f, 0.133333f
ForestGreen 0.133333f, 0.545098f, 0.133333f
olive_drab 0.419608f, 0.556863f, 0.137255f
OliveDrab 0.419608f, 0.556863f, 0.137255f
dark_khaki 0.741176f, 0.717647f, 0.419608f
DarkKhaki 0.741176f, 0.717647f, 0.419608f
khaki 0.941176f, 0.901961f, 0.549020f
pale_goldenrod 0.933333f, 0.909804f, 0.666667f
PaleGoldenrod 0.933333f, 0.909804f, 0.666667f
light_goldenrod_yellow 0.980392f, 0.980392f, 0.823529f
LightGoldenrodYellow 0.980392f, 0.980392f, 0.823529f
light_yellow 1.000000f, 1.000000f, 0.878431f
LightYellow 1.000000f, 1.000000f, 0.878431f
yellow 1.000000f, 1.000000f, 0.000000f
gold 1.000000f, 0.843137f, 0.000000f
light_goldenrod 0.933333f, 0.866667f, 0.509804f
LightGoldenrod 0.933333f, 0.866667f, 0.509804f
goldenrod 0.854902f, 0.647059f, 0.125490f
dark_goldenrod 0.721569f, 0.525490f, 0.043137f
DarkGoldenrod 0.721569f, 0.525490f, 0.043137f
rosy_brown 0.737255f, 0.560784f, 0.560784f
RosyBrown 0.737255f, 0.560784f, 0.560784f
indian_red 0.803922f, 0.360784f, 0.360784f
IndianRed 0.803922f, 0.360784f, 0.360784f
saddle_brown 0.545098f, 0.270588f, 0.074510f
SaddleBrown 0.545098f, 0.270588f, 0.074510f
sienna 0.627451f, 0.321569f, 0.176471f
peru 0.803922f, 0.521569f, 0.247059f
burlywood 0.870588f, 0.721569f, 0.529412f
beige 0.960784f, 0.960784f, 0.862745f
wheat 0.960784f, 0.870588f, 0.701961f
sandy_brown 0.956863f, 0.643137f, 0.376471f
SandyBrown 0.956863f, 0.643137f, 0.376471f
tan 0.823529f, 0.705882f, 0.549020f
chocolate 0.823529f, 0.411765f, 0.117647f
firebrick 0.698039f, 0.133333f, 0.133333f
brown 0.647059f, 0.164706f, 0.164706f
dark_salmon 0.913725f, 0.588235f, 0.478431f
DarkSalmon 0.913725f, 0.588235f, 0.478431f
salmon 0.980392f, 0.501961f, 0.447059f
light_salmon 1.000000f, 0.627451f, 0.478431f
LightSalmon 1.000000f, 0.627451f, 0.478431f
orange 1.000000f, 0.647059f, 0.000000f
dark_orange 1.000000f, 0.549020f, 0.000000f
DarkOrange 1.000000f, 0.549020f, 0.000000f
coral 1.000000f, 0.498039f, 0.313726f
light_coral 0.941176f, 0.501961f, 0.501961f
LightCoral 0.941176f, 0.501961f, 0.501961f
tomato 1.000000f, 0.388235f, 0.278431f
orange_red 1.000000f, 0.270588f, 0.000000f
OrangeRed 1.000000f, 0.270588f, 0.000000f
red 1.000000f, 0.000000f, 0.000000f
hot_pink 1.000000f, 0.411765f, 0.705882f
HotPink 1.000000f, 0.411765f, 0.705882f
deep_pink 1.000000f, 0.078431f, 0.576471f
DeepPink 1.000000f, 0.078431f, 0.576471f
pink 1.000000f, 0.752941f, 0.796078f
light_pink 1.000000f, 0.713726f, 0.756863f
LightPink 1.000000f, 0.713726f, 0.756863f
pale_violet_red 0.858824f, 0.439216f, 0.576471f
PaleVioletRed 0.858824f, 0.439216f, 0.576471f
maroon 0.690196f, 0.188235f, 0.376471f
medium_violet_red 0.780392f, 0.082353f, 0.521569f
MediumVioletRed 0.780392f, 0.082353f, 0.521569f
violet_red 0.815686f, 0.125490f, 0.564706f
VioletRed 0.815686f, 0.125490f, 0.564706f
magenta 1.000000f, 0.000000f, 1.000000f
violet 0.933333f, 0.509804f, 0.933333f
plum 0.866667f, 0.627451f, 0.866667f
orchid 0.854902f, 0.439216f, 0.839216f
medium_orchid 0.729412f, 0.333333f, 0.827451f
MediumOrchid 0.729412f, 0.333333f, 0.827451f
dark_orchid 0.600000f, 0.196078f, 0.800000f
DarkOrchid 0.600000f, 0.196078f, 0.800000f
dark_violet 0.580392f, 0.000000f, 0.827451f
DarkViolet 0.580392f, 0.000000f, 0.827451f
blue_violet 0.541176f, 0.168627f, 0.886275f
BlueViolet 0.541176f, 0.168627f, 0.886275f
purple 0.627451f, 0.125490f, 0.941176f
medium_purple 0.576471f, 0.439216f, 0.858824f
MediumPurple 0.576471f, 0.439216f, 0.858824f
thistle 0.847059f, 0.749020f, 0.847059f
snow1 1.000000f, 0.980392f, 0.980392f
snow2 0.933333f, 0.913725f, 0.913725f
snow3 0.803922f, 0.788235f, 0.788235f
snow4 0.545098f, 0.537255f, 0.537255f
seashell1 1.000000f, 0.960784f, 0.933333f
seashell2 0.933333f, 0.898039f, 0.870588f
seashell3 0.803922f, 0.772549f, 0.749020f
seashell4 0.545098f, 0.525490f, 0.509804f
AntiqueWhite1 1.000000f, 0.937255f, 0.858824f
AntiqueWhite2 0.933333f, 0.874510f, 0.800000f
AntiqueWhite3 0.803922f, 0.752941f, 0.690196f
AntiqueWhite4 0.545098f, 0.513726f, 0.470588f
bisque1 1.000000f, 0.894118f, 0.768627f
bisque2 0.933333f, 0.835294f, 0.717647f
bisque3 0.803922f, 0.717647f, 0.619608f
bisque4 0.545098f, 0.490196f, 0.419608f
PeachPuff1 1.000000f, 0.854902f, 0.725490f
PeachPuff2 0.933333f, 0.796078f, 0.678431f
PeachPuff3 0.803922f, 0.686275f, 0.584314f
PeachPuff4 0.545098f, 0.466667f, 0.396078f
NavajoWhite1 1.000000f, 0.870588f, 0.678431f
NavajoWhite2 0.933333f, 0.811765f, 0.631373f
NavajoWhite3 0.803922f, 0.701961f, 0.545098f
NavajoWhite4 0.545098f, 0.474510f, 0.368627f
LemonChiffon1 1.000000f, 0.980392f, 0.803922f
LemonChiffon2 0.933333f, 0.913725f, 0.749020f
LemonChiffon3 0.803922f, 0.788235f, 0.647059f
LemonChiffon4 0.545098f, 0.537255f, 0.439216f
cornsilk1 1.000000f, 0.972549f, 0.862745f
cornsilk2 0.933333f, 0.909804f, 0.803922f
cornsilk3 0.803922f, 0.784314f, 0.694118f
cornsilk4 0.545098f, 0.533333f, 0.470588f
ivory1 1.000000f, 1.000000f, 0.941176f
ivory2 0.933333f, 0.933333f, 0.878431f
ivory3 0.803922f, 0.803922f, 0.756863f
ivory4 0.545098f, 0.545098f, 0.513726f
honeydew1 0.941176f, 1.000000f, 0.941176f
honeydew2 0.878431f, 0.933333f, 0.878431f
honeydew3 0.756863f, 0.803922f, 0.756863f
honeydew4 0.513726f, 0.545098f, 0.513726f
LavenderBlush1 1.000000f, 0.941176f, 0.960784f
LavenderBlush2 0.933333f, 0.878431f, 0.898039f
LavenderBlush3 0.803922f, 0.756863f, 0.772549f
LavenderBlush4 0.545098f, 0.513726f, 0.525490f
MistyRose1 1.000000f, 0.894118f, 0.882353f
MistyRose2 0.933333f, 0.835294f, 0.823529f
MistyRose3 0.803922f, 0.717647f, 0.709804f
MistyRose4 0.545098f, 0.490196f, 0.482353f
azure1 0.941176f, 1.000000f, 1.000000f
azure2 0.878431f, 0.933333f, 0.933333f
azure3 0.756863f, 0.803922f, 0.803922f
azure4 0.513726f, 0.545098f, 0.545098f
SlateBlue1 0.513726f, 0.435294f, 1.000000f
SlateBlue2 0.478431f, 0.403922f, 0.933333f
SlateBlue3 0.411765f, 0.349020f, 0.803922f
SlateBlue4 0.278431f, 0.235294f, 0.545098f
RoyalBlue1 0.282353f, 0.462745f, 1.000000f
RoyalBlue2 0.262745f, 0.431373f, 0.933333f
RoyalBlue3 0.227451f, 0.372549f, 0.803922f
RoyalBlue4 0.152941f, 0.250980f, 0.545098f
blue1 0.000000f, 0.000000f, 1.000000f
blue2 0.000000f, 0.000000f, 0.933333f
blue3 0.000000f, 0.000000f, 0.803922f
blue4 0.000000f, 0.000000f, 0.545098f
DodgerBlue1 0.117647f, 0.564706f, 1.000000f
DodgerBlue2 0.109804f, 0.525490f, 0.933333f
DodgerBlue3 0.094118f, 0.454902f, 0.803922f
DodgerBlue4 0.062745f, 0.305882f, 0.545098f
SteelBlue1 0.388235f, 0.721569f, 1.000000f
SteelBlue2 0.360784f, 0.674510f, 0.933333f
SteelBlue3 0.309804f, 0.580392f, 0.803922f
SteelBlue4 0.211765f, 0.392157f, 0.545098f
DeepSkyBlue1 0.000000f, 0.749020f, 1.000000f
DeepSkyBlue2 0.000000f, 0.698039f, 0.933333f
DeepSkyBlue3 0.000000f, 0.603922f, 0.803922f
DeepSkyBlue4 0.000000f, 0.407843f, 0.545098f
SkyBlue1 0.529412f, 0.807843f, 1.000000f
SkyBlue2 0.494118f, 0.752941f, 0.933333f
SkyBlue3 0.423529f, 0.650980f, 0.803922f
SkyBlue4 0.290196f, 0.439216f, 0.545098f
LightSkyBlue1 0.690196f, 0.886275f, 1.000000f
LightSkyBlue2 0.643137f, 0.827451f, 0.933333f
LightSkyBlue3 0.552941f, 0.713726f, 0.803922f
LightSkyBlue4 0.376471f, 0.482353f, 0.545098f
SlateGray1 0.776471f, 0.886275f, 1.000000f
SlateGray2 0.725490f, 0.827451f, 0.933333f
SlateGray3 0.623529f, 0.713726f, 0.803922f
SlateGray4 0.423529f, 0.482353f, 0.545098f
LightSteelBlue1 0.792157f, 0.882353f, 1.000000f
LightSteelBlue2 0.737255f, 0.823529f, 0.933333f
LightSteelBlue3 0.635294f, 0.709804f, 0.803922f
LightSteelBlue4 0.431373f, 0.482353f, 0.545098f
LightBlue1 0.749020f, 0.937255f, 1.000000f
LightBlue2 0.698039f, 0.874510f, 0.933333f
LightBlue3 0.603922f, 0.752941f, 0.803922f
LightBlue4 0.407843f, 0.513726f, 0.545098f
LightCyan1 0.878431f, 1.000000f, 1.000000f
LightCyan2 0.819608f, 0.933333f, 0.933333f
LightCyan3 0.705882f, 0.803922f, 0.803922f
LightCyan4 0.478431f, 0.545098f, 0.545098f
PaleTurquoise1 0.733333f, 1.000000f, 1.000000f
PaleTurquoise2 0.682353f, 0.933333f, 0.933333f
PaleTurquoise3 0.588235f, 0.803922f, 0.803922f
PaleTurquoise4 0.400000f, 0.545098f, 0.545098f
CadetBlue1 0.596078f, 0.960784f, 1.000000f
CadetBlue2 0.556863f, 0.898039f, 0.933333f
CadetBlue3 0.478431f, 0.772549f, 0.803922f
CadetBlue4 0.325490f, 0.525490f, 0.545098f
turquoise1 0.000000f, 0.960784f, 1.000000f
turquoise2 0.000000f, 0.898039f, 0.933333f
turquoise3 0.000000f, 0.772549f, 0.803922f
turquoise4 0.000000f, 0.525490f, 0.545098f
cyan1 0.000000f, 1.000000f, 1.000000f
cyan2 0.000000f, 0.933333f, 0.933333f
cyan3 0.000000f, 0.803922f, 0.803922f
cyan4 0.000000f, 0.545098f, 0.545098f
DarkSlateGray1 0.592157f, 1.000000f, 1.000000f
DarkSlateGray2 0.552941f, 0.933333f, 0.933333f
DarkSlateGray3 0.474510f, 0.803922f, 0.803922f
DarkSlateGray4 0.321569f, 0.545098f, 0.545098f
aquamarine1 0.498039f, 1.000000f, 0.831373f
aquamarine2 0.462745f, 0.933333f, 0.776471f
aquamarine3 0.400000f, 0.803922f, 0.666667f
aquamarine4 0.270588f, 0.545098f, 0.454902f
DarkSeaGreen1 0.756863f, 1.000000f, 0.756863f
DarkSeaGreen2 0.705882f, 0.933333f, 0.705882f
DarkSeaGreen3 0.607843f, 0.803922f, 0.607843f
DarkSeaGreen4 0.411765f, 0.545098f, 0.411765f
SeaGreen1 0.329412f, 1.000000f, 0.623529f
SeaGreen2 0.305882f, 0.933333f, 0.580392f
SeaGreen3 0.262745f, 0.803922f, 0.501961f
SeaGreen4 0.180392f, 0.545098f, 0.341176f
PaleGreen1 0.603922f, 1.000000f, 0.603922f
PaleGreen2 0.564706f, 0.933333f, 0.564706f
PaleGreen3 0.486275f, 0.803922f, 0.486275f
PaleGreen4 0.329412f, 0.545098f, 0.329412f
SpringGreen1 0.000000f, 1.000000f, 0.498039f
SpringGreen2 0.000000f, 0.933333f, 0.462745f
SpringGreen3 0.000000f, 0.803922f, 0.400000f
SpringGreen4 0.000000f, 0.545098f, 0.270588f
green1 0.000000f, 1.000000f, 0.000000f
green2 0.000000f, 0.933333f, 0.000000f
green3 0.000000f, 0.803922f, 0.000000f
green4 0.000000f, 0.545098f, 0.000000f
chartreuse1 0.498039f, 1.000000f, 0.000000f
chartreuse2 0.462745f, 0.933333f, 0.000000f
chartreuse3 0.400000f, 0.803922f, 0.000000f
chartreuse4 0.270588f, 0.545098f, 0.000000f
OliveDrab1 0.752941f, 1.000000f, 0.243137f
OliveDrab2 0.701961f, 0.933333f, 0.227451f
OliveDrab3 0.603922f, 0.803922f, 0.196078f
OliveDrab4 0.411765f, 0.545098f, 0.133333f
DarkOliveGreen1 0.792157f, 1.000000f, 0.439216f
DarkOliveGreen2 0.737255f, 0.933333f, 0.407843f
DarkOliveGreen3 0.635294f, 0.803922f, 0.352941f
DarkOliveGreen4 0.431373f, 0.545098f, 0.239216f
khaki1 1.000000f, 0.964706f, 0.560784f
khaki2 0.933333f, 0.901961f, 0.521569f
khaki3 0.803922f, 0.776471f, 0.450980f
khaki4 0.545098f, 0.525490f, 0.305882f
LightGoldenrod1 1.000000f, 0.925490f, 0.545098f
LightGoldenrod2 0.933333f, 0.862745f, 0.509804f
LightGoldenrod3 0.803922f, 0.745098f, 0.439216f
LightGoldenrod4 0.545098f, 0.505882f, 0.298039f
LightYellow1 1.000000f, 1.000000f, 0.878431f
LightYellow2 0.933333f, 0.933333f, 0.819608f
LightYellow3 0.803922f, 0.803922f, 0.705882f
LightYellow4 0.545098f, 0.545098f, 0.478431f
yellow1 1.000000f, 1.000000f, 0.000000f
yellow2 0.933333f, 0.933333f, 0.000000f
yellow3 0.803922f, 0.803922f, 0.000000f
yellow4 0.545098f, 0.545098f, 0.000000f
gold1 1.000000f, 0.843137f, 0.000000f
gold2 0.933333f, 0.788235f, 0.000000f
gold3 0.803922f, 0.678431f, 0.000000f
gold4 0.545098f, 0.458824f, 0.000000f
goldenrod1 1.000000f, 0.756863f, 0.145098f
goldenrod2 0.933333f, 0.705882f, 0.133333f
goldenrod3 0.803922f, 0.607843f, 0.113725f
goldenrod4 0.545098f, 0.411765f, 0.078431f
DarkGoldenrod1 1.000000f, 0.725490f, 0.058824f
DarkGoldenrod2 0.933333f, 0.678431f, 0.054902f
DarkGoldenrod3 0.803922f, 0.584314f, 0.047059f
DarkGoldenrod4 0.545098f, 0.396078f, 0.031373f
RosyBrown1 1.000000f, 0.756863f, 0.756863f
RosyBrown2 0.933333f, 0.705882f, 0.705882f
RosyBrown3 0.803922f, 0.607843f, 0.607843f
RosyBrown4 0.545098f, 0.411765f, 0.411765f
IndianRed1 1.000000f, 0.415686f, 0.415686f
IndianRed2 0.933333f, 0.388235f, 0.388235f
IndianRed3 0.803922f, 0.333333f, 0.333333f
IndianRed4 0.545098f, 0.227451f, 0.227451f
sienna1 1.000000f, 0.509804f, 0.278431f
sienna2 0.933333f, 0.474510f, 0.258824f
sienna3 0.803922f, 0.407843f, 0.223529f
sienna4 0.545098f, 0.278431f, 0.149020f
burlywood1 1.000000f, 0.827451f, 0.607843f
burlywood2 0.933333f, 0.772549f, 0.568627f
burlywood3 0.803922f, 0.666667f, 0.490196f
burlywood4 0.545098f, 0.450980f, 0.333333f
wheat1 1.000000f, 0.905882f, 0.729412f
wheat2 0.933333f, 0.847059f, 0.682353f
wheat3 0.803922f, 0.729412f, 0.588235f
wheat4 0.545098f, 0.494118f, 0.400000f
tan1 1.000000f, 0.647059f, 0.309804f
tan2 0.933333f, 0.603922f, 0.286275f
tan3 0.803922f, 0.521569f, 0.247059f
tan4 0.545098f, 0.352941f, 0.168627f
chocolate1 1.000000f, 0.498039f, 0.141176f
chocolate2 0.933333f, 0.462745f, 0.129412f
chocolate3 0.803922f, 0.400000f, 0.113725f
chocolate4 0.545098f, 0.270588f, 0.074510f
firebrick1 1.000000f, 0.188235f, 0.188235f
firebrick2 0.933333f, 0.172549f, 0.172549f
firebrick3 0.803922f, 0.149020f, 0.149020f
firebrick4 0.545098f, 0.101961f, 0.101961f
brown1 1.000000f, 0.250980f, 0.250980f
brown2 0.933333f, 0.231373f, 0.231373f
brown3 0.803922f, 0.200000f, 0.200000f
brown4 0.545098f, 0.137255f, 0.137255f
salmon1 1.000000f, 0.549020f, 0.411765f
salmon2 0.933333f, 0.509804f, 0.384314f
salmon3 0.803922f, 0.439216f, 0.329412f
salmon4 0.545098f, 0.298039f, 0.223529f
LightSalmon1 1.000000f, 0.627451f, 0.478431f
LightSalmon2 0.933333f, 0.584314f, 0.447059f
LightSalmon3 0.803922f, 0.505882f, 0.384314f
LightSalmon4 0.545098f, 0.341176f, 0.258824f
orange1 1.000000f, 0.647059f, 0.000000f
orange2 0.933333f, 0.603922f, 0.000000f
orange3 0.803922f, 0.521569f, 0.000000f
orange4 0.545098f, 0.352941f, 0.000000f
DarkOrange1 1.000000f, 0.498039f, 0.000000f
DarkOrange2 0.933333f, 0.462745f, 0.000000f
DarkOrange3 0.803922f, 0.400000f, 0.000000f
DarkOrange4 0.545098f, 0.270588f, 0.000000f
coral1 1.000000f, 0.447059f, 0.337255f
coral2 0.933333f, 0.415686f, 0.313726f
coral3 0.803922f, 0.356863f, 0.270588f
coral4 0.545098f, 0.243137f, 0.184314f
tomato1 1.000000f, 0.388235f, 0.278431f
tomato2 0.933333f, 0.360784f, 0.258824f
tomato3 0.803922f, 0.309804f, 0.223529f
tomato4 0.545098f, 0.211765f, 0.149020f
OrangeRed1 1.000000f, 0.270588f, 0.000000f
OrangeRed2 0.933333f, 0.250980f, 0.000000f
OrangeRed3 0.803922f, 0.215686f, 0.000000f
OrangeRed4 0.545098f, 0.145098f, 0.000000f
red1 1.000000f, 0.000000f, 0.000000f
red2 0.933333f, 0.000000f, 0.000000f
red3 0.803922f, 0.000000f, 0.000000f
red4 0.545098f, 0.000000f, 0.000000f
DeepPink1 1.000000f, 0.078431f, 0.576471f
DeepPink2 0.933333f, 0.070588f, 0.537255f
DeepPink3 0.803922f, 0.062745f, 0.462745f
DeepPink4 0.545098f, 0.039216f, 0.313726f
HotPink1 1.000000f, 0.431373f, 0.705882f
HotPink2 0.933333f, 0.415686f, 0.654902f
HotPink3 0.803922f, 0.376471f, 0.564706f
HotPink4 0.545098f, 0.227451f, 0.384314f
pink1 1.000000f, 0.709804f, 0.772549f
pink2 0.933333f, 0.662745f, 0.721569f
pink3 0.803922f, 0.568627f, 0.619608f
pink4 0.545098f, 0.388235f, 0.423529f
LightPink1 1.000000f, 0.682353f, 0.725490f
LightPink2 0.933333f, 0.635294f, 0.678431f
LightPink3 0.803922f, 0.549020f, 0.584314f
LightPink4 0.545098f, 0.372549f, 0.396078f
PaleVioletRed1 1.000000f, 0.509804f, 0.670588f
PaleVioletRed2 0.933333f, 0.474510f, 0.623529f
PaleVioletRed3 0.803922f, 0.407843f, 0.537255f
PaleVioletRed4 0.545098f, 0.278431f, 0.364706f
maroon1 1.000000f, 0.203922f, 0.701961f
maroon2 0.933333f, 0.188235f, 0.654902f
maroon3 0.803922f, 0.160784f, 0.564706f
maroon4 0.545098f, 0.109804f, 0.384314f
VioletRed1 1.000000f, 0.243137f, 0.588235f
VioletRed2 0.933333f, 0.227451f, 0.549020f
VioletRed3 0.803922f, 0.196078f, 0.470588f
VioletRed4 0.545098f, 0.133333f, 0.321569f
magenta1 1.000000f, 0.000000f, 1.000000f
magenta2 0.933333f, 0.000000f, 0.933333f
magenta3 0.803922f, 0.000000f, 0.803922f
magenta4 0.545098f, 0.000000f, 0.545098f
orchid1 1.000000f, 0.513726f, 0.980392f
orchid2 0.933333f, 0.478431f, 0.913725f
orchid3 0.803922f, 0.411765f, 0.788235f
orchid4 0.545098f, 0.278431f, 0.537255f
plum1 1.000000f, 0.733333f, 1.000000f
plum2 0.933333f, 0.682353f, 0.933333f
plum3 0.803922f, 0.588235f, 0.803922f
plum4 0.545098f, 0.400000f, 0.545098f
MediumOrchid1 0.878431f, 0.400000f, 1.000000f
MediumOrchid2 0.819608f, 0.372549f, 0.933333f
MediumOrchid3 0.705882f, 0.321569f, 0.803922f
MediumOrchid4 0.478431f, 0.215686f, 0.545098f
DarkOrchid1 0.749020f, 0.243137f, 1.000000f
DarkOrchid2 0.698039f, 0.227451f, 0.933333f
DarkOrchid3 0.603922f, 0.196078f, 0.803922f
DarkOrchid4 0.407843f, 0.133333f, 0.545098f
purple1 0.607843f, 0.188235f, 1.000000f
purple2 0.568627f, 0.172549f, 0.933333f
purple3 0.490196f, 0.149020f, 0.803922f
purple4 0.333333f, 0.101961f, 0.545098f
MediumPurple1 0.670588f, 0.509804f, 1.000000f
MediumPurple2 0.623529f, 0.474510f, 0.933333f
MediumPurple3 0.537255f, 0.407843f, 0.803922f
MediumPurple4 0.364706f, 0.278431f, 0.545098f
thistle1 1.000000f, 0.882353f, 1.000000f
thistle2 0.933333f, 0.823529f, 0.933333f
thistle3 0.803922f, 0.709804f, 0.803922f
thistle4 0.545098f, 0.482353f, 0.545098f
gray0 0.000000f, 0.000000f, 0.000000f
grey0 0.000000f, 0.000000f, 0.000000f
gray1 0.011765f, 0.011765f, 0.011765f
grey1 0.011765f, 0.011765f, 0.011765f
gray2 0.019608f, 0.019608f, 0.019608f
grey2 0.019608f, 0.019608f, 0.019608f
gray3 0.031373f, 0.031373f, 0.031373f
grey3 0.031373f, 0.031373f, 0.031373f
gray4 0.039216f, 0.039216f, 0.039216f
grey4 0.039216f, 0.039216f, 0.039216f
gray5 0.050980f, 0.050980f, 0.050980f
grey5 0.050980f, 0.050980f, 0.050980f
gray6 0.058824f, 0.058824f, 0.058824f
grey6 0.058824f, 0.058824f, 0.058824f
gray7 0.070588f, 0.070588f, 0.070588f
grey7 0.070588f, 0.070588f, 0.070588f
gray8 0.078431f, 0.078431f, 0.078431f
grey8 0.078431f, 0.078431f, 0.078431f
gray9 0.090196f, 0.090196f, 0.090196f
grey9 0.090196f, 0.090196f, 0.090196f
gray10 0.101961f, 0.101961f, 0.101961f
grey10 0.101961f, 0.101961f, 0.101961f
gray11 0.109804f, 0.109804f, 0.109804f
grey11 0.109804f, 0.109804f, 0.109804f
gray12 0.121569f, 0.121569f, 0.121569f
grey12 0.121569f, 0.121569f, 0.121569f
gray13 0.129412f, 0.129412f, 0.129412f
grey13 0.129412f, 0.129412f, 0.129412f
gray14 0.141176f, 0.141176f, 0.141176f
grey14 0.141176f, 0.141176f, 0.141176f
gray15 0.149020f, 0.149020f, 0.149020f
grey15 0.149020f, 0.149020f, 0.149020f
gray16 0.160784f, 0.160784f, 0.160784f
grey16 0.160784f, 0.160784f, 0.160784f
gray17 0.168627f, 0.168627f, 0.168627f
grey17 0.168627f, 0.168627f, 0.168627f
gray18 0.180392f, 0.180392f, 0.180392f
grey18 0.180392f, 0.180392f, 0.180392f
gray19 0.188235f, 0.188235f, 0.188235f
grey19 0.188235f, 0.188235f, 0.188235f
gray20 0.200000f, 0.200000f, 0.200000f
grey20 0.200000f, 0.200000f, 0.200000f
gray21 0.211765f, 0.211765f, 0.211765f
grey21 0.211765f, 0.211765f, 0.211765f
gray22 0.219608f, 0.219608f, 0.219608f
grey22 0.219608f, 0.219608f, 0.219608f
gray23 0.231373f, 0.231373f, 0.231373f
grey23 0.231373f, 0.231373f, 0.231373f
gray24 0.239216f, 0.239216f, 0.239216f
grey24 0.239216f, 0.239216f, 0.239216f
gray25 0.250980f, 0.250980f, 0.250980f
grey25 0.250980f, 0.250980f, 0.250980f
gray26 0.258824f, 0.258824f, 0.258824f
grey26 0.258824f, 0.258824f, 0.258824f
gray27 0.270588f, 0.270588f, 0.270588f
grey27 0.270588f, 0.270588f, 0.270588f
gray28 0.278431f, 0.278431f, 0.278431f
grey28 0.278431f, 0.278431f, 0.278431f
gray29 0.290196f, 0.290196f, 0.290196f
grey29 0.290196f, 0.290196f, 0.290196f
gray30 0.301961f, 0.301961f, 0.301961f
grey30 0.301961f, 0.301961f, 0.301961f
gray31 0.309804f, 0.309804f, 0.309804f
grey31 0.309804f, 0.309804f, 0.309804f
gray32 0.321569f, 0.321569f, 0.321569f
grey32 0.321569f, 0.321569f, 0.321569f
gray33 0.329412f, 0.329412f, 0.329412f
grey33 0.329412f, 0.329412f, 0.329412f
gray34 0.341176f, 0.341176f, 0.341176f
grey34 0.341176f, 0.341176f, 0.341176f
gray35 0.349020f, 0.349020f, 0.349020f
grey35 0.349020f, 0.349020f, 0.349020f
gray36 0.360784f, 0.360784f, 0.360784f
grey36 0.360784f, 0.360784f, 0.360784f
gray37 0.368627f, 0.368627f, 0.368627f
grey37 0.368627f, 0.368627f, 0.368627f
gray38 0.380392f, 0.380392f, 0.380392f
grey38 0.380392f, 0.380392f, 0.380392f
gray39 0.388235f, 0.388235f, 0.388235f
grey39 0.388235f, 0.388235f, 0.388235f
gray40 0.400000f, 0.400000f, 0.400000f
grey40 0.400000f, 0.400000f, 0.400000f
gray41 0.411765f, 0.411765f, 0.411765f
grey41 0.411765f, 0.411765f, 0.411765f
gray42 0.419608f, 0.419608f, 0.419608f
grey42 0.419608f, 0.419608f, 0.419608f
gray43 0.431373f, 0.431373f, 0.431373f
grey43 0.431373f, 0.431373f, 0.431373f
gray44 0.439216f, 0.439216f, 0.439216f
grey44 0.439216f, 0.439216f, 0.439216f
gray45 0.450980f, 0.450980f, 0.450980f
grey45 0.450980f, 0.450980f, 0.450980f
gray46 0.458824f, 0.458824f, 0.458824f
grey46 0.458824f, 0.458824f, 0.458824f
gray47 0.470588f, 0.470588f, 0.470588f
grey47 0.470588f, 0.470588f, 0.470588f
gray48 0.478431f, 0.478431f, 0.478431f
grey48 0.478431f, 0.478431f, 0.478431f
gray49 0.490196f, 0.490196f, 0.490196f
grey49 0.490196f, 0.490196f, 0.490196f
gray50 0.498039f, 0.498039f, 0.498039f
grey50 0.498039f, 0.498039f, 0.498039f
gray51 0.509804f, 0.509804f, 0.509804f
grey51 0.509804f, 0.509804f, 0.509804f
gray52 0.521569f, 0.521569f, 0.521569f
grey52 0.521569f, 0.521569f, 0.521569f
gray53 0.529412f, 0.529412f, 0.529412f
grey53 0.529412f, 0.529412f, 0.529412f
gray54 0.541176f, 0.541176f, 0.541176f
grey54 0.541176f, 0.541176f, 0.541176f
gray55 0.549020f, 0.549020f, 0.549020f
grey55 0.549020f, 0.549020f, 0.549020f
gray56 0.560784f, 0.560784f, 0.560784f
grey56 0.560784f, 0.560784f, 0.560784f
gray57 0.568627f, 0.568627f, 0.568627f
grey57 0.568627f, 0.568627f, 0.568627f
gray58 0.580392f, 0.580392f, 0.580392f
grey58 0.580392f, 0.580392f, 0.580392f
gray59 0.588235f, 0.588235f, 0.588235f
grey59 0.588235f, 0.588235f, 0.588235f
gray60 0.600000f, 0.600000f, 0.600000f
grey60 0.600000f, 0.600000f, 0.600000f
gray61 0.611765f, 0.611765f, 0.611765f
grey61 0.611765f, 0.611765f, 0.611765f
gray62 0.619608f, 0.619608f, 0.619608f
grey62 0.619608f, 0.619608f, 0.619608f
gray63 0.631373f, 0.631373f, 0.631373f
grey63 0.631373f, 0.631373f, 0.631373f
gray64 0.639216f, 0.639216f, 0.639216f
grey64 0.639216f, 0.639216f, 0.639216f
gray65 0.650980f, 0.650980f, 0.650980f
grey65 0.650980f, 0.650980f, 0.650980f
gray66 0.658824f, 0.658824f, 0.658824f
grey66 0.658824f, 0.658824f, 0.658824f
gray67 0.670588f, 0.670588f, 0.670588f
grey67 0.670588f, 0.670588f, 0.670588f
gray68 0.678431f, 0.678431f, 0.678431f
grey68 0.678431f, 0.678431f, 0.678431f
gray69 0.690196f, 0.690196f, 0.690196f
grey69 0.690196f, 0.690196f, 0.690196f
gray70 0.701961f, 0.701961f, 0.701961f
grey70 0.701961f, 0.701961f, 0.701961f
gray71 0.709804f, 0.709804f, 0.709804f
grey71 0.709804f, 0.709804f, 0.709804f
gray72 0.721569f, 0.721569f, 0.721569f
grey72 0.721569f, 0.721569f, 0.721569f
gray73 0.729412f, 0.729412f, 0.729412f
grey73 0.729412f, 0.729412f, 0.729412f
gray74 0.741176f, 0.741176f, 0.741176f
grey74 0.741176f, 0.741176f, 0.741176f
gray75 0.749020f, 0.749020f, 0.749020f
grey75 0.749020f, 0.749020f, 0.749020f
gray76 0.760784f, 0.760784f, 0.760784f
grey76 0.760784f, 0.760784f, 0.760784f
gray77 0.768627f, 0.768627f, 0.768627f
grey77 0.768627f, 0.768627f, 0.768627f
gray78 0.780392f, 0.780392f, 0.780392f
grey78 0.780392f, 0.780392f, 0.780392f
gray79 0.788235f, 0.788235f, 0.788235f
grey79 0.788235f, 0.788235f, 0.788235f
gray80 0.800000f, 0.800000f, 0.800000f
grey80 0.800000f, 0.800000f, 0.800000f
gray81 0.811765f, 0.811765f, 0.811765f
grey81 0.811765f, 0.811765f, 0.811765f
gray82 0.819608f, 0.819608f, 0.819608f
grey82 0.819608f, 0.819608f, 0.819608f
gray83 0.831373f, 0.831373f, 0.831373f
grey83 0.831373f, 0.831373f, 0.831373f
gray84 0.839216f, 0.839216f, 0.839216f
grey84 0.839216f, 0.839216f, 0.839216f
gray85 0.850980f, 0.850980f, 0.850980f
grey85 0.850980f, 0.850980f, 0.850980f
gray86 0.858824f, 0.858824f, 0.858824f
grey86 0.858824f, 0.858824f, 0.858824f
gray87 0.870588f, 0.870588f, 0.870588f
grey87 0.870588f, 0.870588f, 0.870588f
gray88 0.878431f, 0.878431f, 0.878431f
grey88 0.878431f, 0.878431f, 0.878431f
gray89 0.890196f, 0.890196f, 0.890196f
grey89 0.890196f, 0.890196f, 0.890196f
gray90 0.898039f, 0.898039f, 0.898039f
grey90 0.898039f, 0.898039f, 0.898039f
gray91 0.909804f, 0.909804f, 0.909804f
grey91 0.909804f, 0.909804f, 0.909804f
gray92 0.921569f, 0.921569f, 0.921569f
grey92 0.921569f, 0.921569f, 0.921569f
gray93 0.929412f, 0.929412f, 0.929412f
grey93 0.929412f, 0.929412f, 0.929412f
gray94 0.941176f, 0.941176f, 0.941176f
grey94 0.941176f, 0.941176f, 0.941176f
gray95 0.949020f, 0.949020f, 0.949020f
grey95 0.949020f, 0.949020f, 0.949020f
gray96 0.960784f, 0.960784f, 0.960784f
grey96 0.960784f, 0.960784f, 0.960784f
gray97 0.968627f, 0.968627f, 0.968627f
grey97 0.968627f, 0.968627f, 0.968627f
gray98 0.980392f, 0.980392f, 0.980392f
grey98 0.980392f, 0.980392f, 0.980392f
gray99 0.988235f, 0.988235f, 0.988235f
grey99 0.988235f, 0.988235f, 0.988235f
gray100 1.000000f, 1.000000f, 1.000000f
grey100 1.000000f, 1.000000f, 1.000000f
dark_grey 0.662745f, 0.662745f, 0.662745f
DarkGrey 0.662745f, 0.662745f, 0.662745f
dark_gray 0.662745f, 0.662745f, 0.662745f
DarkGray 0.662745f, 0.662745f, 0.662745f
dark_blue 0.000000f, 0.000000f, 0.545098f
DarkBlue 0.000000f, 0.000000f, 0.545098f
dark_cyan 0.000000f, 0.545098f, 0.545098f
DarkCyan 0.000000f, 0.545098f, 0.545098f
dark_magenta 0.545098f, 0.000000f, 0.545098f
DarkMagenta 0.545098f, 0.000000f, 0.545098f
dark_red 0.545098f, 0.000000f, 0.000000f
DarkRed 0.545098f, 0.000000f, 0.000000f
light_green 0.564706f, 0.933333f, 0.564706f
LightGreen 0.564706f, 0.933333f, 0.564706f

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

==Editor Support==
Color support is dependent on the support for the containing features in any specific editor.

==External links==
Wikipedia article on RGB colorspace http://en.wikipedia.org/wiki/RGB<br>
A Page with samples of these colors. http://web.njit.edu/~walsh/rgb.html
[[category:Map_Objects]]
[[category:Map Making]]