Originally Posted by
dspguy
Part of the problem is physics. You have a propagation delay from you to the server and back. Mind you, that's just for one bit over the wire. That's before we talk about the transmission delay. These add up awfully quick and only a few of them are something the server can do something about.
The "jump action" is produced client-side for the jumper. It is nearly instantaneous. It is why you can run around still when your link is lost. However, we have the client building the packet(s) to send out to the server showing you jumped (along with any other actions you might send, like your position, etc etc). It bundles all of these packets together and sends them out probably at set intervals. These ARE things they can change. Maybe it is optimized, maybe it isn't.
However, then you have the "over-the-network" time. These are all the switches/routers/underwater cables/etc that connect you to your DC. These are outside of the developer's control. For example, my ping from my location to my DC is 100ms. There is absolutely nothing SE can do about that. Some of this is physics - the propagation delay over a wire. I can't say for sure how much delay they can lower, if any. There is an overhead for each packet sent. If they doubled the frequency at which packets are sent out, the servers might actually handle them slower since they'd need to parse more packets. It isn't clear if there are any gains.
In other words - the excuse is partially physics (outside the control of SE), network transmission delay (out of their hands) and internal packet delay (in their control).