Thread: .3 Second Positional Update Delay (Requesting Dev Response)

Originally Posted by Astarica

** Considerations on timestamps **

Here's the particular extract I feel is worthy of attention in general sync design. You may replace "performing a headshot" with "dodging an AoE" or "interrupting the enemy's cast", in all cases it's a matter of positional assessment, it works for any action performed as/on a moving element (a mobile, or "mob", as we call them in MMORPG, here including Playing Characters).

Originally Posted by Gabriel Gambetta

Lag Compensation

So you’re aiming perfectly at the target’s head with your sniper rifle. You shoot - it’s a shot you can’t miss.

But you miss.

Why does this happen?

Because of the client-server architecture explained before, you were aiming at where the enemy’s head was 100ms before you shot - not when you shot!

In a way, it’s like playing in an universe where the speed of light is really, really slow; you’re aiming at the past position of your enemy, but he’s long gone by the time you squeeze the trigger.

Fortunately, there’s a relatively simple solution for this, which is also pleasant for most players most of the time (with the one exception discussed below).

Here’s how it works:

• When you shoot, client sends this event to the server with full information: the exact timestamp of your shot, and the exact aim of the weapon.
• Here’s the crucial step. Since the server gets all the input with timestamps, it can authoritatively reconstruct the world at any instant in the past. In particular, it can reconstruct the world exactly as it looked like to any client at any point in time.
• This means the server can know exactly what was on your weapon’s sights the instant you shot. It was the past position of your enemy’s head, but the server knows it was the position of his head in your present.
• The server processes the shot at that point in time, and updates the clients.

And everyone is happy!

The server is happy because he’s the server. He’s always happy.

You’re happy because you were aiming at your enemy’s head, shot, and got a rewarding headshot!

The enemy may be the only one not entirely happy. If he was standing still when he got shot, it’s his fault, right? If he was moving… wow, you’re a really awesome sniper.

But what if he was in an open position, got behind a wall, and then got shot, a fraction of a second later, when he thought he was safe?

Well, that can happen. That’s the tradeoff you make. Because you shoot at him in the past, he may still be shot up to a few milliseconds after he took cover.

It is somewhat unfair, but it’s the most agreeable solution for everyone involved. It would be much worse to miss an unmissable shot!

Source: http://www.gabrielgambetta.com/fpm4.html

The timestamp of that headshot would happen between regular checks (between the 0.3 seconds), making it an extra check performed by the server, based on a "presumed" authority of the client, subsequently validated by the server.

Now, a more graphical take on the same matter. Consider the following picture: imagine that the 1st-person "shooter" is an AoE firing, and you (the player) would be the running character (here towards the left). This is a good representation of what the server "sees" (hitboxes) versus what we see on our clients (textured character). The server thinks you're the blue hitbox when in fact, on your screen, you're already in the clear. Without some form of interpolation generated by your client, the hit is confirmed by the server: bloodstains on the wall (resp. floor ^^), you're dead. But if your client can send a timestamped update of your position at any time, especially when an AoE is fired, then you're in the clear, it can be reconstructed, and the hit is not validated by the server. Currently, ARR's server doesn't perform such an interpolation, thus you always see yourself in the future of what the server knows, conversely you never see AoE and castbars in the present but always in the past (it's a two-way street).


Source: https://developer.valvesoftware.com/...yer_Networking

I don't see any other explanation for what we observe in-game. As we all can see, it's perfectly documented and there are number of workarounds —validating your idea that "network is hard to code" is an argument that holds no water in 2013, nor has it for a decade actually.