[CF-Devel] client cpl.ob.face at the start

[Mark Wedel]

Michael Toennies wrote:
>
     
     
     >
     
      Hi
     
     >
     
      Ah, thanks for the fast patch.
     
     >
     
     
     >
     
      Can you insert a patch for the experience too?
     
     >
     
      To include it easily also with older client, we need a better
     
     >
     
      interface for client->server setup.
     
     >
     
     
     >
     
      For the sound for example, you can make set it on/off.
     
     >
     
      But you must waste a cmd for it.
     
     
 I don't know if waste is the correct term.  And its not like we are restricted
to a small number of commands for the protocol.

>
     
     
     >
     
      Better we use a kind of setup cmd.
     
     >
     
      Like:
     
     >
     
     
     >
     
      SETUP <len> <(word) cmdid> <(word) value> <(word) cmdid> <....>
     
     >
     
     
     >
     
      Thats bottom up compatible and we dont must use the VERSION cmd for it.
     
     >
     
      We simply can set:
     
     >
     
     
     >
     
      SETUP SETUP_SOUND ON SETUP_EXPEXT ON .... and so on.
     
     
 A few comments:

 1) the client & server always needs to have at least some level of
compatibility between them.  If we take your example above, what do we do if the
server does not have the experience extension, and how does the client know it? 
There probably needs to be some level of acknowledgement, especially if the
client requires some 'extension' to work properly.  Going back a few releases,
if your client only supported png's, and tries to connect to an old server, it
needs to know that server does not have png support and thus bail out.

 2) I would rather not have the protocol commands/coding get too complicated
with (if this extension then else if that one then else if this, etc).  This
tends to create more bugs and is harder to debug.  IT is of course near
impossible for me to debug something if the unix client doesn't support that
extension, so in some sense, the unix client basically needs to be a referance
and at least support all the various commands (what it does with the data may be
another case)

 3) The current protocol versions is largely there so a client a few revs back
won't immediately break if it tries to connect to the latest server.  At some
point, the code to support these olders clients will be removed

 Now one problem with the current protocol scheme is that it is not very exact,
but the point of it was basically to know how up to date both the client and
server are.  If for example you had protocol rev 1045, and then had changes to
go to 1046 and then changes to go to 1047, if the client claims to be rev 1047
compliant, it must also be 1046 client.

 Now what it chooses to do with that data is up to it.  A client that lacks
sound capabilities but does not send a command to turn sound off should still
deal somehow with the incoming sound commands.  It may choose to just ignore
them, but none the less, it must be able to handle them in some way.

 One problem/issue is that there is a potentially huge set of data out there
which it could be nice for the client to know.  The problem is that this could
result in pretty huge client & server bloat, as well as bandwidth issues.

 In the case of this particular request (sending skill experience information 
to the client), a few notes:
 
1) If I was going to do it, I would just extend the stats command and update the
protocol revision.  ITs not that much bandwidth, but as said, I'm not convinced
this is something that needs to be known often enough to updated.

2) The way the 'skills' command works on the server is currently highly
inefficient.  Some improvements to efficiency can be done, but even then, to
gather the information as currently stored each tick would start chewing up a
lot of cpu time (skills are currently invisible objects stored in the players
inventory.  The skills command traverses the inventory looking for a matching
skill number, and if it finds one, prints the result.  these means it has to
travers nrof of skills * number of objects in the players inventory each time
the command is run).

3) Adding fields in the player structure which contains the various skill
experience totals could be done, but this is no longer a trivial fix (the
updating of the face for example was a trivial 1 line fix).  And I already have
a pretty long list of things I plan to work on which I consider more important
than that.  Also, at some point it may get less costly if/when invisible objects
are stored in a separate list from visible objects.