Finally got a reply to my Dead Hard validation ticket - Official response added on P2

And the client doesn't retain enough memory to roll back power uses and give the correct outcome. Hence, powers getting swallowed, Victor getting dropkicked, etc.

Once a game? You mean once every 40 seconds by all four survivors, AND every pallet that gets used in a match.

I hope people will at some point understand this very obvious issue of networked multiplayer games: Every single player sees a slightly different game reality because network latency exists. The information every player has on the state of the game world is delayed because it takes that information some time to get to every player via internet connections. And since it takes different amounts of time for different players, the events on different players' screens can disagree with one another. This is an issue inherent to online networks, and it physically cannot be solved because even at actual light speed information still simply takes time to travel between different locations in space. So unless we are dreaming of networks employing quantum entanglement or spacetime curvature where information exchange might actually be instantaneous in both directions, we will simply have to accept this unfortunate reality and how it affects online multiplayer games.

There are three "perspectives" on game events: those of the respective player clients and that of the server. The events on the clients will be the most affected by latency since information needs to travel from one client to the server and then from the server to the other client. Example: Player A has a latency of 50ms to the server, Player B one of 80ms - in this case, the information either player has on the other player is 130ms delayed.

Of course, the question becomes, if two players' screens disagree on what happened in the game, how do we decide what actually happens? Do you think it is fair if we take the events on the screen of one player and disregard all other screens? That's what DbD has always done and still does in most situations now: whether a hit happens or not only depends on whether it did on the killer's screen, even if on the survivor's screen that hit is completely impossible. That means any latency in any player's connection including the killer's will benefit the killer on hits, because the higher the total latency, the further in the past the survivor model will be on their screen. Using our example values from above, the survivor position will be 130ms further in the past on the killer's screen than it is on the survivor's screen.

The server perspective on the game events is the most real-time accurate, since on it player information will only be delayed by the latency a respective player has to the server, rather than the latency of both players combined. Using our example from above again, the server will see player information at a delay of merely 50ms and 80ms respectively, rather than the 130ms total. It is not only the most accurate but also the most fair perspective on the game events, since players with a higher latency will be at a disadvantage rather than benefitting from their latency. And not only will it therefore not put any player at a disadvantage just because their opponent has a high latency, but the disadvantage the player with the higher latency has is also much smaller than the disadvantage in a system based on client perspective: in our example, Player B with 80ms obviously has the higher latency to the server, however they will only be at a disadvantage of 30ms because their opponent has a latency of 50ms to the server, so Player B's information is only delayed by 30ms relative to that of their opponent. We go from a disadvantage of 130ms to one of 30s, a four-fold improvement. And rather than latency always being to the disadvantage of the survivor player, now it will be to the disadvantage of the player with the higher latency of the two, survivor or killer.

To illustrate this a little more clearly:

Again using our latency examples from above, let's look at a gamestate from a survivor perspective and how it compares to the killer and server perspectives.

In this example, the survivor's real-time position on their own screen is 2.5 meters away from the killer. That is obviously 0.5m more than the killer's ~2m lunge range (6.9m/s * 0.3s), and therfore means the killer at this point in time is not able to reach the survivor and land a hit (which is especially true once we consider that the survivor can make another ~0.33m distance in those 0.3s, but we'll ignore that for simplicity's sake).

Now we look at what the killer player sees at this point in time. Since it takes their own position 80ms to reach the server, and from the server another 50ms to reach the survivor's client, it is clear that their real-time position at this time will be 130ms further forward than it appears on the survivor's screen. Since killers move at 4.6m/s by default, this means their position on their own screen is 0m + 4.6 * 0.13 = 0.598m. The survivor's position on the killer's screen will be delayed by those same 130ms since it obviously also takes the survivor's real-time position first 50ms to travel to the server and then 80ms from there to the killer. Since survivors move at 4m/s by default, the survivor position on the killer's screen will appear to be 2.5 - 4 * 0.13 = 1.98m. 2.598m (killer position + lunge range) is 0.618m more distance than needed to reach the survivor at 1.98m - the killer easily lands a hit on the survivor here, even if we account for the additional distance the survivor makes during the lunge.

So our clients disagree on whether a hit should happen or not. What does the server see?

The killer's real-time position on their own screen is 0.598m. Since they have a latency of 80ms to the server, they will be 4.6 * 0.08 further in the past, putting them at 0.23m. The survivor's real-time position of 2.5m will be delayed by their 50ms latency (4 * 0.05), putting them at 2.3m. At 2.23m with the lunge, the killer just barely does not reach the survivor here.

So we have a case where on the survivor's screen a hit is absolutely impossible, on the killer's it's comfortably possible, and on the server's end it's a near miss. Yet in DbD, this will be a hit every time.

We can express the unfairness of this numerically for the example too: Since the killer perspective decides, they have a 130ms total latency advantage putting them further away on the survivor's screen and the survivor closer on their screen - that translates to 0.59m + 0.52 = 1.1m advantage for the killer even though we are at relatively low latencies, and even though the survivor has a lower latency. If the server perspective were to decide, the survivor's position would only be 0.2m further in the past and the killer's position 0.36m, meaning the advantage would shrink to 0.16m, ~86% smaller of an unfair impact that latency will have. Of course, in this case the survivor would have that slight advantage, due to having the lower latency, but if we were to reverse the latencies for the players, the killer would have that slight advantage, which in this case would mean the hit still happens.

This means that when shifting from the killer client-dictated hit registration to a server-dictated one, we make latency as fair of an issue as it can be for all players and we reduce the impact latency has on game events altogether at the same time. Additionaly, once the server is the authority on hit reg, networking techniques can be employed by the server to further reduce the impact latency has on the game, such as lag compensation, a technique where the server will calculatively roll back the game state according to player latencies and check whether a game event was valid or not at that time.

And yet, despite the game favouring killers completely unfairly one-sidedly on hits with regards to latency, and despite this being something that benefits 1 player over 4 others as well as something that can actively be exploited via the use of VPNs and laghacks and the like, and despite the server being the objectively most fair perspective on the game, and with only 2 interactions (stuns and Dead Hard) having been moved to the server authority, people complain that letting the server decide on things is unfair...

If you want to see unfair, I invite you to imagine a reality in which DbD did the opposite of what it has always done and still does now, and looked at the survivor's perspective in order to decide whether a hit happens or not. Now if you as a killer have a high ping and/or the survivor you play against does, you could never swing at them from actual lunge distance, you would always have to account for latency and make sure you are much closer to them before you can secure a hit, and often hits would simply be impossible to get despite seeming perfectly possible on your end. Just like survivors in the actual reality of DbD have to account for their own and the killer's latency (which they can't even see) and still get screwed over by impossible hits reguarly. And it would arguably still be much more fair to look at the survivors' perspectives on things, because they are 4 players that otherwise suffer, as opposed to the 1 that is the killer player.

So I'm sorry, I can't find it anything but absurd to see killer-sided complaints about hit reg in this game. To be frank, you have no clue how "privileged" killers are in this game in terms of hit reg. It's a ridiculous aspect of this game and it negatively impacts the playing experience of countless survivor players in countless matches every day, and has ever since the game's launch. If both players are at around <50ms, things are mostly fine, but once either or let alone both players get above that, things start to favour killers on hit reg more and more noticably, and it gets completely ridiculous beyond 100ms. Hit registration should be moved to the server entirely, every single acclaimed multiplayer game from renown studios uses the server as an authority on important game events, even for games that are much faster and more precise than DbD, because it is objectively the fairest and most secure way to do it. And that's despite many of those multiplayer games not even being asymmetrical, meaning that in those games a client-sided system would not even be as unfair as it is in DbD, because all players in them both benefit and suffer from it, whereas in DbD only one side benefits while the other suffers.

Now to speak more specifically to the limited server-sided validation that thankfully at least exists now in DbD:

While it is possible for Dead Hard to "eat" special attacks that in a latency-free environment might have continued to still hit the survivor after the dash, every single one of these instances prior to DH validation simply ended in the survivor on the floor despite having actuated DH on their end. Prior to DH validation, any latency favoured the killer and DH would get eaten every time if the killer hit the survivor on their own screen; now latency favours the player with the lower latency on DH. It's objectively much more fair.

And any instance in which you in the past before the implementation of DH validation hit a survivor after their dash is unchanged, because validation only comes into play if you actually hit the survivor prior to the dash on your screen. Any timing in which you in the past would have hit a survivor after the dash is still the exact same, validation does not change anything about it.

Getting false feedback on validated hits cannot be solved without delaying the feedback on every hit. Your client detects the hit and gives you feedback (blood, scream) instantly, it however takes some time for the server to tell your client that the hit was not valid in the case of an overruled hit. The only "solution" for false hits would be to make the client wait for the server confirmation that a hit was valid, on every single hit, and this delay would feel awful even at low latencies and get worse with higher latencies.

What they however could and should do is play a sound and/or visual notification whenever a hit is overruled by the server, to avoid confusion.

Special attacks getting eaten comes down to very specific timings, and it is not something that can really be solved, it is a compromise of making DH's invincibility mechanic work in a reality where latency exists. Just like survivors can still die despite already being "invincible" on their screen, due to latency. But they could implement killer-specific remedies for some of these instances, such as having the client check whether there wasn't a pallet that would have been destroyed instead if the hit had not happened on the survivor. I think this is possible because it appears that there already is something in place allowing overruled hits to register on another survivor behind the Dead Hard-ing survivor.

Now whether Dead Hard in general is not an overpowered perk that should be adjusted is another question. I would agree that it is too strong and deserves nerfs. But the server authority on whether a hit is valid or not is infinitely more fair and something that should be implemented for the entire game and should have already been with the launch of dedicated servers years ago.

The server does actually correct the killer client according to the validated reality of the hit not having happened: killers go into missed hit cooldown rather than successful hit cooldown, and the survivor does not get a speed boost.

But you're not wrong, there are things this logic does not correct for, such as the possibility of an attack registering on pallets rather than the survivor, or funnily enough apparently even things like Oni still getting power progress or Franklin's Demise still robbing the survivor of their item. I haven't tested around with this much, but there's definitely some wacky interactions. These are very rare to happen in actual gameplay and only seldomly have much of an impact on the matches if they do, but I do think BHVR should sort these things out, not least because they would obviously have to be sorted out when moving the hit system at large to the server authority too.

But yeah, again, they cannot really solve the false feedback on overruled hits and DH sometimes eating attacks that might have otherwise still connected on the survivor after the dash, not without creating other issues. Maybe for one PTB they could disable client prediction of hit feedback so that players can see what it feels like to have latency-delayed feedback on that, and my bet is that nobody will consider it a worthwhile trade-off for getting rid of false feedback. I really think the easiest and most sensible solution is to play a sound/visual effect alongside the overruled hit.

Well, ultimately it doesn't matter whether it's a killer or a survivor client-sided logic that governs the speed boosts and cooldowns and makes it so they don't happen on validated hits, the only important thing is that they don't. I do think the hit cooldown is handled on the killer client and the speed boost on the survivor client, the clip posted earlier in this thread shows Nemesis starting to go into successful hit cooldown because they have a very high latency, and then the overwriting message from the server arrives and turns it into a missed hit cooldown. But yeah, as that goes to show, even at ridiculously high latencies (red lag icon = at least 300ms) the successful hit cooldown only plays for a negligible duration.

Some other interactions are more problematic, such as for instance Nemesis' tentacle not breaking a pallet in its hitzone upon getting a hit rejected on a survivor, but like I said, these are fairly rare and fairly tame in terms of the impact they will usually have even then. Plus some of these interactions can even benefit killers, like a survivor magically losing their item to Franklin's. They should still be sorted out though of course.

Don't worry we'll get a dlc perk to compensate for it.

I have no idea where you got the idea that I don't understand how latency works. I haven't questioned that at all, only possible solutions.

Yes, something needs to be compromised. Or collision detection needs to be reworked--i.e. the client should perhaps calculate what will happen if the survivor's hitbox is removed, which then preserves the interactions that otherwise need to happen or not happen without having to do a power-specific fix for every interaction in the game. Would it inevitably mean weird rollbacks of animations and swapping to other animations? Probably, but that is the compromise for having latency winning out and everything operating correctly: animation jank because the client isn't waiting.

Who said anything about proper transitions? Just randomly going from one frame to a different animation is still something.

Yeah, serverside hit detection is another idea. Really depends how much the servers currently need to deal with level geometry etc, I suppose.

Except they're not rare in the slightest.

Which ones are you frequently experiencing?