recent bugs
------------

- The window isn't shaded when the menu is shown unless we're connected to a
  server

- On a multihead Linux system with Xinerama, BZFlag spans itself across all
  monitors- usually not what the user wants. This could be fixed by implementing
  Xinerama support in BZFlag's X platform code, or by just implementing an SDL
  platform. SDL already has good Xinerama support, and would vastly simplify
  the platform code if it replaced the other platforms.

- the aggressive filter will occasionally encounter a false-positive match
  due to apostrophe's -- need to take then into consideration.  need a
  a better way to handle localized pre/suffix matching too as a handful
  of international words match incorrectly when an english-common suffix
  is applied.

- reached assertion on either World::getTeleportTarget() or
  World::getTeleporter() after getting killed while jumping towards a
  teleporter (and landing in front of the teleporter, albeit dead).  i
  didn't respawn, waited a couple sec (was chatting), then the assertion was 
  raised.

- Change any documentation/help that says rabbit hunters are black (s/b orange)
  If that change is going to stick.

- the "default" keyword in the email line can get into the HUD, it shouldn't.
  must have missed something.

- list server includes counts for players running on non-public/mis-configured
  servers on the same machine on different ports.  if server runs on port 5156
  with publicaddr set to machine:5156 and then also runs another on 59999 with
  publicaddr set to machine:5156 (by accident or otherwise), then player joins
  to the 59999 server mask the 5156 server.  it'd be easy to blow this off as
  expected behavior, but I expect one can also trojan any server's counts 
  using this same technique..

- client crashes upon receipt of a corrupted MsgFlagUpdate message.
  (See http://bzflag.secretplace.us/packet.txt for an example)

- GL Bugs: Looks like the handling of gl contexts is severely messed up in
  bzflag, and there is no very easy cure for this. Someone obviously had
  noticed this before and commented out a glDelete statement in the
  lighting code. Details:

  bzflag uses several classes like OpenGLDisplayList to wrap gl objects.
  These classes use rep subobjects which store the actual state and
  use reference counting. The state can be as simple as an integer
  (for display lists). This integer refereces some object which is
  handled by gl internally and must be created and deleted by calling gl
  functions (like glGenLists() and glDeleteLists()). The bzflag
  classes resp. their rep classes call these functions to create and delete
  the gl objects automatically when necessary, i.e. creation happens when
  a new object is created from nothing (not a copy) and destruction happens
  when the ref coun tof the rep object falls to 0.

  The problem happens when the gl context changes, for example when the
  video resolution is changes on Linux or (I suppose) one switches on
  Windows with alt tab. It is my understanding now (I myself am clueless
  about OpenGL), that the above mentioned ids (referring to a gl display list
  object for example) are related to a gl context. So when the old gl
  context is destroyed and a new one is created and bzflag creates to
  gl objects, it might well receive an id which is still bound to a rep
  object. When that rep object's ref count falls to zero, it will call
  the gl delete function on that id, but this will now delete the new gl
  object for the new context -> oops.

  When freeing the gl context, bzflag should probably first delete all
  gl objects or at least invalidate them, so they won't be deleted when
  the other context is in place.

  I have tried to simply get rid of all the gldelete calls and then it works
  more or less, except for a strange effect where the sky/ground is messed
  up for a fraction of a second after switching resolutions.

  Another note: how is it with contexts and several window like in
  -view three/stacked? Not that I can test it because these views simply
  coredump on me.

- Mac OS X client outputs an Info.plist file with the permissions set
  incorrectly if building an application bundle via XCode.

- saveworld does not save world weapons
  MAC: Unfortunately world weapons aren't sent to the client, so
  there's no way for the client to write them. I suppose they could 
  be packed in the database, for only the purpose of 'saveworld'.

- Spawn code sometimes spawns you mid-air

- doc/guide/NetworkProtocol.xml is not up to date

- Shift+Tab seems to be bound to jump without being bound to jump
  It doesn't happen on Linux. Shift+Tab action is untranslated by XLookupString
  (xfree86 4.3), so need custom code to go into bzflag. 

- menu does not display modified values after quitting and returning, although
  the bindings appear to remain in effect.
  I cannot reproduce this. Can someone give more details, maybe an example?

- Flaghelp falls into the radar area when radar is 'bigger'

- Address Exception reported when unpacking a FlagType in MsgFlagUpdate on
  client in Rabbit game. The reported message buffer address was bad (ie
  0xbfffd7ed) Could we be running off the end of the packet (ie count is
  fubar'ed?) Perhaps add sanity check for not overruning end of buffer.

- On a FFA game, where no purple was allowed a Team size of 65535 was displayed
  for Purple.

- bzadmin seems to be less responsive over the network than bzflag - a
  bzadmin client can get kicked from a very active game by the server
  for causing it to queue too many packages (there's a limit at 20kB, when I
  removed it the queue went up to at least 64kB)

- os x client audio is very choppy when the user has a sound card installed

- bzfs should re-resolve the list server IP if it can't reach it for an update

- make distcheck does not work unless bzflag is configured the same day you
  do make distcheck. Cause is the different version of the two, for the date
  things

- make maintainer-clean does not enter DIST_SUBDIRS
  so all Makefile.in and Makefile files are not removed correctly
  (this is probably a bug in automake 1.4, not in our files)

older bugs in BZFlag
---------------------

see the bug tracker on SourceForge for more
http://SourceForge.net/tracker/?group_id=3248&atid=103248

* exploding tank parts sometimes move along the ground instead of
   flying up into the air.

* not dropping a flag grabbed just before being destroyed

* same stipple on teleporters and phantom zone, making phatom
   tank behind teleporter virtually invisible when blending is off.

* not drawing back to front when depth buffer is on:
   flag edges can't be antialiased right
   teleporter blended on top of shots in front of them

* line stipple doesn't (can't) match polygon stipple
   messes up shadow of flag stem

* can sometimes appear in front of bad guys

* some linux systems get XIO error on startup
   no idea why but it's consistent on those systems
   (probably XIJoystick code?)

* not blanking screen during win32 startup
   should black out screen before changing resolutions
   should raise on top of task bar
   also black out screen when quitting until resolution restored

* error dialogs on win32 may appear off screen
   only when display resolution was changed
