VOOT frame data

Discuss the Virtual-On series.
User avatar
Porcupine
Virtual-On Positive
Posts: 557
Joined: 19 Jul 2012, 19:07

VOOT frame data

Postby Porcupine » 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.
Last edited by Porcupine on 12 Jul 2017, 19:00, edited 1 time in total.

User avatar
Porcupine
Virtual-On Positive
Posts: 557
Joined: 19 Jul 2012, 19:07

Re: VOOT frame data

Postby Porcupine » 03 Feb 2017, 18:00

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.

ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage
ImageImage


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.

User avatar
MentholMoose
Virtual-On Positive
Posts: 1991
Joined: 15 Dec 2008, 22:06
Gamertag: MentholMoose
PSN: MentholMoose_
Location: California
Contact:

Re: VOOT frame data

Postby MentholMoose » 03 Feb 2017, 19:05

Wow, how are you compiling this info?
MentholMoose

User avatar
Porcupine
Virtual-On Positive
Posts: 557
Joined: 19 Jul 2012, 19:07

Re: VOOT frame data

Postby Porcupine » 03 Feb 2017, 19:28

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...


Who is online

Users browsing this forum: Baidu [Spider] and 3 guests