VOOT frame data
Posted: 30 Jan 2017, 18:00
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.
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.