Official Ask Anyone Frame Things Thread

[reverie2]

Crouching reduces hitlag and knockback by 1/3.



Crouching reduces kb (and therefore hitstun) of any hit regardless of it being set kb or growing kb.



If the move launches the victim into air (i.e it doesn't spike) and it does enough kb, but not too much so that it knocks down, the victim can hard land via ASDI down (which happens naturally when you're holding down for crouch), and all hitstun gets cancelled. So often when you successfully crouch cancel, you'll only have your regular landing lag instead of a considerable period of hitstun, and that is why cc + asdi down is so powerful.

Lasers happen to be so weak that hard landing doesn't occur, which is what SplitsOnTrees meant.




If the jumpsquat of the char is X and you input jump frame 0, then you should input airdodge on frame X.

Thanks for the explanation man. Would it be correct to say that if you're in hitstun but not in tumble in midair, and then while still in hitstun you stand on the ground, you will also be able to act the frame immediately after you land?

 

[tauKhan]

Most of the time when you land in hitstun while not in tumble, you'll impact land with only the regular landing lag (4 frames for most of the characters). However sometimes you transition from aerial hitstun into grounded hitstun, like in the case of being hit by falco's laser. I don't know exactly what's the requirement for impact land (@Magus420 ?) during hitstun, but it seems that either kb or overall speed needs to be bigger than some small threshold.

 

[X WaNtEd X]

So for my research on the Ganon chaingrab, I am trying to figure out a way to find the maximum DI Falco would use at certain percents right before Ganon would have to start to dash jc grab. Basically, these are percents where if Falco were to fully DI away, Ganon would have to dash jc grab. But if he were to only slight DI Ganon would just grab.

The trouble is I am not sure how to quantify the DI. How many notches of DI are there? Is there a way for me to be 100% sure I'm getting the farthest DI possible for Ganon to be able to stand grab?

 

[Sycorax]

The trouble is I am not sure how to quantify the DI. How many notches of DI are there? Is there a way for me to be 100% sure I'm getting the farthest DI possible for Ganon to be able to stand grab?

To quote Magus:
"Trajectory DI effect in degrees is the perpendicular distance, squared, then multiplied by 18. DIing Jigglypuff's u-throw [which ejects at 90°] at 0 damage with inputs of 0.7000,0.0000 or 0.7000,0.7000 both result in 0.62238, 4.01108 launch speed on 1st frame of KB, which is an angle change of 8.82 (0.7 * 0.7 * 18) from 90° -> 81.18°."

There are as many "notches" of DI as there are inputs on the control stick. The control stick inputs are all ordered pairs (x,y) such that x,y ∈ ℤ; -80 ≤ x,y ≤ 80; and x^2+y^2 ≤ 6400.

Schmooblidon's knockback calculator also has a DI calculator in it. You can use that to figure out what input would maximally influence your trajectory in a certain direction. The "strength" reading right below the control stick input circle tells you how much of the maximum possible 18° that DI input will cause your trajectory to deviate from the base trajectory, e.g. a strength of 50% would yield a 9° difference from the base trajectory.

 

[X WaNtEd X]

To quote Magus:
"Trajectory DI effect in degrees is the perpendicular distance, squared, then multiplied by 18. DIing Jigglypuff's u-throw [which ejects at 90°] at 0 damage with inputs of 0.7000,0.0000 or 0.7000,0.7000 both result in 0.62238, 4.01108 launch speed on 1st frame of KB, which is an angle change of 8.82 (0.7 * 0.7 * 18) from 90° -> 81.18°."

There are as many "notches" of DI as there are inputs on the control stick. The control stick inputs are all ordered pairs (x,y) such that x,y ∈ ℤ; -80 ≤ x,y ≤ 80; and x^2+y^2 ≤ 6400.

Schmooblidon's knockback calculator also has a DI calculator in it. You can use that to figure out what input would maximally influence your trajectory in a certain direction. The "strength" reading right below the control stick input circle tells you how much of the maximum possible 18° that DI input will cause your trajectory to deviate from the base trajectory, e.g. a strength of 50% would yield a 9° difference from the base trajectory.

Ok so in that calculator, you see how there's a square in the center? If I move the control stick to the right (let's say I'm Falco DIing Ganon's dthrow at 0 degrees) outside of that circle, x jumps from .275 to 1. Is there anything in between that? Because when I boot up an actual copy of Melee and DI with Falco, I'm finding that the amount I tilt my control stick past that little square seems to still affect the KB. It isn't just all or nothing past .275 the way that calculator makes it out to be.

Also, the amount of frames I DI and how far I am DIing on those frames also seems to affect KB.

 

[Sycorax]

Ok so in that calculator, you see how there's a square in the center? If I move the control stick to the right (let's say I'm Falco DIing Ganon's dthrow at 0 degrees) outside of that circle, x jumps from .275 to 1. Is there anything in between that?

Click "Simple" to change it to "Precise".

Also, the amount of frames I DI and how far I am DIing on those frames also seems to affect KB.

There is only 1 frame on which the game reads your DI, the last frame of hitlag. Further, while in hitstun, you have no control over your character's air drift.

 

[Bones0]

Also, the amount of frames I DI and how far I am DIing on those frames also seems to affect KB.

DI doesn't affect KB, only trajectory. You always travel the same distance with the same amount of stun unless you crouch or charge a smash or change some variable that directly increases/decreases KB.

 

[tauKhan]

You always travel the same distance with the same amount of stun unless you crouch or charge a smash or change some variable that directly increases/decreases KB.

Except that launch angle does change distance traveled since fall acceleration and speed work against upwards kb, but there's no such effects against horizontal kb.

 

[Sycorax]

Except that launch angle does change distance traveled since fall acceleration and speed work against upwards kb, but there's no such effects against horizontal kb.

What about air friction and max air speed?

 

[tauKhan]

What about air friction and max air speed?

They do not alter kb velocity to my knowledge. Please let me know if I'm wrong. Kb decay I disregarded since that works against the kb regardless of direction.

 

[Kyu Puff]

Not really a question, but I've read in a few places that the game reads directional inputs in increments of 0.0125 (1/80th).

Nana's directional inputs are actually read in increments of 0.007874 (1/127th) in the positive direction, or 0.0078125 (1/128th) in the negative direction. They are superimposed over 80 degrees of movement, so all possible values end up being TRUNC(x/80*127)/127 for 0 ≤ x ≤ 80. Anybody have any theories for why this might be?

The importance of this are that Nana responds differently than Popo to inputs near the threshold between different actions (what we in the IC boards have been referring to as sensitivity desynchs) because her X/Y directional inputs are slightly different. She also has different movement velocities for walking/aerial drift/etc given the same set of inputs.

 

[Bones0]

Not really a question, but I've read in a few places that the game reads directional inputs in increments of 0.0125 (1/80th).

Nana's directional inputs are actually read in increments of 0.007874 (1/127th) in the positive direction, or 0.0078125 (1/128th) in the negative direction. They are superimposed over 80 degrees of movement, so all possible values end up being TRUNC(x/80*127)/127 for 0 ≤ x ≤ 80. Anybody have any theories for why this might be?

The importance of this are that Nana responds differently than Popo to inputs near the threshold between different actions (what we in the IC boards have been referring to as sensitivity desynchs) because her X/Y directional inputs are slightly different. She also has different movement velocities for walking/aerial drift/etc given the same set of inputs.

Wouldn't the different velocities be a result of her Popo magnet effect where she sort of magically drifts towards him? Or is it something different?

 

[Kyu Puff]

Wouldn't the different velocities be a result of her Popo magnet effect where she sort of magically drifts towards him? Or is it something different?

In this case, no. Her initial aerial drift, for example, is correctly predicted by (X directional value)*0.075, the same as Popo's, except that her X directional value is slightly different for any given input.

The force modifies her position on any given frame by 0.05*(Popo's position 6 frames ago - Nana's position on the last frame). It does affect how far she travels during those movement states, as she effectively targets his position 5 frames before (rather than 6 frames before like she should), but the change is calculated independently on every frame. I've found the hex values for her velocity, position, and directional inputs, and velocity is always just a function of initial velocity and acceleration; the force only seems to affect her position.

 

[tauKhan]

It does affect how far she travels during those movement states, as she effectively targets his position 5 frames before (rather than 6 frames before like she should)

Is this because the force uses popo's position after movement 6 frames before, but is itself applied and therefore also uses nana's position before movement?

 

[Kyu Puff]

Is this because the force uses popo's position after movement 6 frames before, but is itself applied and therefore also uses nana's position before movement?

This is what I originally thought, and framed it as ''6 frames before - 1 frame before' for simplicity's sake. However, there is another possibility.

Just as Nana receives inputs and positional information from Popo, she also receives and imitates his direction. When Popo changes direction as the result of a hitbox interaction (which happens at the end of a frame), or an f-smash input, Nana copies his direction 6 frames later. The strange thing is that when Popo changes direction as the result of a turnaround (beginning of the frame), she copies his direction 5 frames later. To me, it almost seems like she's supposed to copy his direction 5 frames later, which means it's also plausible that she's supposed to drift towards his position (pre-movement) 5 frames later.

If there were a reliable way to freeze the game at different parts of a frame, then maybe we could shed some light on this...

 

[tauKhan]

The strange thing is that when Popo changes direction as the result of a turnaround (beginning of the frame), she copies his direction 5 frames later. To me, it almost seems like she's supposed to copy his direction 5 frames later, which means it's also plausible that she's supposed to drift towards his position (pre-movement) 5 frames later.

Not strange at all to me, it's what I expected tbh. It sounds like popo's position and orientation is stored after movement is done in the frame procession, but before hitbox interactions. F-smash not turning nana 5 frames later seems bit weird, but it can still be explained in the model where position is stored somewhere in the middle of frame procession.

Whether this is all intended or not is a different question of course. To me the difference in orientation change when getting hit and when turning makes the 5 frame delay in drift sound even more like an error. Without knowing the details of how it's all coded, it shouldn't be very hard to make the orientation change to always be 5 or 6 frames. On the other hand, it's such a silly mistake to make that it's perhaps more plausible that it's actually a fix to some behaviour I cannot see. Then again, universal 6 frame delay would fix dd desynch and some other glitches.

 

[Kyu Puff]

Not strange at all to me, it's what I expected tbh. It sounds like popo's position and orientation is stored after movement is done in the frame procession, but before hitbox interactions. F-smash not turning nana 5 frames later seems bit weird, but it can still be explained in the model where position is stored somewhere in the middle of frame procession.

Whether this is all intended or not is a different question of course. To me the difference in orientation change when getting hit and when turning makes the 5 frame delay in drift sound even more like an error. Without knowing the details of how it's all coded, it shouldn't be very hard to make the orientation change to always be 5 or 6 frames. On the other hand, it's such a silly mistake to make that it's perhaps more plausible that it's actually a fix to some behaviour I cannot see. Then again, universal 6 frame delay would fix dd desynch and some other glitches.

Originally I thought all of these things were stored at the same time, and then passed to Nana at the beginning of the frame so that she could interpret the input. However, it makes less sense to me if turning doesn't happen at the end of a frame. In the scenario that you described, she would be receiving his position from 6 frames ago (albeit from a different part of the frame procession), but his orientation from 5 frames ago. To me, there doesn't seem to be more evidence that is the case than that Nana simply receives his position 5 frames earlier from the beginning of the frame as well.

 

[tauKhan]

To me, there doesn't seem to be more evidence that is the case than that Nana simply receives his position 5 frames earlier from the beginning of the frame as well.

But if Nana simply takes orientation 5 frames earlier, how do you then explain fsmash / getting hit turning her 6 frames later? My solution to that is that Turn turns popo before his orientation is stored, while hitboxes/attacks would turn popo after the storing.

 

[Kyu Puff]

But if Nana simply takes orientation 5 frames earlier, how do you then explain fsmash / getting hit turning her 6 frames later? My solution to that is that Turn turns popo before his orientation is stored, while hitboxes/attacks would turn popo after the storing.

That was my solution as well. I meant that position could just as well be taken before Popo's position is updated and passed to Nana 5 frames later. If all three attributes were taken 6 frames before, I would be inclined to accept the explanation that Popo's position is recorded after movement, but as we have one thing being passed 6 frames later (input) and another thing being passed 5 frames later (orientation), I see no reason to support one over the other.

This is my current understanding of a frame procession:

1. Orientation is updated (from turning animations)
2. Inputs are interpreted
3. Velocity, position are updated
4. Hitbox interactions

Evidence for 1 before 2: I've found hex values for direction that read +1 when a character is facing right and -1 when a character is facing left. During a turning animation, a jump or shield input on any frame where the hex value reads -1 is interpreted as facing left. A jump or shield input on the first right-facing frame is interpreted as facing right. Weaker evidence: When Popo smash turns, Nana's orientation updates 5 frames later; she then interprets the input (what was a smash turn) as a dash because she is already facing in that direction (this evidence is weaker because Nana mechanics don't necessarily generalize to other characters).

Evidence for 2 before 3: Airdodge in place reduces velocity to 0 and freezes position on the same frame. Input on the frame you would slide of a platform/ledge is interpreted as if you were standing on the ground. There is one counterexample, though: Input on the first frame of a jump is interpreted as if you are airborne.

Evidence for 3 before 4: Pretty straightforward to test with hitboxes and moving targets. If a hitbox would connect before velocity is applied, but not after velocity is applied, it misses. When a moving target is hit, velocity is added to position on the first frame of hitlag, and subsequently reduced to 0.

 

[tauKhan]

@Kadano , schmooblidon , Kyu Puff , Sycorax

Is it possible that getting hit would make you land where you wouldn't land otherwise? There is a claim on the ganon boards that if you stomp someone out of tumble right before they would land, he'll pop up as if he were grounded and is also unable to tech before getting hit. This seems unlikely to be true to me, just asking to make sure.

 

[Sycorax]

@Kadano , schmooblidon , Kyu Puff , Sycorax

Is it possible that getting hit would make you land where you wouldn't land otherwise? There is a claim on the ganon boards that if you stomp someone out of tumble right before they would land, he'll pop up as if he were grounded and is also unable to tech before getting hit. This seems unlikely to be true to me, just asking to make sure.

Here's what I found playing around. When you're hit by a move, you change animations (obviously) and when you change animations, so does your ECB. If the ECB change would cause you to collide with the ground, the game prevents that. Instead it shifts your character up, moving your TopN to be level with the ground/platform. It looks the same as when you SDI into the ground. The white ECB projection shows your ECB colliding with the ground, but the game doesn't allow that and instead generates the ECB higher off the ground with the TopN bone level with the ground.

This may be different for Jigglypuff, Kirby, and DK, who have the bottom of their ECBs permanently attached to their TopN bone. This means the shift of the TopN bone to be level with the ground would also put the character touching the ground (or maybe only right next to it and not technically a "collision"?). I can't find any setups for it so that I can test For the above paragraph, I tested it by dairing Captain Falcon right before he landed from doing a backwards fullhop NIL on Yoshi's Story. However, for Puff, Kirby, and DK, I can't find any way to have their ECB move downwards upon getting hit. It might not be possible for them with their weird ECBs.

 

[tauKhan]

Sycorax So I gather that if you spike a character that's not puff/kirby/dk before a ground collision, the opponent will get spiked onto ground normally instead of bouncing up like grounded characters do? And that it's impossible to take away tech opportunity in that manner.

 

[Sycorax]

Oops I forgot to include that. Yes, the opponent will be spiked into the ground normally. This applies for Puff, Kirby, and DK as well (unless someone can find an animation frame where the bottom of the ECB is higher than the Damage* 1 ECB). They will be able to tech (the long hitlag on Ganon's dair is probalby what's causing people to miss techs).

 

[schmooblidon]

T tauKhan Although the question has already been answered, I've been researching a bunch of stuff related to this.

I'm pretty certain each action state has a "can land" boolean or there is a global boolean that is change on each action states initialize function, along with a "can ledge grab" boolean (1 for each side) and probably wall tech, maybe other stuff too. But functions for specific frames can turn this boolean on and off,

Doc's Upb for example: Frames 1-3 have doc move downward but he cannot land or grab ledge. Frames 4+ will only allow landing and ledge grabbing if he has downward char velocity. Even if a platform catches him during this phase, he still cannot land unless he has downward velocity.

Hitlag isn't what's preventing it as platform warps can allow the attacker to land during hitlag. It must be the Damage 1 disallowing it, probably to prevent forbidden DI.

 

[Kramepie]

hey there. sorry if this has been discussed already, I'm curious if theres a page to display active frames of all the moves, or at least for the top tiers. I'm just curious if there is a way to see how move speeds rank against each other. thanks

 

[Sycorax]

hey there. sorry if this has been discussed already, I'm curious if theres a page to display active frames of all the moves, or at least for the top tiers. I'm just curious if there is a way to see how move speeds rank against each other. thanks

In each character's forum, there is a pinned post name "[Character] Hitboxes and Frame Data".

 

[Kramepie]

In each character's forum, there is a pinned post name "[Character] Hitboxes and Frame Data".

thanks bro

 

[schmooblidon]

I figured out the walk acceleration formula today:

Current Walk Acceleration = ((MaxWalkVel * Xinput) - PreviousFrameVelocity) * (1/(MaxWalkVel * 2)) * (InitWalkVel + WalkAcc)

MaxWalkVel, InitWalkVel and WalkAcc can be found on Crazy Hand.

And also the run acceleration formula;

Current Run Acceleration = ((MaxRunVel * Xinput) - PreviousFrameVelocity) * (1/(MaxRunVel * 2.5)) * (DRAA + (DRAB/Math.abs(Xinput)))

DRAA/DRAB = Dash & Run Acceleration A/B, which can be found on Crazy Hand.

****in sakurai

Also whilst I was figuring this out I found some cool thing with Mewtwo. As his DRAA = 0, and DRAB = 0.1 and the formula for dash acceleration is;

Current Dash Acceleration = (Xinput*DRAA) + (Math.sign(Xinput)*DRAB)

Mewtwo will always have a dash acceleration of 0.1, no matter his Xinput. This means his moonwalks are very reliable and easy to do perfectly.

 

[tauKhan]

Current Dash Acceleration = (Xinput*DRAA) + DRAB

Mewtwo will always have a dash acceleration of 0.1, no matter his Xinput. This means his moonwalks are very reliable and easy to do perfectly.

This can't be right; surely you're missing a term somewhere since with that formula mewtwo couldn't even accelerate backwards at all during dash.

Also pause buffered full input moonwalk goes way further than buffered dash -> diagonal back input one with mewtwo.

 

[schmooblidon]

This can't be right; surely you're missing a term somewhere since with that formula mewtwo couldn't even accelerate backwards at all during dash.

Also pause buffered full input moonwalk goes way further than buffered dash -> diagonal back input one with mewtwo.

Probs something like:

Current Dash Acceleration = (Xinput*DRAA) + (Math.sign(Xinput)*DRAB)

Or woteva would give the same result.

What are buffered full input and buffer dash -> diagonal back?

Edit: Oh so you are holding diagonal back the whole time?

Sorry I should have clarified;

Current Max Dash Velocity = MaxDashVel * Xinput

So this still applies, so you eventually have to move the stick all the way back to reach the max dash vel in the opposite direction.

 

[tauKhan]

Current Dash Acceleration = (Xinput*DRAA) + (Math.sign(Xinput)*DRAB)

Current Max Dash Velocity = MaxDashVel * Xinput

So this still applies, so you eventually have to move the stick all the way back to reach the max dash vel in the opposite direction.

That makes sense! So Mewtwo's moonwalk is easier because you have a lot of time to move stick back before your dash speed is close to MaxDashVel with diagonal input.

 

[schmooblidon]

That makes sense! So Mewtwo's moonwalk is easier because you have a lot of time to move stick back before your dash speed is close to MaxDashVel with diagonal input.

Yeah exactly

 

[Sycorax]

T tauKhan reminded me recently of this post by Achilles in which he reveals the exact code for the knockback formula. It's hard to read so here's a more legible version.

The formula on top shows the calculation as it appears in the code. The formula on bottom shows the calculation slightly simplified (just the weight term and the KBG are changed).

I'm a little slow to the party (the post is a kinda old), but there is one consequence that I wanted to make sure everyone was aware of. The floored percentage term is not accounted for in @Kadano's knockback calculator Excel spreadsheet. This is easily fixed by changing the formula in cell C8, titled Total Damage, on the Calculation & Data sheet to be "=FLOOR.MATH('Input & Output'!J6)+A8" instead of "='Input & Output'!J6+A8".

The effect this has on calculations is that fractional damage percentage values for the victim don't matter. A move will do the same knockback to a victim at 5% as it would do at 5.999% or 5.5%. This might matter for your calculator app schmooblidon but it seems you can only increment the percent by integer values so I guess it doesn't matter.

 

[schmooblidon]

Sycorax Yeah I actually took out the fractional percent selector because of this. Shoutouts to achilles being a homie

 

[reverie2]

I found a reddit thread with the description of power shielding a melee attack which cites a magus post i couldn't find:

1) 4 frame window
2) No shield damage
3) Same shield hitlag
4) More shield pushback than full shield
5) Same shield stun as full shield
6) Allows you to cancel the shield dropping animation with an A or B attack

I had a question:

If you cancel the shield dropping animation, does that mean I can do whatever I want (like dash around) after? Or does the attack I used to cancel the shield get executed? eg if I just pressed A after shieldstun from powershielding, does that release shield and I can dash, or does it automatically jab?

Also does any have the original magus source for this?

 

[Sycorax]

a magus post i couldn't find

Try looking in the Melee Library next time. It's in there. Ctrl+F for "powershield".

If you cancel the shield dropping animation, does that mean I can do whatever I want (like dash around) after? Or does the attack I used to cancel the shield get executed? eg if I just pressed A after shieldstun from powershielding, does that release shield and I can dash, or does it automatically jab?

You can only cancel the GuardOff animation with an attack, not with movement, e.g. a dash. You can jump though. But you also have access to all your tilts, smash attacks, and special moves.

 

[tm]

Worth mentioning that you can't do a jab / tilt BEHIND you, as that would require entering Turn first. But you can fsmash / sideB backwards.

 

[reverie2]

Worth mentioning that you can't do a jab / tilt BEHIND you, as that would require entering Turn first. But you can fsmash / sideB backwards.

So that means tilting backwards = # frame for tilt forward + 1 frame for the turnaround, but this doesn't apply to smash attacks?

 

[tauKhan]

Yes, the attack itself can turn your char with forward smashes. Turn -> smash is still of course possible.

 

[Kyu Puff]

http://imgur.com/a/2na5b

The grounded A control stick map will show you why this is the case.