Talk:Notation: Difference between revisions

Discussion page of Notation
Line 69: Line 69:
The current approach with spaces and commas is a part of the overall goal of the notation to have strings read like words. By doing this, a combo with standardised notation is extremely quick to read, because you can quickly identify the strings/moves (words) in the combo (sentence).
The current approach with spaces and commas is a part of the overall goal of the notation to have strings read like words. By doing this, a combo with standardised notation is extremely quick to read, because you can quickly identify the strings/moves (words) in the combo (sentence).


However, stances kind of throw a wrench in this idea, because they're really a part of the "word", but there's a space between it and the input. This causes people to want to use commas in combos which have a lot of stances moves in them, compare e.g.
However, stances kind of throw a wrench in this idea, because they're really a part of the "word", but there's a space between it and the input. This causes people to want to use commas in combos which have a lot of stances moves in them, compare:


# WS 4 1 f,F+4 RFF 3,4 RFS b+4 S! RFF f+3 LFS b+3
(Example Hwoarang combo)
# WS 4, 1, f,F+4, RFF 3,4, RFS b+4 S!, RFF f+3, LFS b+3


# WS 4,4 S! f+3+4 RSS 2 d/f+1 f+3,F RSS 3+4
* WS 4 1 f,F+4 RFF 3,4 RFS b+4 S! RFF f+3 LFS b+3
# WS 4,4 S!, f+3+4, RSS 2, d/f+1, f+3,F, RSS 3+4
* WS 4, 1, f,F+4, RFF 3,4, RFS b+4 S!, RFF f+3, LFS b+3
 
(Example Kazumi combo)
 
* WS 4,4 S! f+3+4 RSS 2 d/f+1 f+3,F RSS 3+4
* WS 4,4 S!, f+3+4, RSS 2, d/f+1, f+3,F, RSS 3+4


Because of the spaces between the stance and input, option 1 doesn't read that well. People naturally try and resolve this by either getting rid of the space (e.g. writing WS 4 as ws4) or by adding commas. But adding commas just makes things worse, because now commas are being used for two different grammatical purposes (separating moves within strings, and separating whole moves from other parts of the syntax) and with unclear rules (should there be a comma before/after the S!?, or before/after a move that transitions to the stance?). Writing WS 4 as ws4 can work sometimes, but this doesn't look good for a lot of stances (particularly if the last letter has a riser, e.g. rff3,4 looks a bit funky) or if there's also a directional input (e.g. you can't write lfsb+3 or LFSb+3)
Because of the spaces between the stance and input, option 1 doesn't read that well. People naturally try and resolve this by either getting rid of the space (e.g. writing WS 4 as ws4) or by adding commas. But adding commas just makes things worse, because now commas are being used for two different grammatical purposes (separating moves within strings, and separating whole moves from other parts of the syntax) and with unclear rules (should there be a comma before/after the S!?, or before/after a move that transitions to the stance?). Writing WS 4 as ws4 can work sometimes, but this doesn't look good for a lot of stances (particularly if the last letter has a riser, e.g. rff3,4 looks a bit funky) or if there's also a directional input (e.g. you can't write lfsb+3 or LFSb+3)

Revision as of 09:53, 18 January 2021

Notation based on user preferences

It's been suggested that we display different notation based on user preference. This could be implemented by using a template whenever notation is used, e.g. instead of "d/f+1,1+2" we would write:

{{Notation
|text=d/f+1,1+2
|ironfist=df11+2
|numpad=3LP,LP+RP
}}

Reasons not to do this:

  1. Makes it harder for people to contribute, because that's a lot more to write every time you wanna write any notation.
  2. Would put a massive burden on bureaucrats to make sure these are always done right and the notations all mean the same thing. (Imagine if someone wrote the above but wrote numpad=3LP,RP instead. That error can only get detected by someone looking at the code.)
  3. There isn't always a substitute in ironfist / numpad.
  4. Prevents us from making up useful new notation since it won't have a mapping in ironfist / numpad.
  5. For out-of-wiki communication, it'd be a lot easier if everyone is already used to the same thing.

These are heavy costs to pay, so we are currently not interested in doing this. RogerDodger (talk) 06:51, 18 January 2021 (UTC)

Combo annotations

R! — Never seen a person use that, while it is probably important for some characters, most have just one Rage Drive and one Rage Art, even with characters that do have multiple, they tend to also use just the name of the move, or it is obvious which one is used (e.g. Deadly Rave), also both when writing combos and writing articles it's generally more readable to write 'RD' or fully 'Rage Drive' than 'R! f+2+3'

The reason to avoid this is to be explicit about inputs as much as possible. For someone new to a character, telling them to use the rage art or rage drive is indirect: They'd have to then lookup the movelist to know how to do that move. Aside from this, it's confusing for characters with multiple rage drives, e.g. some Steve texts right now says to use "RD2" -- well, which is that? It's confusing. RogerDodger (talk) 06:41, 18 January 2021 (UTC)

W! as wall bounce — There is no common way to define wall bounces, but I do argue against using wall splats for wall bounce as well, because they are different, mechanically and visually they are very different, there is also an incentive not to create confusion like "Why is that wall combo not working, oh, because it's wall bounce combo" or similar. I propose Wb!

In what situation would this confusion occur? If it's used before a move that wall bounces, then it's obviously a wall bounce. Even if this is not apparent to the reader immediately (because they don't know that the move wall bounces), it'll be immediately apparent to them (a) when they try the combo (b) because the combo is naturally going to have another W! after it. For example, if you see the combo b+3+4 W! 4,3,4 W! 4,u+3 f+4,3 d+3 without any context, you can already tell that b+3+4 is wall bouncing, because how else was there another W!? A disambiguiating notation like !Wb creates unnecessary knowledge burden on readers and writers, who'll have to remember the difference between !WB and !Wb, on top of being longer. This is distinct from the above issue of R! vs RA and RD, in which we want to be explicit about inputs (which are never obvious without instruction), because this is about an outcome, which will be obvious to the reader (following the other, explicit instructions) eventually. RogerDodger (talk) 06:41, 18 January 2021 (UTC)

F! — F! is a meme, but also it's inconsistent with other breaks, WB! BB! F!

All else equal, the priority is for the shortest notation possible. WB! and BB! would be W! and B! if they could be, but W! is used already (and not clear without context, so disambiguation useful in this case), and B! isn't used for Tekken 7 but is used for bound in Tekken 6, so still better to avoid. Not sure what meme you're referring to. RogerDodger (talk) 06:41, 18 January 2021 (UTC)

cc! — Crouch cancel is an action a player does, but '!' exclamation mark asserts it's the result of the last action

I can see this being confusing. My idea with the '!' is that it indicates something non-essential (i.e., just a helpful tip). But the cc is essential, so it might be more sensible to put this (and other things like "dash", and "iws") into another section called "Techniques". RogerDodger (talk) 06:41, 18 January 2021 (UTC)

iws — Instant ws is a common thing specifically in combos, and it isn't anywhere else on the page.

The reason I think this notation should be avoided is that iWS describes a broad range of different techniques. So on its own it's not clear which technique to use, and thus not useful notation. If the combo says e.g. W! ws4 d/f+1,4 1+2 (Kazuya wall staple), this is sufficient notation for anyone who knows the crouch dash iWS technique - it's implied - and both "ws" and "iws" are totally useless to someone who doesn't, or only knows about the universal iWS method. The way this is handled in Lee combos is to explicitly tell the reader about this character's iWS technique at the top of § Staples (and/or wherever relevant), and then have it implied to be used from there. Essentially, passing the buck on where to be explicit. RogerDodger (talk) 06:41, 18 January 2021 (UTC)

Held input * — T7Chicken uses "*", RBNorway and thus Tekken bot uses "*", lots of different games use "*", Geppo just uses Hold.

The TZ legend says to use °, but that's obviously a bad idea because most keyboards don't have that symbol. If T7Chicken and RBnorway use "*", and there's no other widely used prior notation, then yeah we should use that here as well. I'm not aware of RBnorway using this however. The lee page for example lists "1, 2, 4 (Hold long as possible)". Even still, if T7Chicken uses "*", that should also be sufficient precedent. (There's also a comment on that Lee page saying that "*" is for holds.) RogerDodger (talk) 06:49, 18 January 2021 (UTC)

Overloaded "just frame" symbol

The ":" symbol currently has two meanings.

  1. "Pressed on the same frame", replacing a "+", e.g. f,n,d,d/f:2 (Electric)
  2. "Tight input window", replacing a ",", e.g. 1,3:3:3 (Acid Rain)

This seems to be okay, since there isn't to my knowledge any case where this is ambiguous. It would have to be a direction followed by a button on its own, where the ":" is replacing "," and not "+", e.g. something like f,F:2 meaning "f, then F, then (2 with tight input window)", but I'm not aware of any such moves.

Nonetheless, this is pretty confusing, and it might be better if one of these usages were instead given another symbol. Suggested candidates for this are:

  • Use "#" when replacing "+" (since it looks similar to a plus) e.g. f,n,d,d/f#2 (Electric)
  • Use ";" when replacing "," (since it has a "," in it) e.g. 1,3;3;3 (Acid Rain)

Between the two, my preference is to use "#", since ":" to replace "," is the more common current usage.

RogerDodger (talk) 07:09, 18 January 2021 (UTC)

Spaces, commas, and stances

The current approach with spaces and commas is a part of the overall goal of the notation to have strings read like words. By doing this, a combo with standardised notation is extremely quick to read, because you can quickly identify the strings/moves (words) in the combo (sentence).

However, stances kind of throw a wrench in this idea, because they're really a part of the "word", but there's a space between it and the input. This causes people to want to use commas in combos which have a lot of stances moves in them, compare:

(Example Hwoarang combo)

  • WS 4 1 f,F+4 RFF 3,4 RFS b+4 S! RFF f+3 LFS b+3
  • WS 4, 1, f,F+4, RFF 3,4, RFS b+4 S!, RFF f+3, LFS b+3

(Example Kazumi combo)

  • WS 4,4 S! f+3+4 RSS 2 d/f+1 f+3,F RSS 3+4
  • WS 4,4 S!, f+3+4, RSS 2, d/f+1, f+3,F, RSS 3+4

Because of the spaces between the stance and input, option 1 doesn't read that well. People naturally try and resolve this by either getting rid of the space (e.g. writing WS 4 as ws4) or by adding commas. But adding commas just makes things worse, because now commas are being used for two different grammatical purposes (separating moves within strings, and separating whole moves from other parts of the syntax) and with unclear rules (should there be a comma before/after the S!?, or before/after a move that transitions to the stance?). Writing WS 4 as ws4 can work sometimes, but this doesn't look good for a lot of stances (particularly if the last letter has a riser, e.g. rff3,4 looks a bit funky) or if there's also a directional input (e.g. you can't write lfsb+3 or LFSb+3)

My proposition to resolve this is to introduce the notation "." to mean "from stance", e.g. RSS.1 means "1 from RSS". The above combos would then be written:

  • WS.4 1 f,F+4 RFF.3,4 RFS.b+4 S! RFF.f+3 LFS.b+3
  • WS.4,4 S! f+3+4 RSS.2 d/f+1 f+3,F RSS.3+4

This is a significant change to notation with no prior use, but one I think would dramatically improve the readability of combos and notation in general. Because of how significant the change is, it shouldn't be done without overwhelming consensus. RogerDodger (talk) 07:41, 18 January 2021 (UTC)