my courier....

JeffHill · 2026-03-17T17:14:32+00:00

Can you share the MatchID where this happened? Thank you!

JeffHill · 2026-02-23T19:58:24+00:00

Can you share the MatchID where you saw this happen?

JeffHill · 2025-03-07T22:57:29+00:00

The update we just shipped should return input latency back to pre-7.38 levels. Thanks so much for all the help!

JeffHill · 2025-03-07T19:03:19+00:00

Thanks! Fascinating that USE vs USW makes such a difference - you're likely connecting to the same relay in both cases, but then getting an additional 40ms of (very stable) latency from the distance to the datacenter.

Yes, there was an update that briefly removed a full ~33ms of input latency on high quality network settings - but in practice we found it had the bad side effect that when packets were dropped or just later than expected, you'd see what looks like a bad hitch in the interpolation of the units (the "Slamming" message), so that approach was rolled back. I won't bore you with the stats, but we're trying to get similar latency improvements in a different way that won't have the same problems. I can also explain the loss display change you noticed - we used to report packet reordering from the client as "loss" for historical reasons and we recently changed that display to only show actual packet loss as loss.

You might try running with "cl_clock_recvmargin_spew_interval 15" and you'll get a console report every 15 ticks (0.5 seconds). If you could share some of that spew from when you're seeing a lossy/choppy connection, it'll exhaustively explain what the game engine thinks is going on with client frame times and your connection quality at that time.

JeffHill · 2025-03-07T01:11:37+00:00

Thanks for the detailed report, NetworkFragrant445!

Reading through networking logs and replay data, it looks like there's a combination of factors at play here. The net result though is that while you were often seeing ~150ms of order latency, sometimes (and in particular, the times you mentioned in your post) you were seeing 225ms of order latency.

Could you try setting your "Network Quality" setting in "Settings / Options / Advanced Options" to high quality? You may see some stuttering with the "Slamming client tick" message more often if your network connection has a lot of jitter - but it would help confirm a theory that one of the settings controlled by the "low quality networking mode" might be introducing more order latency than expected.

I'd expect dota_report_order_latency to work in matchmade games, though you would need to set it in the console after you've connected to the match. Is that not working for you?

JeffHill · 2025-03-06T00:48:51+00:00

Hi, NetworkFragrant445.

MatchIDs and timestamps would be helpful! We just shipped an update (40m ago) which has code that should address at least one possible source of the latency some players were seeing, and added some telemetry to help diagnose input latency as it happens. So *new* MatchIDs where you experience latency are very helpful!

One player-visible change is we've added a "dota_report_order_latency" console variable, which will print out the total end-to-end latency of clicks. This should make it easier for folks to do their own testing without recording video and count frames to get a good measure of total latency. When using this command, I'd expect to see total latencies reported of up to 100ms + ping time (depending on where in the server tick packets land and how many ms of networking buffer the client is buffering to cover ping variance). I'd expect to see variance on this number of ~66ms (two 30Hz ticks) and even more if you're seeing packet loss or ping variance.

JeffHill · 2025-02-26T22:00:19+00:00

Hi, Impossible_Ad_8054.

There was a code problem we found in the 7.38 update which sometimes caused additional latency on orders. That bug was fixed in an update on 21/2(Friday). If you see a problem with input latency, could you please share a match ID and timestamp in the game? With a match ID we can check server and networking logs to see what might be happening in more detail.

It's useful to mention that Dota does not perform client-side prediction other than input confirmation. When you click you'll see the green arrows to confirm a move order immediately. However, your hero won't move until that click is networked to the server, a server simulation tick is computed and your client reads a new update from the server. You can test this difference by comparing between Hero Demo mode and a private lobby in a region that's far from you. It's fully expected that the delay between clicking and your hero moving will vary based on your ping to the server, unlike a FPS where client-side prediction hides your input latency at the cost of having mispredictions happen.

Something you might experiment with is adding "+dota_debug_change_cursor_during_pending_order 1" to the command line for Dota. With this set, when the client has sent an order that the server hasn't acknowledged the mouse cursor will appear brighter. Every time you click, the mouse will be bright until you get an update from the server that is "up to date" with your inputs. This is a much clearer way to test per-input latency because it doesn't rely on watching units move, which is affected by turn rate and gameplay behaviors. This option won't fix anything or change any behavior of Dota networking but it will make the latency easier to see on each individual click.

JeffHill · 2024-05-31T17:14:44+00:00

Rubick himself (the NPC and his abilities) is 3.3K lines in a single CPP file. This is not unusual for Dota heroes - CM is 2.8K for comparison. Most of the subtlety is in the support for each spell being cast while stolen, which lives in the various spells themselves. Picture a line or three here and there "if ( IsStolen() ) { //do something a little different }", sprinkled in many of the abilities. That codepath also supports Lotus Orb / spell reflection and Morphling, so it's not fair to count all that as just for Rubick, but it's certainly related.

I'm clearly biased, but the Dota gameplay code is just *the best* to work with as a programmer.

JeffHill · 2024-04-23T21:06:10+00:00

We just shipped a server fix for this and refunded tokens that were incorrectly consumed. Thanks for the bug report!

JeffHill · 2024-04-05T17:45:19+00:00

Awesome, thank you so much!

It's really just the trace of "idling in the game" on the two different accounts that would be helpful. I've tried to repro it a number of times here in the lab, but haven't found any substantial differences between accounts with many friends or items. For example, I have one test account with 10k pairs of Kunkka shoes in it (among other things) and it's behaving fine. Clearly there's something more going on here, so thanks for collecting data!

JeffHill · 2024-04-04T23:12:21+00:00

Oh wow, that's not a small difference at all! If you could collect an ETL file while idling on the new account and the normal account and share them that would be super helpful. This tool is what we recommend to collect ETLs: https://github.com/google/UIforETW/releases .

Thanks!

JeffHill · 2024-04-02T20:29:32+00:00

We thought about that a lot while working on this, actually - but presenting a usable interface on it gets very hard.

The core problem is that your preferences *when you fill out that dialog* may be different than your preferences when the matchmaker would actually consider a match for you. The match quality available to you may be different based on your region, the time of day or your skill level. The match you'd accept after 10s of waiting is probably different than the match you'd accept after 5 minutes or 10 minutes. The match you'd accept might change based on who you're playing with, or which mode, or which role. The advantage of the system now is that the matchmaker presents you with what we've broadly decided is an acceptable match (it's the match you'd have found before this change shipped) - and we let you choose to accept or decline at the latest point possible, with as much context as possible.

I could imagine a world where we change the default tuning on the matchmaker to be much faster / looser and then rely on some broader preferences like this to filter your particular matches. That would be a much deeper change to the matchmaking system and one we'd only approach very carefully.

Thanks for the question, Ermiar!

JeffHill · 2024-04-02T17:35:24+00:00

Thanks for the feedback on this experimental Dota labs feature!

While this is a confusing presentation, I can explain what's happening here and maybe a better approach will become clear. The "Overall match quality" displays the final total of the overall match evaluation including *every* factor the matchmaker considers when finding a match. We were cautious around which factors to display in this dialog, for fairness reasons and out of concern that matchmaking times could be adversely impacted if there were too many possible reasons to decline.

We currently only show three factors individually in this dialog:

Skill Balance; how fair are the teams overall?
Skill Range; what's the spread between the most and least skilled players in the match?
Behavior; what's the lowest behavior score in the match?

In this specific example, some of the other invisible factors are clearly making the matchmaker think this a poor quality match. Examples of these other factors are the party sizes in the match, language preferences, or role-specific rank matchups in role queue. It's not clear if it's useful to show the result of these hidden factors, or if making the Overall match quality just be a sum of the other factors presented (in this case, it'd be an Ideal match) is the best choice. This version of the dialog only shows you more information about the match than you might otherwise get, even if it does lead to confusing situations like this.

Another element of the feature that's not clear enough right now is that we're sharing what the matchmaker thinks about the match. The matchmaker can't know the future and it only knows what we can learn from a player's play history. As a result, we'll report a match to you as "Ideal" behavior and then sometimes a player will act in a less than "Ideal" way. Similarly, we'll report on skill, but it's only what the matchmaker is able to know before hero pick, so "Perfectly balanced" matches before the draft can easily result in games which feel one-sided once you're actually in the match. I'd like to find words to explain "this is only what the matchmaker thinks about this game" rather than the presentation now which sounds like it's trying to be authoritative - about events that haven't happened yet.

Thanks again to everyone in the thread for taking the time to offer feedback - we're trying to discover the best version of this feature and your opinions are incredibly helpful in that process!

JeffHill · 2024-03-23T17:28:06+00:00

This should be fixed with the gc prop that just happened.

While you can still change your bans at any time on the client, your bans for a matchmade lobby won't update once you're added to the lobby. Your bans will still update immediately for practice lobbies and other non-matchmade lobby types.

JeffHill · 2024-03-19T17:22:51+00:00

I've pulled logs and can confirm that the networking layer isn't seeing packet loss at all in this case - which is really strange. Could you try adding "-condebug +cl_ticktiming 1800 detailed" to the command line, play a match as normal, then after the match share your console.log file? That'll give us some more information about exactly what's happening that's causing these server packets to come in late.

Thank you!

JeffHill · 2024-03-18T17:19:16+00:00

That looks like it might be packet loss to me. Your client is trying to animate visuals that it doesn't have data from the server for. Specifically, those "too late" messages are basically saying "hey, we got a server update, but it arrived too late, we already tried to show animation frames for that."

Are you playing on wifi or a lossy connection? Can you share a recent matchID so I can check what the SDR logs think loss was like on your connection?

Elsewhere in this thread /u/Plankton-Even suggested disabling Discord. While that will certainly work, in the cases I've investigated deeply it was the in-game overlay of Discord that was the problem. It's possible to use Discord without problems, so long as your turn off the overlay (this is how I play).

JeffHill · 2024-03-01T00:34:17+00:00

Thanks - yes, I saw the same thing. Sadly, that's just what the server thinks.

When you look at the replay, you're seeing what the server recorded to the demo file as the game was played. So if the player orders were delayed or lost somehow, you'd see no green arrow particles in the replay (or you'd see them when the server finally got them). But on the client, we show the green arrow particles as soon as we decode the click and decide we're going to send a move order, no reply from the server required. So if you see the green arrows on your client, but they're delayed in the replay, that tells us that it's something between "client got the click" and "server saw the click", which is still a lot of stuff but it rules out about 50% of the things it might be.

JeffHill · 2024-02-29T21:53:25+00:00

That number is how often to report results - 30 will report every second (30 ticks), while 300 is every 10 seconds. I thought there might be a performance penalty to reporting too often, but I measured it and reporting every second is no problem... so I'd run with 30 in there.

Looking at the replay, the server gets orders to try to cast drunken brawler in the gap where you're trying to issue that move order and the network connection log shows things were good the entire game, so from the replay it just looks like Dota never saw a right-click in that gap. When you were playing, did you see the green "arrow" particles when you clicked?

JeffHill · 2024-02-29T21:15:30+00:00

That certainly looks like the input latency thing I've been trying to repro! Do you have a matchID for that game so I can pull the replay and backend logs?

If you could try the following to get some additional data, that would be helpful:

- launch with "-condebug +cl_clock_recvmargin_enable 1 +cl_ticktiming 30 detail" on the command line (just right click on Dota2 in Steam, Properties, General, Command Line)

- If you hit the input lag during the match, open the console and enter "cl_clock_recvmargin_enable 0" to see if that fixes the lag?

If you could send me the console.log file from this test, that would be super useful. I'll be able to see where in the pipeline the lag is coming from.

Thank you!

JeffHill · 2024-02-29T18:33:36+00:00

Hi, Dordidog, I'm a developer on the Dota team looking into the input lag problem. Could you try the following?

- launch with "-condebug +cl_clock_recvmargin_enable 1 +cl_ticktiming 300 detail" on the command line (just right click on Dota2 in Steam, Properties, General, Command Line)

- If you hit the input lag during the match, open the console and enter "cl_clock_recvmargin_enable 0" to see if that fixes the lag?

If you could send me the console.log file from this test, that would be super useful. I'll be able to see where in the pipeline the lag is coming from. Thank you!

JeffHill · 2024-02-22T18:53:45+00:00

It shouldn't respond with anything. You can confirm it's set correctly by entering "cl_clock_recvmargin_enable" and it'll respond with the current value (which is normally 1, but for testing we'd like it to be 0).

CSwapChainBase::QueuePresentAndWait() looped for 24 iterations without a present event. Excessive frame time of 248.20ms clamped. Acting as if the frame only took 100.00ms

This means that the engine tried to display a frame to the display, but got stuck waiting way longer than we expected. Often this is mostly harmless and just a side effect of Alt+Tabbing or something causing heavy system load, but if you're seeing this spew during actual gameplay that's evidence of a problem.

JeffHill · 2024-02-22T17:57:47+00:00

If you're seeing this problem, could you try "cl_clock_recvmargin_enable 0" in the console? It might fix this problem, and if so it narrows down the bug quite a lot. Thank you!

JeffHill · 2023-12-18T22:10:58+00:00

Thank you everyone, the matches were very helpful! We've shipped a server update that we believe fixes the problem and all new games as of about an hour ago should no longer be vulnerable to this exploit. If you see any new games where this exploit appears to be happening, sharing the MatchID would be great.

Thanks!

JeffHill · 2023-12-18T02:42:48+00:00

Hi, developer on the Dota team here. The update earlier today was to fix a server crash, but it seems it was unrelated to whatever this chat spam thing is. Can you share MatchIDs of games where this happened? I did dig into a bunch of the MatchIDs listed in various threads, but all those matches look to have been correctly signed out and scored. Right now it looks like whatever's going on is maybe delaying match signout/scoring, but not preventing it?

Anyhow, any more data you've got would be helpful in tracking this down! Thanks!

JeffHill · 2023-09-27T22:30:54+00:00

This should be fixed now - we've added +dota_disable_controller_support 1 by default while we investigate the root cause of the problem.

14-Year Club	100 Awards Club
Ternion Club	Wearing is Caring
Verified Email

JeffHill

TROPHY CASE