Visit the Kill Switch Master List for more information on these and other current known issues: https://forums.bhvr.com/dead-by-daylight/kb/articles/299-kill-switch-master-list
We encourage you to be as honest as possible in letting us know how you feel about the game. The information and answers provided are anonymous, not shared with any third-party, and will not be used for purposes other than survey analysis.
Access the survey HERE!
Explaining why Stun Validation looks weird, but makes sense, on a technical level.
"Stun validation has been added to the hit validator. If a Killer has a pending stun on the server, the server will reject the hit. This will be most noticeably in situations such as a Killer who is attacking at the same time a survivor is throwing a pallet, and it should reduce instances where survivors appear to take damage after stunning a Killer."
I work in the field, so let me explain on a technical level why it looks so weird but why this change is necessary.
The most awkward situations happen when:
-----------------------
FIRST SCENARIO. KILLER HAS A LOW PING, BUT ATTACKS ALMOST AT THE SAME TIME.
(*) The server queue look like this.
[Survivor A] [13:32:12:14] [Pallet drop] [Location X] (*1) (Outcome) [Killer] [Status update] [Stun] [Killer] [13:32:12:18] [Hit register] [Survivor A] (*2)
I'm supposing that killer's ping is 20ms, while survivors' is 30ms.
(*) The survivor perspective look like this.
[Survivor] [13:32:11:44] [Pallet drop] [Location X]
Note that survivor (in real time) dropped the pallet at [13:32:11:44], with the 30ms delay, the server received that the Survivor dropped the pallet at [13:32:12:14] (*1).
(*) The killer queue look like this.
[Killer] [13:32:11:58] [Hit register] [Survivor A] [Survivor] [13:32:12:48] [Pallet drop] [Location X]
Note that the killer hit the survivor at [13:32:11:28], with the 20ms delay, the server received that the killer hit the survivor at [13:32:12:18] (*2).
In the other hand, notice that the killer received that the pallet was dropped at [13:32:12:48], 50ms after the actual drop, because the server has to receive this input from the survivor (+30ms), and send to the killer(+20ms).
Notice that more extreme scenarios can happen if the killer has a higher ping than survivor but hits before the stun.
As you can see, there's no doubt that the survivor dropped the pallet early. Mathematically, this awkward situation will always happen when action_registered(survivor's clock + survivor's latency) < action_registered(killer's clock + killer's latency). As there's no doubt that the survivor dropped the pallet early than it received the attack (in real life time), It's safe to say that (*2) can be safely removed from the server's queue, since it doesn't make sense in our real life time. Unfortunately, doesn't make sense on killer's perspective.
-----------------------
SECOND SCENARIO. KILLER HAS A HIGH PING, BUT HITS BEFORE THE PALLET DROP.
(*) The server queue look like this.
[Survivor A] [13:32:12:14] [Pallet drop] [Location X] (*1) (Outcome) [Killer] [Status update] [Stun] [Killer] [13:32:12:18] [Hit register] [Survivor A] (*2)
I'm supposing that killer's ping is 60ms, while survivors' is 30ms.
(*) The survivor perspective look like this.
[Survivor] [13:32:11:44] [Pallet drop] [Location X]
Note that survivor (in real time) dropped the pallet at [13:32:11:44], with the 30ms delay, the server received that the Survivor dropped the pallet at [13:32:12:14] (*1).
(*) The killer queue look like this.
[Killer] [13:32:11:58] [Hit register] [Survivor A] [Survivor] [13:32:12:34] [Pallet drop] [Location X]
Note that the killer hit the survivor at [13:32:11:58], with the 60ms delay, the server received that the killer hit the survivor at [13:32:12:18] (*2).
In the other hand, notice that the killer received that the pallet was dropped at [13:32:12:34], 90ms after the actual drop, because the server has to receive this input from the survivor (+30ms), and send to the killer(+60ms).
This second scenario is the unfortunate one. But as you can see, if the killer has such a high latency, the survivor didn't had time to react the attack, or the animation, because it didn't even appeared on their screen because wasn't processed in the server yet. It's the kind of situation that the pallet is fully dropped and you suddenly get down. Makes no sense from the survivor's perspective.
-----------------------
People comment and upvote so more people can understand a little more about this. If your hit gets negleted by the server (1) you got stunned before, in real life time (2) you need to call your provider to ask for a better connection, or blame DbD's team for a poor server location.
Comments
-
I got robbed of 2 hit in the same game and i decide to quit after in my opinion the game was over in that scenario
0 -
You didn’t get robbed of 2 hits, the hits should never have happened in the first place, hence why the server corrected it.
17 -
I understand your frustation. I've updated the post with more details. Please check out.
1 -
I always appreciate explanations like these,so thanks OP 👍
1 -
Here's some insight from a dev that can also be helpful, as I've seen people saying to make them not scream, and this explains why that's not feasible.
0 -
That is a poor excuse, all it's going to do is frustrate killers if a survivor screams it should be a hit
1 -
He got robbed because he's playing according to what he sees on his screen. No-one can play according to what the server sees. Which just means that in chases (i.e. the critical component of the killer's role), the survivor gets favoured because the killer is punished for acting on what they see on their side with no ability to work beyond it
0 -
I mean, Survivors before this change got robbed of health states consistently, even though the pallet was already dropped. Effectively, having a high latency gave killers an advantage by "robbing" healthstates from survivors. Now the person with the worse connection gets the punishment, rather than the person with the better connection.
You should never give priority to someone with higher latency.
So no, the killer doesnt get robbed, they never hit it anyway. They should blame their connection rather than the game.
3 -
I'm gonna disagree there... survivors often get greedy and wait to drop the pallet at the last moment. That's where the punishment comes in.
Now, they're being rewarded for it.
0 -
Goody, so we're going with "sucks to be you, get used into it" reasoning.
So with all the other balls in the air killers have to juggle, "did that scream because I smacked the survivor actually count as a hit" is getting tossed in there too because now we can't even rely on what we see and hear to be what's happening.
I'm gonna be blunt DBD Dev guy on the stream; if this is just now going to be something killers just have to deal with because you can't or won't figure out an actual fix, I'm probably done. Red Ranks is frustrating enough as it is and now having to play a game of "Did I actually hit the survivor?" every time I swing at them is just one frustrations too many on the pile...
0 -
I agree with your sentiment, but the servers in this game are not the best all the time and the game should not overly punish someone, who might even have great internet, for server issues like ping. At least with the old system both killers and survivors got something. Killers a hit and survivors a stun (and yes I know the stun is not worth much). People can only go with what they see on screen.
1 -
This! We don't have enough of this here. People who can actually breakdown the technical aspect and explain it clearly. Thank you!
1 -
So in other words if you don't live in the servers back yard or have $1000 a month internet Go ######### yourself....got it.
0 -
Bruh
1 -
Where do you live that a half-decent Internet connection is so expensive?
0 -
How is that a fair punishment if they succesfully dropped a pallet? That was always the risk/reward.
If you were to succesfully get a risky stun out, you shouldnt recieve that hit. Just as risky it was for a killer to greed for a pallet hit.
Except the killer doesnt get rewarded for a hit that was too late anymore.
Your logic here is entirely flawed.
2 -
im tired and sick i dont wanna read this ksamfsdjsd
0 -
We can't play based on what the server sees but I find the ongoing endless churn around this point amazing.
I've been playing games since forever. It didn't take long to figure out with online games that often the perception I have of what's on my screen isn't 'real' and isn't the end all of what will happen when actions take place. It's been like this in many, many online games forever.
Still, people come to these forums and complain. Given, it's right to complain that the results aren't fulfilling and they're making the game less fun. That's always going to happen both ways. Survivors will feel ripped off sometimes, killers will feel ripped off sometimes.\
But to come on and act like you're somehow right because it LOOKED like something happened on your screen but the server obviously disagreed and you just don't see it and it has to be explained to you... Get some skill at analysis. It's so hard to believe that people can't figure this out. Maybe I just don't understand how people complain any more. I suppose it's still the same problem, just ridiculous how people complain about it as if they don't understand how web-based games work and they seem to think that what's on their screen is gospel and they got ripped off rather than it's that there still needs to be some massaging to the webcode to make things make sense to as many participants as possibe.
That being said, the game industry is crazy in that every developer seems to have to figure out the same s**t in every game. You see problems in multiple MMOs that have been solved in other MMOs years ago and follow the exact same solution path, from the user's perspective. Same with multiplayer PVP games. I remember some of this stuff with TF2 and I'm sure it happened with other shooters but I haven't played those. Constantly, games are somewhere on the curve of fixing these multiplayer hit issues and pissing off their players. You'd think there'd be a solution. It's like we're watching car designers putting fuel tanks in front of the dash until enough people die for every car model, then putting the fuel tank on the roof, etc. for every car model as they figure it out for each individual one. Just really weird that there aren't industry veterans who can come in and know how to fix these problems quickly. It's like developers are always solving these problems for the first time.
1 -
I don't understand why people talk about 'fairness' in this context. Both clients versions of events are valid, the server literally has to pick one though. Do you favor whoevers input got there first? Do you favor the defensive action? The offensive one? There is no fairness here, just an arbitrary decision that MUST be made. Short of taking away the asynchronous nature of online games this is an impossible solution to solve for.
This is why you see wacky things like the hit occurring but not really. Imagine if it was the other way around, the survivor drops a pallet on their screen, they get hit, then the pallet magically pops itself back upright. That is also a potential solution to the problem, I'm not saying which one is correct because the answer of which is correct depends entirely on what you think should be prioritized.
0 -
You can solve for it in a way. You have to find a way to make it make sense for all players involved. Like in an online shooter, right? It's a little Hawking-ish, but you shoot at me and I move and you haven't seen me move yet and I haven't seen you shoot yet.
From your perspective, you shot dead on. From my perspective, I moved out of the way then you shot. Who was right? To your point, one has to be picked. Honestly, I don't know the solution but I DO know that there are tons of games out there with more players and faster reaction requirements that don't have these sync complaints. So there IS a solution to make the game FEEL right even if the math isn't right or perfect. We have to wait for Behaviour to MAYBE find that happy medium or, like some games, to just keep oscillating back and forth and pissing everyone off. Hopefully, they find a solution. Maybe hire someone from a Battlefield dev team or Fortnight or Apex Legends or something where this kind of hit validation is critical so they can find out how to make it work and keep their paying players happy.
0 -
Maybe hire someone from a Battlefield dev team or Fortnight or Apex Legends or something where this kind of hit validation is critical so they can find out how to make it work and keep their paying players happy.
I keep seeing videos of all those games from people complaining about hitboxes and hit registration. That's because there is one absolute and overriding factor here that no amount of programming can account for: the laws of physics.
0 -
Other games might have faster tick rates(how often data is transmitted to the server) or smarter algorithms to hide the truth of what really went on, but at the end of the day there will always be divergent client versions of events and when two of them clash on an action the server has to choose which one will become reality.
1 -
What did you expect?
0 -
Interesting point. I must admit that I just pulled names of games that seemed popular out of my ear.
If these games have problems, and there really aren't any games that HAVE worked out hit registration to keep fans happy enough, then it can never get fixed.
I just remember being pretty happy with a few games like TF2 and Battlefront, at least enough that I didn't feel the need to look into whether or not it's being worked on and I could get on with having fun.
0 -
Sure but if those solutions work enough to keep players happy, then that solution is good enough. When there is more than one viewpoint and non-zero data transmission rates, there will never be a perfect agreement. I don't pretend to know how it's solved but I feel like a number of games out there are keeping their userbase happy at least on this front. Maybe I am way off as I play few games these days...
0 -
If these games have problems, and there really aren't any games that HAVE worked out hit registration to keep fans happy enough, then it can never get fixed.
Indeed it can't, because of the laws of physics. Information can only travel so quickly. It doesn't matter how perfect your code is, or how high your tick rate is, you cannot beat the laws of physics.
The only way you could potentially make it look like it's all working instantly is if everyone lived so close to the server and each other that the ping between any and all players is lower than any of their reaction times.
I just remember being pretty happy with a few games like TF2 and Battlefront, at least enough that I didn't feel the need to look into whether or not it's being worked on and I could get on with having fun.
My guess is, you must've been playing very close to the server, and so were the other players.
2 -
This has nothing to do with dropping a pallet early or dropping it late.
It's all about latency between the server and the clients. The decision making process does now consider information from the killer side and the survivor side and that is done by the server.
My suggestion is to read Mercês first post again.
1
