Frame Data

Overview
A unit’s movement animation can be broken down into five main parts: starting delay, movement, attack, buff application, and return movement.


 * Starting Delay: the delay in the beginning due to earlier units’ BBs activating
 * Movement: the movement time required before the attack begins
 * Attack: the hits from your unit that damage the enemy
 * Buff Application: the application of BB buffs to the team (or debuffs to the enemy)
 * Return movement: the movement from the enemy position back to the unit’s start position

All the information required to fully calculate all frame delays can be found on this page and from Deathmax’s Datamine. The specific portions of the datamine with the information for each part will be listed in its respective section.

Moving Units
Moving type units are those that physically move across the screen to get to the enemy and attack. A list of units with Moving Type movement can be found here.

Teleporting Units
Teleporting units are those that teleport to get to the enemy and attack. A list of units with Teleporting Type movement can be found here.

Stationary Units
Stationary units are those that attack the enemy in place without traveling to them. A list of units with Stationary Type movement can be found here.

Starting Delay
If there are multiple units swiping BB’s on autobattle, then there is a delay that each BB causes to all units after it. For example, if there is a Mifune using SBB after a Soleil, then Soleil’s SBB will add a slight delay to Mifune’s attack. The exact delay depends on whether BB cut-in is on.

If BB cut-in is on, then there is a single frame (+1) delay to all units after it. If BB cut-in is off, then there is a longer delay of two frames (+2) to all subsequent units.

Example: let’s say there is a swiping sequence of Rozalia -> Azurai -> Lasswell in a team with BB cut-in off (+2 frames per SBB). Rozalia has no units swiping before her, so she has no starting delay. Azurai has only Rozalia swiping before him, so his starting delay is +2. Finally, Lasswell has both Rozalia and Azurai swiping before him. Each contributes +2 frames to his delay, for a total delay of +4 frames for Lasswell.

''Note: Teleporters are an exception and have a very strange starting delay when cut-in is turned on. Instead of the usual +1 frame per previous SBB, it maintains the +2 frame per SBB that would result from having cut-in off. In addition, this scenario also subtracts a constant frame delay of 6 frames compared to having cut-in off. ''

Movement
Before an attack can begin, units need to move to the enemy position. When there is more than a single enemy on the field, moving units always travel to a fixed point in the center of the field (making them easy to predict). However, when there is only enemy, the unit travels to the specific position the enemy is in (making it harder to predict sparking). This single-enemy case is vulnerable to inconsistency, often off by +1 or -1 frame.

There are three types of units, each of which move to the enemy in a different manner: moving units, teleporting units, and stationary units.

 Location in the datamine: Movement Type = unit_id >> movement >> skill >> move type

Moving Units (Type 1)
Moving units are broken up into five different types (simply called speed types 1, 2, 3, 4, and 5) that each have a corresponding movement speed. This movement speed value determines how long it takes for the unit to get to its target. These values are actually inversely proportional to the unit's real speed; the lower the value of the movement speed, the faster the unit travels. Therefore, speed 5 units like Mifune move the fastest.

The move speeds for each of the five types of moving units are listed below:

Each of the move speeds can be used to determine the exact number of frames required to move to the enemy, relative to the distance traveled across the field. Since the back row of units is further back, the movement time from the back row is longer than that from the front row.

Since moving units travel to the same spot in any situations involving 2+ enemies, regardless of the enemy’s position, these movement times depend only on unit position and move speed type. The compiled table of frame delays (obtained through testing) for each of the cases is below:

For cases involving single target enemies, the frame delay varies based on each of the 6 enemy positions. The testing involved for finding these values would be extremely tedious (and the results wouldn’t be entirely usable, since attacking single target enemies is especially vulnerable to frame lag and makes consistent sparking impossible). As a result, these values are currently unknown.

 Location in the datamine: Movement Speed Type = unit_id >> movement >> skill >> move speed type

Teleporting Units (Type 2)
Teleporting units are by far the hardest unit type to find movement delay for. The values for movement frames in the datamine do not seem to accurately reflect the real teleporting time, so the values for each teleporter have to be calculated through in-game testing. The currently-tested teleporter delays are as follows:

These values are independent of the positioning of either the teleporter or the enemy. This is because, no matter how close or far the teleporter might be to its intended destination, it will simply teleport there without having to travel across the screen.

Example: for a Zeis teleporting to the enemy, there needs to be just the addition of a constant 24 frame delay for her teleportation movement.

Stationary Units (Type 3)
Stationary units all have a simple movement delay, called the “move speed”. This is a constant frame delay that is independent of any positioning of the unit or enemy (since stationary units don’t have to perform any movement).

Example: Sakura Miku has a move speed of 4, so we need to add 4 frames of in-place movement as a delay before her attack can begin.

 Location in the datamine: Movement Speed = unit_id >> movement >> skill >> move speed

Attack
After movement, there is a slight delay (called the effect delay) before the attack itself can begin. After the effect delay, the attack’s damage needs to be calculated. On this start frame, the game checks the effects of all buffs, except those that are calculated on a hit-by-hit basis (like spark damage and BC/HC drop), and applies them to the attack. Any buffs that were applied on a frame before this calculation frame are considered. Once this is done, the timings for the attack can be determined by adding the frame times for each hit to obtain the actual frame on which every hit lands.

Note that hit-by-hit buffs like spark damage are calculated on the particular frame that a hit sparks. On each hit, the game checks to see whether the hit is sparked; if it is, it receives the effect of any active spark damage buffs.

Example: To illustrate how attack frame calculation is done, suppose there is a Mifune with a total of 10 frames movement delay, 1 frame effect delay for damage, and a single hit applied on frame 30. Then, the effect delay will cause the attack to start on frame 11 (10+1). Any buffs applied on frame 10 or earlier will affect this attack. Then, the single hit will land on frame 41 (11+30).

 Location in the datamine: Damage Frames = unit_id >> [bb/sbb/ubb] >> damage frames >> [0] >> frame times

 Location in the datamine: Effect Delay = unit_id >> [bb/sbb/ubb] >> damage frames >> [0] >> effect delay time(ms)/frame

''“[0]” will need to be replaced by the specific effect number the attack is on. This is typically just 0, but with dual-attacking units you might have an attack with a nonzero value here.''

Buff Application
Buff application uses the same type of effect delay as attacks do. Basically, each BB buff effect has its unique effect delay after movement time on which that buff applies. Typically, the effect delay for a unit’s buff is 0 for buffs to make sure they also apply in time to affect the unit's own attack.

Example: using the same scenario with Mifune as previously mentioned, imagine that his attack buff has a 0 frame effect delay. Then, the buff will apply on frame 10 (10+0), which is just in time to buff his own attack that starts on frame 11.

Return Movement
For all teleporting and moving units, the return movement will always be a moving type action. The return speed for all units is set to a constant 0.002, which corresponds to a speed partly between move speed types 4 and 5 (which is quite fast). Since this is a moving type action, the time taken to return to the original position will vary based off of enemy and unit position.

For stationary units, since they never move in the first place, they don’t have any return time.

Frame Calculation Formulas
To calculate the total frame delay before a unit’s attack, use the formulas listed below. These total delays are added to each frame of the attack to get the final frame that each hit lands on.

Moving Units
Delay = sbb_frame_delay*(order-1) + movement_speed + effect_delay


 * Sbb_frame_delay: set to 1 for cut-in on, 2 for cut-in off (the delay for each previous BB)
 * Order: the order in which the unit was swiped (1 for first, 6 for last)
 * Movement_speed: the speed for movement (taken from the table)
 * Effect_delay: the delay before the attack's damage frames begin

Teleporting Units
Delay = 2*(order-1) - {6 if cut-in on} + teleport_time + effect_delay


 * Order: the order in which the unit was swiped (1 for first, 6 for last)
 * {6 if cut-in on}: constant difference if cut-in is on (0 if cut-in is off)
 * Teleport_time: the teleport movement time (taken from the teleporter table)
 * Effect_delay: the delay before the attack's damage frames begin

Stationary Units
Delay = sbb_frame_delay*(order-1) + move_speed + effect_delay


 * Sbb_frame_delay: set to 1 for cut-in on, 2 for cut-in off (the delay for each previous BB)
 * Order: the order in which the unit was swiped (1 for first, 6 for last)
 * Move_speed: the movement delay for in-place movement
 * Effect_delay: the delay before the attack's damage frames begin

Example 1: Moving Unit

 * Starting Delay: 2*(3-1) = 4 frames
 * Movement delay: 19 frames
 * Attack: starts on frame 24 (4+19+1)
 * Buff Application: applied on frame 23 (4+19)

By frame 4, Felice has started. By frame 23, she is finished moving. She applies buffs at frame 23, then attacks at frame 24 (meaning her BB mod buff has enough time to apply to her own attack). So her first three hits are delayed by 24, landing on frames 47, 50, 53.

Example 2: Teleporting Unit

 * Starting Delay: 2*(2-1) = 2 frames
 * Movement delay: 24 frames
 * Attack: starts on frame 27 (2+24+1)
 * Buff Application: applied on frame 26 (2+24)

By frame 2, Zeis has started. By frame 26, she is finished moving. She applies buffs at frame 26, then attacks at frame 27 (meaning her EWD buff has enough time to apply to her own attack). So her first three hits are delayed by 27, landing on frames 67, 70, 73.

Example 3: Stationary Unit

 * Starting Delay: 1*(6-1) = 5 frames
 * Movement delay: 0 frames
 * Attack: starts on frame 6 (5+0+1)
 * Buff Application: applied on frame 5 (5+0)

By frame 5, Ensa has started. By the same frame, she has already finished moving. She applies buffs at frame 5, then attacks at frame 6 (meaning her BB Mod buff has enough time to apply to her own attack). So her first three hits are delayed by 6, landing on frames 97, 100, 103.