Well… unless you see someone stop dead in their tracks between packets, guess whats going on?
You still aren’t making sense, so please explain what you think is going on in this situation so that I can actually respond.
Server stopped getting updates, but it continues cloning the inputs and then trying to predict positions as it spits out packets back to the client as well as a note to ramp up its timestep. The cloned data coming back and the use of any available inputs requires extrapolation (maths). Interpolation and Extrapolation happen on all clients and the server for different things at different times. Thats , literally the basis of what lag compensation is.
Heck, that’s literally the only way anything moves without a game looking like a stop motion animation.
That’s not extrapolation. If the server clones previous inputs, it’ll just simulate entities as normal with those inputs and whatever happens is what actually happens. I’m not sure what you mean by “ramp up its timestep”.
No, that is not the basis of what lag compensation is. I keep trying to tell you that lag compensation refers to rewinding entities to match what the shooter saw during hit registration. It’s also called backwards reconciliation.
Yes, the client needs to interpolate to have render framerate be independent of the tickrate, but the server doesn’t render.
The CLIENT isn’t running the master sim on projectiles.
Yes, that’s what I’m saying. The client interpolating between ticks to render doesn’t affect simulation anyways.
It does for what the client is attempting to hit. And at 40ms which is what I maintain, and is literally the goal they set for maintaining a responsive connection, there’s no reason for a dead center shot to miss a target, OR, explode on impact and deal zero damage.
This all comes back to how they sprinkle in their little mitigation features, treat shooter favor, simulate projectiles on the server before clients, except in the case of the likes of pharah though her projectile is treated entirely differently all around from what I remember, extrapolation for shooter latency, missing packets etc.
That .1 radius change caused a big issue, because we are already dealing with a sliver of time for that collision to mean anything on the client’s side.
The problem was peoples ‘feelings’ about walking head first into a projectile for which they had every advantage over as far as netcode is concerned.
I honestly hope we’re on the same page on what is going on here now.
Not sure what you mean. Both the server and client simulate, then if the client learns it mispredicted when it gets a server snapshot, it rewinds to the tick the discrepancy happened and simulates back to the current time with the correct info.
Only if your RTT + interp delay is over the 250ms lag comp limit.
Depending on the character there’s exceptions to how they allow a client simulation of Projectiles to progress before receiving an update from the server.
Still not the problem for everyone but yes.
30ms. Because dynamic queue.
It’s practically negligible.
You would think right? And yet, Junkrat projectiles still phase past hitboxes, through enemies, and on wonderful occasions deal zero damage.
That’s the way the netcode works.
Client side hit detection with favour the shooter mechanics.
Making Junkrats bombs bigger won’t change what you’re experiencing.
It’s the same with all projectiles.
That’s why I don’t like the video.
Actually watch the damn video, or at least skim to the part about hit reg.
And let’s be fair. Being hit by a grenade that appeared to miss you entirely would feel far, far worse than being hit by a grenade that seemed to just barely miss. Though, I’m not sure it’d take any more blame…
The main thing to me is, I’ve definitely been killed by Hanzo projectiles after I’ve seemingly rounded a corner or Mines after I’d already dashed far out of their area of effect, which would seem to indicate that projectiles aren’t necessarily victim-favoring, yet Junkrat grenades certainly seem to be. I can’t think of a single unfair death I’ve had from Junkrat grenades (or from Pharah’s direct hits, but that may be coincidental due to only ever avoiding or one-shot flanking her).
Roadhog seems to have gained a whole orbit of idiosyncrasies over his hook changes. I’ve had a few times where I’ve hooked a Genji back into my fore as – and, judging by the animation, after – he’d dashed through me. I’ve also at least a few time cancelled ultimates in their animation I had absolutely no business cancelling.
It elaborates on what we already know from a prior video they made.
It’s the same story.
That’s how the game works.
Changing a hero doesn’t change how the servers operate.
The video explains that they use lag compensation/backwards reconciliation for hit reg, which means the server rewinds entities to match what the client saw rather than simply trusting the client as to whether it hit.
The video also explains that Overwatch is server authoritative and the client only sends its inputs and aim angles.
Exactly. The server gets that information from the client.
With lag compensation, the server keeps its own records on where entities were each tick. The client only gives it the timestamp to rewind to.
EDIT: And you’re ignoring the second half of my post, they explicitly say that the client doesn’t send that sort of information
Um, changing the radius quite clearly DID change the experience. The junkrat mains were able to tell.
We know the server is authoritative.
He’s explaining how the server makes decisions.
So changing a hero won’t help change anything.
The server doesn’t play the game for you.
It’s really not that hard to understand for anyone with even an intermediate knowledge of networking.