Re: Interesting Valorant Video and Speed Movement...
Posted: 02 Oct 2024, 11:09
Nah I want to explain this to you why I think the buffers are the root cause of everything13n47 wrote: ↑02 Oct 2024, 09:29Bros I found the solution. Quit reddit, quit valorant, hit the gym, get a good woman and win in life. They made the netcode shit on purpose so you can have a good life.
But back to the topic, in this video he doesn't have all the graphs out. Throughout my testing this stuff before I quit this game, this movement happened most likely because there's a choke/throttle in the incoming/outgoing packets for(i think it's more likely incoming) a fraction of a second. The game is just guessing that the skye kept moving towards the wall, but then received a packet and there was a move correction - thus the incredible adjustment in speed to the opposite side found in this clip. But I get what you're saying, the player models still move too fast and hit registry feels so off even when there are no chokes - we all feel it way too often
The problem is that something in the netcode or game engine is messing up with the lag compensation/interpolation and you get fast movements with sluggish hitreg in 90% of matches. To me, it looks like a problem with client/server side buffering - sometimes I was manually able to fix it by simulating packet loss, ping spikes, changing resolution back and forth, changing network buffering setting, increasing ping, restarting the game mid match, changing the FPS on the client. Sometimes this could also make it worse too so fiddling with the delicate engine was a risky coin toss.
This problem is universal and applies to everyone - most don't notice it, are compliant or ignorant about it or have quit the game entirely. Honestly I think it even impacts the game on LAN and the esports scene is a joke because of it. 4 years and they haven't bothered to deep dive into this, but for League of Legends they once did some magical shit in a tournament. It just shows Riot shows more love and sends more resources for their favorite baby instead of Valorant. They don't see it as a necessary issue to fix, it would take way more resources so they divert focus on skins. Even replay system taking this long an absolute joke, they probably have 2 part-time engineers working on it as a medium/low priority project with one halfassed project manager - this means they put only a few hours into it in a quarter
Thus we came back to my first paragraph. It's a feature, not a bug. Enjoy life bros. Life is prettier when you escape Riot Games.
The developers explained the situation themselves in their post:
Let's break this down.Another way we found to get a similar effect was to simulate a quick Ping spike on the client. A spike of higher ping back to lower would cause a build up in the Server’s move queue for that Client. A spike from lower ping back to higher would cause a build up in the Client’s move queue for other players. In either case, this build up of moves in the queue would cause a higher apparent latency until the queue got back to its target size.
Ping spike from low to high: When your ping suddenly spikes from low to high, the delay between your actions (movement, shooting, etc.) and the server receiving those actions increases. The server, which processes player movements, keeps a queue of move data from each client. When the ping spikes, the server might not receive your movement data as frequently (because it's delayed due to the higher ping). This leads to a "build-up" of your moves in the server's queue, because it’s waiting for the delayed inputs to arrive. The delay between your actions and their effects in the game world (like moving or shooting) becomes larger, causing higher apparent latency. Essentially, the server is trying to "catch up" with your delayed movements, and until it processes the accumulated queue, your character's movement may seem less responsive.
Ping spike from high to low: If your ping suddenly drops from high to low, the delay between receiving data from the server (like the positions of other players) reduces, but the client is still processing the previous high-ping state. The client also keeps a queue of incoming movement data for other players. When the ping drops from high to low, the server can start sending data more frequently, but your client is still processing the delayed data from when your ping was high. The client now has a build-up of movement data from other players in its queue. Since it’s processing delayed moves while also receiving fresh data, it causes a perceived delay in how other players’ movements are displayed, leading to higher apparent latency for you when observing their movements.
Both the server and client rely on move queues to process the flow of movement data, smoothing out any inconsistencies caused by network conditions. When there’s a sudden change in ping, these queues either build up (if data arrives too slowly) or get overwhelmed (if too much data arrives too quickly), causing higher apparent latency. For the server, the queue build-up happens because it’s receiving your delayed inputs in a batch. For the client, the queue builds up when the server sends a backlog of data for other players, resulting in jerky or delayed movement.
The build-up in either case means that, for a while, the game feels less responsive, and you experience higher latency. This continues until the queue "drains" and the server or client catches up to the current state. The move queues are buffers that store incoming or outgoing data. They help smooth out small fluctuations in latency or packet delivery, but when there’s a sudden, large ping spike, these queues get flooded or drained in a way that temporarily desynchronizes the server and client. When your ping spikes, the server has to process more movements from you in one go (because they were delayed), which makes it seem like your inputs are delayed When other players’ movements are suddenly sent faster after your ping drops, your client struggles to process this flood of data, so other players appear to move faster or in a delayed way.
Over time, as network conditions stabilize (ping returns to normal), the server and client queues should start to process data at a normal pace again. But it doesn't do that. This function in the netcode is broken. This is why I have been able to normalize the conditions by changing ping, causing ping spikes, changing FPS and so on - these methods change the network conditions/client FPS so suddenly, that sometimes the buffers are forced to calculate again. But it's so rare when the netcode gets the correct buffers for you - when it does the game suddenly becomes beautiful.
now we need only to figure out how to make it stable for us all or atleast for some broken cracked silvers like me...who suffer all this shit