Flame Dash

"

sfangwb wrote:

Only thing I have to say about Flame Dash is that the targeting is a little bit wonky. If you don't shift-click and click out of the skill's maximum range, you walk over before teleporting. This can be kind of clunky in the middle of chaotic fights. Consider just making your character just teleport the maximum range in the direction clicked if the player clicks outside of the skill's range.

Aside from that, it does what it's supposed to do. No complaints.

Wow. I came here to write about exactly this (+1). This twisted behaviour is unintuitive and makes it unreliable.

It also makes the quality bonus useless, because what is the point of increasing the cast rate, when it doesn't immediately perform the dash, but dilly-dallys to some unknown point first?! The increased cast rate simply diminishes when the entire duration of this twisted behaviour is more or less a random amount of time (the walking time + dash).

Also the argument of this twisted behaviour being somehow important is mood. The cumulative DoT damage is a lot stronger than the hit damage. Even if you were using it for the purpose of an attack would you not really care where exactly you land, but only that you don't land directly on the target. If one wanted to land directly on the target are there also other skills available for that purpose such as Shield Charge, which don't need to have their behaviour copied by Flame Dash, but rather should one want more diversity among the skills and not more of the same.

Further, it is irrelevant if the end point is a defined point (therefore can relied upon) when the starting point is unknown. For example... say I wanted to avoid Shocking Ground and hence dash to a point across a patch of Shocking Ground. I can choose a point free of it beyond the patch, but what does this give me? I might be walking a fair bit over Shocking Ground first before the dash, because the start point isn't exactly known. What I wanted to avoid - not to walk over Shocking Ground - can still occur. So it remains unreliable even when the end point is known.

It should get swapped with its non-shift behaviour. Please change it with the next evaluation.

Edit: I've read up on the thread and added some counter arguments to the devs' reasoning and why the current behaviour isn't as sound as they believe it to be.