[CF-Devel] Client/server protocol enhancements.

[Mark Wedel]

 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

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.

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.

===
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.

===
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).

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.

 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.