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

THESE SHOULD HAPPEN BEFORE THE NEXT RELEASE:

* command line options that have -set <name> <value> equivalents should be
  reviewed and possibly eliminated

THESE ARE LOWER PRIORITY

* Send world weapon 'tilt' info over the wire for saving maps

* look closely at how local and global logins / groups interact:
  - add option for non-public servers to use global logins? (match servers)
  - add option for public-servers to not use global logins?
    (if no passdb, then they only use global logins ie: no /register)

* bzfs should error out if no users or groups have SPAWN

* bzbb login names are used for global authentication. If the user changes
  bzbb login names (which is possible), this can cause problems Another user
  can take up the old name and get that user's permissions. Internal bzbb IDs
  are unique, though, maybe somehow move to those. This would fix some issues
  and create others. All the implications are not quite clear yet. Best
  practice at the moment: Don't change your bzbb login name.

* fix the misalignment between the selected server and the one that
  is joined when the Server List Cache is enabled.

* Teach Roger not to drive into deadly physics drivers.

* need to verify that the anti permissions (e.g. antiban) really do
  prevent the action properly (e.g. you cannot get banned if you have
  antiban -- even from master ban list).

* integrate motd.php into mysql on db

* add language translations for the new flags

* fix the corners and edges on the tabbed panels (corner pixels are
  missing)

* configure should test and enable the fudged acosf atanf asinf

* 1/2 the board split diagonally does not draw the ground for TimRiker
  Debian unstable powerpc with a Radeon 9200. a driver bug

* should only send out and print those objects which are required by
  the map. This could be implemented by added a referenced() member
  function to each type that would be be called during
  ObstacleMgr::makeWorld()  (including materials, physics drivers,
  texture matrices, transforms, and dynamic colors).

* grouping for links (with  relative and absolute names)
  grouping for weapons and entry zones (with transforms)
  grouping for physics drivers (with transforms and copying)
  grouping for texture matrices, dynamic color, xforms, and materials
    (mostly for keeping a clean namespace)

* if libcurl is going to be the path forward:
  * convert to multi from simple
  * use curl_multi_fdset so it's non-blocking
  * implement list server access in curl
  until these are done, TimRiker recommends disabling curl
  on all public builds.

* sdl build does not set the application icon .. kinda important for
  the folks with icons

* improve the mesh collision code (edging)

* incorporate the player's handicap value into the check calculations.

* incorporate physic drivers into the check calculations.

* kill as many "externs" in .cxx files as possible. evil and wrong.

* the players have spoken, and hold-the-flag is wanted

* Iterative octree cell shot collision detection

* instead of kicking laggy players, they should be made observers
  unless there are no observer slots left (then kick).

* ban both the player's name in addition to their IP case insensitively.
  (at least on a poll ban) (might not be relevant with central login)

* keep track of the last messages sent by a player in the last N
  seconds and auto-silence them if they spam any specific message
  within that time frame.

* need to test for AR so that SGI build uses -o instead of cru

* extend player name cycling (like on /kick and /ban) to /poll kick and
  /poll ban

* reject ADDs on list server where players > maxplayers ditto for each team.
  probably want to verify this data in the callback.

* /identify reply should list groups you are in, perhaps global identify too

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

* provide the ability to publish a single 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.

* make tank scene node not use a list per size mode, just use the scale matrix.
  (the disadvange is the speed hits from GL_NORMALIZE or GL_RESCALE)

* server should track last reported player and shot positions (done?)

* Improve server picked spawn locations
  - 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
  - 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>

* require an email contact name for public servers. Perhaps
  unpublished by default. Perhaps a central username, probably without password

* support gameinfo requests as one time udp packets and include all the
  same information that the central list server 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.

* 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.

* 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

* 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

* 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

* 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 specify image based skyboxes.



THESE NEED TO WAIT FOR THE NEXT PROTOCOL BREAKAGE

* 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

* 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 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 attach 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.

* 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.

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

* break rendering system into separate lib and allow different renderers 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.