Protocol refinements, Was Re: [CF-Devel] Does gcfclient have a maintainer?

[Mark Wedel]

Michael Toennies wrote:

>
     
      The compelling reason will come in the future, the game grow and the data we
     
     >
     
      send
     
     >
     
      also. I find the idea, to send the triggered cmds of one action as a batch
     
     >
     
      not so
     
     >
     
      strange.
     
     
 triggered commands may be useful.

 While I agree the data that the server sends to the client may increase, there
will always be a case that the client and server need to know what data they can
send to each other.  So the addition of a batch command does not help that.

>
     
     
     >
     
      Also, there is no "mega command", all what you do is to send the cmds as one
     
     >
     
      package,
     
     >
     
      accessing the socket one time, and use the BATCH cmd as a meta tag, telling
     
     >
     
      the client
     
     >
     
      nothing more than the data are a row of cmds.
     
     
 Which is no different than just sending the individual commands.  Encapsulating
them in a batch command makes no difference.  I don't know why you think it
will.

 What the client & server consider a packet is not the same as the ethernet
packet.  The os the server is on will combine a bunch of small pieces of data
into one physical (ethernet) packet

>
     
     
     >
     
      All what you do is, to assemble the normal cmds from the batch and work
     
     >
     
      through it in the same
     
     >
     
      way you got them as single cmd from the socket. There is no difference in
     
     >
     
      debugging or something
     
     >
     
      else.
     
     
 And no difference in bandwidth.  You save nothing.  You gain an extra level of
encapsulation.

>
     
     
     >
     
      A fact is, that if you play with sound and you have some lag like i
     
     >
     
      yesterday, the game starts to
     
     >
     
      run creepy because you got the cmds for a action (attacking or opening doors
     
     >
     
      for example) not exactly,
     
     >
     
      means you got a message, after some time the sound, etc.
     
     >
     
     
     >
     
      Because a sound need a good timing with your game action, the effect is bad.
     
     >
     
      This will be avoided if
     
     >
     
      you send it in a batch.
     
     
 Please explain how.  Even with batch, the server will still queue up these
commands, that get transmitted down the wire when the bandwidth is available. 
The client still process all data it can when it receives it.

 The problems I see with the batch (or any attempted refinement):
Someplace in the code you need to put a 'start_batch' command for the socket.
server then goes and sends commands as it normally would, now getting queued up.
Someplace else, you need to have a 'send_batch' function that now transmits
all of that.

 I see oppertunity for someone to forget the start batch or send batch, causing
problems.  And as said, it improves performance in absolute no way.

>
     
     
     >
     
      I aggree, but much better is to rip of this artifact and put the useful code
     
     >
     
      in a oldstuff module, where interested people can use it. There is really
     
     >
     
      much
     
     >
     
      unused and odd stuff in the client, i work through much unused structure
     
     >
     
      parts or
     
     >
     
      even double implemented stuff from older versions.
     
     
 Crossfire (and the client) is a constantly changing source base.  I don't
expect that to change immediately. Just the partial resistance will require many
changes in various areas.


>
     
      The food and poison food is a good example. What of course the client should
     
     >
     
      not know is, that one is good food and the other poison. But what it should
     
     >
     
      know is that booth are from type "TYPE_EATABLE".
     
     
 Should the client know different scroll types (spell scroll, skill scroll,
information scroll?)  Those also have different server types.  And I am sure
there are others.  The answer may very well be yes, but there is no easy way to
say 'poison should really be sent as type eatable'.  But I'll comment on that
more down below.

>
     
     
     >
     
      The use of the table is really really bad coding. The names and stuff in
     
     >
     
      there should
     
     >
     
      not be hard coded in any module! They are generated stuff by the map editor.
     
     >
     
      What you do
     
     >
     
      with at runtime generated stuff like "xyz bodypart"?
     
     
 I agree it is not ideal.  Custom items get sorted to the end of the inventory,
which actually is not a bad thing - in many cases, these custom bodyparts are
actually fairly, so having them get sorted differently is not bad.

 Originally, it was envisioned that the client would read in an item_types file
at run time, so each user could customize it to their own desire.  I see that
code never got done.

>
     
      This can be avoided if we define a CLIENT_TYPE_XX. This the type, the
     
     >
     
      user/client identify the item,
     
     >
     
      and when we make it smart it is the type that the server can force the
     
     >
     
      client to know it as it.
     
     
 Yes - that is the 'ideal' way to do it, but would require updating all the
archetypes that the player can pick up.  And perhaps that will gone done at some
point.  That is one of those things - not hard to do, just a lot of work.

 
>
     
      No big reason to drop the drawinfo, but when you extend the the stat cmd,
     
     >
     
      it can be generated on client side, you can drop a cmd and safe some
     
     >
     
      bandwidth,
     
     >
     
      so why not?
     
     
 because the amount of bandwidth the drawinfo uses for saying your protection
spell has ended is insignificant compared to the big bandwidth hogs (map updates
and look window updates?)  I mean, your saving 60 bytes of the course of a few
minutes.

>
     
     
     >
     
      If the client show the stats value, the value can start blinking for 2
     
     >
     
      seconds in red
     
     >
     
      for example, if it drops, this will show it very nice to the player. Most
     
     >
     
      times, you
     
     >
     
      have extended your protection by spell or potion you do it why you must
     
     >
     
      fight or do some
     
     >
     
      action. This will cause often some messages and will make it hard to read.
     
     
 As said, I want do want to change the server and client logic so it can
separate these message types.  That way, all the attack messages could get
shuffled into one window, leaving the other messages (which are more important)
in another subwindow.