===============================================================
Short overview of how Tribes 1 interacts with netcode and demos
===============================================================

 1. The game waits for a packet of data. This can come from a demo
    or from an underlying net connection, the game doesn't
    differentiate.
 
 2. The packet is passed off to the NetStream object.
 
 3. The NetStream object will update the packet rate/size if needed
    and pass off the rest of the data to each of 3 objects:

    A. EventManager will process any non-game events
    B. PlayerPSC will process player interaction with the server
    C. GhostManager processes ghosting objects from the server
    
 4. This same sequence happens in the same order for writing packets
    to the server. Obviously a demo source will ingore the writing packets
    phase.


 NOTE. A demo actually has more than just the packet data from the server
       embedded. It also has player move information to locally update
       the controlled object which is the exact data sent to the server
       when the demo was recorded. 
       
       It also has IDACTION's for zooming embedded, which is how you are
       able to see when a player using the default zoom methods zooms. This
       is also why a player using a custom zoom script that only alters 
       $pref::playerFoV will appear to never zoom in a demo.



=========================
Source Class Descriptions
=========================

T1NetStream (abstract)
----------------------
An abstract (unusable on it's own) class to process Tribes 1 data packets.
T1NetStream handles packet rate and size updates to the server and 
reads and writes to the 3 Tribes handler objects: 
 - EventManager, which handles non-game events such as player messages, 
   team adds, and such
 - PlayerPSC, which handles local player control over game objects, 
   command map information, etc.
 - GhostManager, which handles ghosting game objects from the server and
   keeping them updated

T1NetStream is abstract as it doesn't care where it's source information 
is coming from. You must provide a derived class to feed it data, the 
two obvious choices being a Demo reader class (to stream data from a 
Tribes demo), and a UDP connection class to read live data from a
physical server.

T1Connection
------------
Implements a UDP packet handler for the Tribes 1 protocol. T1Connection
negotiates connection instantiation, packet ordering and drops, and sends 
alerts up to a T1NetStream object.

T1NetLayer : T1NetStream
------------------------
Derived class to source packets from a udp connection (T1Connection). Also
takes care of writing packet data back out to the server.


T1Demo : T1NetStream
--------------------
Derived class to source packets from demos. Nothing special


T1EventManager
--------------
T1EventManager processes non-game object releated events such as player 
messages, datablock events on first join, remoteEvals from the server, etc. 
It reports any interesting events back to a T1Game class, which can then do 
with them what it likes.

The EventManager also handles sending remoteEvals back to the server, which 
is how you interact with the server. It will resend any remoteEvals that are 
dropped.

T1Game
------
T1Game is the final stop for game events that you can act on. It also handles
a T1NetStream object which it passes off game initiation and update calls to.

You choose which type of T1NetStream you want by using OpenDemo or OpenServer,
set any appropriate options you need (SetTimeScale, SetPlayerName, etc) and
then Start / Poll the T1Game object until you're ready to quit. The underlying
T1EventManager and T1NetStream classes will filter events up to your T1Game
derived object for you to act on.

All event functions are stubbed to do nothing by default, except a few like
OnDataFinished_Chain, which remoteEvals a dataFinished / CGADone, or 
OnTeamAdd_Chain, which fakes a CGADone since we don't have any mechanism in 
place to handle ghosting. You only need to override the events you're 
interested in watching in your derived class.



===============
Generic Methods 
===============

Close
-----------------------
Resets the object to an un-opened state, initializes settings
to defaults.

If members don't require initialization, they are left untouched and only 
handled by constructor/destructor. Close does not need to be called before
deleting an object, it is assumed the destructor will call it.

Open
-----------------------
Open prepares the object to be run. Parameters may be passed for 
initialization.

Start
-----------------------
Start attempts to set the object running. If Start is unable to do this, it 
returns false.

Poll
-----------------------
Poll queries the object and allows it to process some work. If the object is 
done and/or ready to be closed, it will return false.


