
   The client is mostly identical to and compatible with all server/clients
   (it's been upgraded from my original udp client from back in the early 
   days of udp).

   Extra feature:	',' puts up a menu ('network' for your .xtrekrc) with 
			4 toggle options and 1 integer entry field:

   NOTE: this feature only works on calvin.usc.edu, _port 2594_ (not 2592),
   and vlsi.ics.uci.edu, port 2592 (my testing server)

   MENU:

   [Don't] Receive variable and short packets		(1)
   [Don't] Receive messages				(2)
   [Don't] Receive kill messages			(3)
   [Don't] Receive warning messages			(4)
   Receive threshold:					(5)
   Done

   (1) Variable and short packets.  This tells the server to send several
   new types of packets instead of the original types.  The technical
   details follow at the end.

   (2) Toggle receive messages.  If off, NO message packets are sent to the
   client.  (NOTE: clicking the mouse button on the reviewAll window also 
   toggles this option.)  I added this mainly to test the effect of completely 
   turning of all messages.  I discovered that kill messages account for a very
   common "blink" just as the player is exploding.  With that in mind I added:

   (3) Toggle kill messages.  Turn off kill message sending.  This is
   especially useful for bases since during an ogg people are dying all
   over flooding your client with 80byte packets each time.

   (4) Toggle warning messages.  Turn off all warning messages.  The problem
   with the current server scheme is that warning messages occur while (or 
   because of) weapons firing.  This is quite detrimental during an ogg or while
   dogfighting since each time you fire more then 8 torps (very common in my
   case since I'm holding the key down) you get "Our computers limit us to
   8 torps..") for every extra torp packet, or each time you fire a phaser
   ("Phaser missed!", "Phaser hit xx for xx points"), even worse, for
   enforced udp sending several phaser packets are sent resulting in several
   warnings everytime you fire a phaser.  Each of these warning packets 
   contribute a tiny "blink" (even on clear networks).

   (5) Receive threshold.  This is complete experimental.  If a non-zero
   threshold is specified then the server will only send that many bytes
   (roughly since it's only checked after each update phaser, i.e. after
    torps, after players, after planets, etc..) in that cycle.  The idea
    is to spread out the amount of information over several cycles so that
    the client doesn't get swamped with a huge packet.  The best way to
    use this I think is to keep your updates high but lower the threshold.
    So far I've discovered that a too low threshold (say < 100) is bad 
    because you'll never get updates for anything other then torps.  But,
    as I said, it's very experimental, I don't know if it's useful or not.
   

   Misc. external client features not necessarily related to the above:  
   1-10 update option selection, visible my-tractor, my-pressor option, 
   planet and player lock galactic icon, different cursors for various
   windows, galaxy ship support, local independent bitmaps, message to
   GOD ('G'), non-warp message feature (hit 'm' and type).

   Misc. internal features:  optimized X drawing and X server traffic (this is 
   the only client that was able to handle 160 torps on local without getting 
   behind on my sun4/110.), good interaction with window managers, new key 
   words in .xtrekrc: 

   'server: <name>'	default server,
   'port: <number>', 	default server port,
   'udpClientSend: [0-tcp, 1-simple udp, 2-enforced UDP,
   		    3-enforced UDP (state & weap)]', 
   'udpClientReceive: [0-tcp, 1-simple udp]',
   'udpSequenceCheck: [on/off]'
   'tryUdp: [on/off]'	try to use udp when entering game.
   'buttonmap: <button number><key]...'  mouse button map

   --

   Variable and short packet justification:  The three largest contributors 
   to netrek bandwidth are the packets SP_PLAYER (all player movement), 
   SP_YOU (information relating to your ship statistics, and your status)
   and SP_TORP (torp movement).  In one test I got these statistics:

      SP_PLAYER:      2407 K
      SP_YOU:         1408 K
      SP_TORP:        1118 K
      SP_STATS:       262 K
      SP_FLAGS:       148 K
      SP_WARNING:     139 K
      SP_TORP_INFO:   90 K
      SP_MESSAGE:     82 K,
      ... (the remaining packets account for about 50K)
   
   Without much doubt, the first three (SP_PLAYER, SP_YOU, SP_TORP) contribute 
   most of the overhead. So...

   NEW PACKETS:
      
      ORIGINAL	    	SIZE (bytes)	NEW 		SIZE (bytes)
      --------------------------------------------------------------
      SP_PLAYER		12		SP_S_PLAYER	6	(*)
      SP_YOU		32		SP_S_YOU	12
					SP_S_YOU_SS	12
      SP_TORP		12		SP_S_TORP	6	(*)
      SP_TORP_INFO	8		<not needed>
   
   (*) variable packets, each packet containing 2 bytes of type & length
   information and some number of 6-byte entries, 

   Notice that the reduction in network traffic is very close to 50% of
   the original.

   SP_S_PLAYER:		byte 	bit description
			-----------------------
			0	0-4 player number, 5-7 high bits speed
			1	0-7 lsb of player x/SCALE (client coordinates)
			2	0-7 hsb of player x/SCALE
			3	0-7 lsb of player y/SCALE (client coordinates)
			4	0-7 hsb of player y/SCALE
			5	0-2 high bits of speed, 3-7 direction

   SP_S_TORP:		byte	range
			-----------------------
			0	0-7 torp number
			1	0-7 lsb of torp x/SCALE (client coordinates)
			2	0-7 hsb of torp x/SCALE
			3	0-7 lsb of torp y/SCALE (client coordinates)
			4	0-7 hsb of torp y/SCALE
			5	0-3 war, 4-7 torp status

   Since war & torp status is included in every torp packet, SP_TORP_INFO
   is no longer needed.

   SP_S_YOU and SP_S_YOU_SS are the result of dividing SP_YOU into two
   packets.  Most of the time, SP_YOU gets sent because ship status has
   changed, i.e. damage, fuel, or shields.  The remaining information,
   hostile, swar, armies, and flags are not needed as often.  Therefore it
   makes sense to split SP_YOU into two packets:
      
struct youshort_spacket {       /* SP_S_YOU */
     char       type;

     char       pnum;
     char       hostile;
     char       swar;

     char       armies;
     char       whydead;
     char       whodead;

     char       pad1;

     unsigned   flags;
};

   and

struct youss_spacket {          /* SP_S_YOU_SS */
     char       type;
     char       pad1;

     unsigned short     damage;
     unsigned short     shield;
     unsigned short     fuel;
     unsigned short     etemp;
     unsigned short     wtemp;
};

   Limitations:	the new packets limit max players, max torps, but since those 
   are already limited by client arrays it doesn't seem to be as big a deal.  
