Q&A Official FAQ and QnA Thread - Ask Your Questions Here!

[Bones0]

I'm looking for information on stages.

General stuff about all the stages, at which percentage you would kill certain characters and which character should pick/ban which stage.
Does something like that exist?

Nothing like that exists. KO percentages are dependent on the opposing character, their percent, how stale your move is, where you are on the stage, and how well they DI. You can test general KO percents in Training Mode, but human opponents will usually live longer so you should only use that as a general guideline.

Which stages you should strike/ban aren't set in stone. The stages you will want to choose are going to be based off of your style, your general skill level, how your style interacts with the opponent's, and many other factors. Even top players with highly refined games show a large amount of flexibility in determining stages. When you're first starting out, you will likely be changing your opinion about the stages constantly, which is honestly way better than getting stuck in a mentality of "this stage is unplayable for my character or in a certain matchup". Many people go their entire Smash careers auto-banning a stage that might actually be in their favor if they didn't assume it was bad from the get-go.

New to competitive play, any videos I should absolutely watch?

The Smash Brothers (documentary)

 

[PunkAaron]

The Smash Brothers (documentary)

Seen it already, very good series. Maybe I'm not entirely new. I just need tips on tech/how to brush up on skills.

 

[Tarv]

Does anyone know the set counts between the top 5? Trying to remember all the times they faced each other in tournament is proving to be difficult. I think juggleguy may have made a somewhat recent comment about these statistics but I don't know where that was or from when he was gathering that information.

Thanks

 

[SAUS]

Seen it already, very good series. Maybe I'm not entirely new. I just need tips on tech/how to brush up on skills.

https://www.youtube.com/watch?v=vckV2MJgBzo

My questions about crew battles still stand. Is there a set of rules somewhere that is the standard?

 

[Bones0]

https://www.youtube.com/watch?v=vckV2MJgBzo

My questions about crew battles still stand. Is there a set of rules somewhere that is the standard?

There is no standard. Here is what I would recommend:

- If applicable, draft crews in 1-2-1-1-1... fashion.
- Each crew must write down the first player that will go in and the chosen character for all of the crew members.
- Strike for the first stage.
- The crew that lost the previous match sends in their next player.
- After the incoming player selects a character, the opponent bans 1 stage.
- If a game reaches time, the player with the most stocks wins, and his opponent's stock count is subtracted from the next game. If the game goes to time and you have 3 stocks while your opponent has 1, you start the next game with 2 stocks. If the stock count is tied, both players are eliminated. To prevent stalling at the beginning, the match must start within 30 seconds (or you could set the timer to 9 minutes and start at the 8-minute mark).

If you do not want to keep all players character locked, then use this rule:
- After the incoming player chooses a character, the opponent can choose to ban 1 stage OR change their character.

This rule makes it so you can switch characters, but your opponent will be able to choose their best counterpick vs. that character.

 

[SAUS]

There is no standard. Here is what I would recommend:

- If applicable, draft crews in 1-2-1-1-1... fashion.
- Each crew must write down the first player that will go in and the chosen character for all of the crew members.
- Strike for the first stage.
- The crew that lost the previous match sends in their next player.
- After the incoming player selects a character, the opponent bans 1 stage.
- If a game reaches time, the player with the most stocks wins, and his opponent's stock count is subtracted from the next game. If the game goes to time and you have 3 stocks while your opponent has 1, you start the next game with 2 stocks. If the stock count is tied, both players are eliminated. To prevent stalling at the beginning, the match must start within 30 seconds (or you could set the timer to 9 minutes and start at the 8-minute mark).

If you do not want to keep all players character locked, then use this rule:
- After the incoming player chooses a character, the opponent can choose to ban 1 stage OR change their character.

This rule makes it so you can switch characters, but your opponent will be able to choose their best counterpick vs. that character.

I like that counterpick rule. As for timing out, we just turn off the timer. I will run this by my friends to see what they think. Thanks!

 

[Bones0]

I like that counterpick rule. As for timing out, we just turn off the timer. I will run this by my friends to see what they think. Thanks!

If you don't think anyone is going to excessively stall, then yeah, removing the timer is fine. I just include it as a precaution against the 1 in 100 times someone decides to stall in a crew battle.

 

[N9TMARE]

where/how can i learn all the terminology to metagame smash? i've been on this forum a while and i have never seen definitions to any of the terms frequently used. here are examples:
randel
dair, nair etc

 

[Ecoh]

*snip*

Pretty much any character guide has a frequently used terms list, I'd say find one for the character you frequent. In any case, d- n- u- f- b- is down neutral, up, forward, and back in that order. It can be attached to aerials or smashes. e.g. bair, dsmash.

My suggestion would be to check out a few guides.

 

[Bones0]

where/how can i learn all the terminology to metagame smash? i've been on this forum a while and i have never seen definitions to any of the terms frequently used. here are examples:
randel
dair, nair etc

How this thread got unpinned is beyond me, but it should answer all of your questions and then some:

http://smashboards.com/threads/the-...e-basics-how-to-improve-frame-data-etc.97603/

Also, just for quick answers, "Randall" is the name of the cloud platform on Yoshi's Story. Fair, dair, bair, uair, and nair stand for all of the aerials (forward, down, up, and neutral). This same thing applies to smash attacks (fsmash = forward smash) and tilts (dtilt = down tilt).

 

[mixa]

[...] There was an AMAZING day[9] daily about this very subject [...]

FOUND IT, **** YEAH! There are 4 parts.

[collapse=Part 1]

[/collapse]

[collapse=Part 2]

[/collapse]

[collapse=Part 3]

[/collapse]

[collapse=Part 4]

[/collapse]

good post. good links. very interesting. i had heard about this day[9] guy but his youtube has just too much stuff. can't really browse that.
do you know of any other talks, videos, analyses, stuff (i guess books too though i'm reading those already), that deal with the competitive mindset? other (fighting) game communities are larger so it wouldn't be surprising to find good content.
i remember seeing an extensive video on what to look for in videos/how to learn from them (applied to SF). have anyone seen that?

 

[Bones0]

good post. good links. very interesting. i had heard about this day[9] guy but his youtube has just too much stuff. can't really browse that.
do you know of any other talks, videos, analyses, stuff (i guess books too though i'm reading those already), that deal with the competitive mindset? other (fighting) game communities are larger so it wouldn't be surprising to find good content.
i remember seeing an extensive video on what to look for in videos/how to learn from them (applied to SF). have anyone seen that?

I don't know of any others off the top of my head, but I definitely remember seeing a vlog from an old SF pro who talked about his early days. I looked for like 10 minutes on YouTube but can't find it. I just don't remember his name.

 

[mixa]

gif of Unknown522 teching a Fox down smash near the ledge.

so is this just your regular smash DI towards the stage + walltech?

 

[Bones0]

gif of Unknown522 teching a Fox down smash near the ledge.

so is this just your regular smash DI towards the stage + walltech?

Yeah. You can watch the GIF frame by frame in case you didn't realize. lol

 

[d z]

What frame does the game look for your joystick position to determine whether you get a backwards or forwards sh/hf (I'm guessing last frame of jump squat)?

 

[tauKhan]

Pick bowser, go in to 1/4 slow motion and test. You can probably figure out whether pressing right and releasing stick has you jump right or not.

Edit bowser is bad for that lol, hes back jump is difficult to notice. I tested with falco with pausing and 1/4 time, and it seems, that only last frame of jump squat matters. You can definitely jump, hold right, release stick and hop upwards.

 

[SAUS]

What frame does the game look for your joystick position to determine whether you get a backwards or forwards sh/hf (I'm guessing last frame of jump squat)?

I believe it is the first frame you go into the air that it checks (which is the first frame after jump squat ends).

 

[Bones0]

I believe it is the first frame you go into the air that it checks (which is the first frame after jump squat ends).

The game has to check your stick's position on the last frame of jumpsquat in order for it to know what to display on the first airborne frame.

 

[d z]

Im not sure thats the case. Input has to be the first part of the gameloop otherwise how could shines come out on the same frame they are entered?

 

[tauKhan]

The game has to check your stick's position on the last frame of jumpsquat in order for it to know what to display on the first airborne frame.

This depends on your point of view as this is philosophical question. The gamecube calculates the game at 60 fps, but it takes time for what is inputted by the players to happen on the screen. So where should we think that the game time actually runs? Your view point and mine until this last hour seems to be that the game time moves to next frame when the console has calculated what happened on that frame. This is a natural way to look at how the game flows. However, you might as well define the game time as being the same as what is shown on the screen, or as the time the console has processed the output signal.

I think our perspective is stupid in a sense: By that logic you must input your jump one frame before you jump. This is why I think it's most sensible to think that the game time is the same as the time you input actions divided into time intervals.

It doesn't actually matter what perspective you have, but when we are talking about input windows and framedata, it's necessary that we have same perspective and that we don't confuse it. I have made some errors in framedata calculating due to this. For example, when I first read your post, I thought that the window during jumpsquat in which you can do nothing is actually 1 frame less than it is, because I didn't realize that you input the jump 1 frame before the jump.

Edit: I believe many of us actually confuse these perspectives, since frame data threads actually say that shine hits on frame 1, but I think in discussion about wds it's often said that you input air dodge in the first aerial frame, when you can actually do the airdodge on the first aerial frame. Sdi guides tell you to input your sdi during hitlag, but if we have the perspective that shine hits on frame 1, then the Sdi window would actually begin 1 frame before hitlag.

 

[Bones0]

This depends on your point of view as this is philosophical question. The gamecube calculates the game at 60 fps, but it takes time for what is inputted by the players to happen on the screen. So where should we think that the game time actually runs? Your view point and mine until this last hour seems to be that the game time moves to next frame when the console has calculated what happened on that frame. This is a natural way to look at how the game flows. However, you might as well define the game time as being the same as what is shown on the screen, or as the time the console has processed the output signal.

I think our perspective is stupid in a sense: By that logic you must input your jump one frame before you jump. This is why I think it's most sensible to think that the game time is the same as the time you input actions divided into time intervals.

It doesn't actually matter what perspective you have, but when we are talking about input windows and framedata, it's necessary that we have same perspective and that we don't confuse it. I have made some errors in framedata calculating due to this. For example, when I first read your post, I thought that the window during jumpsquat in which you can do nothing is actually 1 frame less than it is, because I didn't realize that you input the jump 1 frame before the jump.

Edit: I believe many of us actually confuse these perspectives, since frame data threads actually say that shine hits on frame 1, but I think in discussion about wds it's often said that you input air dodge in the first aerial frame, when you can actually do the airdodge on the first aerial frame. Sdi guides tell you to input your sdi during hitlag, but if we have the perspective that shine hits on frame 1, then the Sdi window would actually begin 1 frame before hitlag.

I agree with what you're saying and normally would say "you input the direction of your jump on the first airborne frame" the same way I would say you airdodge on the first airborne frame in order to wavedash. However, he specifically asked "what frame does the game look for your joystick position". It makes sense to say you input the direction on the first airborne frame, but saying the game checks the joystick position on that frame isn't really debatable. It's just false. Of course these are semantics past a certain point, but I do think it's worth being precise with our wording because maybe he was wondering about a situation where the stick is held left for a dash and only switched to right for a jump-back animation. Saying the game won't take that left input as the jump direction if you are still holding it on the last frame of jumpsquat is misleading.

 

[tauKhan]

Wow, how could I make such a sound looking post which is actually totally of the point.

@ Bones0 We both were wrong (though I was more). This problem has nothing to do with input lag at all. The problem is this: the game operates with discrete time, but we live in continous time. So what is the "frame" we speak about when we say we input something on a frame? We make an input in the open interval between frames of the game. There is two solutions to add those open intervals to the discrete points to make a continuos time, and they are both equally good. We can have "frames" that don't include the past game frame. This is natural, because then your inputs have effect on the "frame" they are pressed. You can equally well have "frames" that don't include the game frame that takes place after the input interval. This can be argued to be natural, because then next frame will take place when the game state changes.

To be honest, I think the best solution is to stop talking about pressing inputs on a frame, and say that you make an input between frames.

 

[Kadano]

What frame does the game look for your joystick position to determine whether you get a backwards or forwards sh/hf (I'm guessing last frame of jump squat)?

This depends on your point of view as this is philosophical question. […]

I’ve been thinking about this often, and it’s all very complicated. Although it seems less correct – and probably is – I’m in favor of the [01][12] counting instead of [00][11], the former twin digit being the frame of input and the latter twin digit being the calculated and displayed frame. (First twin digit →00←latter twin digit.)

With [01][12], you would say of a Fox who stands idle (0) and suddenly dashes forward that he pressed forward on frame 0, and at the next frame (1) he starts moving. Whatever he inputs on frame 1 will take effect on frame 2 etc.
When we keep in mind that the controller input is actually the first thing Melee polls for when it starts calculating a frame, this way to look at it seems very wrong and [00][11] seems more exact, where we would say that Fox pressed forward on frame 1 and his dash also started at frame 1.

But if we imagine the inter-frame interval being 3 seconds instead of 17 ms – an extreme slow-mo mode – [01][12] feels more natural.
In this mode, we would see frame 0 for 3 seconds, more than enough time for us to react to what is displayed at frame 0.
During these 3 seconds, we would decide that we wanted to dash forward, so we would start holding forward, knowing that the input will be polled between the end of frame 0 and the beginning of frame 1.
Then, frame 1 would start being displayed and we would see Fox in the first frame of his dash animation. We would separate these time periods by the time points where we first perceive a new frame. Thus, frame 1 would start to us when it is being displayed, and after the inputs for it have been polled. We will hold the input that takes effect on frame 1 for most of frame 0, so we would group these together as 01, 12, 23 etc., which I denoted as [01][12] earlier.

Because you, tauKhan, mentioned SDI input, that’s another thing that makes more sense to view from the [01][12] perspective to me.
When a new frame is calculated, the game will assign every character to his new animation and position, according to the current controller input. Only after doing so, the hitbubbles are generated (if applicable). Therefore, if you stand just within the range of an enemy attack and would get hit by it at frame 1, by the logic of [00][11], it would not be possible to SDI on frame 1 of the hitlag. If you would hold away from the opponent on frame 1 (again, [00][11] thinking), your input would cause you to turn / dash away, out of the enemy’s range, or attempt to do so and still get hit if you are too close to the opponent.

This problem is very important to me because it frequently affects my creation of content. For example, I want to write an input display Avisynth script soon, but I’m not sure whether I should display the inputs on the frame they are held at, or at the frame they take effect. As you’ve probably guessed, I’m more inclined towards the former, which is in line with the [01][12] logic, but I am aware that this could be rightfully perceived as inaccurate by some people. I’m also considering delaying the input display by half a frame, at least for video scenes slower than 30 in-game frames per second.

To come back to d z’s question about FJump and BJump control stick polling: This happens at the last frame of the jumpsquat (Kneebend) animation. Only one frame is queried, so if we take Bowser as an example (8 frames jumpsquat), it doesn’t matter what you do with the control stick during the first 7 frames. On frame 7 ([01][12] logic), you hold the direction you want to jump in, and it’s processed at frame 8. What you press on frame 8 ([01][12] logic) / at frame 9 ([00][11] logic) doesn’t influence your horizontal momentum at all, although you can input all kinds of aerial moves.
You are airborne at frame 9.

Edit: I use the word on to express that I refer to the frame currently visible, and at to refer to the frame that’s currently being calculated.

 

[tauKhan]

I favor the [01][12] because even though the game obviously polls only at certain points of time, we play in continuos time, and it's more natural from our perspective that the frames add to a continuum. [0] [01] [1] [12] [2] and so on. I.e. we make an input between frames even if it is read at frames

Please delete this.

 

[Bones0]

@ Kadano
Idk what an Avisynth script is, but I'm guessing it has something to do with displaying inputs (in text form) alongside video of the game. If that's the case, I think displaying the inputs the frame they take effect is much more natural. Displaying the shine input the frame before the game displays a shine is really confusing and largely useless because that one frame of "delay" is going to apply to every single input ever. You might as well just consider a button being pressed on frame 17 as a frame 18 input.

Perhaps the easiest solution is simply to use these terms:
Input - the moment at which the player presses the button(s)
Output - the moment at which the game displays inputs from the player

Ex. To wavedash with Fox (3 frames of jumpsquat), you should input the airdodge on frame 3.
To wavedash with Fox, you should output the airdodge on frame 4.

Saying output like that is kind of weird, but it seems much clearer since the screen displaying the airdodge is, in reality, the output, not the input. The only problem is trying to get the entire Smash community (and perhaps other gaming communities) to adopt this standard to prevent confusion. In the mean time, at least the second example statement remains clear. The only confusion it will introduce is for those still saying "input" when referring to the frame the command is displayed.

Thoughts?

 

[Kadano]

@ Kadano
Idk what an Avisynth script is, but I'm guessing it has something to do with displaying inputs (in text form) alongside video of the game. If that's the case, I think displaying the inputs the frame they take effect is much more natural. Displaying the shine input the frame before the game displays a shine is really confusing and largely useless because that one frame of "delay" is going to apply to every single input ever. You might as well just consider a button being pressed on frame 17 as a frame 18 input.

Perhaps the easiest solution is simply to use these terms:
Input - the moment at which the player presses the button(s)
Output - the moment at which the game displays inputs from the player

Ex. To wavedash with Fox (3 frames of jumpsquat), you should input the airdodge on frame 3.
To wavedash with Fox, you should output the airdodge on frame 4.

Saying output like that is kind of weird, but it seems much clearer since the screen displaying the airdodge is, in reality, the output, not the input. The only problem is trying to get the entire Smash community (and perhaps other gaming communities) to adopt this standard to prevent confusion. In the mean time, at least the second example statement remains clear. The only confusion it will introduce is for those still saying "input" when referring to the frame the command is displayed.

Thoughts?

Yeah, as I wrote before (“but I am aware that this could be rightfully perceived as inaccurate by some people”), I agree that [00][11] display could be confusing. I like the input / output concept, even if using output in this way does feel a little weird.
What do you think about my idea with shifting the input display by half a frame interval?

Btw, Avisynth is a scripting language that tells a frameserver what to write to a video stream. This can be text, but it can also add overlays, layers and do all kinds of things with the video stream.

 

[tauKhan]

One question: doesn't melee actually poll input between frames? I have heard that the frequency is much higher than 60 fps.

 

[Kadano]

One question: doesn't melee actually poll input between frames? I have heard that the frequency is much higher than 60 fps.

I remember reading a Magus post about inputs being polled 3 times per frame or something. I don’t know the first thing about using Dolphin-debug and reading Melee code, so I’m not able to look into this myself. I’d love to learn all about it, though.

So far, I’ve just been assuming that polling happens immediately after a frame has been output through the video plugs because I felt this couldn’t be too far from the truth.

 

[tauKhan]

It would make much more sense for the game to poll input just before frames happen, I have always assumed It works like that. Because then there is no delay between inputs and actions taking place. And that is why I said it would make sense to mark inputs with [01] and actual frames [0][1] and so on.

 

[Bones0]

I remember reading a Magus post about inputs being polled 3 times a second or something. I don’t know the first thing about using Dolphin-debug and reading Melee code, so I’m not able to look into this myself. I’d love to learn all about it, though.

So far, I’ve just been assuming that polling happens immediately after a frame has been output through the video plugs because I felt this couldn’t be too far from the truth.

Do you mean 3 times a frame? What purpose could polling more than once a frame serve? It makes me think about a bunch of jank possibilities like if a player is holding left for 2/3rds of a frame and right for the last 1/3rd of the frame, it would output a "left" command even though "right" was what was being inputted at the end of the frame. Not saying anything like that is likely, just daydreaming. lol

I don't think delaying the input display by half a frame will make much difference at all except in those situations like for shining. It just sounds weird to me envisioning a character shining with the "down+B" display appearing half a frame later. I might just be too OCD to prefer anything other than full frame input displays that match up exactly with the output frame (so the entire first frame of shine would have "Down + B" next to it).

 

[Kadano]

Do you mean 3 times a frame? What purpose could polling more than once a frame serve? It makes me think about a bunch of jank possibilities like if a player is holding left for 2/3rds of a frame and right for the last 1/3rd of the frame, it would output a "left" command even though "right" was what was being inputted at the end of the frame. Not saying anything like that is likely, just daydreaming. lol

I don't think delaying the input display by half a frame will make much difference at all except in those situations like for shining. It just sounds weird to me envisioning a character shining with the "down+B" display appearing half a frame later. I might just be too OCD to prefer anything other than full frame input displays that match up exactly with the output frame (so the entire first frame of shine would have "Down + B" next to it).

Yeah, I meant frame, not second, lol.
Iirc, it’s made that way so that no button presses are missed. When we consider that for Fox’s short hop, we need to let go of X/Y/↑ after about 2 frames, it’s not out of the question that a player could press and release a button within 0.9 of a frame interval. If Melee polls only once per frame, this input could get lost and nothing happens, although the player clearly pressed the button (albeit very briefly).

I think I didn’t get the concept across for delayed input display. I meant that the shine input display starts half a frame earlier than the frame the shine is visible, and also only lasts for one frame, so during the second half of the first frame of the shine, the input for the following frame is displayed.

 

[KingDozie]

What is circle jumping? and what is it use for.

 

[Bones0]

Yeah, I meant frame, not second, lol.
Iirc, it’s made that way so that no button presses are missed. When we consider that for Fox’s short hop, we need to let go of X/Y/↑ after about 2 frames, it’s not out of the question that a player could press and release a button within 0.9 of a frame interval. If Melee polls only once per frame, this input could get lost and nothing happens, although the player clearly pressed the button (albeit very briefly).

I think I didn’t get the concept across for delayed input display. I meant that the shine input display starts half a frame earlier than the frame the shine is visible, and also only lasts for one frame, so during the second half of the first frame of the shine, the input for the following frame is displayed.

Oh, okay. When you said delayed input display, I thought you meant you would delay the input display... lol Yeah, showing the input just before the action seems okay. I guess it really depends on what you're showing/how slowed down the video is.

What is circle jumping? and what is it use for.

I've never heard of circle jumping, but I've heard of circle camping which is simply the process of avoiding the opponent using the floor and 3 platforms (hence the name because of the circular movement).

 

[texh]

What's the best adapter to PC for GameCube controller?

 

[lokt]

What (cheap) devices do I need to record video?

 

[Bones0]

What (cheap) devices do I need to record video?

http://meleeiton.me/2014/04/18/c_naughts-console-capture-crash-course-part-1/

 

[Kadano]

What's the best adapter to PC for GameCube controller?

Mayflash’s adapter that takes 2 GCCs at the same time, afaik. I use them and have no complaints. I do have lag when emulating, but I’m very sure that it’s due to Dolphin and not due to the GCC adapter.

 

[hariooo]

.... since when does knockback depend on stale moves in melee? isn't it only percentage?

Also what exactly is the mechanic behind the kind of super crouch cancel that reduces knockback to the point that for example puff survives a fox usmash at 100%. it happens every so often but i haven't foonud an explanation anywhere.

 

[Bones0]

.... since when does knockback depend on stale moves in melee? isn't it only percentage?

Also what exactly is the mechanic behind the kind of super crouch cancel that reduces knockback to the point that for example puff survives a fox usmash at 100%. it happens every so often but i haven't foonud an explanation anywhere.

You're correct, it's only based on percentage (and the move ofc). The only way stale moves affects KB is by doing less percent; the KB calculation is done with the post-hit %, so if the attack does 1% less than normal, it will have less KB because the opponent's % will be 1% less than it would have been from a fresh hit.

I don't think there's any super CC. The difference you are noticing is probably just ASDI down vs. a true CC. A true CC results in reduced KB and stun, but it only happens when your character is actually crouching (or starting to crouch). If you are in lag or something that prevents your character from actually crouching, you are simply ASDIing downward into the ground which can cause you to land from moves like jabs or slightly reduce how far you get KBed relative to the point of collision. There usually isn't much point in true CCing at higher percents ('cause you could just, you know, shield lol), but when you do, it can look really weird to see how little KB you have. That's probably what you noticed.

 

[tauKhan]

Yeah, ASDI down will either let tech or cancel hitstun depending on kb. I will add that ASDI is quite powerful, and will work even vs sheik dash attacks and falcon stomps even in beyond 30%. Incidentally, most jabs are sakurai angled, and cannot be asdi'd down in early percents.
Crouching reduces knockback by 1/3, which often helps canceling the stun, but vs sakurai angled moves, (most moves which send at 45 degrees at higher percents, like fox's nair, sheik bair.) it actually has negative effect at low percents since it makes the attack not lift you off the ground.