You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's 10% better to retrace its steps than to just say in place, so it oscillates back and forth, retracing the last segment of its path. This happens if it's for example on a highway and the goal is way down below, a GoalYLevel so it's all equal heuristic, so backtrack cost favoring is the tiebreaker.
The text was updated successfully, but these errors were encountered:
I think I know what's happening here... through chunk caching, it realized it had to make a large backtrace and new route. However, it cutoff that backtrack at the chunk load limit. Then, the next path it calculated was right back to where it started. It didn't continue the backtrack and around because it was better to just go for the easy heuristic improvement.
Maybe with the new movement cost verification lookahead in PathExecutor it might be safe to disable chunk cutoff but leave static cutoff? That would fix this...
With 462ccad (using the estimate from calculation phase) I think it's actually safe to disable load boundary cutoff. That should solve a ton of issues and recalculation woes.
It's 10% better to retrace its steps than to just say in place, so it oscillates back and forth, retracing the last segment of its path. This happens if it's for example on a highway and the goal is way down below, a GoalYLevel so it's all equal heuristic, so backtrack cost favoring is the tiebreaker.
The text was updated successfully, but these errors were encountered: