Instant Air Dash (IAD): What it is, how it works, and why it's probably a bug

CDranzer

Member
This may be a little divisive, but here goes.

Instant Air Dash is a relatively well known(?) "movement tech". The premise is simple:
A fairly standard form of movement is to perform a jump into an air-dash into a slide. It's easy to perform, and fairly benign. If, however, you jump and then air-dash with as little delay as possible (i.e. "instantly" air-dash), your resulting slide will be slightly faster and carry more momentum. If you can chain these over a long distance, you can get movement speed increases of around ~20% over standard air-dash sliding.

In order to pull it off, you have to essentially jump and dash at the same time. It does seem to be frame-perfect input - even being slightly off will result in either a ground dash, or a regular jump dash.

So what, exactly, is going on here?

A standard air-dash works as follows: Gravity and air friction are disabled, you get a burst of speed, and then after a short delay gravity and air friction are re-enabled. You start falling, and your forward momentum quickly returns to normal.

But there's also the issue of slides. With slides, there are actually two kinds: Ground slides, and air slides. Ground slides seem to cap your forward momentum, and you can't seamlessly jump or dash out of them. Air slides on the other hand (that is, slides that happen when you fall from the sky) preserve forward momentum and can be cancelled out of by jumping or dashing. This is one of the main reasons why the jump-dash into slide is generally faster than just slide-dashing in general.

Now, If you examine the IAD without the slide, you may notice something that appears to be an animation cancel of sorts. Your air-dash animation seems to stop a little early. That's not the issue, but it does give us a hint as to what's happening: The animation cancel is the result of your character hitting the ground.

Essentially, when you IAD, what's actually happening is you're air-dashing very close to the ground. The moment you come out of it, gravity starts taking effect, meaning you hit the ground almost immediately, before your mid-air momentum has a chance to go down. Therefore, if you start sliding the moment your air-dash ends, the majority of your air-dash momentum will be carried into a slide before it has a chance to be reduced by mid-air friction. And keep in mind, this is an air-landing slide, which can itself be cancelled into another IAD, preserving and even boosting your momentum even further.

So why did I post this on the bug forum instead of making a youtube video?
Because I believe this is not an intentional mechanic, and for two main reasons:
Firstly, all other mechanics seem to want to prevent your maximum dash momentum from compounding: Ground slides have stronger momentum cancelling and can't be chained, and air-dashes lose momentum very quickly while airborne.
Secondly, while the execution requires extremely precise timing (and is somewhat stressful on the hands as a result), it is absolutely trivial to write a macro for.

I expect to be told I'm complaining about nothing and that this is something that shouldn't be removed because it's a fringe mechanic that doesn't have any significant impact. I am also expecting to be told this is a critical movement mechanic that should not be removed because it's key to high-end gameplay. I expect to be told both these things, at the same time, by the same people, in spite of them being directly contradictory to one-another.

Personally, I think that if this mechanic were to be kept, (and I can see an argument for it,) I'd rather see sliding and chain-sliding be normalized so you can still do the whole zooming-around thing with just ground slides, if only to mitigate the RSI risk.
 
Keep in mind you can bind your dash to 2nd button like scroll down and it makes it trivial to do that.
Most of fun movement tech in source games is bugs and it is essential to keep those not ground breaking ones to make game fun.

I AM ALL FOR MAKING IT EASIER, that is not a question, but against deleting it.
 
Keep in mind you can bind your dash to 2nd button like scroll down and it makes it trivial to do that.
Most of fun movement tech in source games is bugs and it is essential to keep those not ground breaking ones to make game fun.

I AM ALL FOR MAKING IT EASIER, that is not a question, but against deleting it.
Incidentally, you can't actually bind a single key to both jump and dash. You can do a weird thing where you alt-bind a key and for some reason you don't need to hold alt, which is technically a bug in and of itself, but not a direct dual-bind.
 
Incidentally, you can't actually bind a single key to both jump and dash. You can do a weird thing where you alt-bind a key and for some reason you don't need to hold alt, which is technically a bug in and of itself, but not a direct dual-bind.
I didn't mean binding 2 keys to one button, i meant like, reducing strain on keyboard hands by making pinky not have to both press dash and slide and jump between those 2, you can space +mwheel down then CTRL, repeat.
 
Your explanation contradicts your conclusion and actually argues that this is not a bug and just a natural consequence of how the systems interact with eachother.

Basically you aren't suggesting a bug fix. You are suggesting a rework of how the physics work in general which would have greater consequences than just removing IAD.

Also IAD is probably one of the least straining and accessible higher level movement mechanics (I have plenty of experience with hand/finger strain lol).

It doesn't require specific keybinds unlike the ridiculous amount of scrollwheel only mechanics (this should be fixed). For instance: I jump with right click (I have done this in all games for many years) and dash with ctrl and can IAD with near 100% accuracy. Some people bind C,V, or B to dash and just press both space and said key with their thumb. It is just pressing two buttons at the same time (if you want to be technical, jump should be read first but beyond that, it simply isn't necessary to time your inputs).

IAD is as "buggy" as a superglide. It's fine. Unproblematic. Low barrier of entry. And accessible to everyone on every setup. Just a natural interaction between systems.

Ask yourself: how would IAD be patched out without affecting any other interaction and game feel?
 
Your explanation contradicts your conclusion and actually argues that this is not a bug and just a natural consequence of how the systems interact with eachother.
A semantic debate about what constitutes a "bug" is largely irrelevant in this case. This thread is here because IAD is an unintended edge case with undesirable side-effects.
Ask yourself: how would IAD be patched out without affecting any other interaction and game feel?
Firstly, that clause is superfluous. Solutions aren't always direct. If it were up to me, I'd create parity by allowing the player to chain ground dash-slides together to achieve the same effect as IAD without the misery of frame-perfect inputs, and then balance around that. I'd "fix" IAD by making it redundant.

Secondly, even if I knew the exact internal workings of the engine, my personal ability to propose a solution is completely immaterial. My post exists to highlight a problem more than it exists to propose a solution.

Thirdly, your prompt is not as high a bar as you think it is. The most trivial form I can think of would be to extend the zero-gravity state of an air-dash for an extra few frames so that air friction has a chance to kill the chainable momentum. If the miniscule extra distance granted by that change inexplicably becomes game breaking, shorten the length of an air dash by an equivalent miniscule amount.
 
Last edited:
Why so aggressive...
Your thread is advertised as and largely consists of an explanation of why you believe IAD is a bug. I argue why it is not one, and while no one was thinking "let me add IAD to the game", also can't even be considered unintended. Why propose the idea that it is a bug if I am not allowed to challenge that? You can't shut things down by just saying "arguing semantics".

Suggesting solutions is just a good way to pick apart what the issues really are. In your initial post you talk about removal but once I asked for solutions you brought up parity as an alternative.

I never thought it was high bar lol. It's just good to think about things. Simple thought experiments. What's interesting though is I asked for solutions that don't alter game feel and I explicitly mentioned that you are actually suggesting changes to the physics (which is fine but should probably be posted to gameplay ideas instead).

Your suggestion then included... changes to game feel and altering of the physics (whether assumed to be miniscule or not) even in cases where an IAD is not being attempted.

Looking back at your initial post though it seems like you weren't here for a discussion anyways and had already created an imaginary enemy ready to project onto anyone willing to challenge you. My fault I guess.
 
Why so aggressive...
Not aggressive, just direct.

If I had to formally categorize IAD, it'd be "physics exploit". It's not that disruptive, but it is what it is. There are plenty of physics exploits in games. There are several within the source engine itself. People use them all the time. Sometimes they become defacto features simply by virtue of the devs ignoring them for an extended period. Deadlock is in an early development phase, which offers a rare opportunity for such things to be addressed while they're still in a transient state.

People who abuse exploits do not like their abuse being labeled as such, because it increases the likelihood that such exploits will be identified and removed. This is why people call things like this "movement tech". It's a legitimization strategy. I have zero patience for it. If an anomalous mechanic has a path to legitimization, it should be explored directly.

The reason I suggested parity is because I can recognize the entertainment value of chaining dashes and slides. But if we're going to consider chaining dashes and slides as a movement mechanic, I'd prefer to see it formalized in some way so it doesn't require frame-perfect simultaneous inputs.

The reason I proposed adding extra anti-gravity is because it's the most implementationally simple change that would have the least impact. The problem with a "pure" solution is that when physics exploits like these show their head, they're the result of an unaccounted edge case, and the first step is deciding what should be happening. Any change I suggest is going to have some impact on some gameplay facet because that's what it means to fix an exploit.
 
> Personally, I think that if this mechanic were to be kept, (and I can see an argument for it,) I'd rather see sliding and chain-sliding be normalized so you can still do the whole zooming-around thing with just ground slides, if only to mitigate the RSI risk.

Sounds like this belongs in Gameplay Feedback, post it there instead.
 
Whether its a bug or not doesn't matter because Valve ultimately decides whether it stays as a feature or not. They've done the same before for "bugs" (HMC, Corner Boosts), keeping, removing, or modifying them despite being bugs from the start.

If you have thoughts on whether IAD should be a part of Deadlock in its current state, then post about those. You won't get anywhere trying to "convince" Valve its a bug (because they know it is).
 
The primary purpose of this thread is to identify an oversight/bug/exploit.

Because of the nature of bug, the thread also serves a secondary purpose of discussing the tangential gameplay issues surrounding it. This is not unusual. If people want to discuss the issues, I'm willing to engage, because I'm invested in such things.
 
IAD is a bug, no amount of weird dogpiling is going to change that fact. Bug reports are a legitimate part of the feedback process.

I find it very weird that people have the inherent need to run damage control over IAD for some reason. Just because it's "fun" to use, doesn't mean that it isn't a bug.
 
Back
Top