[CF-Devel] Client/server protocol enhancements.

Mon Dec 31 00:02:31 CST 2001

Scott MacFiggen wrote:

>

      onscreen player position: Right now the client does not know where on

     >

      the screen the player is, usually it is right in the center but not

     >

      always. If the client knew this information, it could do a few neat things

     >

      in terms of user-feedback. Like flashing the player square red when

     >

      resistance to fire is either lost of attained...

 I can't think of any cases where the player is not in the center of the map. 
The functions that pack the map data and send it to the client always place the
player in the center (starting at player position - half size of viewport to
player position + half size of viewport).

 Now if the client is using even map size (eg, 14x14), there is no true center
(or there is a 4 space center area if you want to think about in that terms). 
In that case, I think the player would always be in the upper left portion of
that 4 x 4 center area - not positive on the positioning, but I can say with
fairly high certaintity that positioning will not change and the behaviour is
well defined.

>

     >

      checksum of the image file the server is using: To help with image caching,

     >

      if the server sent a checksum of the file containing all the

     >

      png images, it would know if the images it has in its cache from a

     >

      previous run are still valid or not.

 Server already provides this on an image by image basis, so if the client is
caching, the client can know if its version is up to date with what the server
has.  If your talking about something else, please do followup.

 A few notes on this however:
1) I already have modified the server (I'll check it in tonight - it has no
problem with older clients, as the change is transparent for the client unless
they reqeust a different set) to handle multiple image sets - thus, the server
can provide both the main and alternate set, the client during setup says which
one it wants.
2) If the client supports it (based on the client using a faceset setup
command), the client is told what image set thte image is about to get belongs
to, as well as its checksum.
3) I plan to modify the caching on the client so that it caches the image into
appropriate sub directories based on the set the image belongs to - thus, going
between the main and alternate set won't result in your cache getting
re-written.
4) I plan to have the client be able to look for images in a system wide cache
(defined by prefix/sharedir as built) - this system wide set can then also be
easily distributed in rpm and tar form for people to install.
5) I also plan support for the client to be able to get the checksums for all
the images the server has (of the set the client currently plans to use), so if
there are new images or changed images, the client can download them before play
starts.

>

      Does the server currently allow dynamically changing the viewable

     >

      area size? That could be a nice client feature.

 Maybe.  If not, the code to do this would be pretty easy (just need to re-set
the server side map caching).  I've never tried it myself - simplest would
probably be to have the client try it and sees what happens.  There is no
technical reason this can't be done.

>

     >

      Umm, can the client currently get a list of all spells and spell

     >

      descriptions and stuff from the server? What about skills?

 The server doesn't even have a list of spell descriptions.  Now are you talking
about what the player knows, or what just exists on the server?

 The later isn't too difficult.

 The former isn't really difficult depending on how accurate you want it to me. 
Spells get trickier because there are many factors that can affect if a player
knows or can cast a spell (level gain could affect the list).  But also putting
on attuned/denied/repelled items can affect what you can cast.  And if you care
about spellpoint cost, those items can also effect it.

 The simple solution would be to just send the players entire spellist when the
player logs in and whenever one of the spellcasting skills change level.  The
only potential downside on such an approach is that when you gain a level, that
is most likely when you are in heavy combat or whatever, and would really like
to try and minimize any extra data transmission that may cause extra latency.

 A simple solution for that is for the client to request (and get) the spellist
when the player logs in, and in whatever gui mechanism or whatever the client is
using to display the spells, have something like an 'update spell information'
button - the player is probably the best judge of when a good time to update the
listing.  I suppose the client (or server) could try and watch traffic and
determine a 'quiet' time to send non important updates to the client.

>

      It would also be nice if the client could get a list of all

     >

      player races and ability score bonus/penalties and starting

     >

      skills for a better new player interface.

 I agree that the current method is not good.  IMO, in addition to it rolling
dice, the player should just get some number of points to make the stats he
wants.  I know peter at one point made some hack to a client for it to roll
stats until something 'good enough' was achieved, but given the handshaking
involved, that was still a slow process (eg, server rolls stats, send them to
client, client has to examine them, and then say, no roll again, but you have
the issue with latency for all of those, so if your server is 100 ms away, it
basically means you can perhaps do 2 characters/second)

 My thought on how this could perhaps work is something like:

S->C: newplayerstats <total
points><race1><adjustments><description><race2><adjustments><description>...
C->S: Newplayer <str><dex><con>...<race>

 Server then verifies that the data is OK (eg, valid race, that the point total
is within range, and that the stats themselves are within valid range for the
race)

 This first removes the necesary of rolling a dozen times to get a good
character.  It also means that the client can have a much nicer interface, and
it also removes a lot of code from the server.

>

      Would it also be possible to make the client/server handshaking more

     >

      strict? So like enforce sending version and setup commands before

     >

      anything else.

 The version commands are getting obsoleted - using the setup command to
describe the feature the client is capable of works well, and this can also get
used to indirectly check for server capability (eg, request for some feature,
and if the servers reply to the setup command is that it doesn't understand that
options, you know not to use it).  Currently, this hasn't been done, because
only new S->C commands have been added, not the reverse.

 We can certainly make things more strict - is there anything specific you have
in mind?  I can certainly see that changing what map command you are using in
midstream could have odd effects.   OTOH, for the most part, I can't think of
any that will really cause problems for the server, and some of the setup
subcommands should probably be issuable at any time (eg, turning sound off).

 But I have no problem saying 'this setup command can only be issued during
initial setup with the client' in cases where trying to support it during active
play could make things really complicated.  But I'm mostly concerned about this
on the server issue - if, for example, it was very difficult for the server to
handle a change of mapsize it sends to the client, then saying that can only be
sent at the start of negotiation is fine.  But right now, I can't think of any
of them that are hard for the server to handle at any time - more likely, the
client might have trouble, but then its more an issue of telling the client
'don't change the commands if you can't handle it'.

>

     >

      I'm sure I think of some more stuff later..

 No problem.