Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
It appears that you are using ad block :'(
Hey, we get it. However this website is run by and for the community... and it needs ads in order to keep running.
Please disable your adblock on Smashboards, or go premium to hide all advertisements and this notice. Alternatively, this ad may have just failed to load. Woops!
I just checked it Bowser Jr.'s fair landing also frame syncs naturally. The basic mechanic of it is simply that landing lag overlaps with hitlag instead of being delayed by it.
I never fully understood how the game decided when to allow you to land when frame syncing traditional aerials. You don't necessarily land the frame after you hit; I saw variable timings with it, the latest I've had (garbage quality recording) was five frames after the hit, which...doesn't make a ton of sense when your character shouldn't be moving at all. Figuring that out's been something I've wondered about for months now, but I have no idea how I'd go about determining what causes that.
That's a fantastic addition to the compendium of knowledge on this subject! Thanks for sharing that! I guess this means that frame syncing isn't necessarily a frame perfect move, meaning you could land partway through your hitstun and overlap some (but not all!) of those frames.
So the question becomes this: what dictates the ability to move during attacker hitstun? Can you move during attacker hitstun? The recording you have there implies that the answer is yes. Though that whole Ganon test thing I did earlier might say otherwise (subject to retest!). Is it possibly a move-specific trait? Is it effected by shields in some way? Who knows? Not me (yet!).
Knowing this works on shield as well now is pretty interesting. Wonder if any characters get enough frame advantage to get a guaranteed dash grab if their frame synced aerial is shielded.
So I've been doing this aerial disadvantage spreadsheet and when it's come to landing hitboxes thus far I haven't taken frame syncing into account.
Sheik's Dair Landing: [-27, -28]
ZSS Dair Landing: [-22,-23]
Popping in 0% hit lag modifiers (unless I'm missing something that's all that is being 'achieved'):
[-22,-23] +5
[-19,-20] + 3 [it has a 0.3 modifier naturally]
Perhaps Pikachu's dair
Down Air Landing: [-41,-42]
The electric modifier is making it 4 frames less safe than it could be, plus it has a 1.0 modifier
Assuming correctly on how frame syncing will pan out, it should be making the scenario TEN frames safer than what Brawl-paradigm would expect.
[-31,-32]
-
ZSS Neutral Air is one of those moves we've been thinking/seeing anecdotes of frame syncing since early on.
On hit, done properly you have enough time to jab someone while they're still in hit lag.
Nair -11 (-12 if not fully fresh); electric modifier is making it 5 frames less safe than it could be.
If the hit lag modifier was 0; it would be -2 on shield
If the electric attribute wasn't there it "should" be +2 on block.
But here's the kicker, the total hit lag being received shaved is 13 frames, while the landing lag is 10.
That above value is on block, so there's 4 frames of shield stun that wouldn't be applying on hit. 3 frames that wouldn't be overlapping if I'm thinking correctly, and then you have to ask "how is jabbing [frame 1] fast enough to hit the opponent in hit lag?"
Knowing this works on shield as well now is pretty interesting. Wonder if any characters get enough frame advantage to get a guaranteed dash grab if their frame synced aerial is shielded.
So... Frame syncing is more complicated than first thought. Any brainstorming and discussion will help, but I will continue to search for the real cause of this phenomenon either way.
Firstly, some results from an entire night of labbing:
I replicated all of Bowser Jr's down air results from Lavani
, which says good things about the potential auto-frame-sync properties of landing hitboxes.
I re-confirmed my work with Ganon, which shows the footstool to down air frame sync set up is still true, but still does not work no shield.
I sought to replicate more known cases of frame syncing... and got stuck. I can't replicate Falco's in frame advance mode.
For reference: Falco's jump squat is 6 frames, he's airborne for 32 frames, and has a soft landing lag of 2 frames (not important, but I re-measured it for fun). All that said, he needs a hitbox on the 38th frame of that jump arc. Down air takes 16 frames to come out, and by pausing the game on frame 22 and letting that rip, you should get the same effect you see in Izaw's original video.
Except you don't. Seriously. Just try it.
I've had some discussion with @Fox Is Openly Deceptive , and this test is a bit odd. It seems that Izaw had a fast fall somewhere just before the down air, and that may have effected his final position. My current running idea is that you can think of the jump arc as being discrete units of distance, a sort of "frame-length." This obviously varies between characters, fall speeds, and what not, but it IS just a hypothesis for now. Anyways, Falco may actually need that fast fall to align himself into a sort of "sub-frame" space between his normal existing frames where he can start actions. He needs a sub-frame that's closer to the ground than he is during his normal short hop arc.
@Fox Is Openly Deceptive also noticed that the characters this works easily with, Falco and Ganon, have a downward bodily extension. This may move their ECB (Environmental Collision Box) into the ground on the same frame that the hitbox is generated. This may be the only reasonable hypothesis... since try as I might I cannot force a character to move during attacker hitstun, so the attacker SDI theory is out.
Oh, and I tried to replicate Greninja's frame sync nair too. With similar degrees of failure without fast falls. Greninja also doesn't seem to extend any limbs downward, so I'm unsure if it actually will work with him at all if the current hypothesis is correct.
I saw variable timings with it, the latest I've had (garbage quality recording) was five frames after the hit, which...doesn't make a ton of sense when your character shouldn't be moving at all.
I counted the frames here, and this isn't a frame sync. Greninja slides during landing lag, and that's neat, but he is not dashing and he isn't free to take any action. I'm going to guess that the jump was buffered, and when counting from his hit to the first jump frame, I get 24 frames. That accounts for nearly everything. 9 frames of attacker hitstun (see: sixriver's hitstun calculator), 12 frames of landing lag, and 4 jumpsquat frames. That comes out to 25, but I think the point stands enough. For my own re-testing later tonight, Greninja naired on frame 18 and fast fell on frame 22 (I don't have a computer that loads frame advance gifys at home).
So... here's what I think we know:
Characters with frame 1/2 ground hitboxes work fine, AND they work on shields. Continue to test other ground hitbox cases to confirm.
Initial testing indicates that characters freeze during attacker hitstun and are otherwise immobile. Continue testing this for clarity, and try to think of corner cases.
Characters may force the frame sync effect by moving their ECB into the ground on the same frame as their hitbox comes out. This is a hypothesis.
Ganon has a massive amount of bodily movement on his down air, check for others which have the same trait. Also! Try to time his down air out of a short hop using frame advance and see if it works there too.
In the video ZSS seems to get a combo not otherwise reachable through the use of a frame synced nair. She does not, however, extend her body downward in any way that would reinforce this hypothesis. However. This is not evidence yet. It must be re-tested in frame-advance mode!
Movement is quantized into frame-lengths. Sub-frame movement through the activation and cancellation of fast falls may be necessary to move a character to the right location for a frame sync.
In summary... this phenomenon is FAR from trivial, and I think we should not hastily apply this to all aerials OR shields until further testing is complete.
The answer: I don't know. That's the whole point of the huge post. I don't think the community really knows, and I think the community is extrapolating too much. But that's sort of what we do, we try to find general reasons for things. I just think we're moving too fast on this one, it's too complex to get sorted out that easily. We seem to have confirmed the auto-frame-sync capabilities of landing hitboxes though, but that's move specific.
If it's actually ECB movement that frame syncs a move, then it would be move specific... though ECB movement is technically a general mechanic. So the answer to your question is still vague. If my ZSS video above is a real frame sync (to be checked), then the ECB hypothesis may not be valid, and more research will be needed.
In summary... the answer is "more research is needed." I hope more details come out soon.
So... Frame syncing is more complicated than first thought. Any brainstorming and discussion will help, but I will continue to search for the real cause of this phenomenon either way.
Firstly, some results from an entire night of labbing:
I replicated all of Bowser Jr's down air results from Lavani
, which says good things about the potential auto-frame-sync properties of landing hitboxes.
I re-confirmed my work with Ganon, which shows the footstool to down air frame sync set up is still true, but still does not work no shield.
I sought to replicate more known cases of frame syncing... and got stuck. I can't replicate Falco's in frame advance mode.
For reference: Falco's jump squat is 6 frames, he's airborne for 32 frames, and has a soft landing lag of 2 frames (not important, but I re-measured it for fun). All that said, he needs a hitbox on the 38th frame of that jump arc. Down air takes 16 frames to come out, and by pausing the game on frame 22 and letting that rip, you should get the same effect you see in Izaw's original video.
Except you don't. Seriously. Just try it.
I've had some discussion with @Fox Is Openly Deceptive , and this test is a bit odd. It seems that Izaw had a fast fall somewhere just before the down air, and that may have effected his final position. My current running idea is that you can think of the jump arc as being discrete units of distance, a sort of "frame-length." This obviously varies between characters, fall speeds, and what not, but it IS just a hypothesis for now. Anyways, Falco may actually need that fast fall to align himself into a sort of "sub-frame" space between his normal existing frames where he can start actions. He needs a sub-frame that's closer to the ground than he is during his normal short hop arc.
@Fox Is Openly Deceptive also noticed that the characters this works easily with, Falco and Ganon, have a downward bodily extension. This may move their ECB (Environmental Collision Box) into the ground on the same frame that the hitbox is generated. This may be the only reasonable hypothesis... since try as I might I cannot force a character to move during attacker hitstun, so the attacker SDI theory is out.
Oh, and I tried to replicate Greninja's frame sync nair too. With similar degrees of failure without fast falls. Greninja also doesn't seem to extend any limbs downward, so I'm unsure if it actually will work with him at all if the current hypothesis is correct.
I counted the frames here, and this isn't a frame sync. Greninja slides during landing lag, and that's neat, but he is not dashing and he isn't free to take any action. I'm going to guess that the jump was buffered, and when counting from his hit to the first jump frame, I get 24 frames. That accounts for nearly everything. 9 frames of attacker hitstun (see: sixriver's hitstun calculator), 12 frames of landing lag, and 4 jumpsquat frames. That comes out to 25, but I think the point stands enough. For my own re-testing later tonight, Greninja naired on frame 18 and fast fell on frame 22 (I don't have a computer that loads frame advance gifys at home).
So... here's what I think we know:
Characters with frame 1/2 ground hitboxes work fine, AND they work on shields. Continue to test other ground hitbox cases to confirm.
Initial testing indicates that characters freeze during attacker hitstun and are otherwise immobile. Continue testing this for clarity, and try to think of corner cases.
Characters may force the frame sync effect by moving their ECB into the ground on the same frame as their hitbox comes out. This is a hypothesis.
Ganon has a massive amount of bodily movement on his down air, check for others which have the same trait. Also! Try to time his down air out of a short hop using frame advance and see if it works there too.
In the video ZSS seems to get a combo not otherwise reachable through the use of a frame synced nair. She does not, however, extend her body downward in any way that would reinforce this hypothesis. However. This is not evidence yet. It must be re-tested in frame-advance mode!
Movement is quantized into frame-lengths. Sub-frame movement through the activation and cancellation of fast falls may be necessary to move a character to the right location for a frame sync.
In summary... this phenomenon is FAR from trivial, and I think we should not hastily apply this to all aerials OR shields until further testing is complete.
I counted the frames here, and this isn't a frame sync. Greninja slides during landing lag, and that's neat, but he is not dashing and he isn't free to take any action. I'm going to guess that the jump was buffered, and when counting from his hit to the first jump frame, I get 24 frames. That accounts for nearly everything. 9 frames of attacker hitstun (see: sixriver's hitstun calculator), 12 frames of landing lag, and 4 jumpsquat frames.
I...think you're missing something here. In that gfy Greninja hits on frame 30 and lands on frame 35, nair's sweetspot would normally lag him for 9 frames. Nair>Shadow Sneak also can't combo normally. It is indeed a frame sync.
I sought to replicate more known cases of frame syncing... and got stuck. I can't replicate Falco's in frame advance mode.
For reference: Falco's jump squat is 6 frames, he's airborne for 32 frames, and has a soft landing lag of 2 frames (not important, but I re-measured it for fun). All that said, he needs a hitbox on the 38th frame of that jump arc. Down air takes 16 frames to come out, and by pausing the game on frame 22 and letting that rip, you should get the same effect you see in Izaw's original video.
Except you don't. Seriously. Just try it.
I've had some discussion with @Fox Is Openly Deceptive , and this test is a bit odd. It seems that Izaw had a fast fall somewhere just before the down air, and that may have effected his final position. My current running idea is that you can think of the jump arc as being discrete units of distance, a sort of "frame-length." This obviously varies between characters, fall speeds, and what not, but it IS just a hypothesis for now. Anyways, Falco may actually need that fast fall to align himself into a sort of "sub-frame" space between his normal existing frames where he can start actions. He needs a sub-frame that's closer to the ground than he is during his normal short hop arc.
What do you mean by the same effect? Falco's Dair did get changed in patch 1.0.8 where it hits grounded people differently, so there's one difference. If you mean full hop Dair and not getting a frame sync... then I don't know, except that Izaw does fast fall Dair I think the moment it's inputted.
I...think you're missing something here. In that gfy Greninja hits on frame 30 and lands on frame 35, nair's sweetspot would normally lag him for 9 frames. Nair>Shadow Sneak also can't combo normally. It is indeed a frame sync.
I think the hit sparks (the red/grey animation) obscure his landing time in that gify, so it's hard to pin down his exact land time. This is why I marked the frames for nair and fast fall and will replicate it at home. I think the slide after nair is what allowed the Nair>Shadow Sneak, not a potential frame sync. If he indeed was only in attacker hitlag for 5 frames and not 9, the jump should have happened faster. Or in the case of a late jump input, he should have come out of that landing lag crouch earlier.
I'll re-run it later today and return with more information.
What do you mean by the same effect? Falco's Dair did get changed in patch 1.0.8 where it hits grounded people differently, so there's one difference. If you mean full hop Dair and not getting a frame sync... then I don't know, except that Izaw does fast fall Dair I think the moment it's inputted.
When I said "the same effect" I meant that the frame setup described should have produced a frame sync. I also meant that the full hop dair DID get a frame sync, but I can't seem to replicate it on short hop. Izaw seems to fast fall the frame or two before the dair, then dairs to cancel the fast fall. This should move his landing position slightly. Potentially to a "sub-frame" position.
ZSS neutral air actually does have hurtbox change issues, I've commented on this before.
ZSS squats (bends her knees) as she comes to attack. This can affect the frame she can land, although I've never fully tested my assumption on this; I've thought before that if ZSS bent her knees just a little bit faster, then fast falling neutral air would have a much LARGER window to land with a hitbox just out, but at this stage it's really really small/finicky.
The hitbox of nair "moves" during frames (another hitbox property that may be apart of this) in a linear proportion (XYZ pos start, X/Y pos end options). This made me assume that for ZSS to neutral air landing sync not only does she need to be falling (or fast falling) at a specific point, the opponent themselves have to "move in" to her (one way or another, even an idle animation perhaps) to have it ever be possible to get the last frame hitting before landing; as otherwise it's near impossible to hit someone just before landing that wouldn't have hit them "earlier" than required.
OK. I've worked on this tonight, and here's what I have.
The potential Greninja frame sync was replicated within reasonable accuracy to the gif and the hitlag and landing lag were still distinct from each other. I believe the slide closed the gap necessary to allow Shadow Sneak to connect.
I confirmed ZSS' frame sync nair. By starting nair on frame 27 and fast falling on frame 29, she frame syncs.
I confirmed Falco's frame sync... in real time. This was, oddly enough, not yet reproducible in frame advance mode.
If anyone is willing to have that replay sent to them to record at 60 fps, please contact me. I would like to learn what frames my actions were taken on so that I may attempt to reproduce this in frame advance mode.
I believe I have evidence that shows your body must be in contact with the ground on the frame your hitbox appears in. Or, at the very least, your proximity to the ground must be very close.
Here's my hypothesis: your limb/hurtbox/ECB (environmental collision box) must connect with the ground on the same frame as your aerial produces a hitbox. This all must occur in the frame before you enter landing lag. These conditions are NOT always produced by simply timing your aerial's hitbox for come out on the last airborne frame. Case in point: Zero Suit Samus and her neutral air.
When appropriately timed, the picture in the spoiler tag below is produced by short hopping and executing neutral air so that its hitbox is produced on the frame before ZSS enters landing lag. For reference, this occurs when neutral air starts on frame 32 of the short hop. This does not frame sync.
**Note - cell phone pictures were necessary due to the inability to take screen shots during training mode.
Notice her foot position. It is off the ground. This can be affirmed again by noticing the separation of her foot's shadow and her foot itself.
The next figure is produced by short hopping, using neutral air on frame 27 and fast falling on frame 28. This framesyncs!
In this case, her foot is clearly touching touching the ground. It's even clipping into the ground to a small degree.
Unfortunately... even with this precision, and with her foot clearly clipping into the ground... this fails to work on shield. ZSS' short hop fast fall neutral air on shield... does not frame sync. (I haven't completely ruled this out yet, but by all present testing methods, it fails).
I ran this test with Falco too. Even though I could only produce the frame sync in real time, I still got the pictures I needed by pausing the replay.
Falco's first image is produced by timing his last hitbox to appear on the frame before landing. I have a least a page of frame combinations that produce this result (hence my frustration). This does not frame sync.
This next image was produced by practice in real time (and luck). It shows the frame Falco hits down air, just before it frame syncs. As that description implies, this does frame sync.
That's... inconclusive. The striking animation is in the way. This, however, is a recording and I was able to zoom. I could zoom so far in, it clipped into the platform itself, giving a nice view of Falco's foot, partway inside of Battlefield. It's small, but noticeable.
==============
==============
So, what is happening here? Why is it harder to get your feet lined up with some characters (Falco) than it is with others (Ganon, ZSS)? I believe it is because characters in this game move in quantized "frame lengths." A frame length is the distance you are moved during the game's minimum time span: one frame. Unlike the Planck length, which this is named after, Smash's frame lengths are not fixed. They vary based on your fall speed, run speed, etc.
My hypothesis is as follows: when short hopping, you pass through certain fixed frame positions. For some characters, such as Falco, this will effectively prevent frame syncing, since his feet will always be too far away from the ground on the frame before landing. Your frame position can be adjusted by fast falling before or after your aerial to move your future frame positions. The goal is to find a frame position that forces your body into the ground at the moment you hit your foe.
A poorly drawn example is below. Imagine your position passes through the thin blue lines as you perform a short hop left to right. That last right blue line is pretty far from the ground, and doesn't really work for frame syncing. If you fast fall partway through the short hop, your position changes to the blue diamonds. That last blue diamond is pretty close to the ground, and is potentially a candidate frame position for frame syncing.
Some characters have it easier, since their body movement helps... but do note, all movement stops on the frame you hit the opponent. Unlike the statement made in Izaw's original video, you cannot fast fall after you hit your foe to generate the frame sync effect.
Hypothetically, this should mean this is possible with most aerials (there's likely a weird exception somewhere). However, this is effectively a double frame perfect trick. The aerial must come out on the correct frame, and you must fast fall on the right frame. Some characters, such as Ganon and RED's footstool setup, will be luckier than others (FALCO).
Further research still applies!
I would like to recreate all known frame syncs (FAAALCOOOO, seriously if someone has recording capability, PM me)
Special moves have yet to be tested, though some anecdotes claim it works for some.
The above frame length hypothesis does not explain why this does not work on shield (except in the case of landing hitboxes). It must be improved, or another hypothesis should be proposed.
Research into more setups for guaranteed frame syncs would be great.
Feel free to ask questions, raise skeptical eyebrows, or present evidence of your own. I think more work still needs to be done to completely understand this, but this is a step in the right direction.
Do we know yet what causes certain moves to cancel momentum? Messing around with perfect pivoting reminded me that this is a thing, I'm not sure if there are parameters for this in our data dumps but at a glance I didn't see anything when comparing Lucina (slides)/Marth (comes to a halt) utilts in Master Core.
I just want to be lazy and look at numbers instead of testing more things zzz
This made me assume that for ZSS to neutral air landing sync not only does she need to be falling (or fast falling) at a specific point, the opponent themselves have to "move in" to her (one way or another, even an idle animation perhaps) to have it ever be possible to get the last frame hitting before landing
If I'm understanding you correctly (opponent shoves you into the ground during hitlag?), I had the same hypothesis back in Izaw's thread and someone shot it down saying those types of interactions shouldn't happen while airborne. Soon after that post I confirmed Ike could sync a tipper bair (no chance of collision nonsense there) so even if that is a thing it shouldn't be a necessary factor.
If I missed the mark there, it's possible to frame sync ZSS nair on an idle, non-animating opponent either way:
Shoutouts to whoever suggested having Mega Man hold an item for a dummy with no idle animations way back when (Reflex?).
The hurtbox shifting thing is a pretty real issue for some moves though I think, I haven't had any success with Falcon's uair because of how his body shifts upward on the first active frame. I don't know if that prevents it from being synced entirely as I never tried with the back end of it, but eh.
HOWEVER, while getting some footage for that I did notice something of interest - whenever I frame sync ZSS nair, she either lands the first frame after hitting or seven frames after hitting. 10 minutes of footage had no other variations.
What's happening with the second one exactly? (what is syncing and how?)
And I bet you it was a lot harder to do SIR~ (and Megaman being a completely straight standing character probably has it's benefits)
(It wasn't really harder but you're probably right about Mega Man's frame, I remember this being a lot harder when I tried it on Diddy way back when)
I'm...not sure what the difference is, honestly. At first I thought I just started my fastfall late but that doesn't seem to be the case, she's the same height off the ground on the hit frame in both.
Just looking at some random nair hits, she seems to jitter up and down for some amount of the hitlag. Maybe if she goes down initially she lands frame 1 and if she goes up it's frame 7 and it's just a dice roll as to which you get? Though in that case it doesn't make sense to me that she'd be landing frame 7 from that, the jittering's like a 4~5 frame thing...
How many frames after hitting the opponent is ZSS acting (in the optimal case)?
Is it still 13 frames later (what hit lag should be: 8.8 -> 13.2)? Is it 10 frames later? Megaman is experiencing 13 frames of hit lag still?
And time to test your skills; landing sync nair on shield
Was looking into earlier posts in this thread about the mechanic of shield lock frames being carried over if you're hit during the lock period. Just wanted to get some clarity on this post by Big O though:
The 11 frame lock isn't reduced by hitlag or shieldstun as far as I can tell. Basically, shieldstun is applied after the 11 frame minimum time is achieved and shieldhitlag extends this timer for as long as it lasts.
I'm also pretty sure it was like this in Brawl, but it didn't really matter because it added on like 3 extra frames tops.
So if shieldstun is applied after the 11 frame lock time, wouldn't this mean that the extra shield lock frames would effectively be like increasing shieldstun?
I'm just a bit confused because a few posts before this Big O said "you can still jump cancel/roll/shield grab at the same time as usual", which would imply that the lock frames would have to be applied after shieldstun since you are normally able to cancel it with oos options. But since you have to go through shieldstun before you can do anything oos, lock frames applied before shieldstun shouldn't be able to be cancelled with oos actions, and the extra frames should effect even actions that you don't have to drop shield for like grabbing/rolling/jumping.
Just wondering if this was a mistake, or if maybe I'm misunderstanding something
How many frames after hitting the opponent is ZSS acting (in the optimal case)?
Is it still 13 frames later (what hit lag should be: 8.8 -> 13.2)? Is it 10 frames later? Megaman is experiencing 13 frames of hit lag still?
And time to test your skills; landing sync nair on shield
Was looking into earlier posts in this thread about the mechanic of shield lock frames being carried over if you're hit during the lock period. Just wanted to get some clarity on this post by Big O though:
So if shieldstun is applied after the 11 frame lock time, wouldn't this mean that the extra shield lock frames would effectively be like increasing shieldstun?
I'm just a bit confused because a few posts before this Big O said "you can still jump cancel/roll/shield grab at the same time as usual", which would imply that the lock frames would have to be applied after shieldstun since you are normally able to cancel it with oos options. But since you have to go through shieldstun before you can do anything oos, lock frames applied before shieldstun shouldn't be able to be cancelled with oos actions, and the extra frames should effect even actions that you don't have to drop shield for like grabbing/rolling/jumping.
Just wondering if this was a mistake, or if maybe I'm misunderstanding something
The 11 frame minimum shield duration is separate from shieldstun and shieldhitlag and there is no overlap between the three. The timer for minimum shield duration stops during shieldhitlag and shieldstun, then resumes after shieldstun is over.
So if you don't powershield an attack the sequence goes like this: Start of minimum shield duration > X frames pass before hit > Shieldhitlag > Shieldstun > Resume minimum shield duration > Y frames pass before end of minimum duration > End (can let go of shield now). X + Y = 11.
I said it's applied after because it always finishes after everything else is done. In my oversimplification of the explanation (along with the "you can jump cancel/roll/shield grab at the same time as usual" part to make sure people understand it doesn't affect any shield cancelable OoS options), I guess that made it more confusing.
Do we have a comprehensive list of the differences between the Omega stages? Someone brought a Wario glitch to my attention that only seems to work on Omega Gaur Plain.
I did some testings on Frame Synchs back when Izaw made that thread. What I found was that most multi-hit aerials have a point where landing lag and hitlag frames can be synched. These are generally the easiest ones to do and thus are already well known [aka Bowser Jr / Fox dair, G&W bair etc]. I wanna say it should be possible with all multi-hit aerials but I didn't actually test it so I could be wrong.
Do we have a comprehensive list of the differences between the Omega stages? Someone brought a Wario glitch to my attention that only seems to work on Omega Gaur Plain.
I will investigate. Reminds me of what Brawl Wario affectionately called The Forbidden Technique in that a specific position causes the Bike to freak out and not know where to put you:
The Bike also does damage based on how quickly you're going relative to the normal speed, iirc. It appears to be hitting the edge while fully forward at a specific height. It's pretty hard, though, and it does seem to hurt more than normal.
I've gotten it at somewhat varied timings, and sometimes it launches Wario more forward than what happens in the video; the max damage I could get is 18%. I think the only thing that matters is being tilted at least somewhat downward while having the tire at a certain height at that edge. Seems to be specific to this stage.
I believe what's happening is that something about that spot on the ground wants Wario to move upward, as if he's on a hill (hence the upward motion). By holding forward, you're accelerating when you get to the ground, and I think it's allowing you to accelerate repeatedly, getting you to a speed you can't normally get to.
- F-Smash out of Dash. I think this was patched? You used to simply Dash and F-Smash the opposite way, much like F-Tilting?
- Shield as fast as possible out of a Dash. I just can't seem to get this, and end up running into things. It's as if it lags more out of a Dash...
It wasn't patched. You have to return the analog stick to neutral and quickly input whatever attack you wanna use in whatever direction. Running and shielding out of it is done similarly.
Ground movement is a commitment in this game, so you gotta be careful.
I did some testings on Frame Synchs back when Izaw made that thread. What I found was that most multi-hit aerials have a point where landing lag and hitlag frames can be synched. These are generally the easiest ones to do and thus are already well known [aka Bowser Jr / Fox dair, G&W bair etc]. I wanna say it should be possible with all multi-hit aerials but I didn't actually test it so I could be wrong.
All the moves you listed have landing hitboxes. Through the recent conversation and research, we've determined that all moves with landing hitboxes automatically frame sync. Uniquely, they all work on shield too. Granted, am those moves should still be tested, but the notion currently stands.
- F-Smash out of Dash. I think this was patched? You used to simply Dash and F-Smash the opposite way, much like F-Tilting?
- Shield as fast as possible out of a Dash. I just can't seem to get this, and end up running into things. It's as if it lags more out of a Dash...
re shield out of dash, you cannot let go of your dash direction before inputting shield, otherwise you'll get stuck in skid animation. hope that helps.
Do we have a comprehensive list of the differences between the Omega stages? Someone brought a Wario glitch to my attention that only seems to work on Omega Gaur Plain.
All the moves you listed have landing hitboxes. Through the recent conversation and research, we've determined that all moves with landing hitboxes automatically frame sync. Uniquely, they all work on shield too. Granted, am those moves should still be tested, but the notion currently stands.
Sorry, I didn't really read any of the other posts on this subject matter in detail [yet] so I might say stuff that's already been figured out but there are aerials without landing hitboxes that can synch frames still. So while it's easier to synch frames of a moves that has a landing hitbox the mere fact that they do have a landing hitbox is not what makes them 'synchable'.
My initial theory back when Izaw made the thread and I started looking into it was that in theory all aerials should be able to synch frames as long as you manage to get hitlag and landing lag to occur simultaneously. For moves that don't have a landing hitbox that means that you have a very small frame window but moves like ZSS nair and Falco dair don't have landing hitboxes and they are still known to synch if timed correctly. It may have something to do with how hitboxes are aligned too because it's easier to do with ZSS nair [which has a generous hitbox on its front and can be fastfalled into the ground during the move's startup frames] than with Falco dair [which is weird to time right because its hitbox is mainly vertical and has long startup]. I also remember doing it with the first and second hits of Yoshi bair, the timing for that was rather manageable in both cases.
Do we have a comprehensive list of the differences between the Omega stages? Someone brought a Wario glitch to my attention that only seems to work on Omega Gaur Plain.
- F-Smash out of Dash. I think this was patched? You used to simply Dash and F-Smash the opposite way, much like F-Tilting?
- Shield as fast as possible out of a Dash. I just can't seem to get this, and end up running into things. It's as if it lags more out of a Dash...
The 11 frame minimum shield duration is separate from shieldstun and shieldhitlag and there is no overlap between the three. The timer for minimum shield duration stops during shieldhitlag and shieldstun, then resumes after shieldstun is over.
So if you don't powershield an attack the sequence goes like this: Start of minimum shield duration > X frames pass before hit > Shieldhitlag > Shieldstun > Resume minimum shield duration > Y frames pass before end of minimum duration > End (can let go of shield now). X + Y = 11.
I said it's applied after because it always finishes after everything else is done. In my oversimplification of the explanation (along with the "you can jump cancel/roll/shield grab at the same time as usual" part to make sure people understand it doesn't affect any shield cancelable OoS options), I guess that made it more confusing.
Ahh, didn't think of it in the sense of stopping/starting a timer. This makes sense though, thanks for the explanation.
One more thing, do you know the maximum shield lock frames that can be carried over? Like if I hit someone on frame 4 of their shield, will frames "4-11" (8 frames) be added to shield drop or will it just be frames "5-11" (7 frames)? Similarly, if I hit someone on frame 11 of shield, will that last frame of shield lock still be added to shield drop or does it sort of overlap with the first frame of hitlag?
I just think this is a really interesting mechanic.
Can anyone direct me to data on dash-to-shield properties? I found initial dash speed, but I think there is a certain amount of time after a dash you can't shield that is also unique. I guess the first shieldable frame of dash, data, is what im looking for. Thanks!
Can anyone direct me to data on dash-to-shield properties? I found initial dash speed, but I think there is a certain amount of time after a dash you can't shield that is also unique. I guess the first shieldable frame of dash, data, is what im looking for. Thanks!
The 11 frame minimum shield duration is separate from shieldstun and shieldhitlag and there is no overlap between the three. The timer for minimum shield duration stops during shieldhitlag and shieldstun, then resumes after shieldstun is over.
So if you don't powershield an attack the sequence goes like this: Start of minimum shield duration > X frames pass before hit > Shieldhitlag > Shieldstun > Resume minimum shield duration > Y frames pass before end of minimum duration > End (can let go of shield now). X + Y = 11.
I said it's applied after because it always finishes after everything else is done. In my oversimplification of the explanation (along with the "you can jump cancel/roll/shield grab at the same time as usual" part to make sure people understand it doesn't affect any shield cancelable OoS options), I guess that made it more confusing.
So let me get this straight : if you shield right before getting hit but fail to PS the hit you will have to wait more time before dropping the shield than if you had put it up sooner ? Damn that's harsh.
I'd say its a mechanic designed to make shields at least a bit of a commitment.
If you want to see an example of how this effects safety of moves, there is some excellent ZSS analysis by Dr. Tuen
(its currently in his signature) on nair, D-smash, and paralyzer on shield where these few frames are actually critical.
Yea Tuen's ZSS shield advantage/disadvantage thread is how I originally found out about the mechanic.
Without this, powershielding would be all reward with no risk. Now that there's added risk in powershielding, I think it adds some more depth to the shield game by forcing players to be more careful in how they use it. Attackers have an added incentive to barely delay attacks on shield, enough to hit the earliest possible frames of shield lock and give them that much more shield advantage.
I think this will eventually become a big part of the meta, as adding up to 7/8 shield drop frames for missed powershields is pretty huge when it comes down to it.
