Testing Frame Data

I have been testing frame data using Eddieinput (https://github.com/nirgoren/Eddienput) on VF5 REVO. For those interested, I've attached the config file I've created for VF5 REVO. It uses keyboard inputs to ensure consistent inputs (Eddieinput sometimes has inconsistent inputs with the Xinput virtual controller). It includes several quality of life macros in the config file to drastically shorten the amount of characters you need to type to make sure inputs are consistently read (mainly holding inputs for 2 frames).

However, there is a bug in Eddieinput that does not send spacebar properly, so the config file assumes P, K, and G are mapped to J, K, and L (just need to change G input from spacebar to L on default controls). I've also attached a test playback file to ensure the inputs are working properly.

The config file is uploaded as vf5revo_keyboard.txt since VFDC does not allow .json to be uploaded. You just need to put it in the config directory and rename the extension to .json (.json is just a text format).

Edit: Fixed a bug with the *9 macro in the config file.
Edit2: Added *ROLL2 and *ROLL8 macro to maximize side roll ukemi window
Edit3: Added one extra frame to *ROLL2 and *ROLL8 macro to take into account edge case.

 

While testing frame data dealing with okizeme, I have come across some curious findings. Attached are the playback files so people can verify the situations. The attacker playback is used to record for in-game playback. The defender playback is used by the player and synced to the recording in-game. The defender playback is synced up to the recorded commands in-game by adjusting the delay to ensure the attacker gets a counter hit on any of the saved attacks at the last possible moment. This ensures 100% synced actions between the attacker and defender down to the frame.

Here are the curious findings I do not quite understand. Forgive me if people already know about some of this information.

There are actually 3 different in-place ukemi timings. Normal, Exact, and Late. The CPU can only be set to Normal and Exact timing. When I was testing in-place ukemi timings with Aoi vs Aoi, I found something a little strange. When doing a counter-hit at the last possible moment with a move that starts with 3 (3K, 3K+G, 3P+K), the player is only able to do Late and Exact ukemi timing. Also, the window for the ukemi is 1 frame longer than any other hit (normal or counter). Typically, there is a 13-frame ukemi window with 2 frames in that window for an exact ukemi. Frames 1-5 and 8-10 result in normal ukemi, Frames 6-7 result in exact ukemi, and frames 11-13 result in "late" ukemi.

When I set up the recording, Aoi would do a meaty 6P such that if the CPU was set to normal ukemi, it would hit on the 2nd active frame (frame 15) resulting in a +8 advantage, and if the CPU was set to exact ukemi, it would hit on the 1st active frame (frame 14) resulting in a +7 advantage. When the defender ukemis, the normal and exact ukemi windows result in the expected +8 and +7 advantage, however the "late" ukemi would cause the 6P to whiff.

The strange part comes with the moves that start with 3 (3K, 3K+G, 3P+K). When I get counter-hit at the last possible moment I could input 3K, 3K+G or 3P+K, the window to perform the ukemi increases by 1 frame to 14 frames. Any non-exact ukemi automatically becomes a "late" ukemi causing the 6P to whiff. Also, the counter hit happens one frame later than the other attacks. I don't understand why these properties happen. It is not based on damage because higher damage moves do not exhibit these properties. The common thread seems to be a 3 input.

Two other curiosities: If Aoi initiates a 3P input against a high attack on the frame she would get hit or on the frame before, she will get a 2_3P move instead of 3P thereby ducking under the attack instead of getting counterhit. If she initiates a 3P input 2 frames or more earlier, she will get counter hit out of her 3P startup. Also, if she does a K+G input on the frame she would get hit by an attack, she will end up guarding the attack instead of getting counter hit. If she does it earlier, she gets counter hit out of her K+G.

I am not understanding some of these strange interactions. If anyone has any insight, it would be appreciated.

 

For the benefit of those who want to test out some frame data, I've attached some example files that are better than the ones in my previous post for ease of syncing up both characters. The idea is to have both players trade 2P on the same frame. Everything else will be synced after that. I have been using this format to ensure consistent frame sync between both characters. It's much easier than the method I posted above.

Several more curiosities I have found is how the input determines the window for ukemi rolls. A minimum of 2 frames of the same direction and P+K+G is required in order for the game to register it as an ukemi roll. One frame will only register it as in-place ukemi.

The same 3 input as I mentioned previously will extend the ukemi window to 14 frames instead of 13.

The ukemi window is normally 13 frames. However, if you do a 2 frame ukemi on the 8th frame, it will instead register it as an in-place normal ukemi instead of an ukemi roll.

If you do a 2-frame ukemi, on frames 1-5, you will only do an in-place normal ukemi. You need to hold the ukemi longer on each earlier frame until you finally have to hold it for 10 frames on frame 1 in order to register an ukemi roll instead of ukemi in place. If you are counter hit with a 3 input at the last possible moment, then you need to hold it for 11 frames (this is what sparked the update to the config file in the first post).

If anyone has any ideas why the inputs are interpreted this way, I would be thankful. Once I finish compiling the data on okizeme situations, I'll post the final results here. I welcome more people to verify the data or try different scenarios. I understand some/most/all of the work I'm doing has already been done, but I like to verify it for myself and provide playback files for others to verify for themselves.

Edit: Fixed defender playback file scenario (accidentally chose between edge case and normal hit randomly).
Edit2: Put in framework for beginning recording commands to help in getting consistent delay between both characters (useful for testing fuzzy situations).

 

https://virtuafighter.com/threads/o...nput-rules-for-tech-roll-fall-recovery.21894/

Here is an earlier thread of Ohzeki's and Akai's testing of tech roll input rules. You could try verifying these examples.

 

Thanks! Tenguman also referred me to that thread, and I will be going through to verify those rules once I get the frame data for all 4 positions done.

 

Nice work, I had tested a little bit of stuff with ReWASD macros but eddienput looks easier to use