[CF-Devel] New Crossfire commands patch.

[crossfire-devel at archives.real-time.com]

Adam Ashenfelter wrote:
>
     
      On Fri November 28 2003 3:02 am, Mark Wedel wrote:
     
     
>
     
      One of the main disadvantages I see with putting these commands in the client 
     
     >
     
      is that there will be a lot more chances to break compatibility with the 
     
     >
     
      client. 
     
     >
     
     
     >
     
      Lets say for instance we implement the new commands in the client.  Then later 
     
     >
     
      on we create a new type of wearable item.  Say a mask or whatever.  Then 
     
     >
     
      "wear" and "unwear"  would be broken in the clients for masks.  Or a new flag 
     
     >
     
      "not owner" or something like that.  Now "eat food" would not know to avoid 
     
     >
     
      food items my player doesn't own (a client side "apply" would also be broken 
     
     >
     
      in this case").  I can think of a lot more examples.
     
     
  That is sort of a straw case argument.  If you add a new type, the server code 
would similarly need to be updated.

  In fact, given that the client uses the client_type field, it will actually 
work better.

  Look at the doc/Developers/objects, then specifically the client_type 
information.  Client_types are put into broad numbers.

Excerpt from that file:
270-279         Headwear (34)
270             artifact helmets (34)
271             Helmets (34)
272             turbans (34)
273             wigs (34)
275             eyeglasses (34)

  So suppose you add a new object - mask.  you give it client type 276, and it 
works fine, because the client would know that objects in the 270-279 range are 
headware type items.


>
     
     
     >
     
      Note: If the new commands should be in the client, then eventualy "get", 
     
     >
     
      "drop", and "apply" should be in the client as well, and would result in 
     
     >
     
      similar problems.
     
     
  Yep - those should be all client side also.

  Note that right now, if you apply an object in your inventory by clicking on 
it, the client sends the 'apply' protocol command, which is different than if 
you type apply.  With that protocol command, it only sends the object id.  The 
server then finds that object and makes sure it is something the client can 
apply (eg, in the players inventory, or on the same space).  That sanity 
checking code is already in place (otherwise, a hacked client could try to apply 
items of tags that don't belong to it).

  Note also that if you click something to drop, a protocol command (moveitem I 
believe) is used to drop the objbect.  It doesn't call the same drop that a 
player might type in.  And same thing - the server does sanity checking to make 
sure it is something that can be dropped (not equipped, not locked, in the 
players inventory, etc).

  And all this code works just fine obviously.  So if you did the client side 
apply, like I suggest, the server already has the code to do the sanity checking.


>
     
     
     >
     
      What we would really be moving to the client would be a string match, and a 
     
     >
     
      type check  for each candidate item.  The server still needs to verify that 
     
     >
     
      we can (apply, drop, get) the item or we open up a lot of cheats.
     
     
  And as said, the server already has code in to make sure the object is 
something the player can deal with.

>
     
     
     >
     
      If what you really want to do, is offload this matching work to the client, 
     
     >
     
      then this is what I think should be done.
     
     >
     
     
     >
     
      1.  Client preparses command, and decides which item should be the target of 
     
     >
     
      the command.
     
     >
     
      2.  The client sends the full command to the server and the item tag of the 
     
     >
     
      item that should be the target of the item.
     
     >
     
      3. The server receives the command and checks the client version.
     
     >
     
      4.  If the client is new enough to handle this command, call the command with 
     
     >
     
      the item tag,  if not reparse the string to make the correct decision.  (The 
     
     >
     
      logic stays, but it is run less often)
     
     
  Don't need to do any of that - built in apply command that only takes an item 
tag is already in the protocol, and already extensively used.  So all you need 
to do is #1 - steps 2->4 are already done or not needed.



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel