What causes a dodge roll chaining into a continuous glide?

You let the dodge input start a new roll at any time, so spamming it re-applies the dodge velocity every press and the player glides across the floor without ever recovering.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a Dodge Roll Canceling Into Itself and Turning Into a Glide

Quick answer: Lock out new dodge inputs while a roll is active and add a recovery cooldown after it ends, so each dodge must fully resolve before another can begin.

A dodge that can be re-triggered mid-roll becomes an infinite slide. Gate the input behind the active roll and a cooldown. Here is how.

How to fix it

1. Block input during the roll

While the dodge state is active, ignore further dodge presses. The current roll must finish its full duration and movement curve before another can start.

2. Add a recovery cooldown

After the roll ends, start a short cooldown during which dodge is unavailable. This prevents back-to-back rolls from blending into a continuous slide.

3. Drive the roll off a fixed duration

Run the dodge for a set time with a decaying velocity curve, then return control. A fixed timeline ensures the roll always resolves rather than being restartable at will.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Reproduce it once with full context and the fix writes itself. The hunt is the expensive part.