Gimlet DHC-input bug

hawkeye

#1

I’m not sure if this has been discovered, but DHC’ing into a qcf super right after Gimlet (the gold arrow) activates results in a dp-motion super instead.

This doesn’t happen if the DHC from Gimlet is delayed.

Example:

With Hawkeye, use Gimlet. As soon as the arrow hits the opponent, I tried DHC’ing into Hulk’s Gamma Tsunami (qcf). Instead, the game considers that the dp motion was input, giving me Gamma Quake. So far from testing, this bug works when DHC’ing into Hulk, Wesker, Zero, and Strider.

[media=youtube]KuTHhlj87Qw[/media]


Hatin' from experience, the LouisianA Thread Live by our rep
#2

Also happens with CapAm apparently. Made sure to turn on the input display and all

Probably loose input windows gone wrong


#3

I think it happens with any character that has both qcf and dp-motion supers.


#4

I don’t think it’s a bug, I think the game just doesn’t reset the inputs to neutral until after Gimlet hits.
Quickly testing for like 5 seconds it just seems like the game is still reading the :f: from the QCF, so DHCing too quickly will resort in a lazy man’s SRK.

Or maybe Hawkeye just doesn’t want to play nice with others.


#5

It’s clearly for balance. Gimlet DHC into Final Justice would make the game implode.


#6

So, after more testing, it seems that this is more widespread (i.e., doesn’t just apply to Hawkeye).

Doing a fast dhc from Maximum Wesker gave a dp super instead of a qcf super. Definitely not a good sign…


#7

WARNING: Post contains scientific testing!

Yeah, I was seeing this problem a lot with trying to DHC out of Wright’s Maya hyper too. I think the main thing here is that the game is using your old :f: input which then takes the input priority over the :qcf: hyper. Adding extra inputs during the freeze doesn’t even help; I can do full 360s starting with up to try to make the input buffer forget that :f: input and it just doesn’t care. I have done some more testing, and this is a really huge issue in this game affecting a huge chunk of characters though a similarly big chunk can easily DHC into :qcf: hypers so it’s hyper specific which ones have problems. Here’s my test of every character who has a DHC-able :qcf: hyper (everyone except Shuma-Gorath, Dr. Doom, and Captain America) and who is affected:

Affected:

Jill
Phoenix Wright
Strider
Vergil
Wesker
Dante
Tron Bonne
Chun-Li
Felicia
Akuma
Haggar
C.Viper
Hawkeye
Doctor Strange
Iron Fist
Rocket Raccoon
Dormammu
M.O.D.O.K.
Spider-man*
Sentinel (both hypers)
Hulk
Super-Skrull
Phoenix
She-Hulk
Taskmaster

*Spider-man revealed the exact cause to me. It’s related to the number of frames pre-hyper freeze. If the number is 10 or fewer, it will be a problem. If it is 12 or greater, it won’t. Maximum Spider is variable based on distance to the wall, and of course, this means it sometimes has problems and sometimes doesn’t based on how far away from the wall you start. Interestingly, doing things to speed up the animation doesn’t matter. XF3 Firebrand in Luminous Body still doesn’t have issues even though his 12 frame pre-freeze hyper was barely past the cut-off and in that form Firebrand is massively sped up. Even more interestingly, if the affected characters are slowed down from either Viewtiful Joe or Amaterasu, the issue goes away! For those wondering about 11 frames, I wasn’t able to find any :qcf: hypers with 11 pre-freeze frames of start-up so the only way it could possibly come up is in the case of Spider-man a very particular distance from the wall which I don’t have the equipment to test. I suspect it’s a “no” though since 10 frames sounds to me like a very likely size for the input buffer.

There is a trick to avoiding this altogether though. During your initial :qcf: to do Gimlet, roll back to :df: and hold it as you do your double input (going to :d: works too, but :df: is easier on a square gate). This will cause the input from your initial hyper going into the hyper freeze to be :df: instead of :f: which won’t make doing a :qcf: hyper instead of a :dp: hyper impossible. Actually you can use any direction (other than :f: obviously!); you can do a tiger knee input :qcf::uf: so fast you don’t even leave the ground and it will prevent the issue; the whole idea is to plug in some useless input so the game never sees that :f: at the start. It’s non-intuitive, but in a way, it actually makes execution easier once you are aware of it… in a perverse kinda way. Hawkeye players will absolutely need to know about this though since Gimlet DHC some other hyper is a big thing with him, and for a lot of characters the :qcf: hyper is the best one to finish with (whiffing full screen shoryuken hypers with Ryu and Akuma sounds infuriating to me!).

At some point this should probably be reposted somewhere more general since this affects half the cast and it’s not obvious how to get around it, but for now, team Hawkeye has a slight tech lead I guess. Bonus points for the topic about this issue I was already curious about being on your board I guess (though I’m kinda interested in Hawkeye too which is completely off-topic).


#8

I’m rendering a video that shows this as incorrect.

Let your inputs go to neutral before you DHC and this “bug” will not happen.
[media=youtube]tWHh4fePtoM[/media]


#9

My inputs are at nuetral, and I want to state this doesn’t only occur with gimlet.

Spoiler

I came to this conclusion myself as well, but I wasn’t able to come up with the proof to show it because I don’t have access to the current frame data. Thanks for clearly explaining this.


#10

Thank you for that major testing. I was wondering why it affected some characters and not others. We know why now.


#11

All I’ll say is my entire team (Vergil, Dormammu, Wesker) is on that list and I can QCF DHC through all three of them and do not get a DP super.

So I don’t know what I’m doing wrong to not be able to recreate this bug. The only time a DP super comes out with a DHC is when I’m just holding forward too long.

[EDIT]
I actually see this now. I get DPs DHC follow ups when I do QCF super and hold forward until the super freeze. If you let go of forward before the super freeze you won’t get DPs


#12

In a real battle, it’s rare to need to DHC right after another hyper’s activation. Plus, you’ll need 4+ bars to notice it (one for the initial hyper and three for the dp motion hyper).


#13

Of course. That’s why I’m testing it in training mode =)
But I see why what’s reported is happening now


#14

We’re all not holding forward and it happens to us. You’re not cancelling fast enough.


#15

=(

How much faster can I do it? I’m inputting the DHC motion during the super freeze.

I had a thought, are the people who are experiencing this on a stick?


#16

Astaroth uses pad, and I’m inputting it as soon as the flash is over.


#17

Okay, back to the lab for me to see if I can reliably reproduce it


#18

LOL everyone makes like this is some technical bug that’s hard to replicate. its so damn simple guys

DHC “DURING” the super freeze it causes a DP DHC. DHC “AFTER” the freeze it works as intended.

Geez it’s not that hard to execute this bug and it is kind of a big deal, some people DHC for safe tags, it could potentially ruin game plans of people by accidentally burning 4 bars instead of 2.


#19

It’s not a bug at all. It’s sloppy inputs on your part, hence why people are having trouble recreating it.


#20

It’s arguably whether it’s a bug or a feature, but it’s definitely not sloppy inputs causing this issue. If you carefully and correctly end your :qcf: in a :f: input and then do your DHC during the hyper freeze (not after it), it is impossible to DHC Gimlet (and many other hypers) into a :qcf: input hyper if a :dp: input hyper would also be valid. If you are finding it possible, you are either inputting some other direction at the end of your :qcf: inputs (and neutral does not count) or doing your DHC at some point after hyper freeze ends (even a single frame after the freeze ends will completely remove this issue). I spent over an hour in training mode carefully looking at input display and testing every timing so I’m quite sure of this.