Input buffer: Difference between revisions

From Wavu Wiki, the 🌊 wavy Tekken wiki
No edit summary
m (Add system navbox)
 
(22 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The '''input buffer''' allows the player to send inputs when they can't act — such as during recovery or blockstun — and have the input act is if it were sent exactly on the first frame of them being able to act. This is what enables [[frame advantage]]s to play out in a consistent way, since both players are almost guaranteed to get frame perfect timing on their follow ups. For example, it allows -10 moves to be [[punish]]ed by i10 attacks without frame perfect inputs.
The '''input buffer''' allows players to send inputs when they can't act—such as during recovery or blockstun—and have the input act is if it were sent ''exactly'' when they can first act. This is what enables [[frame advantage]]s to play out in a consistent way, since both players are almost guaranteed to get frame perfect timing on their follow ups. For example, it allows -10 moves to be [[punish]]ed by i10 attacks without frame perfect inputs.
 
Although the buffer only exists for directional inputs that don't lead to stance and singular attack button combination press.


== Timing ==
== Timing ==
Line 12: Line 10:
|float=right
|float=right
|yellow=Active frame
|yellow=Active frame
|purple=Input buffer
|purple=Recovery (input buffer)
|teal=Recovery
|teal=Recovery
}}
}}
<div class="frame-table-set">
<div class="frame-table-set">
{{FrameTable|
{{FrameTable|
{{Frame|0|1}}
{{Frame|1|1}}
{{Frame|1}}
{{Frame|2}}
{{Frame|⋯}}
{{Frame|⋯}}
{{Frame|9}}
{{Frame|9}}
Line 24: Line 22:
{{Frame|11||teal}}
{{Frame|11||teal}}
{{Frame|⋯||teal}}
{{Frame|⋯||teal}}
{{Frame|18||teal}}
{{Frame|19||teal}}
{{Frame|19||purple}}
{{Frame|20||purple}}
{{Frame|20||purple}}
{{Frame|21||purple}}
{{Frame|21||purple}}
Line 33: Line 30:
{{Frame|25||purple}}
{{Frame|25||purple}}
{{Frame|26||purple}}
{{Frame|26||purple}}
{{Frame|27|1}}
{{Frame|27||purple}}
{{Frame|28}}
{{Frame|28|1}}
{{Frame|⋯}}
{{Frame|⋯}}
{{Frame|36}}
{{Frame|36}}
Line 41: Line 38:
}}
}}
{{FrameTable|
{{FrameTable|
{{Frame|0|1}}
{{Frame|1|1}}
{{Frame|1}}
{{Frame|2}}
{{Frame|⋯}}
{{Frame|⋯}}
{{Frame|9}}
{{Frame|9}}
Line 48: Line 45:
{{Frame|11||teal}}
{{Frame|11||teal}}
{{Frame|⋯||teal}}
{{Frame|⋯||teal}}
{{Frame|18||teal}}
{{Frame|19||teal}}
{{Frame|19|1|purple}}
{{Frame|20|1|purple}}
{{Frame|20||purple}}
{{Frame|21||purple}}
{{Frame|21||purple}}
{{Frame|22||purple}}
{{Frame|22||purple}}
Line 57: Line 53:
{{Frame|25||purple}}
{{Frame|25||purple}}
{{Frame|26||purple}}
{{Frame|26||purple}}
{{Frame|27}}
{{Frame|27||purple}}
{{Frame|28}}
{{Frame|28}}
{{Frame|⋯}}
{{Frame|⋯}}
Line 68: Line 64:
=== Motion inputs ===
=== Motion inputs ===


Non-stance motion inputs can be buffered. For these, the 8 frame window is only concerned with the ''last'' input in the sequence, with the timing window of the motion input itself independent of the input buffer.  
Some motion inputs can be buffered. For these, the 8 frame window is only concerned with the ''last'' input in the sequence, with the timing window of the motion input itself independent of the input buffer.  


For example, [[Kazumi]]'s b,n,f+2 can at most be input in 15 frames:
For example, [[Kazumi]]'s b,n,f+2 can at most be input in 15 frames:


{{FrameTable|
{{FrameTable|
{{Frame|0|b}}
{{Frame|1|b}}
{{Frame|1}}
{{Frame|2}}
{{Frame}}
{{Frame}}
{{Frame|14|f2}}
{{Frame|14}}
{{Frame|15}}
{{Frame|15|f2}}
{{Frame|16}}
{{Frame}}
{{Frame}}
{{Frame|28}}
{{Frame|28}}
Line 85: Line 82:
}}
}}


So the b can be “buffered” for up to 22 frames:
So the b can be “buffered” (i.e. input before having recovered) for up to 22 frames if the f+2 is also input in the first frame of the buffer:


{{FrameTable|
{{FrameTable|
{{Frame|0|1}}
{{Frame|1|n1}}
{{Frame|1}}
{{Frame|2}}
{{Frame|2}}
{{Frame|3}}
{{Frame|3}}
{{Frame|4}}
{{Frame|4}}
{{Frame|5|b}}
{{Frame|5}}
{{Frame|6}}
{{Frame|6|b}}
{{Frame|7}}
{{Frame|7}}
{{Frame|8}}
{{Frame|8}}
Line 101: Line 97:
{{Frame|11||teal}}
{{Frame|11||teal}}
{{Frame|⋯||teal}}
{{Frame|⋯||teal}}
{{Frame|18||teal}}
{{Frame|19||teal}}
{{Frame|19|f2|purple}}
{{Frame|20|f2|purple}}
{{Frame|20||purple}}
{{Frame|21||purple}}
{{Frame|21||purple}}
{{Frame|22||purple}}
{{Frame|22||purple}}
Line 110: Line 105:
{{Frame|25||purple}}
{{Frame|25||purple}}
{{Frame|26||purple}}
{{Frame|26||purple}}
{{Frame|27}}
{{Frame|27||purple}}
{{Frame|28}}
{{Frame|28}}
{{Frame|⋯}}
{{Frame|⋯}}
Line 123: Line 118:
As a general rule, moves that aren't bufferable are those which come out of a stance. If you aren't in that stance while recovering, you can't buffer the moves for that stance. In addition, for most stances entered by motion inputs, entering the stance also can't be buffered.
As a general rule, moves that aren't bufferable are those which come out of a stance. If you aren't in that stance while recovering, you can't buffer the moves for that stance. In addition, for most stances entered by motion inputs, entering the stance also can't be buffered.


For the generic dash stance entered by f,f, the first f can be buffered, but the second cannot. This obeys the rules for motion inputs as above, so it can be “buffered” for up to 20 frames, as that's the biggest gap between the two f's that is normally permitted.
Moves with one input immediately after the other, e.g. [[Yoshimitsu]]'s 3~4, usually can't be fully buffered as they're technically a cancel. You can't cancel a move you haven't started yet.
 
A move not being bufferable means that it can't easily be used as a punisher, follow up, counter-attack, or in combos, since getting the move out may require near frame perfect timing.
 
=== Dash attacks ===
 
For the generic dash [[stance]] entered by f,f, the first f can be buffered, but the second cannot. This obeys the rules for motion inputs as above, so the first f can be buffered for up to 20 frames, as that's the biggest gap that's normally permitted.
 
Dash attacks require the second f to be held for at least one frame before pressing the attack button, so it takes a minimum of 2 frames to input such a move from a bufferable situation, i.e. adding 1 frame for the input. For example, [[Lidia]]'s f,F+2 is i13, but it can only at best punish a -14 move:
 
{{Legend
|float=right
|yellow=Active frame
|teal=Recovery
}}
{{FrameTable|
{{Frame|1|f|teal}}
{{Frame|2||teal}}
{{Frame|||teal}}
{{Frame|20||teal}}
{{Frame|1|f}}
{{Frame|2|f2}}
{{Frame|3}}
{{Frame}}
{{Frame|13}}
{{Frame|14||yellow}}
{{Frame|15||teal}}
}}


A move not being bufferable means that it can't be easily used as a punisher, follow up, counter-attack, or in combos, since getting the move out may require near frame perfect timing.
{{Navbox system}}

Latest revision as of 15:00, 8 June 2024

The input buffer allows players to send inputs when they can't act—such as during recovery or blockstun—and have the input act is if it were sent exactly when they can first act. This is what enables frame advantages to play out in a consistent way, since both players are almost guaranteed to get frame perfect timing on their follow ups. For example, it allows -10 moves to be punished by i10 attacks without frame perfect inputs.

Timing

The input buffer is 8 frames long. This gives an effective 9 frame window to input a frame perfect link.

For example, the following inputs both do a generic 1 jab twice in a row as quickly as possible:

Active frame
Recovery
Recovery (input buffer)
Frame
Input
State
1
1
2
9
10
11
19
20
21
22
23
24
25
26
27
28
1
36
37
38
Frame
Input
State
1
1
2
9
10
11
19
20
1
21
22
23
24
25
26
27
28
36
37
38

Motion inputs

Some motion inputs can be buffered. For these, the 8 frame window is only concerned with the last input in the sequence, with the timing window of the motion input itself independent of the input buffer.

For example, Kazumi's b,n,f+2 can at most be input in 15 frames:

Frame
Input
State
1
b
2
14
15
f2
16
28
29
30
31

So the b can be “buffered” (i.e. input before having recovered) for up to 22 frames if the f+2 is also input in the first frame of the buffer:

Frame
Input
State
1
n1
2
3
4
5
6
b
7
8
9
10
11
19
20
f2
21
22
23
24
25
26
27
28
41
42
43
44

Unbufferable moves

As a general rule, moves that aren't bufferable are those which come out of a stance. If you aren't in that stance while recovering, you can't buffer the moves for that stance. In addition, for most stances entered by motion inputs, entering the stance also can't be buffered.

Moves with one input immediately after the other, e.g. Yoshimitsu's 3~4, usually can't be fully buffered as they're technically a cancel. You can't cancel a move you haven't started yet.

A move not being bufferable means that it can't easily be used as a punisher, follow up, counter-attack, or in combos, since getting the move out may require near frame perfect timing.

Dash attacks

For the generic dash stance entered by f,f, the first f can be buffered, but the second cannot. This obeys the rules for motion inputs as above, so the first f can be buffered for up to 20 frames, as that's the biggest gap that's normally permitted.

Dash attacks require the second f to be held for at least one frame before pressing the attack button, so it takes a minimum of 2 frames to input such a move from a bufferable situation, i.e. adding 1 frame for the input. For example, Lidia's f,F+2 is i13, but it can only at best punish a -14 move:

Active frame
Recovery
Frame
Input
State
1
f
2
20
1
f
2
f2
3
13
14
15