Re: CF: players' handbook, client/server

[Eric Anderson <eanders@cs.berkeley.edu>]

So I sent a long message to this list with a lot of details about the
client/server pieces I wrote.  I've replicated it below.

jklar@lucent.com writes:
 > 	item		transfers examined item info
 > 	drawinfo	tells the client to send a text message to user
 > 	stats		transfers character stats
 > 	pixmap		transfers pixmap data
 > 	bitmap		transfers bitmap data
 > 	version		transfers version data
 > 	player		transfers (trivial) player object info
 > 	
 > 	foo(*)		tells client to output a string to STDOUT
 > 	bar(*)		NOP(?)
 > 
 > 	addme_failed(*)	tells client to print a failure string to STDOUT
 > 	addme_success(*)tells client to print a success string to STDOUT
 > 
 > 	query		tells the client to get a response from the user
 > 
 > (*) I'm assuming these are debugging commands
Yes.  It's easy to convert foo to bar, which is why bar serves as a noop.
It also lets you tell what code the server is executing to make sure
that you understand what's going on inside the server without having to
implement anything new on the client.

 > Hmmm, how is Line-Of-Sight handled?  Looks like I'm going to have to hunt
 > around for the client->server messages.  With any sort of luck and motivation,
 > I should have the basic protocol (commands w/arguments) documented by the end
 > of the weekend.
line of sight is handled on the server.  This is the way it should remain
since you don't want to give the client any information it shouldn't have.
	-Eric

****Message from before:*****
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.