to do list for BZFlag
---------------------

THESE SHOULD HAPPEN BEFORE THE NEXT RELEASE:

* Fix and/or close outstanding bugs in sf tracker that do not require
  breaking protocol.  In particular -- fix the high priority (10) ones
  for 1.10.4 patch release.

THESE ARE LOWER PRIORITY

* reject ADDs on list server where players > maxplayers ditto for each team.

* /identify reply should list groups you are in

* Fix the Windows version of bzadmin so that EOF quits the program, like
  the UNIX version (see checkCommand() in StdBothUI.cxx).

* get a curses system working on windows:  try to build bzadmin on Win32
  using PDCurses (it almost works with the X11 version of PDCurses). It
  currently only works with stdin/stdout.

* bzflag should use the system-supplied zlib if available. Check in
  configure and use system if it's good.

* provide the ability to publish a singer server to multiple list servers.
  (i.e. multiple -publiclist options)  this is useful for a variety of
  reasons, including testing out a new user-reg'd, karmafied list server,
  without needing to run multiple servers.

* when game is over, autoboot everyone after some time, so server cannot be
  blocked forever by one player just sitting there.

* Use listserver to give global announce (e.g. New version released) to client
  & possibly server)

* Smaller ideas: Make PZ have PZ shots, only useahle on PZ tanks, but scare
  the begeebers out of regular folk.

* unable to remap the respawn binding (it's not "specifically/individually"
  provided on the key binding menu) without manually editing the config file
  needs to be decoupled from identify and added to menu.

* make tank scene node not use a list per size mode, just use the scale matrix.

* server should track last reported player and shot positions

* Improve server picked spawn locations
  - server now takes last known position of tanks into accounts
    - could also look at relative facing of tanks as old client code did
  - CTF mode: only spawn in big center-region as in 1.7? Maybe never spawn
    near teamflag or at least not enemy team flag?
  - server needs to track more game state to do this well.
    - shots
    - perform dead reckoning

* remove UDP client setting. code should figure that out now.

* add other db server features
  - see http://bzflag.org/wiki/DbServers
  - player/password registration
  - open group registration. one nick is master for each group
  - karma see http://bzflag.org/wiki/KarmaSystem

* rewrite mac os x display/window code to support app switching,
  resolution mode changes, screen captures, etc.

* make it so keys can be bound to multiple actions, and provide a way
   to do global scoping on key actions

* StateDatabase should probably have min max values for eval values

* split -public <desc> into -public, -description <desc>, and -email <contact>

* support gameinfo requests as one time udp packets and include all the
  same information that bzfls tracks.  We should allow server info, player and
  score lists over udp from any udp address, not just a "connected" player.

* Make bcast traffic and serverlist traffic less blocking. (ie: same select() call)

* listen all the time on udp for bcast game info replies when in Find Servers

* would be nice if LocalPlayer<->Robots wouldn't relayPackets
  (MsgPlayerUpdate) through server. bzflag should be able to act
  as a relay for a local player and the server should know to
  only send one MsgUpdate to the master, who will relay to the
  connected players/bots. This will allow multiple players
  behind one slow net connection to play multiple players
  behind another slow connection. (for example) ie: -relay

* bzflag -relay should attempt to listen and reply on udp, resending server
  info for which ever server it is connected to.  Descriptions should begin
  with "relay:" in this case. -solo <n> should enable this behavior.

* BZDB:
  - rework the BZDB->eval() caching to support expression dependencies - if
    a variable changes, all the expressions that use that variable should be
    updated as well, or at the least, flush the entire cache when a callback
    happens; maybe collapse GlobalDBItem and the extra caching into the same
    class, so all would be auto-cached

  - some bzdb values are stored elsewhere and written to bzdb only on exit.
    these should be stored in bzdb for the entire time; also why are some
    variabels startign with _, while others are not? The distinction between
    the different types of variables stored in BZDB is not quite clear

* make the vertical rico solution more elegant - get rid of
  BoxBuilding::getNormal and fix existing code to do z -
  getNormalRect & the like.

* require an email contact name for public servers. Perhaps
  unpublished by default

* Create a new MsgThrottle message sent from client to server
  to inform server to throttle MsgPlayerUpdates from other clients
  to X. X is set in bzflag.bzc. Server uses PlayerInfo.lastState to
  batch send PlayerUpdates after throttle time has passed.
  Clients timestamp updates themselves, to catch out of order
  packets, but server restamps timestamps to get consistent
  times for all messages.

* Lag information should be appended to MsgPlayerUpdate packet
  by server, and use half in dead reckoning calculations

* remove all DNS lookups from client when contacting a server IP
  supplied from the list server

* add http proxy support in client for contacting list server. Should follow
  the environment variable http_proxy where a sample might be
  http_proxy=http://user:password@proxy.example.com:8080/

* add http connect proxy support in client and bzadmin for talking tcp to game
  servers.  This would use "HTTP CONNECT" like https clients to get to the tcp
  port on a game server. Note that performance will suck and udp will not be
  available.

* allow /dev/dsp* on Linux to be selected someplace. command line,
  environment var, config file, who knows. ;-)

* some bzdb values are stored elsewhere and written to bzdb
  only on exit. these should be stored in bzdb for the entire
  time

* add caching to bzdb for integer/float values, so they don't
  have to be atoi()'ed or eval()'ed all the time. isTrue would
  also be a good one to cache

* document headers with JavaDoc-style comments (for doxygen)

* update doc/guide/NetworkProtocol.xml all descriptors to new format

* support gameinfo requests as one time udp packets (if udp)

* bzadmin should build without GL headers installed fails with:
  ../../include/bzfgl.h:35: GL/gl.h: No such file or directory

* build a prototype(4) for bsd, solaris

* fix up irix idb

* if we stay with tcp/udp then use the same ports for the
   udp pipe as for the tcp pipe on both client and server

* encapsulate stuff requiring platform #ifdef's:
   networking API into libNet.a.
   fork/exec (used in menus.cxx) into libPlatform.a
   file system stuff (dir delimiter, etc.)
   user name stuff

* clean up libraries that could be reused by other games

* move robots to separate binaries and allow either the
   client or server to exec them. Have a server option
   to keep n players in the game which auto spawns/kills
   enough bots to do it. Get rid of bot player type
   completely. bots should get all message types.

* smarter robots

* Add some sort of spacial sorting method to the world database, searching takes too long.

* Use TextureMatrix to generate UVs for objects at scale, move all objects into lists, and
  sent to GL card ( perhaps just for "super high" quality ).

* think about combining the texture/quality options to just minimum, low, normal, and high.

* replace stipple shadows with blend shadows. See if there is any reason to keep stipple.

* add type of shot (normal, gm, sw, etc) to killed message

* radio chat:
   allow players to communicate via low-quality audio.
   already some support built into the server for this.

* consider integrating with a real full-fledged sky model like stellarium for
  more realistic skies: http://sourceforge.net/projects/stellarium/
  very cool, but very low priority.

* consider allowing maps to spcify image based skyboxes.



THESE NEED TO WAIT FOR THE NEXT PROTOCOL BREAKAGE

* Add new messages to the protocol that sends information like players
  IP addresses, full banlist information etc to admins when they become
  admins, and whenever new players connect or the banlist changes. This
  would be very useful for bzadmin, and for the administrative functions
  in bzflag.

* move -synctime data to different Msg packet, or create new one.
  MsgSetVar (ala 1.8) would be a good one

* flags should all be nullflags from client view until
  a) you pick one up
  b) you get the identify flag (send updates for all flags?)
  If player drops a flag and it stays, players have it's real ID.

* shorten laser to like 1.25 normal shot
  This is needed for larger maps so we can send sparse player updates.

* server should send less frequent updates for "distant" players

* move team base packing into WorldInfo (bzfs)
  and add height (z)

* remove flipz from pyr net code and replace with neg height.

* ipv6 support

* consider using ENet http://enet.cubik.org/ for
   the network protocol

* make the texture manager give out IDs ( wrapered or raw ),
  and have everyone use the ID, not the image pointer, as it can change.

* allow user specified textures for world on a per object basis.

* allow user specified textures for tanks on a per tank basis.

* allow user specified meshes for tank models( this has LOTS of issues )
  on a per tank basis.
   figure out what to do with the shadows.
   figure out what to do with the IDL.
   figure out what to about LOD.
   figure out where to atach the flag.
   figure out how to do the 3 lights on top.
   figure out how to do team colors if a team skin is not provided.

* supply tank/map meshes and textures from the server if client does not have.
    implement resouce cache on client and have server offer
    new resources as needed. (md5 resouces to ensure they are the same??)

* allow client to only choose meshs from the server list

* find some way to limit tank skins to team colors.

* Add a platform that uses SDL.

* implement one way cross server teleporters

* implement a visual "server list" game server

* pre-game waiting room:
   provide a means for players to gather before and after
   a game.  basic text chat facilities.  allows players
   to wait for enough players for a game and to discuss
   strategy, etc.  could build this into bzfs easily.

* look into doing projected textures for light glows, this would
  get rid of the 8 light limit.

* look into burning global lighting into world, perhaps with lightmaps. Allow map lights.

* look into useing projected textures or some other shadow method that allows for better shadows.

* look into removing the GL 1.0 code and requireing GL 1.1

* see if 3dfx/other old hardware limits are still practical.

* break rending system into seperate lib and allow difrent rednerers that are targeted
  to hardware or software.

See the Task Tracker on Sourceforge (http://sourceforge.net/pm/?group_id=3248)
for more todo items and future planning endeavors.

