CF: players' handbook, client/server

[jklar@lucent.com]

Re: players' handbook

Hey!  Good start!  A few other comments...

- In a typeset document you want to stay away from underlining
- There are several '--' pairs that should be converted to a single dash.
   Pairs are valid for monospaced fonts, but an em-dash should be used in
   a typeset document.
- Use a monospace font for email addresses
- What's a 20 kg Sheila? (pg 35, towards end of section 6.3.1) :)
- I have been unable to find anything crossfire on ftp.i.net

Other Suggestions:
- Add a walkthru of one of the newbie dungeons or at least point
   new players to the Begginers'
- An example is needed of some gods, what powers they grant, what  
   vulnerabilities they inflict


Re: client/server

I've just been poking at this -- please don't take it as a commitment :)

On Fri, 12 Jul 1996, Kris Bosland wrote:
> I think that the client/server interface can start out resembling some
> internal function calls from inside the current server, and then let it
> evolve.

That's pretty much the case.  The c/s conversation is something of a
multilayered (at least 2) protocol:

The eutl library encodes the messages into a stream of Longs, Strings, Buffers
and Char's and prepends an overall message length.  The latter makes a big
difference in performance (an event/interrupt per message intstead of per
byte).

The next layer embodies the c/s conversation.  According to cf-client-0.92.4
the following server->client commands are understood:

	map		transfers encoded map data
	map_scroll	tells the client to reposition the viewport
	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

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.

John