Re: CF: Suggestion and comments

So I felt a little bad as one of the people that worked on the client
for not documenting, so here is some documentation for the different pieces:
If people have questions, they can feel free to send them to me.  I don't 
expect to spend any time working on crossfire in the near future.
	-Eric

Client side:

Overall, the client talks to the server through a tcpsocket.  It recieves
messages telling it what to do, and it sends inputs to the server.  Many
of the commands are more low-level than would be preferrable, but the
low-level commands mesh better with the current crossfire implementation.

client.c:
  * this file sets up a few global variables, connects to the server,
  * tells it what kind of pictures it wants, adds the client and enters
  * the main dispatch loop
  *
  * the main event loop (event_loop()) checks the tcp socket for input and
  * then polls for x events.  This should be fixed since you can just block
  * on both filedescriptors.
  *
  * The DoClient function recieves a message (an ArgList), unpacks it, and
  * in a slow for loop dispatches the command to the right function through
  * the commands table.   ArgLists are essentially like RPC things, only 
  * they don't require going through RPCgen, and it's easy to get variable
  * length lists.  They are just lists of longs, strings, characters, and 
  * byte arrays that can be converted to a machine independent format

commands.c:
  * this file contains most of the commands for the dispatch loop most of
  * the functions are self-explanatory, the pixmap/bitmap commands recieve
  * the picture, and display it.  The drawinfo command draws a string
  * in the info window, the stats command updates the local copy of the stats
  * and displays it. handle_query prompts the user for input.
  * send_reply sends off the reply for the input.
  * player command gets the player information.
  * ItemCmd grabs and display information for items in the inventory
  * MapScroll scrolls the map on the client by some amount
  * MapCmd displays the map either with layer packing or stack packing. 
  *   packing/unpacking is best understood by looking at the server code
  *   (server/ericserver.c)
  *   stack packing is easy, for every map entry that changed, we pack
  *   1 byte for the x/y location, 1 byte for the count, and 2 bytes per
  *   face in the stack.
  *   layer packing is harder, but I seem to remember more efficient:
  *   first we pack in a list of all map cells that changed and are now
  *   empty.  The end of this list is a 255, which is bigger that 121, the
  *   maximum packed map location.  
  *   For each changed location we also pack in a list of all the faces and
  *   X/Y coordinates by layer, where the layer is the depth in the map.
  *   This essentially takes slices through the map rather than stacks.
  *   Then for each layer, (max is MAXMAPCELLFACES, a bad name) we start
  *   packing the layer into the message.  First we pack in a face, then
  *   for each place on the layer with the same face, we pack in the x/y
  *   location.  We mark the last x/y location with the high bit on 
  *   (11*11 = 121 < 128).  We then continue on with the next face, which
  *   is why the code marks the faces as -1 if they are finished.  Finally
  *   we mark the last face in the layer again with the high bit, clearly
  *   limiting the total number of faces to 32767, the code comments it's
  *   16384, I'm not clear why, but the second bit may be used somewhere
  *   else as well.
  *   The unpacking routines basically perform the opposite operations.

player.c:
  *  does most of the work for sending messages to the server
  *   Again, most of these appear self explanatory.  Most send a bunch of
  *   commands like apply, examine, fire, run, etc.  This looks like it
  *   was done by Mark to remove the old keypress stupidity I used. 

item.c:
  *  I didn't write this piece, so don't really know how it works.

Server Side:

server/ericserver.c:
  * This file implements all of the goo on the server side for handling 
  * clients.  It's got a bunch of global variables for keeping track of 
  * each of the clients. 
  * SWH sends a message, protecting against certain exceptions being thrown.
  * InitConnection initializes the connection with the client, and sends
  * the server's protocol version (the client sends one of these too)
  * PlayerCmd executes commands from the player 
  * VersionCmd checks the version number of the client
  * AddMeCmd adds the player to the game. 
  * KeyConversion/KeyPress/KeyRelease are deprecated.
  * Examine,Apply,Move Cmd handle those things
  * dropconnection destroys the connection from the client.
  * init_ericserver reads in all of the bitmap information, and initializes
  * lots of spoo.
  * CmdMapping is the dispatch table for the server, used in HandleClient,
  * which gets called when the client has input.
  * esrv_remove_player removes a player (called from xfire sources)
  * esrv_drawinfo sends drawing info to the client
  * send_query asks the client to query the user
  * esrv_print_msg draws a normal message on the client
  * esrv_write_ch is deprecated
  * esrv_foo and esrv_bar are for debugging and just ship across server
  * messages
  * esrv_update_stats sends a statistics update.
  * blah blah blah more esrv_* commands
  * esrv_send_face sends a face to a client if they are in pixmap mode
  * nothing gets sent in bitmap mode. 
  * esrv_map_new starts updating the map
  * esrv_map_clearcell clears a map cell
  * esrv_map_setbelow allows filling in all of the faces for the map.
  * if a face has not already been sent to the client, it is sent now.
  * mapcellchanged, compactlayer, compactstack, perform the map compressing
  * operations
  * esrv_map_doneredraw finishes the map update, and ships across the
  * map updates. 
  * esrv_map_scroll tells the client to scroll the map, and does similarily
  * for the locally cached copy.