• 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!

Ultimate Ground Movement Analysis: Turbo Edition

Army805

Smash Cadet
Joined
Aug 7, 2015
Messages
52
So if i'm understanding correctly, if max angle WD is the highest value (outside of perfect waveland), then continuous wavedashing given that its the max angle would be that characters fastest movement option? Not including characters like jiggs, where prob like shorthopping and using aerial mobility is probably faster.
 
Last edited:

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
So if i'm understanding correctly, if max angle WD is the highest value (outside of perfect waveland), then continuous wavedashing given that its the max angle would be that characters fastest movement option? Not including characters like jiggs, where prob like shorthopping and using aerial mobility is probably faster.
Yeh pretty much. Assuming they perform the wavedashes directly after each other.
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
Wondering about the difference between "Initial Dash Velocity" and "True Initial Dash Velocity" ?
When you start a dash, you do not gain any velocity until frame 2 of dash. On frame 2, your left stick input is read. Assuming you hold forward, if your true initial dash velocity is the same as your maximum velocity (like mario and doc), you will simply gain that amount on frame 2. But if your true initial dash velocity is less than your maximum, you will gain true initial dash velocity + dash acceleration. If your true initial dash velocity is higher than your maximum, you will gain true initial dash velocity - traction.

Fox and Falco are a good example of this.

Both have a true initial dash velocity of 1.90

Fox has a maximum dash velocity of 2.20 (and a dash acceleration of 0.12)

Falco has a maximum dash velocity of 1.50 (and a traction of 0.08)

So on frame 2 of dash, assuming they are holding forward (altho falco will do the following either way);

Fox will have an initial velocity of 2.02

Falco will have an initial velocity of 1.82

Peach has a very sneaky true initial dash velocity. Her maximum dash velocity is 1.3, her dash acceleration is 0.12, and her true initial dash velocity is 1.2. So assuming she holds forward on frame 2, she will gain a velocity of 1.3.
 

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
Excuse me if this is off base, but I am infinitely curious about this (and trying to work on an application that uses movement and the Project M Calculator by Shell).

Is this data experimentally discovered? I figure you were able to acquire the values of "Melee Meter" from the game files, but as for the formulas, if you could shed some light on the process you used I'd be extremely grateful. I suppose I'm just confused on how I would even begin to work on something like this, but I'd absolutely love to.

Thanks for anything you are willing to provide!
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
Excuse me if this is off base, but I am infinitely curious about this (and trying to work on an application that uses movement and the Project M Calculator by Shell).

Is this data experimentally discovered? I figure you were able to acquire the values of "Melee Meter" from the game files, but as for the formulas, if you could shed some light on the process you used I'd be extremely grateful. I suppose I'm just confused on how I would even begin to work on something like this, but I'd absolutely love to.

Thanks for anything you are willing to provide!
I used this melee mod by magus, to look at character velocities in real time frame by frame. Most of the character's properties I found using that, but you can also find them within the .dat files (using Crazy/Master Hand). Then to determine the formulas for each movement option was all just lots of observation and pattern recognition.

I'd make a few different cases (like starting at different velocities, different characters who have different attributes), then I'd look for any correlation because stuff like the character's traction or something, make a guess of the formula, and test the formula on a bunch of cases. If it conforms with a reasonable amount of cases, I consider it correct and then I convert it to python code, so I can just run a script to find whatever result I need without the manual work.

Sounds like you want to make a program that could draw hitboxes after a movement option is calculated and then the trajectory it hits. With that you could determine pretty much any combo. If you want to make this for melee you will likely have a really hard time. The trajectory is simple enough (I've actually been developing this in javascript and am close to completing it), and so is the movement options. But there is currently so easy way to obtain hitbox offsets, and hurtbox sizes and positions. The melee mod above has an option to see hitbox id x,y,z offsets from topN (topN being the position that is calculated for all movement), so you could theoretically get that info, but it takes sooooo much manual labour. I started a similar project a while ago, jab was quick to get offsets, but fox's nair took me about 40 minutes. I abandoned it after that because I knew it wasn't a feasible method.

That being said, just thinking about this now has given a great idea. Fizzi has been able to obtain in game values directly from the wii in real time. If he were to run magus' mod and have it so all hitbox id offsets will be copied to a file when activated, you could just let that run and perform all the chars moves. I believe many people have done similar things using dolphin, and probably a lot easier. I'll look into this.

If you are doing this for PM, you can ignore all of that, as I believe everything you need is very easily accessible.
 

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
Sounds like your approach was similar to what I was about to set about doing, and your work is great! I actually bumped into your Dr. Mario extended Up-B writeup and ended up looking at your heatmaps and everything.

Yeah, I'm planning to work on it for Project M, partially because the information is right there. I'd say I'm not particularly doing anything groundbreaking, just trying to repackage already known information into a nice application for people to use.

Instead of working with the hitboxes/hurtboxes with a size and offset (who knows, down the line I'll probably be tempted to consider them), I mostly just want to have it calculate a trajectory to effectively see if you could move your character to the point you've hit them in time before hitstun wears off. It'd be a quick and dirty way to figure out possible followups rapidly, with only minimal testing.

That being said, I'm certainly not disinterested in getting deeper into this and helping to create something that handled more. I'll definitely have to look into both Magus's mod and Fizzi, probably further down the line when I get a working version of what I'm currently working on.

Again, thank you very much for the detailed explanation! It helped immensely.
 
Last edited:

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
Hey again! Sorry for such a short response (should I PM you or something?) but how did you get the stages with such precision? What I personally was doing was edited a PM character's attributes to be close to one and counted frames it took to travel across a stage. Did you just try with multiple characters with multiple values till you found a pretty solid exact?
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
Hey again! Sorry for such a short response (should I PM you or something?) but how did you get the stages with such precision? What I personally was doing was edited a PM character's attributes to be close to one and counted frames it took to travel across a stage. Did you just try with multiple characters with multiple values till you found a pretty solid exact?
Magus' mod also shows topN positions which is the base of the characters. So I just walk to the edges (teetering) write down the value, then go to other side and compare the 2. If you are looking for PM stuff, I would ask around the PM modding forum, I'm sure someone knows how to get the ingame values, as lots of people make new stages all the time.
 

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
Magus' mod also shows topN positions which is the base of the characters. So I just walk to the edges (teetering) write down the value, then go to other side and compare the 2. If you are looking for PM stuff, I would ask around the PM modding forum, I'm sure someone knows how to get the ingame values, as lots of people make new stages all the time.
Right, right. Thank you so much for your time and keep up the great work!
 

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
So I have no idea if you're still interested in all this and such, but I started some analysis on horizontal movement on jumping. Jumping itself is easy enough (just applied velocity on being airborne effectively), but I have a bit of data on horizontal movement's factor!

From the moment you press the jump button, horizontal movement can no longer be applied, meaning you get Ground Friction applied for each frame of jumpsquat. At the end of jumpsquat, your horizontal speed airborne is the horizontal speed at the last frame of jumpsquat times the Ground to Air Jump Momentum Multiplier plus the X axis of the analog sticks value times the Jump H Initial Velocity, or
((Initial speed - (Ground Friction * Jumpsquat Frames)) * Ground to Air Jump Momentum Multiplier) + (X axis analog stick value * Jump H Initial Velocity)
If this value surpasses the Jump H Maximum Velocity value, the horizontal velocity is set to that.
This is just a little bit of work I've done, and I'll probably have a lot more soon. I'm not entirely sure if this is all just common knowledge on mechanics that I'm redigging up, it seems like it might be since the attributes are fairly self explanatory in MasterHand.

My question is: would any of this data/research help you, or are you interested in seeing mine? If so I'd love to share and chat about it!
 

artifice

Smash Ace
Joined
Feb 12, 2007
Messages
567
Location
Spokane, WA
My question is: would any of this data/research help you, or are you interested in seeing mine? If so I'd love to share and chat about it!
Ide like to see others data collecting/organizing methods - and always like to compare equations. My excel sheets are getting better but I'm not too good with excel in general, and maybe you guys are using another method?


schmooblidon schmooblidon
I had a question about the KnockBack calculating program you did, or rather the equations you were using. My issue is I cant figure out where the KB Velocity rate of degradation comes from. For instance taking character's KB Vertical Velocity, and subtracting the vertical KB Velocity of the last frame is always more than just character's gravity, what is that remainder?




p.s - Thanks for the 'True Initial Dash Velocity' explanation before (above).



 
Last edited:

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
I had a question about the KnockBack calculating program you did, or rather the equations you were using. My issue is I cant figure out where the KB Velocity rate of degradation comes from. For instance taking character's KB Vertical Velocity, and subtracting the vertical KB Velocity of the last frame is always more than just character's gravity, what is that remainder?
The rate of velocity degradation when in hitstun (the value you are looking for) is a friction rate that is universal. Each frame, the knockback's velocity decreases by 0.051. In a vertical direction, the velocity decreases by sin(angle of attack) * 0.051 + gravity, each frame. In a horizontal direction, the velocity decreases by cos(angle of attack) * 0.051.

Basically, the value you are looking for is "0.051"

My method of collecting data is... rather dumb? I would say. I have an excel document with numbers just everywhere, and various functions that calculated differences or averages or what-have-you. I used Magus's mod that schmooblidon advised to look at the velocity frame by frame, and used guesses and MasterHand to pull character attributes and examine them.

I have the full range of player control on character's jumping, as well as being in the air down to a formula now in regards to horizontal movement, I'm simply not sure if I should try and make a post here or in a different thread.
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
schmooblidon schmooblidon
I had a question about the KnockBack calculating program you did, or rather the equations you were using. My issue is I cant figure out where the KB Velocity rate of degradation comes from. For instance taking character's KB Vertical Velocity, and subtracting the vertical KB Velocity of the last frame is always more than just character's gravity, what is that remainder?
Ponkapa beat me to it, all of the equations used can be found here. Even if you don't code, it should be quite intuitive to read. If you ever need anything explained hit me up.

My method of collecting data is... rather dumb? I would say. I have an excel document with numbers just everywhere, and various functions that calculated differences or averages or what-have-you. I used Magus's mod that schmooblidon advised to look at the velocity frame by frame, and used guesses and MasterHand to pull character attributes and examine them.

I have the full range of player control on character's jumping, as well as being in the air down to a formula now in regards to horizontal movement, I'm simply not sure if I should try and make a post here or in a different thread.
What sort of stuff are you planning on calculating. If I was doing it I'd form equations for a few cases like dash > jump full drift, dash > jump no drift, wait > jump drift, wait > jump no drift etc. And compare every character for each case. Doing this analysis was super simple because it was just 1 axis, I think it'd be best to display the information of jumps with visual graphs. Numbers can work, but it's not intuitive to compare and not easily imagined when dealing with 2 axes.

I could actually very easily modify the calculator to draw circles from a source. Would give you a circle for each frame, so you have a sense of time, altho I'm planning on adding an animation for the calculator in general, I could add that in early.
 

Ponkapa

Smash Cadet
Joined
Mar 22, 2014
Messages
72
Ponkapa beat me to it, all of the equations used can be found here. Even if you don't code, it should be quite intuitive to read. If you ever need anything explained hit me up.



What sort of stuff are you planning on calculating. If I was doing it I'd form equations for a few cases like dash > jump full drift, dash > jump no drift, wait > jump drift, wait > jump no drift etc. And compare every character for each case. Doing this analysis was super simple because it was just 1 axis, I think it'd be best to display the information of jumps with visual graphs. Numbers can work, but it's not intuitive to compare and not easily imagined when dealing with 2 axes.

I could actually very easily modify the calculator to draw circles from a source. Would give you a circle for each frame, so you have a sense of time, altho I'm planning on adding an animation for the calculator in general, I could add that in early.
At this point, I'm not even sure what I'm planning to calculate. It quickly became something I just wanted to understand, function wise. Looks like you beat me to coding all of it certainly!

I suppose the last thing I wanted to do was work on some kind of decision making for leading one hit into another in a combo, for some semblance of optimization.

Honestly, I'm really just happy to see your code on github, looking at it leaves me with a mix of wonder and just that nice sense of learning. Thanks!
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
At this point, I'm not even sure what I'm planning to calculate. It quickly became something I just wanted to understand, function wise. Looks like you beat me to coding all of it certainly!

I suppose the last thing I wanted to do was work on some kind of decision making for leading one hit into another in a combo, for some semblance of optimization.

Honestly, I'm really just happy to see your code on github, looking at it leaves me with a mix of wonder and just that nice sense of learning. Thanks!
That's sorta the plan for the calculator, although of course there are the issues I mentioned above. Even just for approximate combo calculation using accurate movement calculations is such a long way away. It needs tonnes of work, and I'm pretty busy with other projects atm, and I have no idea how I would fit it all in the UI.

I added a new option on the calculator just now to import source positions. Just press S to bring up the menu, the instructions are super clear. Press U to undo your last source graph. Also remember to hide all the side controls for a better view of the display. I might make some pics for the ground movement actually. If you use this and think there is a better way to format the data, like something you can easily make in excel or something, let me know it's pretty straight forward to change it.
 

1ampercent

Smash Journeyman
Joined
Nov 28, 2013
Messages
310
Location
Australia
schmooblidon schmooblidon
I've got a question about Falco, how fast is Falco when he does a 1 frame dash into SH laser and then repeat? Interested to know this because I feel like it's faster than running. Also I think the different amount of time spent in the air could mean different results.
 

artifice

Smash Ace
Joined
Feb 12, 2007
Messages
567
Location
Spokane, WA
schmooblidon schmooblidon
I've got a question about Falco, how fast is Falco when he does a 1 frame dash into SH laser and then repeat? Interested to know this because I feel like it's faster than running. Also I think the different amount of time spent in the air could mean different results.
I believe it is mentioned somewhere in this thread: that no velocity is added during that first frame of dash-state. secondly, I think their are several things faster than running cross stage with Falco, including fox-trotting, and possibly wave-dashes in-between the trots. But This type of specific question seems best answered by going into debug mode yourself and doing some math.

Edit: A frame[1] dash input, and a frame[2] jump input will in-fact add the expected dash horizontal velocity to jump-squat frames.
 
Last edited:

Klemes

Smash Journeyman
Joined
Jul 4, 2015
Messages
236
Location
France
What's an extended DD ? Do people do it ? And straight to the point, would it be good for falco ? thanks !
 

Army805

Smash Cadet
Joined
Aug 7, 2015
Messages
52
This is similar to my previous question but i just need confirmation. If a character's max angle wavedash is faster than wavesurfing, than for a single wavedash is it faster to just do a WD, opposed to dash for 1 frame -> WD? I always thought it was better to dash WD to cover tech away on reaction with characters such as IC's but it appears as though it's faster to just WD. Also how is dash dance velocity different than initial dash velocity? Does it just account for the 1 frame of smash turn or something?
 
Last edited:

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
What's an extended DD ? Do people do it ? And straight to the point, would it be good for falco ? thanks !
Extended dash dance is when you release the stick before you transition into run, so that you remain in dash for longer, giving you more time to dash back and some more distance, it's good for everyone.

This is similar to my previous question but i just need confirmation. If a character's max angle wavedash is faster than wavesurfing, than for a single wavedash is it faster to just do a WD, opposed to dash for 1 frame -> WD? I always thought it was better to dash WD to cover tech away on reaction with characters such as IC's but it appears as though it's faster to just WD.
From stationary, a dash will produce velocity on frame 2 onwards (frame 1 copies the velocity from the previous frame). A wavedash will produce velocity on frame 4 onwards. 1 frame of dash will produce some velocity during those jumpsquat frames. So you would need to compare what is gained from those 3 jumpsquat frames, to what you get after wavedash landing lag.

Dash produces 1.4, and so on jumpsquat 1-3. you get 1.33, 1.26, 1.19. A max angle wavedash on the first actionable frame will produce 2.09, then 2.02, 1.95, 1.88 etc.

So you gain 3.78 during jumpsquat, and sacrifice the last frame of wavedash slide. The highest wavedash slide value you can sacrifice is 2.09, so that means 1 frame of dash goes farther in the same amount of time, by at least 1.69Mm. But doing 1 frame of dash consistently isn't super easy. 5 or more frames of dash will give you the opposite result;

Initial values would be 0,1.4,1.4,1.4,1.4,1.33,1.26,1.19 = 9.38

Sacrificed wavedash values would be 2.09,2.02,1.95,1.88,1.81 = 9.75

Now this is only assuming that you plan on moving for only 18 frames, then immediately comparing the distance, if you want to slide for longer, than you need more dash frames to make a lone wavedash a better option.

Also how is dash dance velocity different than initial dash velocity? Does it just account for the 1 frame of smash turn or something?
Yes it accounts for the frame of smash turn, which times velocity by 0.25, and then they repeat that value for frame 1 of dash, then they gain their true initial dash velocity, and if needed, have to accelerate back up to their max dash velocity. So ICs for example will go like this;

1 - 0
2 - -1.4
3 - -1.4
...
13 - -1.4
14 - -0.315 (smash turn) (also reduces by traction)
15 - -0.315 (1st frame of dash)
16 - +1.155 (-0.315 + 1.4 + 0.07)
17 - 1.225
18 - 1.295
19 - 1.365
20 - 1.4
...
27 - 1.4

The calculation takes values of frames 14-27 and averages them
 

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
So with Dash Dance Velocity, you are actually slowing down and speeding back up over those frames?

I have some questions about how moonwalking works with characters that have to walk first
I heard that if you have a long initial dash, moonwalks are easier

Mainly concerned with how this impacts the movement of Pichu, Pikachu, Peach and Puff

Been experimenting with how momentum is transferred to air with different characters,
like how you can do Boost Run with Puff and jump, or waveland off a platform into aerial drift

I know sometimes the tactile sensations can be misleading, but it seems like there is some difference with the spacings I can get
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
So with Dash Dance Velocity, you are actually slowing down and speeding back up over those frames?
Yup
I have some questions about how moonwalking works with characters that have to walk first
I heard that if you have a long initial dash, moonwalks are easier

Mainly concerned with how this impacts the movement of Pichu, Pikachu, Peach and Puff

Been experimenting with how momentum is transferred to air with different characters,
like how you can do Boost Run with Puff and jump, or waveland off a platform into aerial drift

I know sometimes the tactile sensations can be misleading, but it seems like there is some difference with the spacings I can get
Jump horizontal velocity is calculated as :

cVel.x = (cVel.x * charAttributes.groundToAir) + (input.lstickX * charAttributes.jumpHinitV);
if (abs(cVel.x) > charAttributes.jumpHmaxV) {
cVel.x = charAttributes.jumpHmaxV * sign(cVel.x);
}

So there is always a cap for the initial velocity, then there is the aerialHmaxV for limiting anytime when in the air.

These attributes can be found using crazy hand
 

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
Thx for the quick response!

So, what I'm noticing isn't an increase to (initial Horizontal Velocity), but an increased acceleration to the (aerial Horizontal max Velocity)?

I don't really look at the game files, so I wouldn't know the first thing to do with Crazy Hand

But I can think about the movement stats in the abstract and test things to see differences


Back to the moonwalking question though, I still don't understand entirely how it works, esp for characters that can't get a good one out of walk. It's easy enough to see the result on chars like M2, Falcon and the Links.

Can you explain the inputs/mechanics behind needing to walk into a moonwalk?
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
Thx for the quick response!

So, what I'm noticing isn't an increase to (initial Horizontal Velocity), but an increased acceleration to the (aerial Horizontal max Velocity)?
I'd say you are just noticing a "headstart" to their aerial horizontal max, and can even reach there immediately upon going airborne. My point was that you can never get any extra speed in the air, it's always capped.

Back to the moonwalking question though, I still don't understand entirely how it works, esp for characters that can't get a good one out of walk. It's easy enough to see the result on chars like M2, Falcon and the Links.

Can you explain the inputs/mechanics behind needing to walk into a moonwalk?
So the point of a moonwalk is too travel backward, and to get that backward velocity you have to accelerate there which takes time.

To let's say you are walking to the right and right velocity is positive velocity. When you hit back to start a dash, you then gain the character's initial dash velocity to the left (negative). This is additive, so the faster you were walking the more you negate that dash velocity. Then during dash, you will accelerate based on your stick's X position, where left is -1 and right is 1. For this moonwalk you ofc want to hold right, so you accelerate by 1 * character's dash acceleration value.

People usually do the half circle or nike tick motion on the stick immediately after inputting the dash. This is because a back input too quickly will be considered a smash input, and will start a dash in the other direction (so you dash dance). So you need to tilt back for at least 2 frames before hitting full back.

So needing to walk is to negate as much of the dash velocity as possible, and give the moonwalk a head start. Some characters just have slow walks and crappy dash attributes, so they can struggle even with a walk.
 
Last edited:

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
I'm very new to seeing all the hard values, can you show me some more numbers to help explain?

How much dash negation is necessary to get a practical moonwalk?
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
I'm very new to seeing all the hard values, can you show me some more numbers to help explain?

How much dash negation is necessary to get a practical moonwalk?
There are quite a few attributes to consider when calculating moonwalks. They are all detailed in the OP by clicking on the "Calculations" spoiler within each character.

dx is the amount of dash frame before a run is started, assuming you are holding forward. (This is unimportant for moonwalks)
dy is the maximum amount of dash frames before the animation will end.
du is the initial dash velocity
dv is the max dash velocity
da is the dash acceleration
dtu is the true initial dash velocity (Dash is weird in that you only start gaining the velocity on the 2nd frame, and it is almost like that first frame velocity is calculated but never applied, this true initial dash velocity is used for that first frame)
t is traction
maxwalk is max walk velocity

So when you start the dash back, you add dtu to your current velocity. Then you will need to tilt back for a few frames, say a horizontal input of 0.6, which will apply 0.6 * da each frame in the given direction. Then full back, so 1 * da each frame. You have dy frames to do this acceleration before it ends. You also cannot go beyond dv in either direction (only boost run can break this rule), and if your stick is in neutral you will slow down by t

So the amount of dash negation needed, depends how fast the walk is, and how much acceleration you can gain during the dash. I guess you could then calculate it by doing something like ((dy - 0.8)*da + maxwalk) - dtu to get the amount of velocity you can use in the moonwalk direction, and how much smaller/larger that is to the initial dash velocity. You could change that 0.8 to something more human like, say 1.4, and reduce maxwalk a little bit (about 0.1), because reaching the absolute max walk vel takes a long time (it increases logarithmically). Then if the answer is positive, you can assume it's possible to finish the moonwalk moving backward, and if it's above aorund 1 or 1.5, you could call it a practical moonwalk.
 

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
Okay, just making sure I'm plugging everything in correctly here:

Pichu
dy = 22
da = 0.1
maxwalk = 1.24
dtu = 1.8
du = 1.72
dv = 1.72

Formula:
((dy - 0.8)*da + maxwalk) - dtu = moonwalk velocity

answer - initial dash velocity = total moonwalk velocity

so what is the purpose of the 0.8 in the formula? the number of frames tilting a horizontal input before holding full back in the moonwalk direction after dash? so that number is the variable in execution of the moonwalk?

((22 - 1.4)*0.1 + 1.14) - 1.8 =
((20.6)*0.1 + 1.14) - 1.8 =
(2.06 + 1.14) - 1.8 =
(3.2) - 1.8 = 1.4 moonwalk velocity

1.4 - 1.72 = -0.32 total moonwalk velocity

So in other words, if that math is correct, Pichu doesn't have a 'practical' moonwalk, in that he doesn't really generate momentum that can be transferred to anything, he just kinda turns in place.
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
Okay, just making sure I'm plugging everything in correctly here:

Pichu
dy = 22
da = 0.1
maxwalk = 1.24
dtu = 1.8
du = 1.72
dv = 1.72

Formula:
((dy - 0.8)*da + maxwalk) - dtu = moonwalk velocity

answer - initial dash velocity = total moonwalk velocity

so what is the purpose of the 0.8 in the formula? the number of frames tilting a horizontal input before holding full back in the moonwalk direction after dash? so that number is the variable in execution of the moonwalk?

((22 - 1.4)*0.1 + 1.14) - 1.8 =
((20.6)*0.1 + 1.14) - 1.8 =
(2.06 + 1.14) - 1.8 =
(3.2) - 1.8 = 1.4 moonwalk velocity

1.4 - 1.72 = -0.32 total moonwalk velocity

So in other words, if that math is correct, Pichu doesn't have a 'practical' moonwalk, in that he doesn't really generate momentum that can be transferred to anything, he just kinda turns in place.
I'm not sure why you have added that last part, when you do "- dtu" in the first equation that is taking away the true initial dash velocity. So when you get the answer 1.4, that is saying that with a decently executed moonwalk, you will end with 1.4 units of velocity, which is pretty good.

Bare in mind this doesn't tell you the distance you move from the starting position, to do that you need to calculate the velocity on each frame and add that to a total distance. Although you can do (maxwalk - 0.1) - dtu + ending moonwalk velocity, to get a clue into whether you have moved from the starting point, where the answer being positive implies you do.

0.8 was a very inhumanly clean moonwalk, where you hit 0.6 on the lstick for 2 frames, so it's (dy - 2) * 1 + 2 * 0.6
 
Last edited:

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
oh okay gotcha. I had gotten confused by the 'compare this to the initial dash velocity for size' part

so the last part here [(dy - 2) * 1 + 2 * 0.6]
is what you simplified into (dy - 0.8)

so I can calculate the cleanliness of my moonwalks with this equation
by plugging in different values for tilt and number of frames

where the number of frames I'm tilting is subtracted from dy
and the degree of tilt is what is multiplied by that number of frames after the plus sign
and the '1' is the full tilt afterward


so with my decent moonwalk of 1.4, for this applying to Boost Run

I Moonwalk, then run 'forward' (the way I'm facing) for Stickywalk, then Run Turnaround


EDIT: After reading up on your explanation of Boost Run, it sounds like Pichu wouldn't be able to do it, since his Dash Acceleration and his Traction are the same, so it would cancel out any momentum he would gain during the Run Turnaround
 
Last edited:

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
oh okay gotcha. I had gotten confused by the 'compare this to the initial dash velocity for size' part

so the last part here [(dy - 2) * 1 + 2 * 0.6]
is what you simplified into (dy - 0.8)

so I can calculate the cleanliness of my moonwalks with this equation
by plugging in different values for tilt and number of frames

where the number of frames I'm tilting is subtracted from dy
and the degree of tilt is what is multiplied by that number of frames after the plus sign
and the '1' is the full tilt afterward


so with my decent moonwalk of 1.4, for this applying to Boost Run

I Moonwalk, then run 'forward' (the way I'm facing) for Stickywalk, then Run Turnaround


EDIT: After reading up on your explanation of Boost Run, it sounds like Pichu wouldn't be able to do it, since his Dash Acceleration and his Traction are the same, so it would cancel out any momentum he would gain during the Run Turnaround
Yup exactly. If you wanted to be even more thorough, you should probably use 0.9875 as your full tilt value, as that is what is inputted on most controllers in each 4 directions.

Yeh unfortunately his boost run will just cap out at max dash velocity
 

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
okay, now I have a handle on who can boost run (since even if your moonwalk isn't anything to write home about, you can still get something out of boost run if [accel > traction])



this next question isn't related to movement....
do you still have plans to finish out the rest of those heatmaps?
it's hard to play pichu, since he's not considered viable

but he has some decent OoS options

also, have you heard of the Frame Melee app for Android?

do you have any plans of getting involved in similar apps for Heatmaps?
 

schmooblidon

Smash Journeyman
Joined
Feb 18, 2014
Messages
496
okay, now I have a handle on who can boost run (since even if your moonwalk isn't anything to write home about, you can still get something out of boost run if [accel > traction])



this next question isn't related to movement....
do you still have plans to finish out the rest of those heatmaps?
it's hard to play pichu, since he's not considered viable

but he has some decent OoS options

also, have you heard of the Frame Melee app for Android?

do you have any plans of getting involved in similar apps for Heatmaps?
I don't really have the time tbh. I have a lot of projects going atm and heatmaps imo are not as useful or interesting as my other projects. They also take a long time to make as they require a lot of tedious labour work to create the vectors. Perhaps if I think of a quicker way to make them I'll consider it. As for apps, only if I have breaks in work and I need some cash, I don't really have any desire to otherwise.
 

Popertop

Smash Champion
Joined
Jun 6, 2006
Messages
2,131
Location
Houston (Clear Lake)
alright, cool man

thx for the prompt responses and attention to detail

I'll prolly float back here at some point if I have more questions about specific movement things
 

Dr3amSm4sher

Smash Cadet
Joined
May 26, 2015
Messages
54
Now it then seems odd that Marth has a slower Max angle wavedash velocity. But this is because marth one of the few who has a cursed wavedash (totally calling it that now). Where he only gains half the distance he should on the first frame.

I think I'll do a wavedash total distance comparison, that won't take long, i can get that out in a hour or so.
So did you ever find out why marth's wavedash is cursed? Also who else has a cursed wavedash?
 
Last edited:
Top Bottom