Results -9 to 0 of 34

Threaded View

  1. #9
    Player
    dspguy's Avatar
    Join Date
    Aug 2013
    Posts
    1,667
    Character
    Jain Farstrider
    World
    Leviathan
    Main Class
    Marauder Lv 100
    Quote Originally Posted by Karan_Vess View Post
    What you're listing are excuses. Not reasons why things can't be better.
    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).

    For your edification:
    From a terminal window (windows command prompt on windows), run tracert <ip address of your DC> This will show you the path(s) taken to the DC and where the delay is. You'll likely find that the delays are in the distance between you and the DC or from nodes that are saturated with other network traffic.
    (2)
    Last edited by dspguy; 04-26-2022 at 07:13 AM.