What causes attack-move units ignoring enemies along the path in Godot?

Attack-move is implemented as a plain move order, so units only check for enemies at the destination instead of scanning continuously while traveling.

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 Attack-Move Units Ignoring Enemies Along the Path in Godot

Quick answer: Tag the order as attack-move and run an acquisition scan each frame so units stop and engage any enemy that enters their range mid-path.

Attack-move should make units fight anything they pass, but if they march straight to the destination they are treating it as a normal move. The fix is a per-frame acquisition scan tied to the order type. Here is how.

How to fix it

1. Distinguish the order type

Store an order_type of MOVE or ATTACK_MOVE on the unit. Only attack-move units run target acquisition while moving.

2. Scan for targets each tick

While traveling, query nearby enemies within acquisition range. If one is found, pause path-following, engage it, and resume toward the original destination once it dies or leaves range.

3. Remember the destination

Keep the original goal so a unit that breaks off to fight returns to its attack-move path afterward instead of stopping where the fight ended.

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