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!
Super Smash Bros. for 3DS and Wii U came out almost two years ago, and the game still puzzles players with unexplainable situations. Techniques, combos and mechanics are being discovered even today; this is the case for YouTubers like the Beefy Smash Doods, who have recently cracked another mystery regarding input buffering.
Input buffering is the action of inputting a follow-up move during the last 10 frames of your current action; this opens up possibilities to reduce the precision needed from the player and allow for more frame-perfect techniques.
Beefy Smash Doods experimented with moves that put a character in a big amount of lag, like Yoshi's Neutral-B, and why sometimes seemingly "random" moves come out of them. To keep the mechanic simple, turns out you can buffer way before the 10-frame window and "hold" the buffered action (only works for aerial attacks) until your lag comes out by mashing your attack button.
But they can explain it better. Watch their video here:
So what do you think? What useful applications do you see for this mechanic? Let us know in the comments, and be sure to follow the Beefy Smash Doods on Twitter @BeefySmashDoods.
Mario "Diosdi" Osuna is a young veteran player, writer, backroomer and TO in the Smash scene from Venezuela. Starting with Brawl in 2010, he didn't find as big of an interest into Smash until 2014. While he is yet to win a tournament, you can enjoy his writing.
It's amazing how we are still finding new techs and mechanics in Sm4sh even to this day. At this rate, just imagine the amount we will discover in the future.
Probably to deter button mashing and force players to be patient enough to wait until they regain control. But while I'm sure it creates daily SDs on For Glory, it does seem to suggest glitch. Especially if it only works for aerials, and not grounded normals and specials.
Probably to deter button mashing and force players to be patient enough to wait until they regain control. But while I'm sure it creates daily SDs on For Glory, it does seem to suggest glitch. Especially if it only works for aerials, and not grounded normals and specials.
There is also the fact that there is no tip for it during the game's loading unlike staling and such, plus the fact that button mashing in any state where it is active is your best option or doesn't significantly effect the outcome of button mashing as a whole, especially to people who are not competent players and rely on mashing to do anything.
Probably to deter button mashing and force players to be patient enough to wait until they regain control. But while I'm sure it creates daily SDs on For Glory, it does seem to suggest glitch. Especially if it only works for aerials, and not grounded normals and specials.
See, I would have gone with the opposite and said that it makes mashing a better option. Without this, you couldn't control what you buffered out of egg lay or when you break out of a command grab in midair. With it, you can set the aerial you want to do, then mash until you can break out and do the move.
It's still really stupid, and now that I know why this happened I can think of countless examples of when this special case of buffering has screwed me over, but I think that was the idea.
It's amazing how we are still finding new techs and mechanics in Sm4sh even to this day. At this rate, just imagine the amount we will discover in the future.
this might come off as unrelated nitpicking, but I think Sm4sh players aught to be a little pickier on the use of "tech" these days... I just see that word being thrown around so much, the fact that "breaking your fall" is considered "teching" sometimes baffles me.
it is intriguing that this game still has numerous mechanics that have yet to be fully explained... especially in this day and age of data miners being a bit more common. one would think somebody could look at the code and have spent some spare time to figure out what it means...
as for this mechanic, so what this video is saying, when you're stuck in the air, either during an aerial or in Yoshi's Egg Lay, the game essentially sets up a queue of sorts for the first action you hit while you're mashing. the only way to reset it is to stop for a moment and make your intended attack the first action you take...?
it is intriguing that this game still has numerous mechanics that have yet to be fully explained... especially in this day and age of data miners being a bit more common. one would think somebody could look at the code and have spent some spare time to figure out what it means...
All the data miners in Sm4sh have done so far is look at a bunch of data and parameter files. Rather than hard coding (writing these values directly into the source code to be compiled to machine language) the base damage and frames of say, Falcon Punch, they're all stored in parameter files that get read into the game before the match starts. This makes the values easier to change, since changing the damage parameter doesn't allow certain mistakes to be made, like deleting an equals sign in an equality comparison (which turns == into =, the assignment operator. Any nonzero value is considered a logical "true" by many common programming languages, so the statement if(a=b) doStuff(); gives a the value of b and then checks to see if a is nonzero, and if it is then you will do stuff. What you probably wanted was to only do stuff if a==b).
Even if one was to look at the code on the disk, it wouldn't mean that much. Here is an example of what C++ code looks like:
#include <iostream>
int main() {
std:out << "Hello, world!" << std::endl;
return 0;
}
/*That frowny face is supposed to be a colon and lowercase c*/
You may not know what this does, but you can probably guess that it says, "Hello, world!" when run. This is what the programmer sees. It's not always clean or sensible or easy to guess, but it's better than assembly, which is almost 1:1 with the machine code the chips see. Here is that source code translated to assembly with G++ 6.1.1, using compiler defaults:
This is what you see if you're lucky. If you're not, you see a bunch of hexadecimal numbers representing instructions, data, memory locations, pointers, and all sorts of good stuff that the so-called high-level languages (everything but machine code and assembler) hide from you and do behind the scenes to make your life easier.
Even if you were to see all that and understand it, there are still potentially important things you haven't seen. Older consoles ran their games on what's called "bare metal". All that's loaded is what's on the cartridge, so if you can read that you know exactly what's happening. Newer consoles adopt a more PC approach, where certain things are always in memory and some control over what's happening is given up to the console's operating system. Even if you were to see and understand that, and how it interacted with the game code and data, that still isn't the full story. Many chips (especially CPUs and GPUs) these days have what's called "microcode", code that's run by the chip for help in efficiently performing its functions and to prevent it from receiving HCF instructions (Halt and Catch Fire. It's a joke. Sort of. Not really). Even though assembly is supposed to grant complete control over things like register allocation, processors may take those instructions and change them so it does something slightly different, like make it go to a different register. So you need to know what all the microcode does. Then you have to study the hardware to see if there are any hardware bugs, and then refer back to the microcode to see whether those bugs are patched, and if they're not then they might be used by the assembler code to save time on certain operations.
Bottom line, it's all way too complicated to understand. Even if you had the whole source code, it would take you awhile to understand it enough to look for potentially useful bugs, but once it gets down to assembler on a modern system it's basically incomprehensible. Side note, this is also why every piece of software ever has five bajillion security holes. Computers have become far too complicated for any single human to understand.
