On Ledgedashing and PODE



PODE and more generally, dashback have been hot topics as of recent, especially considering the recent introduction of Universal Controller Fix (hyperlink). This article will focus on the lesser known topic of ledgedashing, how to improve a ledgedash, and how a controllers PODE can make its ledgedashes good or bad, or favor one method of ledgedashing over another.


Introduction

Recently, I’ve been switching to and from various controllers after my main controller began acting erratically. Specifically, I couldn’t ledgedash as well as I used to, and I was fairly confident about the accuracy of my inputs. I chalked it up to the control stick becoming looser with age (I’ve been using it for about 2 years now), and resolved to learn to ledgedash with back in order to ledgedash more consistently across controllers. However, as I continued to test with my controller and a variety of potential substitutes I came across some very interesting phenomenon and realizations on why my inputs did what they did.


PODE

PODE, or the potentiometer oddity degradation effect, is a phenomenon which causes control stick inputs to be read in a delayed fashion, meaning some inputs are “skipped” if you move the control stick fast enough. As I switched from controller to controller, some of which had PODE and some of which did not, I noticed that they had an incredibly tangible effect on my ledgedashing. I first learned to ledgedash with the “optimal ledgedash angle”, described here by Kadano. As I tested this method on various controllers, I was struck that some controllers kept doing regular get up, while one controller in particular never failed to let go of ledge, no matter how far I pushed the angle, far past what Kadano had documented. Eventually, I turned on the input viewer in 20XX and saw what was happening. To demonstrate, I perform a single input diagonally downward and to the right. The potentiometer, however, reads something very different. Let's examine the input display.

A diagonal right input?

The controller I was using has strong horizontal PODE, so left/right inputs are delayed in a manner similar to buffering. However, vertical inputs are unaffected, so even for angle close to horizontal, the control stick first registers a nearly straight down input, then jumps to the horizontal angle. This results in amazing ledgedashes using the Kadano method, since it pretty much never does regular get up and guarantees a drop from ledge. Here are the numbers, frame by frame, for an input straight right.

With PODE

Without PODE

This lines up pretty well with the input display's showing above. As a interesting sidenote, this particular controller’s PODE is so strong, the delay in inputs was visible in realtime. Here’s a comparison of quick dashdance inputs on the PODE controller vs a normal controller. Note how the stick seemingly teleports from one side to neutral to the other on the PODE inputs, without as many intermediate polls. Use frame by frame to see exactly what's happening.

PODE

No PODE

Here’s a comparison of spinning the stick in circles. Note the choppy, frenetic movement on the PODE controller. Again, frame by frame is pretty cool to see here.

PODE

No PODE


Optimizing Ledgedash

Armed with this new information, we can apply it to our advantage and modify the method by which we ledgedash to best suit the controller. At the start of this crusade, I had talked to various top players and examined players like Plup and Leffen who ledgedash extremely consistently using an alternate method: the “back” ledgedash. I have always ledgedashed with the Kadano method, which I’ll refer to from this point onward as “down” ledgedashing, since the input is generally in the downward direction to let go of ledge. However, “back” ledgedashers drop from ledge by pressing away on the stick, which has both pros and cons. The main pros are improved consistently dropping from ledge (fewer accidental regular get ups) and no accidental fastfall inputs. Hoping to improve my consistency across controllers, I spent a few weeks grinding out this method until I had it at a decent success rate. On my PODE controller, I could usually get anywhere from 12-15 frames of intangibility using the down ledgedash. But even after investing many hours into back ledgedashing, I consistently was losing several frames of actionable intangibility in comparison. I was again confident in my inputs, so I again recorded myself doing both methods and again, realized something was off. I’d been practicing on my PODE controller, since that’s the one I’m most likely to use in tournament, and hadn’t spent much time trying the back method on any other controllers. As a result, I forgot that PODE would invariably effect my back ledgedashes as well. The main drawback to the back ledgedash is that the stick needs to cover more distance in a short time, which requires some very quick inputs that ideally are frame perfect. Here’s a comparison of the inputs for back vs down: For the back ledgedash, PODE delays both the initial back input as well as the forward input that happens afterward, reducing both the distance and intangibility of the ledgedash.


Ledgedash Breakdown

Let’s do a breakdown to see exactly where the problems are. The timing and frame data varies from character to character, so for simplicity I’ll be focusing on my character of choice, Fox. However, the ideas are generally applicable to any character that utilizes ledgedashes. Ledgedashing is typically done as follows:

    1. Drop from ledge
    2. Double jump
    3. Airdodge onto stage

For step 1, we can break down ledgedashing further into “back” ledgedashing and “down” ledgedashing, depending on the input done to drop from ledge. Ideally, you want to double jump the frame after you drop from the ledge. Otherwise, you spend some time falling, which means that you’ll be vertically lower from the ledge and it’ll take more time to double jump above it, wasting intangibility frames, which of course means a worse ledgedash. In addition, it makes it easier to SD since airdodging too early means you won’t make it above the ledge and onto the stage. If you drop with down, then ideally you’ll want to use a light tap, to keep within the ledgedrop no fastfall zone shown above. If you get a fastfall, you are more likely to fall further if you don’t input a perfect double jump afterwards, which will lose frames for the ledgedash. In addition, you’ll want to angle your control stick slightly forward in order to make getting a good airdodge angle afterwards easier. This will take some practice to get used to and train your muscle memory so that you don’t accidentally do regular getups as often. If you drop with back, you avoid the fast fall issues, but you also have more distance to cover with your fingers/control stick, since you need to now move the control stick to the airdodge down position.

Down ledgedash

Back ledgedash

We want to double jump as early as possible, so that would ideally be the frame after dropping from the ledge. Here's where PODE gets involved. Supposing you have a controller with strong horizontal pode, and you perform the back ledgedash, the quick left/right flick causes some issues. Because of PODE, the input can become delayed, and as shown in the videos, the control stick can get "stuck" for a frame or two at one side of the stick. So in the event that our second input gets delayed, our double jump occurs not toward the stage as intended, but sometimes backwards or maybe straight up. This loses some actionable invulnerability frames, depending on your inputs. Jumping forward gives you some very important momentum that both lets you land earlier and move further during the waveland. Now that we know what we’re looking for, we can even see in realtime the effects of jumping backwards vs forwards for a back ledgedash.

Backward Jump

Forward Jump

Overlaid

The double jump and airdodge occurs on the same frame: the only difference is the jump direction. Another sidenote: even without PODE, this is a pretty important factor that a lot of players don’t take into account while ledgedashing. If the control stick is not registered as holding toward the stage during the double jump, the ledgedash will be significantly worse. As a result, I’ve begun skewing my input for my double jump towards being one frame late. Empirical testing shows me that I’m 90%+ consistent on aiming for two frame windows, so I’ll aim for double jumping either frame perfect or one frame late, which sacrificies only two frames of actionable intangibility at worst. This also prevents tournament winners from pressing the double jump a frame too early.

Conclusion/TL;DR

Main takeaways:

1. PODE affects which ledgedash method you should use! Both methods can result in consistent, near perfect ledgedashes, but adjusting for your controller might be more optimal than what you’re currently more comfortable with. Ideally, learn both methods and switch as needed.
2. If your controller has strong PODE, consider trying the down ledgedash method, and keep in mind that with very strong PODE, using the back method will probably cause you to lose frames, especially if you’re going for a tight, near perfect ledgedash.
3. If your controller does not have strong PODE, the back ledgedash is probably better and more consistent, since you don’t have to deal with accidental fast fall inputs and are less likely to do regular get ups from ledge by accident.
4. When doing back ledgedashes, perform the forward input toward stage on the frame after dropping from ledge, and then aim to do the double jump another frame afterward. This will give you the most consistent forward double jumps, since being one frame early means you’ll still get the forward jump, and will go a long way toward preventing tournament winners.

Happy ledgedashing!

Last edited April 16th, 2018