Control stick buffering

[Y-L]

If you slowly move the stick you can up tilt instead of up smash while holding the stick fully up (ignoring tap jump). So what determines whether or not the stick input is up smash or up tilt? Is it the velocity of the stick? Or if the stick passes a threshold value x amount of frames before the button press? Or something else?

 

[Achilles1515]

Up-Smash with control stick performs the following checks in order:
1) Instant A press
2) Control stick Y axis > 0.66
3) Control stick Y axis cardinal change within last 4 frames

Cardinal change occurs when stick is moved past 0.25.

(It could be "greater than or equal to" 0.66 but I didn't look too intently.)

Many actions requiring stick inputs follow this "meet threshold within frame window" logic.

https://smashboards.com/threads/mel...-here-in-the-op.247119/page-116#post-18806802

In regards to that shield dropping post, notice the frame window difference between spot dodging and shield dropping. Because the timing for spot dodging is tighter, you can do something as follows to buffer a shield drop:

Land normally on a platform. On the first frame of landing lag, hold L and -1.00 control stick y-axis (all the way down). Even though your stick is all the way down (which you normally associate with spotdodging), you will shield drop because the 4 frame window check for spot dodging fails.

 

[Y-L]

Up-Smash with control stick performs the following checks in order:
1) Instant A press
2) Control stick Y axis > 0.66
3) Control stick Y axis cardinal change within last 4 frames

Cardinal change occurs when stick is moved past 0.25.

(It could be "greater than or equal to" 0.66 but I didn't look too intently.)

Many actions requiring stick inputs follow this "meet threshold within frame window" logic.

https://smashboards.com/threads/mel...-here-in-the-op.247119/page-116#post-18806802

In regards to that shield dropping post, notice the frame window difference between spot dodging and shield dropping. Because the timing for spot dodging is tighter, you can do something as follows to buffer a shield drop:

Land normally on a platform. On the first frame of landing lag, hold L and -1.00 control stick y-axis (all the way down). Even though your stick is all the way down (which you normally associate with spotdodging), you will shield drop because the 4 frame window check for spot dodging fails.

Thank you for the informative post. Very interested in the game logic.

 

[Y-L]

Up-Smash with control stick performs the following checks in order:
1) Instant A press
2) Control stick Y axis > 0.66
3) Control stick Y axis cardinal change within last 4 frames

Cardinal change occurs when stick is moved past 0.25.

(It could be "greater than or equal to" 0.66 but I didn't look too intently.)

Many actions requiring stick inputs follow this "meet threshold within frame window" logic.

https://smashboards.com/threads/mel...-here-in-the-op.247119/page-116#post-18806802

In regards to that shield dropping post, notice the frame window difference between spot dodging and shield dropping. Because the timing for spot dodging is tighter, you can do something as follows to buffer a shield drop:

Land normally on a platform. On the first frame of landing lag, hold L and -1.00 control stick y-axis (all the way down). Even though your stick is all the way down (which you normally associate with spotdodging), you will shield drop because the 4 frame window check for spot dodging fails.

Does the game check for control stick angle as well? Following the input map: http://imgur.com/a/2na5b

 

[Y-L]

Achilles1515 According to Kadano's input map, does the game check for two different scenarios? For example, up b. Would it be correct to say the game checks if the stick's x position is in x the neutral b region and the y position is greater than the y neutral b region OR the stick's y position is greater than the first halfish of the up b region AND the stick angle is between that angled up b region? Is that how the game checks for an up b input?

edit: Kadano's map

 

[Achilles1515]

Achilles1515 According to your input map, does the game check for two different scenarios? For example, up b. Would it be correct to say the game checks if the stick's x position is in x the neutral b region and the y position is greater than the y neutral b region OR the stick's y position is greater than the first halfish of the up b region AND the stick angle is between that angled up b region? Is that how the game checks for an up b input?

1) That is Kadano's map, if I am not mistaken. I've never made such a thing.

2) Y-joystick greater than 0.55 while instant pressing B is an up-b input. The game doesn't check joystick angles for inputs.

3) Upon first glance, that map confuses me. In the WAIT action state interrupt, side-b is checked before up-b. Requirement for side-b is for x-joystick magnitude to be greater than 0.60. So I don't understand why the side-b input area isn't straight vertical lines at 0.6 and -0.6. Use the Magus physics feature in 20XX 4.05 Develop Mode to see your joystick decimal values and let me know if you can ever do an Up-B out of WAIT action state with your x-joystick greater than 0.6. That input map is suggesting this is the case, but I don't think it is. I might be missing/misunderstanding something though. But it's also a factor of joystick resolution (1/80) and the octagon gate so....

(Again, the joystick thresholds mentioned above are probably "greater than or equal to" but I'm at work and didn't check too intently.)

 

[Y-L]

1) That is Kadano's map, if I am not mistaken. I've never made such a thing.

2) Y-joystick greater than 0.55 while instant pressing B is an up-b input. The game doesn't check joystick angles for inputs.

3) Upon first glance, that map confuses me. In the WAIT action state interrupt, side-b is checked before up-b. Requirement for side-b is for x-joystick magnitude to be greater than 0.60. So I don't understand why the side-b input area isn't straight vertical lines at 0.6 and -0.6. Use the Magus physics feature in 20XX 4.05 Develop Mode to see your joystick decimal values and let me know if you can ever do an Up-B out of WAIT action state with your x-joystick greater than 0.6. That input map is suggesting this is the case, but I don't think it is. I might be missing/misunderstanding something though. But it's also a factor of joystick resolution (1/80) and the octagon gate so....

(Again, the joystick thresholds mentioned above are probably "greater than or equal to" but I'm at work and didn't check too intently.)

My mistake on the creator of the maps. Anyway, I find it strange that the game isn't checking joystick angles. When you look at the wait A grounded options it seems as if its definitely necessary to check for control stick angles. I'll experiment with this when I get home and report back. Kadano any information to add?

 

[Y-L]

1) That is Kadano's map, if I am not mistaken. I've never made such a thing.

2) Y-joystick greater than 0.55 while instant pressing B is an up-b input. The game doesn't check joystick angles for inputs.

3) Upon first glance, that map confuses me. In the WAIT action state interrupt, side-b is checked before up-b. Requirement for side-b is for x-joystick magnitude to be greater than 0.60. So I don't understand why the side-b input area isn't straight vertical lines at 0.6 and -0.6. Use the Magus physics feature in 20XX 4.05 Develop Mode to see your joystick decimal values and let me know if you can ever do an Up-B out of WAIT action state with your x-joystick greater than 0.6. That input map is suggesting this is the case, but I don't think it is. I might be missing/misunderstanding something though. But it's also a factor of joystick resolution (1/80) and the octagon gate so....

(Again, the joystick thresholds mentioned above are probably "greater than or equal to" but I'm at work and didn't check too intently.)

Ok so I did some TASing in Dolphin and here are my findings:

- It is greater than or equal to for the stick position, an x position of 0.6 results in forward b
- I could not get an up b with an x position greater than 0.6. The best stick coordinates I could produce was (0.61250, 0.78750) which resulted in a forward b.

It seems reasonable that the stick map could be wrong. Still confusing about the other maps though as they seem angle reliant. Perhaps they are inaccurate like this one?

 

[Kadano]

The input maps assume hardware (controller level) values, not in-game values. Pixel grid x,y follows control stick hardware levels x,y. Color of pixel shows corresponding output (which, in some maps, is the in-game analog levels).

Mapping by in-game analog levels, which are essentially limited in the form of a circle, would not work well with the square shape of computer vision. Hardware levels are "square" too, so I chose them as the reference.

If you try to create a map that maps by in-game values, I'm sure you'll understand why I didn't do it like that. SplitsOnTrees also made a thread on analog inputs somewhere in Melee Discussion which should explain that too.

 

[Y-L]

The input maps assume hardware (controller level) values, not in-game values. Pixel grid x,y follows control stick hardware levels x,y. Color of pixel shows corresponding output (which, in some maps, is the in-game analog levels).

How do the hardware values vary from the in game values?

 

[Kadano]

How do the hardware values vary from the in game values?

See https://smashboards.com/threads/the-specifics-of-trajectory-di.437171/, which is the thread I hinted at in my last post.

Edit: I made a simple overlay where the hardware values that are scaled down to in-game limits are darkened out:

While it might seem like you could simply autocrop the map so that the circle in the middle is left, there are actually some angles that cannot be achieved within that circle. Also, restricting the maps to in-game values makes them much less useful since this way the interaction between the ranges and the octagon gate shape is omitted.

 

[Y-L]

See https://smashboards.com/threads/the-specifics-of-trajectory-di.437171/, which is the thread I hinted at in my last post.

Ah, this makes sense now. So the radial sections of the maps are due to a hardware value being rounded down in game since it is outside the circle of inputs

 

[Kadano]

Ah, this makes sense now. So the radial sections of the maps are due to a hardware value being rounded down in game since it is outside the circle of inputs

Yes, I also edited in an illustration of that and additional text explanations to my last post here.

 

[Y-L]

Okay one more question for Kadano
If the radial patterns are due to rounding of the games input circle, what happens for jab/ftilt/utilt/dtilt? Its radial but its not cut off by the radius of the games input. It could be explained by being rounded by a smaller circle but I'm not sure how that's implemented

 

[Y-L]

Do we know what the game checks for to perform an ftilt/jab from wait? If it's simply x position >/< 0 depending on direction then that would confirm rounding to a smaller circle however I don't see how that would be implemented. Otherwise it looks like some sort of angle would be needed? It's strange because the radial pattern of the tilts is at a different angle than the smash attack radial patterns. Also in the picture above it looks as if ftilt/jab is checked before utilt/dtilt as you can see overlap which seems to me more evidence for option 1?

 

[Y-L]

Update: I think I have it figured out now.
After some experimenting I think I have it figured out. Turns out x = abs(0.7y) matches up perfectly with the jab radials. The following programmatic example should match up perfectly with the input map.

1) The game first checks for fsmash (x >= 0.80), (x <= -0.80)
2) Check for utilt (y >= 0.66)
3) Check for dtilt (y <= -0.66)
4) Check for jab/ftilt based on direction (x >= abs(0.7y)) , (x <= -abs(0.7y))
5) Check for utilt (y > 0)
6) Check for dtilt (y < 0)
7) else jab

If there's anything in the game code confirming steps 4-6 that would be nice to know

 

[Achilles1515]

For FTilt (facing right),

1) check for instant A
2) check x-joystick > 0.25
3) check joystick angle is within +- 50 degrees. 0 degrees is straight right.

Then goes into the execute FTilt function which checks for the different types of ftilts.

 

[artifice]

I think their are two misnomers in the explanations/conclusions of this thread.

The first being that the game doesn't "check" for angles - which is correct only in that melee itself does not care about the angle of the control stick [except in some specific cases apparently] , however the hardware inputs do consider the angle before giving melee its "system-direct" values. which is to say...the final input value of one axis actually can effect, and be effected by the other axis input value. This happens primarily for the cases in which this thread claims values are "rounded" - which is the second misnomer I had previously referenced. That being just that, rounded isn't a precise or accurate term for what happens to the values in those cases.

To be more clear, an example is best...

The highest magnitude of input values results from an input of a 45 degree angle in the control stick. the end result of that input being system direct values of (.7, .7) being displayed in melee debug. It is no coincidence that:

sin(Rad(45)) = .7071
cos(Rad(45)) = .7071

and to go one step further... to get that "45" angle you could say that:

angle(x) = ATAN2(input.x / magnitude(input.x and input.y) * (180/pi)
angle(y) = ATAN2(input.y / magnitude(input.x and input.y) * (180/pi)



Notes:

* I'm no math wiz, def take constructive criticism of maths...

*these things only apply to input values before melee receives them, prolly. and nothing here derived from melees code or address hacking.

*I can't say for sure but I believe that their are two cases, two formulas for ending input values. use of the formulas may be determined by the magnitude of the raw input values (magnitude of the absolute value of each axis distance from center value)...