Parry Bug

[Trivvy]

At first I just thought it was a fluke, but this has happened to me multiple times now.

The bug:
A punch will sometimes go through a parry, as if it wasn't there.

I even questioned my opponent about the parry, and those that actually respond do admit that they saw their fist hit my parrying character, and not get parried.

I'm not sure if it's a latency thing (in which case, my opponent wouldn't see the parry), or if the parry window doesn't match up with the animation. It tends to occur when the parry is JUST before the punch connects.

Essentially, if you time your parry to try and parry just before the punch connects, there's a good chance it might not work, this seems unintended.

 

[nicholas.east]

I think there is ongoing problems with melee hit registry. Whenever I check the replay it looks completely different to what I saw in game, with parry conveniently being milliseconds late. Once it got so bad that I parried 2 seconds early then watched an Abrams fall over stunned after he punched me long after the parry window had passed.

 

[me556]

Can confirm that there are issues with the parry since the latest major patch.

If abrams punches a minion (and you while parrying) the parry will not trigger in one of the more obvious ones I've ran into. I used to do this all the time with my minions, but now it only works around 50% of the time.

Might be related to melee charge or other items abrams players usually buy.

 

[erithom]

Also seeing this, and I think it may be a lack of latency compensation.

In the first clip, I parry the second melee attack about 5 frames (at 60fps, so 83ms) before the impact animation starts, but my ping was only 48ms.

Assuming one update packet per roundtrip time, if my last update packet before the parry was less than 12ms earlier, then the next update packet--which would tell the server about the parry--wouldn't make the roundtrip until after the hit registered on the client. If it was more than 12ms, the next roundtrip would be early enough to complete first. The second clip has the same timing: 83ms early with 48ms latency.

This could also be a sign of low server tickrate if updates are happening asynchronously; 48ms is only a little faster than a 20 tick per second server would be handling updates.

 

[Dr. Nuke]

I've noticed too that parry sometimes fails if you try to parry at the very last moment. You can see the blue parry animation before getting hit. I don't think the Parry window should be too big, or it would become a really bad idea to try and hit opponents with heavy melee attacks ever. It's already quite a risky move to heavy melee opponents as it is. So I'd say it might be preferable to make a slight animation change to where it takes a small moment before you see the blue animation pop up (so it better reflects what is actually happening) rather than making the parry window bigger! But that's my noob opinion

 

[Bunga]

I just also made a thread about this and this was in my recommendation at the bottom, I notice this issue especially AFTER the last big Thursday update on 11/07

 

[friendlyfiregm]

I want to bump this as a reddit post got a good video of the it:

https://www.reddit.com/r/DeadlockTheGame/comments/1grsg0w/why_i_think_parries_feel_horrible

Note interestingly how damage happens before the swing starts at all. Maybe there's an animation component to the issue?

It does feel to me like parry's are not configured properly in the netcode. Overwatch had issues like this early on, where various movement/defensive abilities didn't properly have priority. So even if you reacted in time on your screen, your opponent saw it hit on their client, so the server counted it as a hit. Favor-the-shooter is good by default, but reactive actions need to instead get priority. Which is exactly what a parry is.

 

[gibnewitems]

I want to bump this as a reddit post got a good video of the it:

https://www.reddit.com/r/DeadlockTheGame/comments/1grsg0w/why_i_think_parries_feel_horrible

Note interestingly how damage happens before the swing starts at all. Maybe there's an animation component to the issue?

It does feel to me like parry's are not configured properly in the netcode. Overwatch had issues like this early on, where various movement/defensive abilities didn't properly have priority. So even if you reacted in time on your screen, your opponent saw it hit on their client, so the server counted it as a hit. Favor-the-shooter is good by default, but reactive actions need to instead get priority. Which is exactly what a parry is.

nothing in that clip seems abnormal.

 

[friendlyfiregm]

nothing in that clip seems abnormal.

Uh, did you watch the whole thing? It slows down to make it very clear. This is the order of events:

1. Abrams starts charging a melee (arm pulled back)
2. Vindicta gets a hit animation and loses health
3. Vindicta starts parry animation
4. Abrams swings his arm forward to punch

The damage from a heavy punch should not happen while the arm is pulled back, it should happen when the arm swings forward for the hit. Likewise, if the parry animation is started before a punch begins to swing forward, the punch should be parried.

There is definitely some animation and/or netcode issue at play.