Page 7 of 17 FirstFirst ... 5 6 7 8 9 ... LastLast
Results 61 to 70 of 165

Thread: Unit Response Delay

  1. #61
    Basic Member zaggeh's Avatar
    Join Date
    Sep 2011
    Location
    Belgium
    Posts
    42
    Nice, I was looking for this topic and found it straight away.

    I'm in the same boat here, I feel like there is a pretty noticeable delay on the orders. Net_graph shows about ~135ms all the time on the EU servers. I'm from Belgium and if I'm not mistaken the EU servers are hosted in France, so there is no reason I should get a ping this high.

    I'll try out the script tonight and report back to see what happens. Thanks for posting it, whoever did.

  2. #62
    Quote Originally Posted by zaggeh View Post
    Nice, I was looking for this topic and found it straight away.

    I'm in the same boat here, I feel like there is a pretty noticeable delay on the orders. Net_graph shows about ~135ms all the time on the EU servers. I'm from Belgium and if I'm not mistaken the EU servers are hosted in France, so there is no reason I should get a ping this high.

    I'll try out the script tonight and report back to see what happens. Thanks for posting it, whoever did.
    I'm pretty sure the script was for what this thread is about, unit response, not high pings.
    If you're having high pings I'm pretty sure it's another issue since all of this thread revolves around unit response delay which I'm experiencing and it's messing me up pretty bad.

  3. #63
    Basic Member zaggeh's Avatar
    Join Date
    Sep 2011
    Location
    Belgium
    Posts
    42
    Quote Originally Posted by Mutill View Post
    I'm pretty sure the script was for what this thread is about, unit response, not high pings.
    If you're having high pings I'm pretty sure it's another issue since all of this thread revolves around unit response delay which I'm experiencing and it's messing me up pretty bad.
    I initially thought the ping would be the cause of the delay, but apparently everyone has it, it's just that I have a bigger delay in it (thanks to additional ms).
    So it should atleast increase a little if I use the script.

  4. #64
    Basic Member
    Join Date
    Sep 2011
    Posts
    8
    Guys tbh, the script won't do much if you are getting 100+ms after testing rates are best left at cmd 30 and update 20 followed by rate of 80000 and cl_interp_ratio 1 with the rest of the commands left as is but cl_interp should be defaulty at cl_interp 0.1

    so

    cl_cmdrate 30
    cl_updaterate 20
    cl_smooth 0
    cl_interp_ratio 1
    cl_interp 0.1

    the script no offense to the maker. Isn't the best, as you need to lower your rate to 60k for it to work, which makes no sense at all. You get better performance at the highest rates if your comp can handle it. If you have a below avg comp. Go for it use 60k. But atm rates of 66 each are useless if your ms is still high. Changing your interp to .152 will also benefit you if you are always playing with around 50ms. I would explain in depth, but this is the source engine, and i've been through the interp thing. the script thats up now. You better be playing with below 50 ms at all times. Or atleast almost at 50ms.

    So pretty much almost defaults with a few tweaks give you the best performance. http://www.mediafire.com/?21dzfrxtpcazx5d
    Thats my auto exec, you should on the other hand since I didnt't change the interp ratio to 1 if you still are getting really noticeable delay. Idk about the animation stuttering aslong as you don't mess with rates that will delay you even further.

    I did on the other hand see that it worked for a few, which is good, but I recommend trying this
    Last edited by sYnceD; 09-28-2011 at 02:14 AM.

  5. #65
    Basic Member
    Join Date
    Sep 2011
    Posts
    50
    Nvm! Edited out!
    Last edited by Fleme; 09-28-2011 at 03:02 AM.

  6. #66
    Basic Member SUNSfan's Avatar
    Join Date
    Sep 2011
    Posts
    68
    Quote Originally Posted by sYnceD View Post
    Guys tbh, the script won't do much if you are getting 100+ms after testing rates are best left at cmd 30 and update 20 followed by rate of 80000 and cl_interp_ratio 1 with the rest of the commands left as is but cl_interp should be defaulty at cl_interp 0.1

    so

    cl_cmdrate 30
    cl_updaterate 20
    cl_smooth 0
    cl_interp_ratio 1
    cl_interp 0.1

    the script no offense to the maker. Isn't the best, as you need to lower your rate to 60k for it to work, which makes no sense at all. You get better performance at the highest rates if your comp can handle it. If you have a below avg comp. Go for it use 60k. But atm rates of 66 each are useless if your ms is still high. Changing your interp to .152 will also benefit you if you are always playing with around 50ms. I would explain in depth, but this is the source engine, and i've been through the interp thing. the script thats up now. You better be playing with below 50 ms at all times. Or atleast almost at 50ms.

    So pretty much almost defaults with a few tweaks give you the best performance. http://www.mediafire.com/?21dzfrxtpcazx5d
    Thats my auto exec, you should on the other hand since I didnt't change the interp ratio to 1 if you still are getting really noticeable delay. Idk about the animation stuttering aslong as you don't mess with rates that will delay you even further.

    I did on the other hand see that it worked for a few, which is good, but I recommend trying this
    For me the earlier config works b/c as I stated originally, I have a low ping but it still feels awfully delayed. I think most people are on that boat.

  7. #67
    Basic Member
    Join Date
    Sep 2011
    Location
    Cairo, Egypt.
    Posts
    125
    Hm if I put these settings in a .cfg, then exec it using console. If I restart the game will they return to their normal values or will I have to reinstall/make a backup .cfg with the default values?

  8. #68
    Banned
    Join Date
    Sep 2011
    Posts
    375
    You can create an autoexec.cfg, it should get executed automaticly. For other configs you can write exec <enteryourcfgnamehere> in your config and then make it read only. ;o
    After executing (exec) a config you don't have to restart.

    The delay had nothing to do with the ping. I had 30ms on EU servers and had delay. Now I still have my 30ms on EU servers (from germany) and it responses immediately

  9. #69
    Valve Developer Zoid's Avatar
    Join Date
    Sep 2011
    Posts
    1,065
    Again, I don't recommend using that script. Let me explain how the networking model works in Dota 2 and where this "unit delay" people are describing is coming from.

    The Source engine is an UDP based networking system that sends snapshot of the unit state to the client at regular intervals. This is the cl_updaterate and its currently locked at 20Hz on our servers right now. This means that every 50ms, the game transmits the position of all the units in the game, their states, etc. (For the curious, I worked with John Carmack when this model was developed in Quakeworld at id Software).

    The way your client handles this is it interpolates between these snapshots. By default, the cl_interp_ratio is 2, which means it interpolates it between three snapshots. Let me explain with a timeline. This assumes you have zero ping (or very low ping):
    Code:
    Time       Server       Client
    0.00       Snapshot A   Idle
    0.05       Snapshot B   Gives command for the hero to move
    0.10       Snapshot C   Idle
    0.15       Snapshot D   Idle
    In this case, you first get Snapshot A and the client doesn't do anything as it has no succeeding snapshot. Snapshot B comes in and the client starts interpolating the motion between A and B. At this point the client tells his hero to start moving. The server responds immediately to this command and starts moving the hero on the server. Snapshot C comes in, but the client is still interpolating between A to C since cl_interp is 0.1, or 10Hz. D eventually comes in and now you start seeing the unit fully respond to your movement command as now you are interpolating between B and D. We interpolate at 10Hz instead of 20Hz so if you lose a packet from the server or its delayed a few microseconds, we "smooth" over it by interpolating around the missed packet.

    There isn't an artificial unit delay, its due to the interpolating between snapshots (which gives smooth motion on the client) that causes it to feel a bit delayed. Since the interpolation time is 10Hz (100ms), it can take roughly half that time, 50ms, before a unit starts to move or appear to respond to its latest command.

    Now this model was tuned for games that have prediction such as Counterstrike, Left 4 Dead, Team Fortress 2, etc. Dota 2 doesn't have prediction as you're basically giving orders to units on battlefield. You're not directly controlling the player as you would in those games and there isn't hitscan based weapons that need prediction and lag compenstation in order to aim. You don't aim in Dota 2, you give commands.

    With this, I'm exploring increasing the snapshot frequency to lower the interpolation time to 50ms. This will cause the perceived respond time to lower to around a 25ms average.

    Of course, you need to add your ping time to all of this. If your ping is 135ms, then its going to take that much longer for the unit to respond. I'm not sure why the ping is so high from France to our new data center in Luxembourg. We recently relocated our servers there and we're still tweaking and talking to ISPs around there. I'll talk to our network administrators about it, but emailing me a traceroute would be great.
    Last edited by Zoid; 09-28-2011 at 08:10 AM.

  10. #70
    Basic Member
    Join Date
    Sep 2011
    Posts
    48
    I agree with Sunsfan(after watching the GLHF top 10 video), there is a certain 'delay' that happens from clicking to action. I have 125FPS and usually 60-70 MS and it's immediately noticeable, glad to see Valve is at least investigating it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •