What causes root motion and scripted movement both writing the transform?

Both the Animator's root motion and your movement script write position each frame, so they overwrite each other and produce stutter, drift, or doubled speed.

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 Root Motion and Scripted Movement Fighting Over the Same Transform

Quick answer: Choose a single authority per state: route root motion through OnAnimatorMove into your controller, or disable Apply Root Motion and drive movement purely from code.

When root motion and a script both move the character, they fight and the result jitters. Give one system control at a time. Here is how.

How to fix it

1. Pick one authority per state

For locomotion you may want full script control (disable Apply Root Motion); for attacks and dodges you may want animation-driven root motion. Switch authority cleanly on state entry.

2. Funnel root motion through code

If you keep root motion, read animator.deltaPosition in OnAnimatorMove and feed it to your CharacterController Move call, so one code path applies the final movement.

3. Never apply both at once

Ensure you do not also add scripted displacement in the same frame root motion is applied, or the speeds add and the character moves twice as far as the animation intends.

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 Unity 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.