[CF-Devel] Client/server protocol enhancements.

[David Hurst]

>
     
       Sending this to the list to see if anyone has anything in addition to what I
     
     >
     
      describe below aded - its easier to extend some of this all in one swoop so that
     
     >
     
      different revisions of the same function are not needed, even if for the current
     
     >
     
      time, the value may just be zero.  For this reason, some of these va
     
     >
     
     
     >
     
      ===
     
     >
     
      Item communication enhancements:
     
     >
     
      In addition to what gets sent now, send the following pieces of information:
     
     >
     
     
     >
     
      client_type (16 bits): this is used for the client for sorting items.  This is
     
     >
     
      informative only - a map maker that wants to disguise an item as something else
     
     >
     
      could change the client_type.  Likewise, things like poisoned booze would have
     
     >
     
      the same client_type as normal booze.  Also, the client_type would not have a
     
     >
     
      1:1 mapping to real type, for example, right now the container type covers bags,
     
     >
     
      quivers, sacks, luggages, etc.   My personal thought would be that items of a
     
     >
     
      similar type would be in groups of 100 (eg, all container items might be in
     
     >
     
      100->199, weapons in 200->299, etc), this gives plenty of space for subtyping
     
     
This sounds good, I am not sure about how many weapon types we have particularly if we include bows and start moving alot of artifacts to .arc files.

>
     
      client_tag (32 bit): This information can be used for whatever the client wants
     
     >
     
      to use it for - it bsically provides a persistent place for the client to note
     
     >
     
      things about items.  The server would not
     
     >
     
      use this for anything, but if the object is dropped on a non per player unique
     
     >
     
      map, this information would get confused (as otherwise the next person that
     
     >
     
      picks it up would have a potential bogus client_type).  Things client_tag could
     
     >
     
      get used for - changing the name of an item (client would have an interface to
     
     >
     
      let the user change the item name, record the new name as well as the
     
     >
     
      client_tag).  It could also get used for favorite lists (think of the different
     
     >
     
      tabs in the gtk client, and add another one or two which have the items you may
     
     >
     
      frequently switch between).  Its really up to the client want to do with this. 
     
     >
     
      Note that client_type information is probably pretty client specific - at least
     
     >
     
      to the same level as the keybindings are.
     
     
Don't know much about this so I wont comment.

>
     
      body_location (32 bit): This is not currently implemented, but has been
     
     >
     
      discussed - rather than the hardcoded information currently the server that
     
     >
     
      armor goes on the body, helms on the head, and limits so set up, this would
     
     >
     
      change it so that a bit in this field would determine where it gets put on (bit
     
     >
     
      1 might be body, bit 2 left hand/arm (shield), bit 3 right hand/arm (weapon),
     
     >
     
      etc.  For the different body types in crossfire, the number of different pieces
     
     >
     
      would be determined (thus, an ettin would have 2 heads, and could then wear 2
     
     >
     
      helmets).  If multiple bits are set, that means all those body parts are needed
     
     >
     
      (thus, given my example above, if bit 2 and 3 are both set, it would mean its a
     
     >
     
      2 handed weapon).  This information is useful for the client because it can know
     
     >
     
      what items may need to get unequipped before something gets equipped, and also
     
     >
     
      allows more useful information for the doll figure.
     
     
Of course everyone knows my view here, I am in total agreement with this plan. In terms of bits, it seems that this may not be entirely perfect. For example, if you wanted a second head you have to designate another bit to it. Surely an int variable for something like that would be more useful ie int head = 1; head = 5 (hydra)? I am not very good with c so if this is the only option so be it, it would be good to have this instead of the current system.

>
     
      ===
     
     >
     
      Look item improvement:
     
     >
     
      Currently, whenever you drop something, or anything appears on the space you are
     
     >
     
      standing on (thrown, spell, whatever), the entire stack of items you are
     
     >
     
      standing on is re-sent.  This is because the order is needed for apply below to
     
     >
     
      work as the player might envision it should.  The simple solution is to remove
     
     >
     
      the apply below functionality, and extend the client so that if just an 'apply'
     
     >
     
      is issued, it looks at what it has in the look window and send the apply with
     
     >
     
      that specific object.  This saves bandwidth, and removes one of the last places
     
     >
     
      where ordering is relevant.
     
     
This sounds good

>
     
      ===
     
     >
     
      Add a general purpose way for the client to request information:
     
     >
     
      C->S: requestinfo <type> <parameters>
     
     >
     
      S->C: replyinfo <type> <paramters> <data>
     
     >
     
     
     >
     
       If the client requests information that is not valid, then data would be
     
     >
     
      something like 'invalid'.
     
     >
     
      Type would just be text.  Data would be specific to the type of request - the
     
     >
     
      client should know based on the type of request how to parse the data.
     
     >
     
     
     >
     
      Things I current envision this being used for:
     
     >
     
     
     >
     
      image_info: With the merge of the alternate set into the main, and potential for
     
     >
     
      any number of sets, this would request the server to tell it about this
     
     >
     
      information  (what sets are available, their size, fallback, etc).
     
     
This is a good idea, I like that idea of being able to request information in this form, I am not sure how the back end of the server works? how flexible is it? Can you for example, request map size?

>
     
      numfaces
     
     >
     
      faces <start num> <end num>:  Request the number of faces, and then request
     
     >
     
      specific face information in some range.  The returned information would be the
     
     >
     
      number, the name of that face, the checksum, and what set that image is from. 
     
     >
     
      In this way, the client can easily find out how its cached faces match up, and
     
     >
     
      update any faces it may be missing before play even starts.
     
     
Anything in this direction I guess is good.

>
     
       Note that requestinfo is not specific to image information - it could also be
     
     >
     
      motd, who command, etc.  There may not be a reason for most of those unless the
     
     >
     
      client desires a method to be more surefire of getting the information instead
     
     >
     
      of trying to get it out of drawinfo commands.
     
     
Don't really follow this

Some important and useful features here, thumbs up

dnh