How the heck does this even happen (hit validation and faux hits)
Coming here from posts about attacks of any kind not hitting while the animation and sounds play... I'm baffled. I'm trying to make sense of how this can even happen, so if someone with more coding experience has any idea please tell me, because this is mind-boggling.
It is an issue that existed before:
Killer 'hits', animation and sound play, but no healthstate or anything changes. Now pallets have joined the ranks (killer attacks, animation and sound play, no hit on the survivor, but then the pallet stun happens)
I can't wrap my head around how such a bug would even happen:
The animation and sound trigger should be tied to a true/false for a hit. like if the variable for a hit is active, sound, animation AND modifiers should be activated in one go.
I'm just entirely at a loss what is happening. Devs, wth?
Comments
with BHVR spaghetti code anything is possible
you'd think so, but... i've worked with plain text coding and visual coding and by all means, the only thing i can imagine happening here is that instead of an 'if then' that leads from a hit to everything being activated at once we're dealing with something that looks like a Jackson Pollock painting, and I can't wrap my head around how you'd even code that
There are a bajillion threads about this. Short answer: latency.
Long answer: Killer's client used to be the referee for if a hit connected. Now, the server is the referee. So now, on rare occasion, if the killer swings into a dropping pallet, their client registers a hit, and the hit sounds and vfx play. But the server goes, "wait, no, that pallet was actually 50% way down." And so the hit gets canceled. You weren't "robbed" as many say. The sounds and vfx just should not have played.
The sounds and vfx just should not have played.
But that's exactly what OP's asking about. Why do those play? How is this game coded that the audio and VFX can play when no hit occurs? Code is a logical sequence of if-then statements, if there's a hit then this sound plays and this visual effect is shown and this health state is lost, but there's no logic to only part of that sequence happening and not the rest, so what in the hell is going on behind the scenes of this game?
i'm not complaining about being robbed or anything. I just want to know how the heck the code can be so all over the place. Cause the trigger for a routine should only come from one end, which now, supposedly is the server.
How the heck do you code things to end like this
exactly.
Like, you can only split this into to possibilities:
1: every killer has their own subroutine for hits
2: all kinds of hits have their own subroutines that check for which killer it is.
But in either case the vfx and sfx should only play IF a hit registered with the referee-routine
There's no logical explanation for how the game can go and do the following (let's take plague as example):
Plague is using Vile Purge -> the referee-routine registers an overlap of hitboxes of projectile and survivor hitbox -> the sfx and vfx play for all parties (killer and survivors) -> despite the referee-routine registering a hit and activating the effects for everyone (meaning everyone around sees/hears it) no hit is registered and the checks for status effects aren't activated.
It SHOULD run like this:
Plague is using Vile Purge -> the referee-routine registers an overlap of hitboxes of projectile and survivor hitbox -> the game checks for hit modifiers (add-ons, etc) -> the new status is applied with these modfiers AND the sfx and vfx play for all parties (killer and survivors)
The killer's client plays out the on-hit VFXs and SFXs before waiting for the hit validation. Probably a relic of the old p2p days and early dedicated servers when the killer was the authority over hits.
However, now the server is the sole authority to determine if the hit actually landed or not. E.g. before or after stuns. If the hit is denied, the health state is not taken away (or it may actually be refunded on the killer's screen. I've never paid attention to the hud. But again, it's merely visuals).
It's notable with this whole system old and new, that the survivor never was the authority over hits or even stuns. So, they see either one only after it's been validated. This leads (led) to those scenarios, for example, where the survivor saw the pallet fully down, the killer swung afterward, then the hit registered and then a very delayed stun played out.
Now, both sides share the same burden. Whoever tells to the server the performed action first takes priority. Even though, the visuals of the interaction could be misleading.
the routine for the killer client activating the hit should NOT be there anymore to begin with. The effects should be activated be the hit validation saying there was a hit.
How?
Yeah, but bhvr is not the quickest at fixes and updates.
However, due to the inavoidable nature of latency, some undesirable effects will still remain. For example, if the client waited for the hit to be validated, like survivors' already do, then the killer might see some hits being credited with noticeable delay.
But, I guess, nothing is perfect in this world.
Oh, sorry, I assumed it was another rage thread. To answer that you need to know a little bit about online multiplayer games with dedicated servers. There is the server that is hosting the lobby, and connected to the server are the clients, as in, your game client and the clients of all the other players. Servers and clients keep track of a lot of the same info, but do different jobs with it. For example, clients are in charge of rendering everything you see, but the server doesn't need to do this, because nobody is playing the game off it, so the server is often just a husk of code and numbers.
In this specific case, the killer's client and the server are our main focus, as the survivors don't hear the false hit sounds. So, the killer's client is detecting a successful hit, and doing what it thinks it should: play hit sounds and vfx. Under normal circumstances this info is transmitted to the server, validated, and then sent to the survivors' clients so that they too play hit sounds.
Crucially, the validation step happens after a potential hit occurs as it takes time for the killer's client to send the hit info to the server, and then more time for the server to validate it and send the info back to the killer's client.
The problem stems from the killer's hit feedback not being governed by the server's validation step on the killer's client only.
So, to sum it all up, the killer's client is just jumping the gun a little bit. It's most likely a relic from when DBD was peer-to-peer, and I would hope could be fixed relatively simply, but, well, it's BHVR. So... expect a fix in 3 months or so.
But that's the thing:
Survivors DO hear the hitsounds and see the animation. That's what's so bizarre. I had it almost routinely now that people notice this happening.
which means the hit on the killer's client gets send to the survivor's clients before the hit is actually validated.
I heard from others that survs didn't hear it, but if they are, then that's a little more complex. DBD was initially built peer-to-peer with the killer as the host. If survivors are in fact hearing it then it sounds to me like the hit sounds use the old peer-to-peer rules but the actual hits themselves use the server validation rules. Do you happen to have a video of a survivor POV hearing a false hit?
not at the moment as I'm not a streamer, but maybe someone who is can help out.
Also, so... am I right to assume that the code now activates BOTH subroutines and just has the new one potentially cancel the validated hit that triggers the effects, instead of having removed the killer's clients hits triggering the effects and then checking for validation?
Yea, that's the gist of it.
Jackson Pollock Painting code, I was right
It isn't rarely.
It's repeatable, see the following video:
https://www.youtube.com/watch?v=HQ4fUJrYirAI've seen it. Repeatable does not mean common. The person in this video was purposely swinging late in a controlled environment. In real games it happens on average 0-1 times per game. Enough for people to notice, but definitely not every game, and extremely rarely multiple times per game.