Frames measure time, and reveal how quickly actions happen. When jump is pressed there is a 3 frame delay before a VR leaves the ground. Rising and auto-rotation starts on frame 4, but jump manual rotation can start on frame 3. Lateral drift movement takes effect from frame 5. The jump can be canceled from frame 4 onward, and immediately stops rising when crouch is pressed, though you stay in the jump animation on that frame. On the next frame you begin dropping at almost full speed, but because your posture changes some VRs appear to linger. Manual rotation is disabled for this frame but auto-rotation is still allowed. Starting on the second frame of dropping you can manually rotate again until you touch the ground.
After reaching the ground there is a freeze that varies by the VR. I have reported their durations by subtracting 1 from the number of frames in the freeze animation. For normal landings, after floating down slowly or fast dropping with crouch, the reported value is the total duration of the freeze. For canceled jumps, add +2 frames of recovery to the reported value, as the dropping posture touches the ground on the frame before the freeze animation starts, and the frame before that has weird collision detection and is usually close to the ground (half the time it even burrows beneath the ground).
Small jump cancels that never leave the ground can be performed as long as crouch is held within 3 frames after pressing jump. In this case add +5 frames to the reported value to get the total freeze duration. This comes from the 3 frame jump delay, the initial frame of the cancel, and one recovery frame in the dropping posture. Auto-rotation is allowed throughout a jump cancel freeze, so add +3 to the reported value to get the total number of auto-rotation frames. Using that number together with the jump auto-rotation speed of a VR, the amount of rotation of a small jump cancel can be calculated.
I have reported the dash attack and jump auto-rotation speeds for each VR as the number of frames it takes them to rotate 180 degrees. The written values are either exact or rounded up. The dash auto-rotation speed can be used together with the frame duration of any given dash attack to calculate the angle at which it can rotate and fire. I also have the camera auto-rotation speeds for each VR, exact or rounded down. This is not as important as it is faster than than the character's rotation, and typically just keeps up. It only matters for jump auto-rotation, because in that instance the camera does not rotate along with the character, but waits for the character to finish facing the enemy, then attempts to catch up afterward.
Given a certain auto-rotation speed, having a shorter jump cancel freeze is strictly advantageous because a VR with a short freeze can choose to jump slightly to increase the amount of auto-rotation. Furthermore, manual rotation can be stacked with auto-rotation as the jump rises. In the minimum case of a jump cancel that never leaves the ground, 2 frames can be manually rotated (the last frame of the jump delay and the initial frame of the cancel). After rising up at least two frames into the air, there are also available frames to manually rotate while dropping.
From a standstill, there is a 2 frame delay after pressing walk or dash before a VR starts moving. The input registers on frame 1 (the dash noise is played) but the VR remains in the standing posture. On frame 2, the walking or dashing animation begins but there is no movement. On frame 3, a stationary dash instantly moves at full speed, while a stationary walk begins accelerating, starting out at low speed (unless there is leftover walking speed via the imaginary walking rule). Stationary dashes have a startup period that varies by the VR during which you cannot do anything (attack, jump, etc) except cancel your dash. The number of dash startup frames listed for each VR includes the immobile frames.
If you were previously walking around, there is only a 1 frame delay after pressing walk or dash before the VR responds. The animation and movement responds on frame 2. For dashing, the speed on frame 2 can be lesser or greater than normal. Moving dashes have no startup period, you can press attack on the frame after pressing dash, thus are generally preferred. From a standstill, inputting a walk direction for one frame then pressing turbo on the next frame gives a moving dash. The drawbacks are that this must be manually timed and although the response can be equally quick, the first frame may have an altered speed.
When you stop walking, the VR animation changes instantly but there is still a 1 frame delay before it begins decelerating. As a matter of fact, all horizontal movement in VOOT lags behind your commands by at least 1 frame. In addition, at all times the distance readout bizarrely shows the distance 1 frame into the future! This future rule would be impossible without the accompanying horizontal lag rule. The camera does not lag and mirrors your VR's horizontal movement perfectly (except when performing extreme rowing glitches).
Vertically, there is no mandatory global lag and some actions respond immediately. Canceling an air dash starts dropping immediately, though the horizontal air dash movement is necessarily still lagged by one frame. The distance readout uses future horizontal coordinates but present vertical coordinates. The camera lags behind your VR by a frame on all vertical movement changes.
There is no delay to rotate, however manual standing and ground dash rotation have VR dependent accelerations. Rarely used, manual rotation during the drop phase of a jump cancel has identical characteristics to standing rotation for all VR. Manual jump and air dash rotation instantly have full speed, as with auto-rotation. The camera's rotation lags by one frame during all dash attacks, as well as manual ground dash rotation. For all other kinds of manual rotation the camera lags by two frames, though it begins tilting after one frame.
VOOT frame data
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
VOOT frame data
Last edited by Porcupine on 12 Jul 2017, 19:00, edited 1 time in total.
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
My lists show the number of frames in the animation of every attack, not including the command frame. For example, a 5-frame attack starts animating on frame 1 and the projectile appears on frame 5. I reported the recovery of all safe moves as the subsequent frame on which you can input a dash (the motion won't begin until one or two frames later). A typical standing attack has a recovery of 1, but there are many abnormal moves. Those that recover at negative frames can be canceled with movement before firing, and also enable instant shots with proper timing. Moves with a recovery of 0 enable a family of attack chains requiring perfect timing. If movement is input simultaneously with the projectile, some of these fire while others do not.
The command frame is invisible but a few weapons such as Temjin CW attacks will glow during this frame. In order to make CW easier to press, LW or RW need to be held down for 3 frames to register, but the extra 2 frames can be hidden in any previous action. You can press turbo up to 11 frames before you press CW and get a turbo shot (only 10 frames before you press a direction to get a dash). You can press crouch up to 15 frames before you press CW and get a crouch shot.
Interval refers to the number of frames between shots, either for multiple-shot attacks or manual chaining techniques. I listed almost all the unique chains I was able to find, including some obscure ones. Chains are enabled through various mechanics, some are glitches and some are intentional. A few chains are enabled by multiple mechanics in which case they may be input in multiple ways. Some chains come out at fixed speed while others reflect the timing of the input. In such cases I either give the shortest interval or the exact output window.
I didn't list the majority of generic chains that can be achieved through plain walk canceling or rotation canceling as the interval can usually be figured out from the provided animation and recovery data. I provided a few examples to help. A few VR have a slower rotation cancel than others, either because their walk decelerates too slowly or because of a glitch in their rotation, but this can be overcome by walking in certain directions, or rotating earlier in some circumstances.
Some dash attacks come out 3 frames slower at the very beginning of a moving dash. The angle of rotation increases accordingly. To remove this, just wait a bit after starting the dash to fire. Every frame you wait removes a frame from the delay. Some VRs cannot do a moving back dash, attempting one yields a stationary back dash with the startup delay worsened by an additional 4 frames. This does not apply to their back diagonal dashes.
I recommend noting the fastest attacks for each VR because they are good for canceling your landing freeze. Using my conventions, a 5-frame landing freeze is equivalent to canceling and replacing it with a 5-frame attack with a recovery of 1. That's assuming perfect timing. When attacks have both interval and recovery data, the recovery is listed relative to the earliest projectile that can be canceled into a dash.
The command frame is invisible but a few weapons such as Temjin CW attacks will glow during this frame. In order to make CW easier to press, LW or RW need to be held down for 3 frames to register, but the extra 2 frames can be hidden in any previous action. You can press turbo up to 11 frames before you press CW and get a turbo shot (only 10 frames before you press a direction to get a dash). You can press crouch up to 15 frames before you press CW and get a crouch shot.
Interval refers to the number of frames between shots, either for multiple-shot attacks or manual chaining techniques. I listed almost all the unique chains I was able to find, including some obscure ones. Chains are enabled through various mechanics, some are glitches and some are intentional. A few chains are enabled by multiple mechanics in which case they may be input in multiple ways. Some chains come out at fixed speed while others reflect the timing of the input. In such cases I either give the shortest interval or the exact output window.
I didn't list the majority of generic chains that can be achieved through plain walk canceling or rotation canceling as the interval can usually be figured out from the provided animation and recovery data. I provided a few examples to help. A few VR have a slower rotation cancel than others, either because their walk decelerates too slowly or because of a glitch in their rotation, but this can be overcome by walking in certain directions, or rotating earlier in some circumstances.
Some dash attacks come out 3 frames slower at the very beginning of a moving dash. The angle of rotation increases accordingly. To remove this, just wait a bit after starting the dash to fire. Every frame you wait removes a frame from the delay. Some VRs cannot do a moving back dash, attempting one yields a stationary back dash with the startup delay worsened by an additional 4 frames. This does not apply to their back diagonal dashes.
I recommend noting the fastest attacks for each VR because they are good for canceling your landing freeze. Using my conventions, a 5-frame landing freeze is equivalent to canceling and replacing it with a 5-frame attack with a recovery of 1. That's assuming perfect timing. When attacks have both interval and recovery data, the recovery is listed relative to the earliest projectile that can be canceled into a dash.
Last edited by Porcupine on 01 Jun 2017, 20:47, edited 4 times in total.
-
- Virtual-On Positive
- Posts: 2053
- Joined: 15 Dec 2008, 22:06
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
I compiled this very slowly over the last two months. The basic technique to gather frame data is simple. I press the Start button during Training Mode with perfect timing over and over, stepping through any set of actions and inputs I choose. I first accidentally realized this was humanly possible as I was compiling information for the bomb research thread. With slow motion on, the leniency for pressing Start increases to 2~3 frames depending how you look at it, making it feasible to continue almost indefinitely without screwing up.
I've already moved on to the next major project utilizing this ability. I will finish the recoveries for the unsafe moves later. It may take a long time but this is only the beginning...
I've already moved on to the next major project utilizing this ability. I will finish the recoveries for the unsafe moves later. It may take a long time but this is only the beginning...
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
I spent three weeks to finish the recovery frame data for all unsafe RT and dash attacks. Some LT attacks also have recoveries but I only marked them in red if their recovery behavior is abnormal. Standing LT attacks can cancel into a walk or dash before full recovery (being able to shoot again without moving). Crouching LT attacks can cancel into a sliding crouch or dash, starting on the same frame. They can cancel into a walk at some later frame, and attain full recovery some time after that.
I applied stricter criteria to standing regular attacks, marking any with more than a few frames of recovery in red. Stationary crouching attacks are not marked in red if they can cancel into a sliding crouch. When possible this always occurs some time before they can cancel directly into a walk or dash. Walking or sliding crouch attacks are only marked in red if they force a VR to be stationary.
RT attacks list the frame on which full recovery occurs. Dash attacks count the number of moving frames after the final projectile appears. This convention could be considered less by one frame. A jump or trigger press may be registered on the next frame, which I'll call the first frame of the freeze. Not commonly known, you can move in any direction on this one frame at walking speed. Some dash attacks allow jumping before the freeze begins, except on the final frame of the dash.
Frame data for diagonal dash attacks is typically identical to the forward or backward version. This is true even when the diagonal attack has a different number of shots, only a different firing interval adjusts the recovery frames. If one version has only one shot while the other has multiple then the recovery frames may also adjust. There are a few side dash attacks with differing left and right dash recoveries.
The number of shots can be reduced by running out of ammo, or firing a crouch attack as a dash is about to expire. When these happen the recovery frames are unchanged so the overall attack finishes quicker. Temjin air forward dash RW, which recovers quickly, is an exception. It recovers slower with only one shot, finishing at the same time overall. Some glitchy dash attacks make an empty gauge sound after firing but that has no effect upon these frame data relationships.
Temjin surfboard and Dordray air rushes have an unlit recovery animation after running out or hitting a wall. They cannot control the subsequent drop nor cancel the landing freeze, but they can jump on the first frame after the aerial recovery animation. Cypher SLC has one frame of unlit recovery then descends with usual air movement. The landing freeze can be canceled and isn't lengthened when ending near the ground.
I applied stricter criteria to standing regular attacks, marking any with more than a few frames of recovery in red. Stationary crouching attacks are not marked in red if they can cancel into a sliding crouch. When possible this always occurs some time before they can cancel directly into a walk or dash. Walking or sliding crouch attacks are only marked in red if they force a VR to be stationary.
RT attacks list the frame on which full recovery occurs. Dash attacks count the number of moving frames after the final projectile appears. This convention could be considered less by one frame. A jump or trigger press may be registered on the next frame, which I'll call the first frame of the freeze. Not commonly known, you can move in any direction on this one frame at walking speed. Some dash attacks allow jumping before the freeze begins, except on the final frame of the dash.
Frame data for diagonal dash attacks is typically identical to the forward or backward version. This is true even when the diagonal attack has a different number of shots, only a different firing interval adjusts the recovery frames. If one version has only one shot while the other has multiple then the recovery frames may also adjust. There are a few side dash attacks with differing left and right dash recoveries.
The number of shots can be reduced by running out of ammo, or firing a crouch attack as a dash is about to expire. When these happen the recovery frames are unchanged so the overall attack finishes quicker. Temjin air forward dash RW, which recovers quickly, is an exception. It recovers slower with only one shot, finishing at the same time overall. Some glitchy dash attacks make an empty gauge sound after firing but that has no effect upon these frame data relationships.
Temjin surfboard and Dordray air rushes have an unlit recovery animation after running out or hitting a wall. They cannot control the subsequent drop nor cancel the landing freeze, but they can jump on the first frame after the aerial recovery animation. Cypher SLC has one frame of unlit recovery then descends with usual air movement. The landing freeze can be canceled and isn't lengthened when ending near the ground.
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
After carefully watching a Japanese replay video, I noticed there is a different timing when doing the jump glitch after Temjin's surfboard hits the edge of the stage.
When the surfboard expires normally there are 8 unmoving frames at the end with the surfboard still lit, followed by 16 unlit recovery frames. After that Temjin descends for 11 frames and has a 6 frame landing freeze. If hitting an obstacle Temjin instead stops for 16 frames with the surfboard still present, followed by 16 unlit recovery frames. In both cases, jumping on frame 17 begins with a 6 frame jump delay mini-freeze, instead of the usual 3.
If hitting the edge of the stage the surfboard ends immediately. There is only 1 unlit recovery frame just when Temjin reaches the wall, and no unmoving frames precede that. Regardless whether the surfboard hits the edge during startup or after missing the enemy, the "Nagoya jump" glitch should be input on the next frame, after contacting the wall. This technique is used by some Temjin players for timeout at the end of a round.
An alternative way to perform this technique is to do a plain air dash all the way until Temjin is rubbing the edge of the stage with his body. Hit CW, then press jump exactly 2 frames after that. Note that in this method there is an extra frame difference in timing due to the CW command frame. In both cases at the edge, the "Nagoya jump" technique begins with the usual 3 frame jump delay.
Dordray can also use this glitch to re-jump or grow giant in midair after his air forward dash LW or CW. In his case it doesn't matter if his air rushes hit an obstacle, the edge, or expire normally. The timing is the same and will also have the usual 3 frame jump delay.
When the surfboard expires normally there are 8 unmoving frames at the end with the surfboard still lit, followed by 16 unlit recovery frames. After that Temjin descends for 11 frames and has a 6 frame landing freeze. If hitting an obstacle Temjin instead stops for 16 frames with the surfboard still present, followed by 16 unlit recovery frames. In both cases, jumping on frame 17 begins with a 6 frame jump delay mini-freeze, instead of the usual 3.
If hitting the edge of the stage the surfboard ends immediately. There is only 1 unlit recovery frame just when Temjin reaches the wall, and no unmoving frames precede that. Regardless whether the surfboard hits the edge during startup or after missing the enemy, the "Nagoya jump" glitch should be input on the next frame, after contacting the wall. This technique is used by some Temjin players for timeout at the end of a round.
An alternative way to perform this technique is to do a plain air dash all the way until Temjin is rubbing the edge of the stage with his body. Hit CW, then press jump exactly 2 frames after that. Note that in this method there is an extra frame difference in timing due to the CW command frame. In both cases at the edge, the "Nagoya jump" technique begins with the usual 3 frame jump delay.
Dordray can also use this glitch to re-jump or grow giant in midair after his air forward dash LW or CW. In his case it doesn't matter if his air rushes hit an obstacle, the edge, or expire normally. The timing is the same and will also have the usual 3 frame jump delay.
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
I had neglected to post this when I added the red recovery data earlier: the VOOT timer counts down quicker than real life. It calculates using 25/50 fps PAL format instead of 30/60 fps NTSC format which is how the game actually runs. Therefore the default 80 second time limit is actually only 66.67 real seconds, no wonder it feels so short!
Frame data for long lasting things tends to be synced to real seconds: angel mode takes 2 real seconds to activate, Cypher plane mode lasts 10 real seconds, etc. Specineff death mode is instead 13 game timer seconds (actually 13.6 because the game allows him a bit more time until after the final Death message disappears off screen).
VOOM has a 90 second default time limit which likewise counts down quicker. It seems to use the same 25/50 PAL format, although for some reason the fractional seconds don't cycle the same displayed number patterns that VOOT does. Interestingly, the time limit for choosing your VR at the select screen counts down in real seconds.
Force has a 90 second default time limit which counts down quicker than real seconds, but slower than VOOM and VOOT. Instead of counting quicker by a factor of 6/5, the Force timer decreases by an extra second about every 12 real seconds.
Index has a 90 second default time limit which counts according to real seconds. Specineff VW super mode lasts 13 seconds, while for other characters it lasts 17 seconds.
Frame data for long lasting things tends to be synced to real seconds: angel mode takes 2 real seconds to activate, Cypher plane mode lasts 10 real seconds, etc. Specineff death mode is instead 13 game timer seconds (actually 13.6 because the game allows him a bit more time until after the final Death message disappears off screen).
VOOM has a 90 second default time limit which likewise counts down quicker. It seems to use the same 25/50 PAL format, although for some reason the fractional seconds don't cycle the same displayed number patterns that VOOT does. Interestingly, the time limit for choosing your VR at the select screen counts down in real seconds.
Force has a 90 second default time limit which counts down quicker than real seconds, but slower than VOOM and VOOT. Instead of counting quicker by a factor of 6/5, the Force timer decreases by an extra second about every 12 real seconds.
Index has a 90 second default time limit which counts according to real seconds. Specineff VW super mode lasts 13 seconds, while for other characters it lasts 17 seconds.
-
- Member
- Posts: 15
- Joined: 16 Apr 2021, 08:17
Re: VOOT frame data
Though I don't play OT much, this frame data set is unbelievably detailed! Thanks for sharing out!
OMG is the best!
-
- Virtual-On Positive
- Posts: 600
- Joined: 19 Jul 2012, 19:07
Re: VOOT frame data
A couple years ago, HerrCarl (Vogel) and izuko (Fei-Yen) independently tested and confirmed that the VOOM timer counts down quicker than real life seconds by a 30/24 factor. So 5/4 = 1.25 times faster. This is slightly faster than VOOT. Rounds last 72 real seconds, which is still longer than VOOT.
I hypothesized that the 24 frames per second could have come from the movie film format, but who knows. I'm not sure if this is intentional or accidental due to confusion over standards. If it is accidental, the precise multipliers could be 23.976 and 29.97 fps.
Some years ago, before I went into temporary retirement, I did all the close combat frame data for Fei-Yen but never got around to other VR. It's more involved than might be expected, because close combat frames in VOOT can be extended, within limits, by your distance to the enemy. Especially if they are dashing away. You'd want to know the number of frames in each stage: from startup, to possible sliding extension, to the final stationary windup before hit frames, the active range and most typical hit frames, and finally the recovery frames.
My Xbox 360 got rrod recently after years of non-use (even though it's the Jasper model) so I'm not likely to finish, unfortunately.
I hypothesized that the 24 frames per second could have come from the movie film format, but who knows. I'm not sure if this is intentional or accidental due to confusion over standards. If it is accidental, the precise multipliers could be 23.976 and 29.97 fps.
Some years ago, before I went into temporary retirement, I did all the close combat frame data for Fei-Yen but never got around to other VR. It's more involved than might be expected, because close combat frames in VOOT can be extended, within limits, by your distance to the enemy. Especially if they are dashing away. You'd want to know the number of frames in each stage: from startup, to possible sliding extension, to the final stationary windup before hit frames, the active range and most typical hit frames, and finally the recovery frames.
My Xbox 360 got rrod recently after years of non-use (even though it's the Jasper model) so I'm not likely to finish, unfortunately.