One thing has started to bother me now. Currently the client is capable of doing selective packet removal - if there are two packets containing moves for the same entity, the earlier packet is dropped and never sent, because the later packet would invalidate it anyway. This saves (surprisingly quite a lot of) bandwidth. But with the new architecture this would be difficult to maintain. If the command did serialize the packet immediately, it would be impossible to later remove that packet from the stream.
The only solution that I can see is to modify the entity move command caller not to emit that command that often - don't move the entity 20 times a second, but only 5 times a second, for example.
I take back the importance of this. I've just tried adding some statistics and the RelEntMoveLook packet is currently not optimized away any single time in over 15000 packets sent. True, that's for a LAN session, WAN results may still vary.
The only solution that I can see is to modify the entity move command caller not to emit that command that often - don't move the entity 20 times a second, but only 5 times a second, for example.
I take back the importance of this. I've just tried adding some statistics and the RelEntMoveLook packet is currently not optimized away any single time in over 15000 packets sent. True, that's for a LAN session, WAN results may still vary.