[CF-Devel] New Crossfire commands patch.

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Fri Nov 28 02:02:47 CST 2003


  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.

  Remember, at one time, there wasn't a client/server model, but when one was 
made, all that code wasn't pulled out.  So while there may be a lot of apply 
logic in the current server, it doesn't mean I want to see even more of it.

  Doing it on the client is in fact simpler in many ways - since the client is 
untrusted, it basically means you can process all the data the client knows 
about - you don't need to worry about floor processing, or 'does the player know 
about that bit of information' - if the client knows about it, it means the 
player knows about it.

  and in that regard, doing this in the client is quite easy - all the bits of 
data are there - client_type to know the type of object.  Name of the object. 
You'd need to make up an item_matched_string function, but that would be pretty 
simple, simply because there are not as many cases to deal with.

  There is already a protocol command to say to apply a specific item.  So once 
you figure out the tag of the item, simple matter of sending that protocol command.

  As said before, if you want to see this stuff committed into CVS, it will have 
to be done in the client.  I care a lot less about code going into the client - 
maintaining it and keeping it bug free is much less important (IMO) for client 
side code than server side code.

  Now there are some things that simply can't be done in the client.  But this 
is not one of them.

  Note there already is an 'inv' command on the client that dumps the player 
inventory.  And the arguement that 'there aren't a lot of command like this on 
the client' is basically meaningless.  If that arguement is used, then there 
will never be any such commands added to the client (no one takes the first step).

  Note it is also very easy to add pseudo bindings to commands on the client. 
Eg, if the player types 'eat', it can then do something like 'apply -t eat' to 
the server.  However, that is more a point of referance, as that isn't what 
should be done in this case.

  What should be done in this case is really quite simple:  Move the commands 
the client.  The client can find the appropriate item type based on the 
client_id types, and then send the apply protocol command for that item.  It 
really isn't going to be any harder to do it in the client than the server.  And 
it belongs in the client.

  I'd note that if the 'apply' command was removed from the server when the 
client was split off, such that the client handled item matching for apply, 
there wouldn't be this discussion right now - it would have been obvious that 
the client was the correct place for this code.  As said above, there is still a 
lot of code in the server which really should be in the client, and probably at 
some point would be.  I don't want to see more code getting added to the server 
that would eventually need to get moved to the client anyways.



_______________________________________________
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