What causes pathfinding recomputed every tick for idle agents?

Agents request a fresh path each tick regardless of whether their goal or the map changed, so a large population pays full pathfinding cost continuously even while standing still.

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 Pathfinding Recomputed Every Tick for Stationary Agents

Quick answer: Cache each agent's path and reuse it until the goal changes or the map is edited along the route, recomputing only on actual invalidation.

If pathfinding dominates your profile even when agents are idle, you are recomputing paths that have not changed. A stationary agent with a fixed goal needs no new path. Cache paths and invalidate them only on real changes. Here is the fix.

How to fix it

1. Cache the path until the goal changes

Store each agent's current path and reuse it across ticks, recomputing only when the agent's goal changes rather than every tick by default.

2. Invalidate on relevant map edits

When the map changes (a wall built, a door locked), invalidate only the cached paths that cross the affected cells, leaving unaffected paths intact.

3. Throttle re-paths under contention

Limit how many agents may recompute paths per tick and queue the rest, so a sudden invalidation event does not trigger a pathfinding storm that spikes the frame.

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.

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.