> slowing down the command processing from the client doesn't help out. If I understand correctly, the problem is less that commands are not processed quickly enough, and more that the drop command must be fully processed before the server can tick again. Here's a different (and probably flawed) approach: If a drop command is received, build a linked list of items that match the command, and drop the first item. Defer the rest of the list, and process the rest of the tick. During the next tick, pull the next item in the list, and drop it, then defer the rest for later. If the character moves, the list is discarded, cancelling the rest of the "transaction." This has several effects:
Drop/pickup of lots of items now is capped at 1 item per tick, or 8 per second. Drop/Pickup of 1 item is still "free", it happens in the same tick. Drop/pickup speed could improve in the future if server tickrate is improved. Players are (quietly) encouraged to not pile items so deep, or manipulate them in bulk. > This becomes an O(n^2) operation, so when dropping a few items, it is pretty > fast, but when dropping a stack of 100 different items, that takes a lot of > time. Strictly speaking, isn't it n^2 only for dropping on an empty tile? Dropping items on a tile that already has lots of items is even worse, with a moderate perf penalty even for dropping a single item onto a pile of 100+ items. Not much way around that though, unless you defer the restacking to another thread or tick. But, that sounds quite complex to implement... --Nathan _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire