[CF-Devel] New Crossfire commands patch.

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Fri Nov 28 18:49:12 CST 2003


On Fri November 28 2003 3:02 am, Mark Wedel wrote:
>
     
        Several notes:
     
     >
     
     
     >
     
        There is a lot of stuff currently in the server that arguably doesn't
     
     >
     
      belong there, and a lot of the current apply logic is such a case.
     
     >
     
     
     

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.

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.

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.

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)


Thanks
Adam Ashenfelter


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


More information about the crossfire mailing list