Busting some hit registration myths
We've always known how the hit detection system in DbD works: The killer client calculates whether a survivor's hurtbox overlaps with the killer's hitbox, and these hit calculations are performed exclusively on the killer client (the killer player's PC/console). Both of this has been stated and demonstrated by the devs themselves multiple times.
Since survivor positions on the killer client are naturally delayed by network latency (they appear further in the past than they actually are because it takes time for their actual positions to be communicated to the killer), the killer can land hits that should be impossible. But only the killer's perspective matters, it has the absolute authority: if a hit happens on the killer's screen, it counts no matter what, even if from the survivor's (and server's) perspective it could not possibly connect. Due to this fact, killers benefit from latency on hits completely one-sidedly, and they benefit from both the survivor's and their own latency at that. This killer client-sided hit registration system and therefore killer latency advantage has existed since the days of peer-to-peer networking hosted locally on the killer client, and it unfortunately still exists now with dedicated servers in place.
Yet still this does not seem to be widely understood, and there remain many commonly purported misconceptions regarding hit reg in this game. Personally I've seen more than enough evidence to not be subject to such misconceptions and find it perplexing that many of them stick around despite the killer-sided nature of how hit reg functions and how latency affects it being obvious just from playing the game. But there have never been comprehensive tests regarding these things to my knowledge, so that's what I set out to do. I won't cover absolutely everything, but I will address the most common and important aspects, and they should make the reality of hit reg in this game obvious to anyone.
First, to showcase that latency favours killers, here are instances of a survivor receiving hits that from their perspective are impossible, but possible from the killer's perspective due to latency:
Survivor perspective:
Killer perspective:
As you can see from the little lag icon present on the survivor side, in this instance the survivor has a high latency (white lag icon appears at 150ms; the survivor here has around 230ms in actuality) and this allows for the hit to connect. But the same is true if the killer is the one with a high latency:
Survivor perspective:
Killer perspective:
You can see how far away from the window the survivor ends up on the floor, and from the killer's perspective the survivor position is corrected to their actual position after the down, sliding into place.
This killer latency advantage of course does not only apply to hits on window vault interactions, but all hits. Here are more examples of hits from a laggy killer, over pallets and just out in the open:
I had to convert to gif, which has a low framerate, but here are still frames showing the precise moment of impact from the clips to make it more obvious:
The survivor is already standing on the other side of the pallet on their screen, yet they still get hit:
Same for the window hit - the survivor is comfortably out of hit range at the moment the hit connects, but it does connect:
This likewise leads us to the first busted myth:
Myth #1: General hit validation exists
Validation for these hits does not exist. BHVR claims to have implemented general hit validation on the servers, but in reality it does not function. Hit validation has one task and one task only: overrule a hit if it is deemed impossible from the server's perspective. This would mean killers with high pings would experience "false" hits in instances such as these, where a hit connects on their screen (the survivor bleeds, screams), but is then undone a brief moment later due to being identified on the server as only having been possible due to the killer's latency. But the reality is that even at ridiculously high latencies of up to 300ms, killers never experience overruled hits; everything that connects on their screen, does connect. (An exceedingly rare exception to this rule are packet loss scenarios, in which the server never even receives the killer's hit message.)
However, I did find out that at 300ms and beyond, general hit validation does sometimes actually work. Mind you, any latency above 80ms already gives ridiculous advantages to the killer, general hit validation only working beyond 300ms means that it might as well not be working. But either way, I did assume that general validation was simply not a thing altogether, but these tests show that it is. Sometimes. Most of the time, even at those ridiculous latencies, the killer did still get completely ridiculous hits, and that despite the survivor having a low latency.
Here are various clips showcasing what happens when facing a 300+ms killer (actual ping was around 400-600ms), while oneself having 29ms:
Here we have an instance of general hit validation working. Out in the open, the killer actually got a surprising amount of these. But again, even at this ridiculously high a latency, the killer still mostly benefitted.
Conclusion: General hit validation only exists at all at killer pings beyond 300ms, and even then it still often rewards the killer for their latency
Of course, there are instances of overruled hits even at much lower latencies, namely in pallet stun and Dead Hard scenarios. That is because BHVR has implemented hit validation specific exclusively to those events, and this event-specific hit validation actually does work. And contrary to what is not seldomly alleged, it works from the server's perspective and as such does not favour either side, but rather favours the player with the lower latency. This leads us to the next misconception.
Myth #2: Dead Hard validation is based on the survivor client
If DH validation would be based on the survivor's perspective, that would dictate that as soon as they see themselves having actuated DH, it should be impossible for them to then take damage, due to the invincibility effect, regardless of their latency.
Same spiel: A survivor dying despite that from their perspective being impossible due to long having actuated Dead Hard. Here are frames to make it more obvious again:
This is the frame where the survivor actuates DH: The "DEAD HARD" prompt disappears, the perk icon goes dark.
This is the moment the survivor goes down, some 12 frames (200ms) after having actuated DH.
It's even more obvious with the stationary DH actuation. Since the survivor does not run (no direction key is being pressed) but rather only holds Shift and presses the DH actuation button, all survivor movement is caused by DH and therefore clearly shows how far into the action the survivor already is when they go down:
Again showing the moment of DH actuation, and then moment of entering health state change:
This time it took 18 frames - we died 300 milliseconds into our DH.
Conclusion: Dead Hard validation is not based on the survivor client, but the server
The same misconception exists regarding pallet stun validation.
Myth #3: Pallet stun validation is based on the survivor client
Again, tests prove this is not the case: A laggy survivor can get hit through pallets long after having started to drop them.
Pallet drop prompt disappears, interaction starts.
30 frames (500ms) later, we get the stun event and health state change.
And here is what that looks like if the survivor is not laggy, but the killer is:
Looking at it frame-by-frame again, we can see that interestingly, the stun event now occurs as soon as the pallet starts moving, merely 10 frames into the interaction this time:
What we can conclude from this is that the stun event itself is handled on the server, and as such valid as soon as the server receives it. Of course, if the stun itself is handled with server authority, the stun-specific validation also can only depend on the server perspective. It too favours the player with the lower latency.
Conclusion: Pallet stuns and therefore pallet stun validation are not based on the survivor client, but the server
A related misconception is the idea that killers experiencing overruled hits on DH validation would enter successful hit cooldowns.
Myth #4: Killers experience longer hit cooldowns on overruled DH hits
Here's an instance of a very laggy killer (red lag icon; 300+ms) experiencing an overruled hit on a DH validation event. As can be seen, even at ridiculously high latencies, the killer does not go through successful hit cooldowns but missed hit cooldowns, as they should.
Conclusion: Killers experience the correct hit cooldowns on overruled DH hits
A different misconception regarding DH validation is that it now would "eat" attacks that in the past before DH-specific validation would have continued and connected after DH had played out.
Myth #4: DH validation cancels attacks that in the past would have still connected after the dash
The thing with this is that validation does not have any bearing on instances in which prior to its implementation a killer would "ride on the back" of a dead-harding survivor's dash and hit them at the end of the dash. This is simply because validation does not come into effect unless the killer actually successfully hits the survivor on their own screen. So any instance in which you in the past hit a survivor "through" their DH is entirely unchanged.
Here is a post-DH-validation-implementation video showcasing as much:
Only in instances where the killer actually hits the survivor before they see them use DH and as such before the dash even happens does validation come into play. And in the past before DH-specific validation, every single such instance would simply result in the survivor "Exhausted on the floor", with the killer never even seeing them DH in the first place, at most seeing them slide on the floor after having downed them, because only the killer perspective mattered.
Yes, it is possible for DH validation to "eat" attacks that in a latency-free environment might have continued through the dash and hit the survivor afterwards, but we unfortunately are not in a latency-free environment, and as such those instances are unfortunate compromises we have to make for a fair hit reg. Again, otherwise these DH latency interactions would still be as completely unfairly killer-favoured as general hits remain to be.
Conclusion: DH validation does not cancel attacks that in the past would have still connected after the dash, those instances are unchanged - but it does cancel attacks that in an environment where latency would not exist might still have connected after the dash, which is however not something that can be easily remedied, if at all
To note: There are situational, killer-specific instances where DH validation will cancel special attacks that otherwise could have destroyed pallets instead (Nemesis tentacle hits, Blight rush hits, Demogorgon shred hits, Billy chainsaw hits), and instances where it will cause Victor to go into fatigue closer to a survivor than he otherwise might have (in a genuine miss he would have overshot its target, potentially ending up further away and therefore being a little more difficult to kick). These are things BHVR is supposedly looking into.
Myth # 5: Grabs are based on the survivor client
This is a more interesting one that I personally was more interested in as well, since I could never really confirm how grabs functioned. Unfortunately it still remains a bit of a mystery to me even now. Let's go through some clips.
First, we have clips from a laggy survivor facing a non-laggy killer:
From both perspectives we can see the grab animation start, but the survivor not ending up actually being grabbed. Looking at it frame-by-frame, I can see that the survivor let go of the interaction merely 2 frames before the grab animation started playing even from their own perspective (33ms), but the survivor's latency is well above 200ms here. The survivor did let go in time, but not early enough to make up for their latency, so they should be getting grabbed here, yet aren't. This would indicate grabs are actually based on the survivor client.
However...
When we look at instances of a non-laggy survivor facing a laggy killer, this happens:
With the survivor clearly being over the pallet, and already in a standing position on the other side of it, the killer still ends up getting a successful grab.
...And then there are instances where a non-laggy survivor does not get grabbed by a laggy killer, as well as some where a laggy survivor does get grabbed by a non-laggy killer:
My conclusion for the moment is that grabs are "lag-sided". Which is to say, the server decides whether a grab happens, but it does so only once both players' info actually arrives. This wait time before the server makes the call is also congruent with the fact that killers can get stuck in grab animations for prolonged periods of time if the survivor has a very high latency or uses means to stall their connection entirely, and vice-versa.
What can additionally be said is that the current "grab validation" mechanic BHVR has in place of turning failed grabs into basic attacks is not ideal due to this wait time: when the grab is confirmed to have been unsuccessful, enough time can have passed for the survivor to be out of reach for said basic attack. This mechanic was stated to only be a temporary solution, but it's already been several months since. A simple improvement for the time being would be to turn failed grabs into successful basic attacks - so if a grab fails, take a health state off of the survivor automatically (or two, if the survivor is Exposed).
Conclusion: Grabs are most likely based on the server, but the server's decision in turn appears to be based on the availability of both clients' info, and latency can therefore unfairly be to the benefit and detriment of either side in grab interactions
This is all I want to tackle for now. I will likely be testing more stuff, such as flashlight blind interactions, and anyone can feel free to suggest more tests they'd like to see. Or to conduct and contribute their own, of course.
I end with some general thoughts:
Server-sided hit validation is fair, or rather as fair as an online multiplayer game can be, as it favours the player with the lower latency. And not only does it favour the player with the lower latency, but the player with the higher latency is also at a tremendously lesser disadvantage than they would be if on the receiving end of a client-sided system. For a crude example, in the current killer client-sided hit system, if one player has a latency of 80ms and the other player one of 50ms, the killer player has a flat latency advantage of the combined 130ms on hits (not entirely accurate because movement extrapolation attempts to make player distances a little more harmonious on the clients, but it can only do so to a limited extent). In a server-sided system, the lower-latency player here would have an advantage, killer or survivor, and merely of 30ms. And the server could also be employing lag compensation to further decrease the impact latency has on the fairness of the game. For an a little more in-depth look at this, consider reading this post: https://forum.deadbydaylight.com/en/discussion/comment/2701633#Comment_2701633
Ever since the game's launch and now still, hit reg is completely unfairly killer-sided, and only two specific events are finally subject to fair server validation. This not only "rewards" killers for any existing latency in the connections, but it also encourages killer players to artificially induce more latency into their connection, to exploit this design flaw.
I suspect one reason why general hit validation is not a thing whereas event-specific hit validation is, is that general hit validation would require the server to do hit calculations that currently only the killer client is doing. For event-specific validation, the server does not have to do complicated calculations whatsoever, it just looks at whether a DH or stun event occurred, and if it did, any hit event being sent by the killer regarding the respective survivor is rejected for Xms afterwards. As opposed to this simple mechanism, hit calculations would require the servers to do a notable bit more work and as such perhaps require BHVR to pay more for more or better servers from Amazon's GameLift service.
Either way, I hope more people will make a fuss about how ridiculous the unfairly one-sided state of hit reg in this game is, and that BHVR perhaps then might reconsider on actually implementing general hit validation, or even moving the entire hit registration system to the server authority. That would be the objectively best, most fair and secure way to do it, and basically all of the most popular and renown online multiplayer games do it.
And before someone starts to argue about "balance": Latency can never be a balancing tool because it varies wildly between different players and entire regions of players; the killer latency advantage can completely change the nature of one match and have next to no impact on another. Moreover, it is exploitable. The hit reg system and how latency affects it has to be as fair as possible, that is objectively correct game design even from a technical perspective. If it then turns out that kill rates drop notably because many killer players have been de-facto propped up by this advantage, there is of course a sheer infinite number of things in the game that can be tweaked and make for actual balancing tools that as opposed to latency affect the game in expected and consistent fashion, which can then be made use of.
Comments
-
This is the worst.
19 -
Thanks for taking the time to analyze this! @zarr
Given how salty people are regarding dead hard and pallet hit validation, doing it for every "hit" would probably cause an outcry (tbh. I would love to see it), but it would be fair. Currently, a lot of hits connect that just shouldn't, and yet, people think it's "skill", when very often it's just client-side hit registration advantage.
I'm still thinking: not everything in the DBD-P2P-age was bad. All you had to do, was to monitor the lobby ping for a couple of seconds to see if it's good (and leave if it's not). Dead hard was also working flawlessly.
PS: funny that such a core mechanic of the game is killer sided. Think about it.
6 -
Why do all these type of post always compare the killer persective with the survivors perspective? Its not like the survivor has 0 latency to the server. You can go a fair amount of distance before your client gets the "you've been hit" from the server.
Remember that killers are chasing ghosts. Where they see you is not where you actually are. Because of this, survivors are reacting to killers reacting to past survivors actions.
Welcome to online gaming.
4 -
I actually have some information on how grabs work, as confirmed by I believe Peanits himself in an older thread, if you're interested in reading it!
This was, like, 2 years ago when the concept of recoding Dead Hard and Grabs was first discussed. Both were still running on P2P netcode instead of code optimised for Dedicated Servers, and for Grabs this remains the case. Essentially, what happens is:
1) The killer sends a grab request to the server. The server double checks everything is all good, and sends the message back to the killer their grab is all clear for the moment, beginning the animation. At the same time, it sends a message to the survivor client to let them know they've been grabbed.
2) The survivor client, however, has an inbuilt failsafe from P2P days, and upon receiving a grab request will perform this failsafe, which involves checking everyone's positions again- this time based off of I believe their client. The server waits to actually allow the killer the grab while this takes place, leading to the issue of your arm just sticking out into the middle of nowhere, and everything freezing as everything is ran through to see if a grab is okay or not.
3) A lot of the time, the survivor client will reject the grab, as on their side the survivor is actually too far away now. The server receives this, and lets the killer client know the failsafe was activated and the grab has been cancelled.
Now, a fourth step occurs, which causes the killer to swing after receiving this request (although this wasn't always the case).
The same was true for Dead Hard without Validation, as all killer clients had a built-in failsafe perfect for P2P and not for Servers.
I hope this can help you understand how the grabs work a little more, at least until they get around to fully recoding it.
2 -
No-one's calling it "Skill", dude.
Most of the time it's after a survivor has vaulted a window for the 7th time on a Double T/L double window tile and we're breathing a sigh of relief and calling it "Lucky".
1 -
This explains why I'm grab-validated so goddamn often.
1 -
The Dead Hard complaints have some value, because there are situations where Dead Hard validation eating a hit instead of letting it pass through like it should due to i-frames.
Best example is Nemesis who can get screwed out of pallet breaks because the tentacle gets validated on dead hard instead.
6 -
Hatchets are indeed a beast of their own. Well, as are things like Victor pounces and Demo shreds. The thing with these is that their bonkers attack speeds exacerbate the killer latency advantage. And additionally, in the case of Huntresses hatchets and Victor, their model size to hitbox size ratio. Simple to think about it like this: If the killer hits you 100ms in the past, that will look increasingly ridiculous the more distance the killer traversed during that time - a lunge travels at 6.9m/s, which would only be a hit 0.69m "in the past"; hatchets can fly at 40m/s, which is 4m, in comparison.
I do find it ridiculous to complain about hit reg in this game from a killer perspective, as the killer enjoys hit reg privileges on multiple levels.
So likewise I agree that people should not complain about Dead Hard validation. However, complaining about Dead Hard itself is fairly understandable, it's a super strong perk and it now working as intended such that it can be reliably used for distance and to dodge hits (if you have a low latency) only highlights how strong it is. I do think adjustments are in order. At the very least, I want SWF restrictions such that they can't use more than 1 DH between them (or more than 1 copy of any perk or item/add-on, for that matter).
True on Resilience and Spine Chill. Together, they speed up vaults by 15%, which is about 100ms on window vaults and 140ms on pallet vaults. Latencies of around 50-80ms are completely common, and since the killer latency advantage is the combined total of both players' latencies, killer latency advantages of 100-160ms are completely common. As I've noted somewhere in the original post, extrapolation shaves off some of it, but it's still fair to say that even at benign latencies, Resilience + Spine Chill at most only make up for the inherent killer latency advantage, and the higher the latencies the less those perks matter of course. And yes, since those perks only apply to vault interactions while the latency advantage applies to hits everywhere, it is not even close.
Showing killer ping in the lobby or at the very least in the match info screen would be at least something. Alas we don't even have that.
You are not saying anything new here, I have explained those same things in the post. However, the point is that the killer benefits from their own latency and the survivor's on hits, while the survivor suffers from their own and the killer's.
Besides, we have killer pings of 200-600ms in these clips, and survivor pings of 20-40ms, so I'm not sure what you think your point is.
Thanks!
That does make sense, it's close to how I assumed it would function, in that the server confirms with both sides rather than making a call on a first-come-first-serve basis.
I do hope the devs will sooner rather than later tackle the "recoding from the ground up" thing they've talked about with regards to grabs and hit registration, which as they've also said do still contain various remnants from the P2P days.
2 -
I'm sad. Why did you have to do it? Now I can't blame being DH validated as killer solely on laggy survivors :( Although, it's still partially their fault :)
JK. Well done! Thanks for taking time to research this!
2 -
If there's one post that I would make every dbd developer and player read it's this post. It does such a good job at busting myths and lays out exactly where the current shortcomings are.
5 -
The only thing that pisses me off is that hit validation mostly benefict survivors.
Ok there are some unfair hits through windows, but it's a good trade for most of the rest ones.
Also, I get stunned sometimes with a Pallet while being a bit far away, sometimes it's a simple stun but other times I'm carrying a survivor and he is saved with that unfair stun and mostly the hit validation respect the survivor perspective but almost never the killer perspectve (only the hit though windows maybe). I hope "the window hit validation" will never be released, we have anough with the Dead Hard hit validation and unfair pallet stuns.
1 -
I wonder why I got DH validated so much. My ping hasn't gone above 35 ms in years.
I think that before BHVR does anything with hit validation, they need more and better servers. Adding in hit validation will prevent a lot of people from playing the game simply because there aren't any servers nearby
7 -
Ha, thanks. The respective devs that are familiar with or even worked on the hit system/network code are obviously aware of what the killer client-sided hit authority entails, but then again, we have no idea how many people that includes, whether they have any kind of say at BHVR, or whether they are even working there anymore. BHVR were for some time actively looking to hire a game network programmer, so it could be possible that the person(s) responsible for coding the original systems aren't even there anymore. And the original hit system of course was not even a networked hit system, since on the P2P architecture the killer client was the "server", operating at "0" latency.
Why they went and adopted that client-based hit system into the dedicated server infrastructure is another question. Again, one suspicion I have is that they are not comfortable having the servers do hit calculations on every single hit, as they would have to if they were hosting the hit system or employing general hit validation (at actually relevant latencies). That would increase the load on them, perhaps enough such that performance could suffer and they'd have to spend on more/better servers. But it's also possible that they were and are not comfortable coding a new, networked hit system for the servers, due to a lack of experienced networking programmers. Or maybe they are simply scared of changing anything that fundamental about the game after all this time because the game is successful as it is, and big changes that are not guaranteed to make it more successful yet come at the risk of making it less successful are obviously scary, not least because if they end up making it neither more nor less successful, the time, work and money invested into those changes was useless for them as a company that as any other company cares about money above all.
That all said, I still hope they will at some point actually do what they've at least stated on a few occasions they want to do, and take a serious look at hit authority and the hit system code again, to revamp it with dedicated servers in mind. And the reason why I've kept bringing this stuff up through the years and still do now, is that one thing that might actually encourage the devs to do so is larger parts of the playerbase understanding and being dissatisfied with the unfairness and flaws of the current system.
I'm glad the devs did at least implement the event-specific validation we have now, and I do like to believe I perhaps contributed a bit to those things happening with my talking about it through the years.
Well, validation benefits survivors if by benefit we mean it shifts the state of the hit system from being a completely unfairly one-sided affair (100 killer - 0 survivor), to a more equal one (50 killer - 50 survivor). It does not "favour" survivors however, in a sense of being a "less-than-50 killer - more-than-50 survivor" affair. That's one of the primary things I want to clarify with threads like this, that the server perspective is being used for validation and that it is the most neutral and fair perspective, in the sense of making latency affect the game in "equally unfair" ways for all players, while simultaneously also reducing the impact latency has on the game altogether. It does not "respect" any perspective more than another, its own perspective is the authority.
And again, if it should turn out that actually fair hit reg would non-negligibly affect global kill rates, there's actual balancing tools to use to compensate. Mind you, in the Korean region where latencies are very low and people are as such playing in quasi-LAN conditions, there are still many killer players that win the vast majority of their matches decisively. Of course, hit validation is not the same as an actual low-latency environment, but it does go to suggest that killers do not "need" a latency advantage to succeed. Which of course is again beside the point that many or most players do not even have a huge latency advantage, since most players' pings are not that high.
Well, the survivors you are facing regularly probably are sub 50ms too, it's common enough these days fortunately. What adds to how common instances of overruled DH hits are is that it is fairly easy to use reactively: if the killer swings at you from max. lunge range, you have 300 milliseconds to react, and even completely average reaction times are well under that. So since the survivor can react in time and actuate DH after the lunge has already started playing on their end, whereas the killer only sees them DH afterwards on their own end, the timing will often be such that on the killer's end they get a hit before the DH plays. So unless the survivor has a sufficiently higher latency than you, that will often mean the server sees the DH before the hit as well.
Just like what happened to grabs when they were moved from the killer to the server authority, validation for DH simply highlights that survivors usually do react in time, and the server overruling the killer in these scenarios is good. But yeah, again, whether a perk that temporarily grants invincibility should exist in this form at all is another question.
As for your second argument, well, while I do agree that more servers would be good, and while there are some regions where the closest servers are indeed at least 80ms away, sometimes 100+ms, for most people general validation would not be very bad at all. Yeah there would be more overruled hits than there are now, but anyone playing killer with <50ms would still basically never have to compensate for their latency and would still land most of all hits that from their perspective should land. Players in the 50-100ms range would have overruled hits a little more frequently if they go for the most ambitious, last-pixel/last-moment hits, but even they still wouldn't have to compensate for their latency an awful amount at all. It's only for players at 100+ms that things would really noticably change on the killer side, and they would have to account for that more deliberately, but thankfully the percentage of the playerbase actually forced to play at that latency is very small.
And of course, likewise it can be said that for all the people playing survivor in those regions, the lack of validation prevents them even more from enjoying or playing the game now as its existence would for killers then, since currently it's a 100% to 0% thing of favouring killers on latency, whereas then it would merely be a 50% - 50%, rather than a 0% - 100% of favouring survivors.
1 -
Just a quick and very uneducated question: How do other games handle this issue? Like ego shooters with PvP where it also depends on milliseconds?
I only played DbD, a bit of Overwatch and finally a lot of Dark Souls II/III. In Souls lag was serious issue and hits could come out pretty wonky. Players reacted by using weapons with bigger hitboxes when facing lagging opponents...
0 -
My issue is that you can play around a bad connection as Survivor. It'd be like playing Dark Souls.
You can drop things early, Dead Hard early, ect ect.
As Killer, I don't really see a way to play around poor connection if you are constantly having hits revoked, getting stunned at weird times and getting flashlight blinded long after you looked up.
Everyone should be on an equal playing field, but I also don't trust BHVR to not screw it up.
6 -
Basically all the popular games use a server-authority system, where the server has the final or even only say on important game events, most of all of course hit events. See these two articles regarding CS and Valorant, two games that are faster and more precise than DbD (hit scan means shots are basically infinitely fast, and the shot hitzone is obviously much smaller than those of killer attacks in DbD):
https://playvalorant.com/en-us/news/dev/the-state-of-hit-registration
Specifically:
Then the client compares the server position with his predicted position. If they are different, a prediction error has occurred. This indicates that the client didn't have the correct information about other entities and the environment when it processed the user command. Then the client has to correct its own position, since the server has final authority over client-side prediction.
And:
With respect to hit confirms, the client waits until it hears back from the server on the result before displaying a hit-confirm. In order to guarantee consistency across all users and to prevent cheaters from hacking their clients to give false shot results, shot results are entirely server authoritative.
These games not only use the server as an authority to validate hits, but the entire hit detection system itself is on the servers (the clients do not even predict hit events).
As I've said, doing it on the server is just objectively the best, most fair and secure way to do it, since it is the most neutral perspective, treats all players equally, prevents people from benefitting from their bad connections or from exploiting and cheating to do so (by artificially inducing latency or even injecting hit events artificially), and since it allows for the implementation of further techniques to lessen the impact of latency, such as lag compensation.
And here's the kicker: These games are actually symmetrical formats in which all clients shoot at each other, so in those games a client-sided hit system could at least actually be to the benefit and detriment of all players - in DbD on the other hand of course, we have an asymmetry where only the killer client does the hitting, so the already unfair client-based hit system is doubly unfair here, with strictly being to the killer's benefit and the survivors' detriment.
There are things you cannot play around even if you do know what the killer's ping is (which DbD doesn't tell you). Not only are you not at all always in a position to drop pallets, vault windows and actuate DH early, but doing so can even be the very reason you die, because you have to commit to an early action allowing the killer to much more effectively mindgame you. Or just think of trying to dodge a Nurse blink or Huntress hatchet when the info you have on where the killer is looking or blinking is outdated. There are tons of scenarios where a survivor can get screwed over by the killer latency advantage even if they have a feeling for how big that advantage is against their respective opponent's connection. I consider myself to be a very good player, particularly in chases - I am very experienced, practiced a lot, watched and played with and against tournament players, have done well in 1V1 competitions. I did these tests knowing what my opponent's ping is and being able to get intimately familiar with what that translates to in terms of the distance I actually have to imagine the killer at. And yet I still had plenty situations where I just got screwed over. And that was against a Trapper, there's many killers that are even harder to try and compensate for latency against. In these scenarios, holding W into corner map might actually be optimal, because anything else can get you randomly dunked on, lol.
Killers can compensate for latency similarly as well (or unwell) as survivors - where survivors have to drop pallets early, killers have to delay their attack a bit to make sure they are that bit closer to secure the hit is actually valid; where survivors commit, killers predict; where survivors dodge preemptively, killers lead shots. Of course it would sometimes suck, how latency affects games is never nice. The point is that with a server-sided authority, latency would affect both sides equally. And again, it would altogether lessen the advantage/disadvantage latency brings about significantly, because currently that advantage/disadvantage is the combined latency of both players, whereas in a server-sided scenario it would be the delta latency, the difference in latency between both players. That means killers also would have to account less for latency than survivors currently have to. Currently survivors are the only ones suffering from and having to account for latency on hits, and the latency of both themselves and the killer at that; in a server-controlled environment, not only would both sides equally "suffer" from and have to account for latency, but only their own latency, and only if and insofar it is higher than their opponent's.
Post edited by zarr on2 -
@zarr :
Thank you very much, this clears things up.
So the overall course should be to make DbD play completly on a server based system where the server has the final authority over who hits and who misses. This seems like a fair course for me and as for as I remember my limited experience with Overwatch this was not a bad thing and rarely felt bad.
Are there downsides to this system thou?
I imagine that DbD did not choose a "bad system" because they want to. You want your game to be good after all and a fun experience for all players.
From what you wrote it sounds like this will put a huge load on the server capacity which would make an upgrade quit cost intensive for BHVR.
0 -
Well, one reason why we have this system is that DbD started out without dedicated servers. The "server" was locally hosted on the killer's machine, which is to say, their game client and simulation functioned as the server, and handled all game functions. Due to that, the killer obviously had functionally no network latency whatsoever and also the authority on all game events, and so they were automatically favoured. It would not have been impossible to make it more fair even then, there are peer-to-peer games that simulate a remote host server environment (I think For Honor did this in the past?) in order to not favour one client unfairly, but either way, for DbD I think it was basically just that doing it this way was the easiest and fastest implementation that posed the least problems in making it work, and originally BHVR of course did not even expect for the game to take off like this.
Why they then never changed the system even when switching to the dedicated server infrastructure is more questionable. But I do reckon it was again a mix of it being the easiest, least cost and effort-intensive approach, perhaps not having the amount of employees with network programming expertise to feel comfortable reconstructing the entire system, perhaps not wanting to potentially pay more for servers that would have to do more work if they were doing hit calculations constantly, and maybe even the opinion that people were used to the killer latency advantage and that the game had been as successful as it had been despite it, and as such not wanting to take any risk on changing that fundamentally. On top of that it's also not like BHVR does anything big like that regularly, it takes them years to tackle things of that and even lesser magnitude, and the hit system cannot even be worked on as a "live" element of the game, the transition would have to happen at-once, and to a system they could only tinker with in "lab" environments and perhaps PTBs.
I will say that DbD is a bit of special case, with only one side doing the hitting while the other tries to avoid hits, and with various different killer attacks. I am not actually a network programmer or intimately familiar with the actual netcode behind hit reg, it is possible that DbD poses unique problems for a server-authority approach on general hit reg. I don't see any reason why, ultimately hit calculations are pretty practical, simple stuff, but it's not impossible that there are issues unique to DbD with that, I for one at least cannot exclude that possibility.
Downsides to the system would be false or delayed game feedback on the clients, since the server is the authority that clients either have to wait for or adhere to if it is in disagreement. However, those things are not actually unfair, they are just symptoms of latency being fairly dealt with. The actual issue is the latency itself. Either way, players do not like to see those things, as has become obvious with overruled DH hits. But it's not a "downside" in terms of a downgrade either, currently survivors of course get lots of false and delayed "feedback" already, by getting hit in ways that are impossible according to what the game shows them, this would only more fairly distribute that.
Another "issue" is that killer players would have to account for their latency, but not only will that not really be the case for most players (since most are below 100ms), and not only can this be combatted with lag compensation on the servers, but it's also not something that is really new, as again survivors currently already have to try and account for latency, and do so much more than players (on both sides) then will.
1 -
This is a really impressive amount of effort you've put in. Often when I get my 35ms ping hit validated, I check the survivor's ping and it way worse than that. I don't understand how that can happen if this is how it works but I can't really argue with your research.
2 -
It's important to keep in mind that it's not only network time that matters for these interactions, obviously the timings of the interactions (player input timings) themselves matter a lot. A survivor with 100ms that actuated DH 200ms before your hit happened on your end will still have that DH arrive on the server 65ms before your hit does (if you have 35ms). That just as a simple way to highlight that.
But a survivor with a higher ping will absolutely more often get failed DHs than a survivor with a lower ping would, even at the same actuation timings. The thing is that you as a killer just can't really tell whether they've gotten a failed DH, whereas failed hits are of course painfully obvious.
2 -
I would hate it so much. Simple reason, I have under 30 ms ping, so I know that most validations are because of survivor's ping. It is really frustrating to lose, because of their ping. It's not my fault we see different things.
4 -
Hey there, thank you for the very detailed write up. You hit the nail on the head with just about all of this, but there is one thing we want to clear up. These days, it's very uncommon for games to calculate hits entirely on the server. Most games will use a system similar to ours that "favours the shooter" (or in our case, the big dude with a machete/club/etc.) This is largely due to the fact that handling everything on the server feels really bad. To use an FPS as an example, you could aim perfectly and shoot directly at an enemy, but your hits may not connect because that's not where they appear on the server. As a result, you have to predict and aim for where they're going to be rather than where they are. This isn't exactly intuitive for the shooter, making it feel like you were robbed when your hits don't connect.
Now, back to Dead by Daylight: DBD is a unique beast since we're typically dealing with melee attacks, and most importantly, your target is running away from you. This is very easy to overlook, but it makes a very crucial difference in practice. In DBD, predicting where your opponent is translates to "get even closer to them before you try swinging"- something that you usually don't have the luxury of doing without having a pallet dropped on your face.
Let's say the survivor you're chasing is running towards a window and about to vault it, but you, the Killer, can juuuust barely lunge and hit them before they make it through. With the system in place now, the server will validate that you were close enough (within a reasonable margin) and give you the hit. But on a purely server based system, the server sees the survivor as further ahead, so the hit never happens.
Is this more fair? Not quite, since the Survivor is always in reality going to be ahead of where you see them. This would mean that any time you can just barely lunge and hit your target, you'll miss. It's not your fault either, it looks like you're close enough, but since the Survivor is (in theory, at least) running away from you, the gap will always be smaller on your end than the server/Survivor's end. This is the main reason why we only validate the hits on the server, not check for them.
For what it's worth, this was actually tested! A system where everything is handled on the server is actually easier to implement than the system we have now. The trouble is, it leads to a whole bunch of rejected hits even with a fairly good connection. This is why we went through the extra work to make it work the way it does now. As long as your connection is decent, your hits shouldn't be rejected, with some additional checks around things like pallets & Dead Hard to ensure that it's operating as fairly as possible in those key moments where every split second counts.
In this upcoming Mid-Chapter, we're also doing some more work to clean up rejected hits. If you've got a good connection but a hit is rejected (whether that's because they used Dead Hard or dropped a pallet on you first), then the game will avoid giving you any feedback that might suggest you hit them. This has zero impact on actual gameplay, but cleans up those weird moments where you see yourself hitting the Survivor and they even fall to the ground only to get right back up and sprint off into the sunset.
Hopefully that sheds some light on why we chose to handle hits the way we do. It's worth noting that we're always looking for more ways to improve hit detection as we go forward, so what you see now likely isn't going to be the exact way it works forever.
23 -
Why is hit validation not applied to vaulting windows? As a survivor, I often clear the window and still get hit. You know how it is, we have all been there. But surely hit validation would clean up some of those instances and make it more clear if the killer hit me or if I escaped.
6 -
the fact that you didnt correct my comment on the grabs makes me think i at least got somewhere close to the ballpark of remembering your comment correctly
0 -
Windows are trickier than pallets and Dead Hard. If you Dead Hard, for example, you're invincible until the dash ends, meaning any hits during that period couldn't have connected. The server can very easily check if the Survivor used Dead Hard before the hit was sent and reject it. Or to use pallets as an example, the server can easily check which was sent first (the stun or the hit) and reject the hit if the stun was first. Can't hit someone if you're stunned, after all.
A window, on the other hand, does not protect you from damage. It's totally possible (and even intended) that you can hit a Survivor through it so long as they're close enough. Because of that, you can't really apply the same logic as pallet stuns since it's still possible that the Killer fairly hit you through a window. Likewise, there's some added complexity in that you can accidentally vault into the Killer (yeah, I've done it before, I'm not ashamed to admit it), so it's not as simple as saying "You vaulted therefore you're safe."- if you did, vaulting at the Killer would give you an immune period.
But all that aside, I'll leave that up to the people who are way smarter than me and actually work on system like this. :P
9 -
And I appreciate the detailed response, very cool to see.
I know you ran this by the team and your response is informed by that, and I won't pretend to know more about this stuff than the dev team does, but I do want to clarify on some things here, and be it to get another response that can clear them up for me instead.
You say it is uncommon for games these days to have the server handle the hit registration process, but above I linked articles regarding two of the most popular FPS games out there, and they explicitly state they use the server to calculate and confirm hits, and as opposed to DbD they don't even let the clients do prediction on that. I could find similar info regarding Rainbow Six Siege, Apex Legends and Unreal Tournament. Am I overlooking something, or are these games an exception?
With regards to players having to predict or lead shots, games usually solve that by employing lag compensation on the servers, i. e. having them roll back game time calculatively according to time stamps of the client info coming in, and checking whether the game state allowed for a hit to happen at the time of the input, thereby taking into account both players' real-time positions and the hitter's view angle.
But even without lag compensation I can't really see that it would be a big issue at normal latencies to have the server decide whether a hit happens. Yes, the killer on their own end still appears ever so slightly closer to the survivor even at low latencies than they are on the server, but at <50ms and with taking into consideration extrapolation on the survivor position, I have a hard time imagining that killers would regularly get overruled hits here. At those latencies it should only at all happen for hits connecting at the very last "pixels" of the attack range, and those are rare instances, instances that can regularly be avoided by the player, and instances in which getting overruled hits if they do happen would not seem very off either, since the player is going for very ambitious attempts. You could also refrain from having the killer client predict hits, such that they won't even get false feedback in these instances, or apply whatever you are doing to make false feedback on validated Dead Hards less frequent an occurence to these instances as well.
And while it is true that killers would have to account for their latency more if they have a bad connection, by making sure they are getting a bit closer to the survivor on their screen before they go for a hit, there are a lot of situations in which that is possible, there's not always a pallet around the survivor can get to just because the killer did not go for a max. range lunge beforehand. And regardless, with the current system survivors of course do have to account for latency, "predicting" how much closer to them the killer is than it appears on their screen. And so even if overruled hits would be a more frequent occurrence even at relatively average latencies with a server-based hit system, I wonder why it is deemed okay for players on the survivor side to have to compensate for latency (and not only their own latency but the killer's as well), and to receive "impossible" hits frequently, but not for killers to have to account for (merely their own) latency and get overruled hits.
I do appreciate the fact that you actually tested a server-based hit system and of course can see and experiment with things in action that we can only theorize about. But I would still like you to reconsider whether making the server the authority on hits isn't still desirable, and more frequent overruled hits simply the trade-off in a fairer system that leads to less impossible hits from the other perspective. Lag compensation might also be something you could look into.
Apart from that, I would like to ask you to at least reconsider whether the current general hit validation implementation should not already be used at latencies below the ~300ms threshold it seems to currently fall to. Players are already experiencing severe disadvantages facing killers with latencies of 100+ms, and as such I think making 100ms the threshold would be more reasonable.
The very least you could consider doing for players is show the killer ping to survivors, either already in the lobby, or in the in-trial match details overlay. This would allow players to at least better adjust to the latency disadvantage in the respective match.
5 -
Bullets are way faster than movement speeds in any of those games. This is not applicable to DBD where almost the entirety of relevant movement is on drastically slower scales. Shooter games are not as forced to track ghosts because the bullet fires so fast there would be next to no movement difference possible between fire and hit time (and none technically, in hit scan). In games where it’s essentially a cat chasing a mouse through physically running at comparatively snail-like paces, that would be extremely problematic because of exactly what Peanits said. No matter what it does, it would not favor the killer because all information they receive is late significantly.
3 -
in regards to windows let me just put it this way. I used to work at a gas station and saw a customer smack someone in the face over the counter. keep in mind the counter was about 2.5 feet deep a window is what? 6 inches deep? we will take the freddy for example cause he is among the shortest. if freddy has an arm length of 2.5 feet and hand length of 8 inches which i feel would be fair and average for someone his height. and you add in his claws of 6 inches that means from tip of fingers claws to his arm pit would be 3.6 feet long so take away the 6 inches of window and you have 3 feet of distance past the window that he can smack you. you have to be a good distance from the window to not get hit. just vaulting it wouldnt do the job
4 -
I don't really see the issue the speeds of the attacks would introduce here. If the killer has a latency of 50ms to the server, the survivor position is only 50ms further in the past on their end than on the server, which is usually only 0.2m. And movement extrapolation done on the killer client reduces the disparity even more, by putting the survivor slightly further into the future than the position info the killer client has available. Server and killer client here should be close enough for most of all hits to be valid.
At average latencies I can't really imagine that this would lead to many instances where things that look like they should connect, do not connect. Only really in "last-pixel" edge cases, which are fairly avoidable. At increasingly higher killer latencies, sure the killer player would have to account more for their latency in order not to experience overruled/phantom hits more frequently, but that is just fair, because for one thing survivor players also have to account for latency, and furthermore that is making it so that both sides will have to account for their own latency, rather than only survivors having to account for both their own and the killer's latency.
0 -
What did you use to simulate latency ?
0 -
I would rather not share this because it can be exploited by players on the killer side (and by players on the survivor side to lock killers into certain animations).
If you are interested in conducting tests yourself, I suggest you find a fellow player from a far-away region from yours, and then whoever of you two hosts the custom match will have a low latency due to connecting to nearby servers, and the player joining the match a high latency, due to connecting to that far-away server. Alternatively, a VPN can be used to reroute data around the world. I did some of the testing using those methods as well.
0 -
Oh I already tried with a VPN and severals softwares to see if we had the same results I was just curious to know what you personally use for this experiment.
I found that using your power on most killers is a nightmare when you have latency. Can you explain why ?
If latency is so strong for killers, why is it not a thing like stretched res ?
0 -
Different killer powers are differently coded from basic attacks, but that doesn't mean all of them are affected by latency in their use. Trapper has no problem placing, picking up and rearming traps regardless of latency for instance. I know Huntress hatchets must be subject to validation in a way no other power seems to be, I have seen decidedly more overruled hatchet hits than overruled general hits (of which I had seen 1 (one) instance total, prior to my experiments). Plague's Purge seems to be affected by latency in that the time before you will actually unleash the attack depends on it, which suggests that it is not predicted on the client.
So yeah, the explanation is that killer powers have code that is not simply basic attack code. Apart from Huntress hatchets I don't think any of them are validated for in a special way, I at least have never seen other overruled special attack hits out in the wild either, but some of the specifics of some of the abilities are definitely affected by latency. One major reason is probably indeed that they are not predicted on the client side, so the handling gets weird with increasing latency. But your question is still good, I should actually do experiments on how latency exactly affects different killer abilities.
Well, if by being a thing like stretched res you mean players exploiting it, then it is a thing like stretched res. People totally do use laghacks and VPNs to artificially worsen their connections. If you mean why isn't it as common a thing as stretched res, well, we would have to speculate on the actual amount of intentional exploitation that's going on with these, but I would agree that stretched res is likely much more common. The reasons for this could be the following: As a killer, you don't actually readily notice that you are benefitting from your latency a whole lot. There are some tells you can look out for such as people sliding into their actual position after you down them, and at ridiculously high latencies it can become rather obvious in other ways too, but hit distances themselves actually do look mostly standard on your screen regardless of your latency as killer. Of course, for survivors hits get more and more ridiculous the higher the killer's latency is, but if they don't stick around to yell at the killer for their McDonald's WiFi in post-game chat, the killer'll perhaps be none-the-wiser. I mean, one of the reasons why I created this very thread to begin with is that many people still do not understand how and why killers benefit from latency. And another reason is that the killer advantage at exploit-worthy latencies is obvious for survivors, so they'll know you have an unfair advantage and are likely intentionally doing it, whereas stretched res of course isn't. Plus stretched res is much easier to achieve than connection manipulation for most people.
That said, "stretched res" (narrow aspect ratios used in order to gain more vertical Field-of-Vision) particularly on the killer side has much less of an impact on the fairness of the game than latency exploits, so I for one am glad the latter are much less frequent of a thing.
Post edited by zarr on0 -
So what's the point of this?
the problem with hit reg is that you took the problem away from the side that has a choice on when to use deadhard and when to drop a pallet and put it on the side that needs accurate information to react.
If i walk up to a survivor to try bait out a deadhard then i need accurate info so i know when i can or can't attack. Same with pallets, i know i should get the hit on my screen so i attempt to hit the survivor and risk taking the stun. The problem is i don't know how trash tier the survivors net is that i am attacking so i am not being fed accurate info and i take a stun and waste time instead.
They moved the problem from the side with a choice and multiple options to the side that has no choice or options.
Are you really going to tell me that the validation videos shown on this forum are fine? the ones where they hit the survivor and then there is a delay before they deadhard. Its disgusting.
1 -
You are asking what the point of this is while clearly not even having read the actual post.
No, one is not taking the problem "away from one side and putting it on the other", the very point is that validation is server-sided, and as such taking the problem from affecting only one side (survivors) and moving it to the middle (the server), such that it equally affects both sides (killers and survivors). You are not getting DH or pallet stun validated on hits because the survivor has bad net, validation does not favour them for their latency. I can't make this any more clear.
Furthermore, I have already lined out in an earlier post that killers can actually compensate for latency just as well (or, again, unwell) as survivors. You may refer to that post. But I will even go further for you: I would argue killers are if anything more able to compensate for latency, because they can actually regularly just get a little closer to survivors before they attack in order to make sure they secure a hit, because they are faster than survivors. What's a survivor going to do against a killer that is faster than them and is also closer than they appear? Run away faster? Sure you'll say drop pallets early because, of course, there's always pallets around, but with that I again refer you to my earlier post in which I already addressed these very arguments. Here's a new argument that I invite you to take me up on though: A match of DbD consists of 5 players, 4 of which are survivors. Why would it not be objectively more fair to favour the 4 players on latency over the 1? That is of course beside the point that a server-authority hit system does not favour either side, but if we were to actually do what you falsely assume BHVR did do, and take hit authority away from the killer perspective and shifted it to the survivor perspective - why would that not be more fair, given that now 4 players are not being screwed over by latency, rather only 1?
Killers do indeed have options to deal with the problem, and sure they aren't great options, but neither are the options survivors have. The effect latency has on multiplayer games and how you play them sucks, latency sucks. The point is that with regards to hits, currently and for the past 5 years, latency has only sucked for survivors completely one-sidedly. Making things more fair would indeed make it affect both sides, of course changing killers from not being affected at all to being affected, but not only is that objectively more fair (and secure and healthy), but in that reality players at least only have to play around their own latency, rather than the combined total of both their own and their opponent's latency (which is currently the case for survivors).
I do have to say overruled DH/stun hits due to server-side validation are fine, yes. Just like instances of survivors dying despite having actuated DH/stunned the killer in time on their screen are fine, since their latency prevented their action from being validated by the server. Because that is dealing with latency as fairly as possible. Latency is the not-fine thing here, and for all hit interactions that are not validated on the server, it is totally not fine for survivors. Look at the clips I posted. A killer with 400+ms hitting a ~30ms survivor 2m after they vaulted a window or pallet. That is disgusting.
3 -
Oh so this explains why i got hit while saving guy from the hook in end game phase, get injured, even if i have distance, i use dead hard to windows with spine chill/resilience combo but ma guy still manages to hit me from Africa! I knew Huntress wasn't the only killer that has range attacks. It even happened today, fast vaulted a window i even made 2-3 steps forward but Nemesis and his big arms can reach me even if we had a country between us.
And no, i don't have a high ms. Between 39-45 all the time, never goes up.
0 -
Wow, you actually said to just bait out the deadhard. i see what i am talking to now.
Validation has taken the problem from the side that has options like dropping the pallet one loop early or using the deadhard early for distance to reach safety (all positive things for them and their team) and unintentionally put it on the side that needs accurate information to react to what the survivor is doing and who's only option is to respect every pallet and never take risks leading to 5 gen chases.
Survivors have always been able to react to my attack with deadhard because my ping is stupidly low so it is nothing new to me. The problem is i am being punished by lagy survivors and their trash ping is now my problem when it never was before. Validation is a one way street that is only beneficial to the survivor side.
Where is grab validation? Gen grabs should be rewarded with 8k points because they are so impossibly rare to the point where i was watching a streamer who sat on a gen and watched the killer stretch out their arm before letting go of the gen. The game reversed the grab and changed it to a hit allowing them to finish the gen in the killers face for adrenaline. How is that in any way fair to the killer?
3 -
Wow, you actually said to just bait out the deadhard. i see what i am talking to now.
What? Genuinely do not understand what you mean with this. You can never react to Dead Hard because if it plays on your end you can obviously not hit the survivor until it ends. Instances where your hit is overruled and Dead Hard then plays are again instances of the server identifying that the DH happened earlier and made the hit impossible, ergo they are fair (or as fair as an online multiplayer game can be).
Validation has taken the problem from the side that has options like dropping the pallet one loop early or using the deadhard early for distance to reach safety (all positive things for them and their team) and unintentionally put it on the side that needs accurate information to react to what the survivor is doing and who's only option is to respect every pallet and never take risks leading to 5 gen chases.
It's becoming rather clear that instead of trying to engage with my arguments and experiments in an actual facts-based discussion, you are more interested in repeating biased talking points. You apparently want network latency to favour the killer side on hits completely, even their own latency. Or you don't want to understand that it does. Makes me wonder whether your ping is actually "stupidly low". (And if it is, you would not even notice hit authority being moved to the server much.)
I really am not in the mood repeating statements that I already repeated for you and that would not have to be repeated at all if you had simply read the original post. But one last time:
Validation has not taken the problem from one side and put it on the other. Validation is not based on the survivor perspective. It is based on the server perspective, which does not favour either side.
This was not unintentional. BHVR very intentionally worked on these event-specific hit validation methods and they are very aware of the effects they have. Overruled hits on the killer side in cases where the server determines that those hits where not valid due to latency, are what validation is supposed to do. Literally one job.
Survivors have as few ways to play around latency as killers do, and as I've said, arguably even fewer. I implore you again to look at my clips. Tell me, what can a survivor do in order to avoid getting hit 2 meter after having vaulted a window or pallet, or from 6m out in the open, against a laggy killer? Committing to interactons such as these that early is a detriment and risk for survivors even if they would save them from ridiculous laghits, because having to commit early opens them up much more to be cut off and mindgamed. But it does not even save them from ridiculous laghits to begin with.
I refer you again to my post in which I already addressed ways in which killers can attempt to compensate for latency that are similar to those survivors have available, this time even with a link: https://forum.deadbydaylight.com/en/discussion/comment/2737212/#Comment_2737212 (It's in my response to Pulsar.)
Survivors have always been able to react to my attack with deadhard because my ping is stupidly low so it is nothing new to me. The problem is i am being punished by lagy survivors and their trash ping is now my problem when it never was before. Validation is a one way street that is only beneficial to the survivor side.
I will again repeat that not only is validation not a "one-way street" that rewards survivors for their own latency (again, it is based on the server and therefore punishes players for their own latency; please refer to the original post which is showcasing this fact with easy-to-understand video evidence), but in fact the game without validation is a one-way street, of rewarding killers not only for a survivor's but also their own latency, since every hit that is not validated for on the server is based completely, exclusively and authoritatively on the killer's perspective. In a server-authority environment, not only are all players equally punished for their own latency rather than rewarded for it, but players also only have to account for their own latency, rather than having to try and account for both their own and their opponent's (like survivors, again, do have to currently because hits outside of DH and pallet stun interactions are completely based on the killer's perspective, and for the past 5 years even hits through DH and stuns were).
Where is grab validation? Gen grabs should be rewarded with 8k points because they are so impossibly rare to the point where i was watching a streamer who sat on a gen and watched the killer stretch out their arm before letting go of the gen. The game reversed the grab and changed it to a hit allowing them to finish the gen in the killers face for adrenaline. How is that in any way fair to the killer?
This is a fair point, and I address grabs and how latency affects them as an issue in the original post. Mind you, as my tests show, it can still negatively affect survivors on grabs too, and of course, basing grabs entirely on the killer's perspective again like they were in the P2P architecture is not a solution since latency then again would only affect survivors negatively on grabs too. But I do agree that how grabs are currently handled is not ideal, and I even suggest a clear improvement for the killer side of that issue in the original post. Being locked into a grab animation and it if it fails then being turned into a basic attack that might very well not hit the survivor is indeed not fair for killers. Failed grabs should at least be turned into actually-successful basic attacks automatically.
3 -
None of this makes sense to what happens in game. The gif from the killers perspective with the pallet hit is what i see all the time (specifically against console users) but i do not get the damage state and instead get teleported and stunned. Perhaps the game acts differently at your exaggerated pings compared to the more sane and common pings of 20-80 ms?
I also get the killer is lagy but survivor isn't one with an almost instant stun the moment they tap the pallet. But again, i am at 20 ping so this doesn't make sense unless the game is lying about my ping.
Can you do a console vs pc test to see if something is iffy with the conversion between the platforms? I don't have many issues against pc users. Generally they are around the same ping as me, but console users are horrible to play against and usually fluctuate around 60-90 ping thanks to wifi.
This also doesn't explain the instances where you hit a survivor and there is a lengthy pause before they deadhard on your screen
Window hits are what ever.. The day they validate basic hits is the day killers start to quit faster than they already are. A 300ms ping killer is so rare and requires a vpn or program to get matched with them that it isn't worth punishing everyone else.
2 -
What you may not really think about are the timings of these interactions, and that they regularly matter much more than latency. Say you have 20ms and the survivor you are facing 80. Lunges last 300 milliseconds, Dead Hard 500 millseconds, pallet pulls 600 milliseconds. A 60ms difference in to-server latency between you and the survivor does not really mean all too much for interactions like this, if the survivor enacts them in a timely enough fashion. And of course, they can even have done so before you started to attack. You shouldn't expect to always get these hits just because your latency is low, if your opponent's latency is also fairly low. But you should be aware that if the timing is tight enough for those 60ms to matter, the server will favour you as the lower-latency player on validation, and the other player will get screwed by their higher-than-yours latency as a result. You often won't even be able to tell you hit them through DH or an early pallet pull in these cases, on your end the hit may look fairly benign. So there exists a sort of "selection bias" in your perception of overruled hits by its very functioning, since you will mostly only notice when an attack of yours that should connect from your perspective doesn't connect, and those instances will be annoying for you, whereas you won't really notice when an attack of yours that shouldn't connect from your opponent's perspective does connect.
Speaking from my experience as a low-latency player too, I am if anything surprised what kind of close-call hits I still regularly land through pallet drops. Overruled hits on DH are a more common occurrence for me too (though not very common either), but that's not surprising to me because the reaction time + to-server latency of survivors will just often be below the timing of attacks + my to-server latency.
I don't know anyone personally that plays the game on console, but I'll see what I can do. Whether cross-platform scenarios change anything about these things is not an entirely uninteresting thing to look into. Noted.
"Lengthy pause" DHs are something I would have to see on a case-by-case basis to be able to tell what might be going on. Don't think we got any instances like that, at varying pings on both sides.
Luckily very laggy players are indeed rare. This game would be nigh-unplayable on the survivor side if 100+ms players were the norm. But yes, that is not the case, and so while it is a very bad experience if it does happen, the completely unfairly killer-sided hit system has not prevented me or the many other people from playing this game a lot. If players are at around 50ms and below, things are actually mostly totally fine. It's not a do-or-die issue. But it's still a very important issue, not least because it allows for fairly easy exploiting that is otherwise pretty much impossible to prevent for the devs.
1 -
Easy fix for BHVR in all this is to show the Survivors the Killers Ping to the Lobby and show the Killer the Survivor Pings.
Only till its more "fixed" should i say so we know what we are walking into.
1 -
I'll be honest I found this very hard too long to read but from what I've read you did a really good job.
Well done on doing a really good test that clears up a lot of things for other people 👍
Also I'd really like to know how long this took to properly test, and especially type out that whole discussion lol
0 -
The main testing didn't take very long, just a few 10-30min sessions. But we also had some fun with it and such. But then I had to go through recordings and make clips and all that. And yes, type out a bunch of stuff. Glad you appreciate the effort!
The main post is definitely a little big, would probably be better if there was a way to collapse/expand sections such that the overall format is easier to follow. But I'm sure people that are interested enough in this stuff don't find it hard to go through, I know I wouldn't.
Cheers. 👍️
0 -
I knew after reading the first bit it was a bit long for me. However after seeing how long it was, the amount of images you included and the credit you got from the comments, I had to give you credit for the amount of effort you put in. This is one of those discussions I might someday come back to read someday if I have any queries on the topic.
It may not have been for me but more of these tests and discussions like this are really good to see. Well done mate 👍
0 -
The problem is the "reasonable margin" is too generous and excessive.
On the point of fairness, yes, it's not fair to get denied hits, but it's equally unfair to get struck when you are far! It seems the devs are exclusively concerned with fairness from the perspective of The Killer. What about fairness for Survivors? It's devastating and frustrating to get hit despite clearing a vault or being too far. Killers often get unfair hits, but that doesn't seem to matter to the devs; they are only concerned with making sure every hit lands for The Killer. Even Pallet and DH Validation seems watered down since the original implementation.
0 -
Been a while, but here's two more things, one of which I had already tested quite a while back but never got around to posting, and another which has recently gotten relevant.
1: Flashlight blinds are not based on the survivor or killer client, but seem to be handled on the server.
Here's a laggy killer (red lag icon) being blinded by a non-laggy survivor - the killer looks away in time on their screen but still gets blinded:
And then here's a non-laggy killer being blinded by a laggy survivor (400+ms as per overlay) - the killer does not get blinded, despite the survivor on their own screen having shone at them for more than long enough:
2: Hit validation for Dead Hard still functions after its rework. Laggy killer getting validated on a non-laggy survivor's DH:
3 -
and yet, nobody can see the killers ping
2 -
That's the most interesting and well-formulated analysis I've seen yet !
It does grate me a bit that the system makes survivor have to compensate for the killer, and that they actually suffer from it. It doesn't feel very fair.
1 -
Who dug this up from the grave? 😂
0
