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