[CF-Devel] Client/server protocol enhancements.

[Mark Wedel]

David Hurst wrote:

>
     
      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.
     
     
 Presumably less than 100.   Its really not too relevant - it really depends on
how the stuff splits up.  For examine, major weapon artifacts (the ones that
currently do have .arc files) might just be given one unique type (artifact
weapon).

 In an ideal world, the client would have controls on how you want the stuff
sorted, so the actual number mapping wouldn't be quite as relevant.


>
     
      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.
     
     
 You confusing what body part(s) and item goes on compared to how  many body
parts the creature may have.

 For example, all helmets may have bit 1 set, saying it goes on the head.  That
says nothing about how many a person can wear.  Each monster/player would have a
body part,which would say it has X heads.

 So in terms of how this works:

 Player tries to apply an item.
 Server looks to see what body_location bits are set.  It then goes through all
the items in the players inventory, and sees how many other objects are already
applied (eg, how many finger items, or how many head items, etc).
 Server then looks at the body_type and sees how many of those bodyparts (heads,
rings, whatever) the creature has.  If it has more than are currently being
used, the item gets applied.  If it has fewer, it tells the player to unapply
something or removes it for the player.

 Now the body type of the player does need to get communicated to the client at
login type if the client is making a doll type figure.

 A few other thoughts I have on this:

1) This should replace all the flag_can_use... values.  If the creature has the
appropriate body part available to an item, it can use it.
2) For monsters, they would just have a pointer to the body type of their
appropriate type (humanoid, big dragon, small dragon, etc - there are probably a
lot fewer body types than monsters, so this makes work easier).  If you want a
monster to be stupid and not use items (say a zombie), then you just set its
body type to one that doesn't use anything.
3) Player structure would have its own copy of the body type.  When you change
religion, this private copy may get updated in various ways based on
restrictions (eg, can't use weapon would result in the number of weapon hands
being reduced to zero.  At the same time, you could increase the number of
shield hands by one).  Probably the way to do this is for the body type
information to be signed (so negative values are allowed), and when changing
religion, the body_type of the specific religion archetype is used to modify the
values (after first undoing the changes from the current religion).
4) Such a system could allow for critical hits against players if desired (eg,
critical hit that removes the left hand would reduce the shield hand by one as
well as ring fingers by one).

===

 Now as I think about it, the range stuff as current done is really misplaced.
In history, at one time the gui was built into the server.  The range stuff was
obviously a method for shortcuts (easily cycle between wands and spells and
whatever else).

 This should really be handled by the client.  You select a wand, and the client
adds it to its list of range types.  cast a spell, the same thing.  In theory,
you could have multiple items of the same type (wand, rods, scrolls, whatever)
readied as different range types.  When you then fire, the client sets what
range type you have set, and sends the appropriate command (fire direction
<item_tag>).

 Ideally, you would want some way for the client to validate that the spell you
are about to cast is something you can actually cast.  There has been talk about
the server sending the client the spells the player knows - this is not an exact
science, as many things might change the spell parameters (putting on a denied
item means you can't cast the spells, yet still know them for example, and
attuned or repelled would alter the spellpoint costs).  Changing levels, either
positive, or negative, would also have effects.
 
>>
     
      Add a general purpose way for the client to request information:
     
     >>
     
      C->S: requestinfo <type> <parameters>
     
     >>
     
      S->C: replyinfo <type> <paramters> <data>
     
     >
     
     
     >
     
      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?
     
     
 The client can try to request anything.  OF course, the server needs to have
some logic in how to answer the request.  This isn't a lot different than just
having unique protocol commands for each type of request - the advantage of
making a general method is that newer clients can try to request something
without the server getting too worried if it can't answer it, and at the same
time, the client gets an acknowledgement that the server did not understand the
request (right now, if someone sends an invalid protocl command, it basically
gets dropped).

 all the <type> above would need backend server code to formulate the reply.  So
you can't request arbitrary data (eg, password for character xxx) and expect a
reply.