shaedyn

Hey - the sluggish feel that you described is one of the issues that we're testing a fix for: network buffering adding excessive round trip delay in a few situations. Alt-tabbing, high network jitter, or client hitches can all cause buffer durations to spike up temporarily. In the cases we've seen, this resolves itself after a short time, but it can be pretty noticeable if you take a fight during that window. If you alt-tab frequently, turning off background framerate throttling may help reduce the impact until fixes go live.
In addition to fixes, we'll also be adding a graph that shows the full round trip latency (including buffering on either side), which should give you some hard evidence if you run into this sort of issue. If you're still having trouble after the changes go live, check that graph and let us know what you're seeing.

Hey, you're probably thinking of this article on Fog of War. Like you say, we only send information about enemies when they're visible (or will soon be visible) by your team. The 'will soon be visible' piece has to be tuned so that your client gets enough advance notice before you see an enemy, but so that fog of war is still tight enough to effectively counter certain forms of wallhacks.

That fast-moving behavior you describe typically happens when your client missed a couple updates from the server and has mispredicted enemy movement. When that occurs, it needs to shift en...

hey folks - sorry for the delay. Here's update on the investigation and findings so far:

Post: https://www.reddit.com/r/VALORANT/comments/u4dlxv/valorant_netcode_gameplay_consistency_update/

Reddit thread for comments / questions: https://www.reddit.com/r/VALORANT/comments/u4dlxv/valorant_netcode_gameplay_consistency_update/

!pin

hey - sorry for the delay here. It took longer that we anticipated to get an update through the pipeline and up on the blog. Here are some details on our approach and findings so far:

https://playvalorant.com/en-us/news/game-updates/valorant-gameplay-consistency-update/

Hey, thanks for the extra info. We've found a couple issues that would cause the symptoms you're describing - effectively adding a small, random amount of client and/or server latency into some matches that can impact how delayed enemy movement appears. We're in the process of fixing those and wrapping up investigations in a few other areas.

If you have any video captures of the jittery movement that you're seeing, feel free to DM them to me and I can review. Also - once the fixes go live, let me know whether they resolve the issues you're seeing. We're planning to ship a couple extra debug graphs alongside the fixes that show details on client/server buffering, which should hopefully highlight any remaining issues if you're still having trouble.

As for timeline, we won't know which patch we're targeting until we wrap up the full investigation and go through internal testing. The current plan is to put out a blog post with details / timeline once we have more...

We’ll plan to share back findings once we wrap up the investigation and/or have potential changes going out. For now, we’re heads down and focused on the work.

No problem. One more thing. I notice the game tends to switch to a higher buffer when the network becomes unstable. Then once the network does become stable again, the game takes a moment then returns back to lowest buffer. Is it possible to have this as a stat as well?

Yes actually - we're planning to add a graph showing that buffering as part of this investigation. :]

We've actually talked about adding this a few times in the past, but never prioritized it. We weren't sure whether it would be valuable or just triggering, especially since dropping some shots is unavoidable around death (and you usually already know when it happened). I'll bring it up again with the team though - thanks for the suggestion.

Hey Jaux, it's hard to say with packet loss, since it's typically an issue with your network or ISP. Packets could get dropped anywhere along the route between you and the game server. If the issue persists for a while, your ISP or network admin are usually your best bet to help diagnose where the issue is occurring. Letting them know may also help them identify or confirm a hardware problem if other folks in your area have reported similar issues.

The only valorant-related packet loss issue that I've come across recently was due to a few players' networks not being able to keep up with Val's packet send rate when running at high framerates (>144 FPS). As an experiment, you could try limiting your framerate to 60 when you're seeing packet loss. Limiting framerate also reduces packet send rate, so that test would help you determine whether it's send-rate related.

hey, Sad. In theory, the server should be playing back your movement, triggers, and other inputs at a delay but otherwise synchronized to how you played them on your client. Having said that, we'll still go add some extra checks to our client/server shot result validation to double check that movement and inaccuracy states agree. Appreciate the tip!

Hey blubbi, thanks for sharing that. It’s a good point about how allowing server selection can negatively impact match quality. That’s one of the unfortunate consequences of peeker’s advantage - players with high ping are very disadvantaged if they try to hold angles. It incentivizes those high ping players to always run around corners, which as you say, takes away from the slower, more methodical experience that you tend to see on LAN or low ping environments.

We try to balance the benefits that players & parties get from being able to specify server preferences with the impact that could have on other players' experiences. Server preference is just one factor that gets fed into the matchmaker, which gets considered alongside other match quality factors to put you in a game.

I'm not an expert here, so I can't personally speak to any changes we'd consider. I'll bring up your feedback and suggestions with others on the dev team who know more though. We may also...

If you look closely - Attacker firstly peeks, notices Shaz, performs a 'stutter step' again like short peek and then shoots.

What defender sees? Just ferrari peek and insta shoot. Shaz had 0 time to react, even tho on attacker's PoV we clearly see Shaz should have been able to kill him as he had enough of time.

This clip is a good illustration of the tradeoffs for visualizing damage immediately vs delaying it to sync to character movement.

The build they were playing on is from before we synced movement and damage, so you see AZK's initial step out from cover, then Shaz's client learns that he died from the server and we show it immediately. As Shaz's body starts to cover the camera, you can see AZK start to step, continuing his movement to where he had fired the shot on his screen.

In VAL today, we'd wait to show Shaz that he was dead until AZK completed the sidestep, but any shots Shaz fired during that window would be...

np!

Our existing telemetry includes data on full round trip latencies, but doesn't currently break it down into buffering vs actual time spent on the network. Without that breakdown, we can't yet distinguish between bad connections and potential system issues.

heya, sure thing. I'll take a swing at these:

Problem with animation of model's legs not stopping aka giving us a feeling of enemy 'run&gunning' while in reality the model stopped.

We’ve made a few changes here over time, the main two are:

1. We tweaked the leg animation blending speed so remote players’ legs visually come to a stop more quickly.
2. We delayed damage and death events to synchronize with remote players’ movement.

Context for (2) - like I mentioned above, we apply remote interp delay (buffering) to remote players’ movement to prevent players from popping around when network issues arise. Back in beta, we didn’t buffer/delay damage in the same way as movement, meaning you’d see deaths take effect as soon as the info came across the wire. The downside of that approach was that you’d sometimes see people firing shots before their movement showed them coming to a stop (aka running & gunning)...

Hey everyone! I’m on the engineering team that owns competitive integrity & netcode for VAL. No need to jump through hoops or provide definitive proof to get noticed! We’ve been following along with the conversations here, and we’re in the middle of investigating the game-to-game inconsistency that the community has been discussing. We don’t have concrete findings to share yet, but I can provide some details for now on our hypothesis and the steps we’re currently taking.

Some quick basics: The time between firing a shot, that shot taking effect, and you seeing the outcome of that shot are the combination of your ping to the server and remote interp delay (buffering) that happens on either side. For a handy visual, this diagram

...

We made a change in 3.04 so that defenders now win simultaneous team wipes pre-plant. We decided to keep the change focused on this specific issue for now.

Thanks again for bringing this to our attention!

https://playvalorant.com/en-gb/news/game-updates/valorant-patch-notes-3-04/

you got a report on a fix or something?

Hey, I do - sorry for the delay. The team took last week off to recharge, so we just discussed today.

Here's a rough patch note preview (this would be in 3.04):

Fixed an issue that caused attackers to win if all living players died simultaneously before the spike was planted (e.g. from the same Raze Showstopper). The defending team will now win in these rare cases, since they successfully prevented the attackers from planting.

Behavior is unchanged if either team outlives the other - an elimination victory is awarded to the team that survives longer.

Per the second paragraph there, we decided to limit the...

My fault jumping to solutions on a saturday morning - I'll discuss with the team :]

VAL gameplay dev here - pretty much what /u/jakelear said!

If the last two players die on the same frame, it looks like the attackers will always win the round in the current patch. We'll look at changing this so that the team that survived longest wins. edit: I'll chat with the team about how we want this to work.

Raze ult (and explosives in general) should kill the player closest to the center of the explosion first, so as long as you don't shoot yourself in the feet, you should win these!

Sorry you were robbed here, /u/JoelTomy, we won't let your sacrifice be in vain. o7