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