God, can you believe it's almost been three years since I originally wrote this? Anyway, the question about buffering in reversals made me think some people out there might benefit from a repeat of this. Note: This was written for VF3, so some of the discussion (buffering in a move at the beginning of a round - cancelling an escape with an attack - reversing Lion's u+pk with a b+pk - execution of attacks) is out of date. Still, the basic principles as to timing of reversals should be sound. -Jason Subject Reversal Timing Posted by Jason Cha (stranger) Posted on 1999/11/01 22:04 Somebody posted a question a while ago about reversal timing, but I don't believe I saw it addressed. So here goes. Timing wise, if you can block the move, you can reverse it. I can think of no case where a move must be blocked, if it can be reversed. Technically the timing for reversals is simple -- the reversal must be inputted during the execution time of your opponent's move. But in practice, because you can buffer in a reversal like any other move, there are two distinct timing requirements for reversals, depending on whether or not you are in rigor/recovery/block stun/etc., of some sort. To bottom line it, timing reversals when you are not in recovery, when your character is capable of attacking is quite difficult, and in general, random reversals like that are pretty ineffective. Timing reversals while your character is in recovery of some sort, is really easy, and is where reversals are really supposed to be done. This is probably why most beginners think reversals are so damn hard, while most experienced players have no problem at all reversing. Let me give you an example, the first from my many matches against Rich's Kage. Akira versus Kage -- Kage elbow (f+p), Akira blocks Akira counterattacks with punch (p), Kage reverses (b+pk) This is a classic flowchart option used by Rich's Kage. In this circumstance, Rich actually has a 19 frame window during which to input his reversal. The first 9 frames comes from the obvious 9 frame execution time of Akira's punch. But the additional 10 frames comes from the 10 frame window (footnote 1) during which Kage can input the reversal while his elbow is recovering. So let's look at the three factors which make it so easy to successfully reverse in this situation: 1) Kage knows Akira's going to Punch. This is simple Yomi, and you'd be surprised at how many intermediate players automatically react to a blocked elbow by punching. 2) Kage knows WHEN Akira's going to Punch. Experienced players know how to buffer in moves, and chances are that Akira's punch is going to come out cleanly after Akira's block stun time has elapsed. 3) Because Kage is in recovery from his elbow, he has a 19 frame (1/3rd of second) window during which to input the reversal. 1/3 of a second might not sound that big to some of you, but this window is HUGE, especially as you, Kage are in control of the timing because you just initiated this entire sequence by elbowing. Now contrast this to another instance... Lion versus Kage... Beginning of the Round Lion -- e, u+pk Kage -- (pause) b+pk Unless the Kage is quite accustomed to reversing in this situation, he will not likely be able to reverse the u+pk. Most of the time, I think, the reversal will come out too early, and Kage will be smacked as he begins his reversal wiff animation. Kage knows that Lion likes to begin the round with escape and u+pk. So anticipating it, Kage attempts to pause a moment at the beginning of the round, and reverse Lion's quick hoppity uppercut like move. But the timing in this circumstance is much more difficult than in the previous example. Kage only has a 12 frame window, the execution time of the u+pk, during which to reverse the move. Because Kage is not in recovery of some sort, if he executes the reversal even one frame before Lion does his u+pk, Kage will go through the wiff'd reversal animation and the reversal will not work. The extra 10 frames afforded by buffering a reversal into a block stun/move recovery time/etc., are not applicable in this case simply because Kage is not in rigor of any sort and is free to execute any move at that exact time. So again, let's look at the 3 factors. 1) Kage knows Lion's going to escape, u+pk. This is a quick and easy opening for Lion, and I've been known to abuse it. 2) Kage only has a fair idea of when Lion's going to u+pk. That is because of two reasons. 1) You cannot buffer in moves before the round starts, (footnote 2) so Lion cannot easily input the dodge cleanly at the beginning of the round. Likely, it will come 3-5 frames after the beginning of the round. Also 2) most players do not have an intuitive feel of exactly when a move can interrupt a dodge. Sure because the move can be buffered in we can learn to guage exactly how long it takes a move to come out of a dodge, but this isn't as easy for em as expecting when my opponent's move will come out after block stun. 3) Kage only has a 12 frame window during which to input the reversal. If he inputs it one frame too early, wiff animation will come out. Now this is a situation where Kage at least has a fair idea of when the move will come out (#2). And it is quite difficult for him to successfully reverse. So do you see why if you randomly try to reverse a move in a situation where you don't even have #2 (such as my opponent loves to SDE, so I'll try to d/b+pk randomly hoping it works) you're prolly going to eat a lot of moves? Sure you'll reverse a few, but I doubt this strategy will really help you. And because most beginners will try reversing randomly and end up with a low percentage of successful reversals, they are lead to believe reversals are hard, or not worth it. But I think it's clear that where you have all 3 advantages, yomi of move, clean knowledge of timing, and a buffer window, you can easily reverse. -Jason ---------- Footnote 1: Don't ask me to prove or say exactly where this 10 frame window number comes from. It may not actually be 10 frames, it's not like Sega tells us these things. It seems right for now. Footnote 2: If there is a buffer window before the round starts, it seems to be very small. I actually would doubt that this exists at all, except that I have executed a SDE with Akira at the beginning of the round, with the debug input data on, and the data on the screen only showed two forward inputs. This would imply that the first foward input was somehow buffered in before the round starts. But somehow I doubt it. If there is a buffer window, I think its likely only 1 frame. It is definately not 10 frames.