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.
  
  
• 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 the fall recovery windows

Detailed Information

• Face up fall recoveries allow early P+K+G input (2 frames after getting hit). The directional input must be done within the ukemi window to register as a side roll fall recovery. Face down fall recoveries do not allow early P+K+G inputs. They must be done within the ukemi window.
  
  
• For a 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 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 Face Down, Head Toward fall recovery, it seems a 3 input move (i.e. 3K, 3P+K, 3K+G, etc.) can register as a counter hit 1 frame later than other input moves. In the case this happens, the ukemi 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 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 DM to defend against a meaty attack and a low throw.
  

To Do List

• Further testing needs to be done to see if all Face Down, Head Toward fall recovery non-exact ukemi from a 3 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 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.
  

Recreating Testing Data

• All 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. All of the testing was done Aoi vs Aoi which may skew the results of the data.
  
  
• 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.