Okizeme Frame Data

Core Information Summary

• Exact fall recovery will shift all recovery windows 3 frames earlier than normal fall recovery
  
  
• Late fall recovery will shift all recovery windows 1 frame later than normal fall recovery for each frame into the late fall recovery window (i.e. doing a late fall recovery on the 2nd frame in the late fall recovery will shift all recovery windows 2 frames later)
  
  
• Holding fall recovery inputs for at least 11 frames will maximize the fall recovery input window. Any shorter may result in on the spot recovery instead
  
  
• During meaty windows, the defending player may only guard high/low (this means any attacks input will not come out at this time and thus cannot be counter hit). The defending player cannot be thrown during this time.
  
  
• During low throw windows, the defending player may do any action. However, if the player chooses only to guard, they are vulnerable to a low throw and will avoid high throws.
  
  
• Back hits are unblockable. Meaty side hits are blockable.
  
  
• All rising recoveries have exactly one frame meaty window and do not have low throw windows
  
  
• Below are some of the fall recovery windows (more testing needs to be done on knockdowns with special effects). The standard ukemi input windows are specifically for standard knockdowns without any special effects (slams, spinning, etc.). Some combo/character combinations result in slightly different ukemi input windows. These windows have "Exception" in the title.

Detailed Information

• Some standard fall recoveries allow early input (2 frames after getting hit). The directional input must be done within the ukemi input window to register as a side roll fall recovery. Some standard fall recoveries do not allow early inputs. They must be done within the ukemi input window. It is unknown what determines early input. For example, Aoi getting hit by Aoi followed by does not allow it, but replacing with does.
  
  
• For a normal side roll fall recovery to register instead of on the spot recovery, the inputs must be held for a minimum number of frames depending on how early in the ukemi input window it is executed:
  • 1st frame: hold input for 11 frames
    
    
  • 2nd frame: hold input for 10 frames
    
    
  • 3rd frame: hold input for 9 frames
    
    
  • 4th frame: hold input for 8 frames
    
    
  • 5th frame: hold input for 7 frames
    
    
  • 6th frame: hold input for 6 frames
    
    
  • 9th frame: hold input for 3 frames
    
    
  • All other frames: hold input for 2 frames
• For some Face Down, Head Toward standard fall recoveries, it seems a input move (i.e. , , , etc.) can register as a counter hit 1 frame later than other input moves. In the case this happens, the ukemi input window extends to 14 frames instead of 13 frames as shown above. Additionally, any non-exact ukemi turns into a late (treated as 1 frame late) ukemi with respect to recovery windows.
  
  
• During a standard Face Down, Feet Toward side roll recovery, if the defending player rolls to the attacker's front, a meaty attack landing on the first frame of the meaty window will result in a side turn meaty. If the defending player does an exact ukemi, then the meaty attack must also land on the first active frame of the attack to result in a side turn meaty.
  
  
• Due to the non-overlapping nature of the meaty and low throw windows, the defender can guard until the last frame of the meaty window then input a Defensive Move to defend against a meaty attack and a low throw (as an example of one defensive technique).

To Do List

• Further testing needs to be done to see if all normal Face Down, Head Toward fall recovery non-exact ukemi from a input move getting counter hit at the last possible moment is treated as a 1 frame late ukemi.
  
  
• Further testing needs to be done to see if there are types of counter hits for other positions leading to a similarly strange ukemi situation as normal Face Down, Head Toward.
  
  
• Further testing needs to be done to fully encapsulate all rising recovery windows (specifically how to do the fastest rising recovery the CPU performs in training mode, current scripts rise one frame later than fastest rising recovery)
  
  
• Further testing needs to be done on all stances and player sides. Current results are from closed stance with the attacker starting on 1P side and the defender on 2P side. Preliminary testing seems to show there is no difference.

• Further testing needs to be done on special knockdowns

• Further testing needs to be done with separate characters to verify the windows do not change between characters

Recreating Testing Data

• Much of the testing data is derived from the attached Eddieinput scripts. The scripts assume the vf5revo_keyboard.json config is used from the Testing Frame Data thread. Most testing was done Aoi vs Aoi which may skew the results of the data. There have been several tests against other characters (mostly against Akira and Goh), but not as extensively. Those tests were to verify the ukemi input window exceptions were exceptions instead of standard.
  
  
• To easily sync the attacker and defender actions, the recorded commands should not enable the delay option. The non-recorded commands should enable the delay option. A 2-frame delay is usually consistent on my setup. If the recorded commands do not sync properly to the 2-frame delay, re-recording the commands normally does the trick instead of needing to change the 2-frame delay. Your mileage may vary.

• These base scripts can (relatively) quickly be modified to other characters/combos. For the attacker, the combo needs to be changed. Then, set the CPU Settings to some type of fall recovery and use the mix option for determining start or end of the given fall recovery. Once it is found, the rest of the windows can be calculated by the frame data given above. Then, bounds testing the new calculated windows can be done quickly. For a quick calculation tip, any attack options requiring a forward dash to close the distance can be done with *FD W23 resulting in exactly 30 frames used since the *FD macro uses 7 frames. Then, prepending any required delay before the *FD can easily be calculated by subtracting 30 frames from it.

EDIT: Updated bullet points to reflect some of the info only applies to normal knockdowns and further testing needs to be done on special knockdowns (slams, spinning, etc.) as well as further testing needs to be done on characters other than Aoi vs Aoi.

EDIT2: Updated ukemi input windows to new testing data verifying standard/exception windows. Added slam ukemi input window. Updated bullet points to reflect the new data. Added more tips to recreate testing data.

 

So this caught mine and a few others eyes yesterday and we ran some tests.

TLDR you should probably keep timing your techs.

If you get launched with say Goh 1P+K of Jeff 3PP, 6K, 33P you can indeed start holding P+K+G surprisingly early on, like almost a second before you hit the ground. I never knew this.

However this seems to only apply to specific types of knockdown and all the examples our tests came up with were these basic launch-yo-ass-in-the-air launcher types. EDIT: or leaving the combo unfinished so the last hit didn't have any kind of spin / extra push-back or anything.

The thing is this doesn't seem to apply to a lot of knockdowns. Goh 3PP (spinning knockdown) tech cannot be held. Ending a combo with Goh 46P+KP6P or Pai 3KPP (small extra pushback on airhit) tech cannot be held. Getting knocked down by Jeffry 3K (same as the previous but this time done on the ground) tech cannot be held.

So unless the move that knocks you down or the move that ends a combo has absolutely no special effects on how the opponent behaves in the air, it looks like tech cannot be held. I find it very interesting that there even are scenarios where this weird quirk works and I really wonder why.

 

Oh, thanks for pointing it out @Combolammas! I originally meant to also test the more difficult ukemi situations, but it completely slipped my mind. I got tunnel vision trying to chase down strange interactions/inputs when exploring just the basic ukemi. I'll update the original post to correctly reflect the core information is for "normal" ukemi situations without any special knockdowns.

If people have any special knockdowns to be tested, please post them so I can cover those as well. Now I have a system in place to be able to speed up testing as well as ensure repeatability.

 

I've always been curious how big the window for teching "spikes" is aka ending a combo with a move what slams the opponent from the air to the ground with a small tech window or get hit with OTG hit.

Stuff like Goh 46P+KPP or Pai KK can be used to cause this as long as the opponent is in the air when the last hit connects.

 

Okay, I started some preliminary tests. I'm going to work on Goh + and Pai next. After that, I'll look into the other four combos you mentioned (Goh , Goh +, Pai , and Jeffry ).

I wanted to notate this here in case others come up with something in the meantime I'm testing the other knockdowns.

Aoi's knockdown slams the opponent into the ground. I tested it with all four orientations. With the exception of Face Down, Head Toward, the ukemi window is 3 frames long. The first frame is considered normal timing and the last two frames are considered exact timing. I had to make an assumption for Face Up, Head Towards because the scenario I had set up allows an ukemi before the hit. This results in a techable OTG instead of a clean combo. I do not know how to get a clean, normal hit . By my testing, counter hits had the same result as the OTG scenario so I think I am safe in my assumptions that the OTG does not affect the duration of the ukemi windows. As an FYI, from my original testing with basic knockdowns, the window for an OTG to succeed against someone attempting to ukemi (assuming they miss the exact window and only hit the normal window) is 3 frames due to the 3 frame shift in recovery windows between exact and normal ukemi.

With Face Down, Head Toward, the shenanigans from basic knockdowns rears its weird head. Usually the ukemi window is 2 frames long. I'm assuming it's considered exact timing since the recovery windows do not shift whether you input in the first or second frame. I need to come up with a scenario where I could feasibly determine an exact or normal ukemi. However, in the case of a input move (in this case, , +, + from Aoi) getting counter hit at the first possible startup frame (which happens to somehow be 1 frame later than all the other moves), the ukemi window lengthens to 3 frames. The first frame is considered to be a normal ukemi window and the other two frames are considered to be exact. Furthermore, I'm assuming due to the counter hit happening one frame later, the recovery windows for this specific scenario are all shifted 1 frame later than the normal 2 frame window in the normal scenario (i.e. the exact ukemi recovers 1 frame later in this weird counter hit scenario than the exact ukemi in the normal scenario).

 

Well, I was originally expecting the tests to be quick and easy with the results equivalent to Aoi's slam. I am surprised. There is more nuance here than expected. So far, Goh's is the exact same 3 frame ukemi window as Aoi's slam for face up, feet toward. However, Pai's slam is only a 2 frame ukemi window for face up, feet toward. It seems testing will be needed for each slam as well as each orientation since I do not visually see a difference between the three slams.

 

Just a heads up, this will require a good bit more testing on my part. It was already on my list to go and test more okizeme frame data on characters other than Aoi vs Aoi since I knew that may have resulted in a bias in my data for basic okizeme. However, testing from different slams have confirmed I definitely need to do extensive character vs character testing to verify all of the okizeme frame data. This will require a good bit more work. Some of the weirder ukemi input window changes (such as face down, head toward or Pai's 2KK), may be character specific. One such example is Goh's combo ender on Face Down, Head Toward is a 3-frame ukemi input window against Goh, but is a 2-frame ukemi input window against Aoi. Specifically, the combo I was using to test this was , , .

As a general rule of thumb, I think the ukemi windows for basic knockdowns are supposed to be 14 frames (with some exceptions dealing with late frames and 1 frame shorter duration), and slam knockdowns are 3 frames (with some exceptions dealing with 1 frame shorter duration). I'll continue compiling test data and update the information as I complete them.

 

Great stuff. Thank you for taking the time and effort for doing all this testing.

 

Some updates to my testing (I've updated the original post with the new findings).

Aoi vs Aoi , results in a face down, head toward ukemi input window of 13 frames, but , results in the standard 14-frame window. Other combos (tested with Goh combos) also result in the standard 14-frame window.

Back turn, head crumple combos (from both Aoi and Goh) seem to result in a 13-frame ukemi input window for face up, head toward. However, a foot crumple CH from Goh (, ) resulted in the standard 14-frame window. It's possible back hit head crumple combos consistently result in 13-frame ukemi input windows, unlike the inconsistent head crumple for face down, head toward. More situations need to be tested.

I cannot figure out for the life of me what determines the 2-frame ukemi input for a slam knockdown versus a 3-frame ukemi input slam knockdown. Seems somewhat random. Possible weight related? More testing needs to be done.

The very early input window also depends on the combo. I could not figure out the rules for it. The ender from Aoi in face down, head toward did not allow it. However, the ender did. Thinking that it requires a standard ukemi input window to be able to do an early input, I tested it with Goh's head crumple combo from a back hit (, ). It also results in a 13-frame ukemi input window but allowed early input.

Throughout my testing, the fall recovery windows do not seem to have any exceptions.

I'll continue testing with more special knockdown effects. I may give up on trying to find out the rules for the exceptions on the ukemi input windows. I'll just document the window exceptions I find.