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
{{ message }}
Repository navigation
If Settler AI can't complete the next step in its path, it gives up and stays where it is forever #213
This definitely occurs if the settler's destination is blocked.
How to reproduce:
Figure out where an AI is sending its settler by looking at the logs
Send a unit to that tile and block it
The AI Settler will hit the Exception that causes it to print "Could not get next part of path for unit", with unit info.
The AI Settler will just stay on its current tile forever
The immediate cause of this is TilePath to the destination running out of locations after the settler tries (but fails) to move to the occupied tile; the next time it throws an exception due to the TilePath queue being empty, and then it just is stuck.
At a higher level, though, this is because we aren't validating that the path (or even just the next step in the path) remains valid. But to fix that, we'll need to enhance the pathfinding algorithm to not route the unit through a rival AI's unit. And it probably doesn't make sense to invest in making BFS better to address that, thus this should not be fixed before #100 unless it becomes more important for some reason.
We might also have odd behavior if a non-final step in the path is blocked, as then the unit likely tries to move to a non-adjacent tile the next turn, but I haven't verified that exact scenario.
Leaving off of Carthage for now as I'm not aware of this being common, and we have enough Settler AI enhancements to make already.
A reproduction test confirmed the original crash is gone — TryToMoveAlongPath repaths and fails gracefully with Result.Error instead of throwing "Could not get next part of path". However, it surfaced a remaining stuck-forever path: FindSettlerLocation kept re-picking a destination the settler can't reach (e.g., a rival unit parked on it), so the settler re-evaluated the same impossible task every turn without ever building.
Fixed in PR #1002 by excluding tiles occupied by foreign units from settlement candidates, with regression tests. I recommend closing this as fixed once the PR merges.
Activity
QuintillusCFC commentedon Jun 16, 2022
Noticed today that the settler was attempting to settle at 66, 34 (Coast on Coast). So there's another possible cause of it.
Billytifft commentedon Sep 23, 2026
A reproduction test confirmed the original crash is gone —
TryToMoveAlongPathrepaths and fails gracefully withResult.Errorinstead of throwing "Could not get next part of path". However, it surfaced a remaining stuck-forever path:FindSettlerLocationkept re-picking a destination the settler can't reach (e.g., a rival unit parked on it), so the settler re-evaluated the same impossible task every turn without ever building.Fixed in PR #1002 by excluding tiles occupied by foreign units from settlement candidates, with regression tests. I recommend closing this as fixed once the PR merges.
Rework C7-Game#213 fix: repath to a new destination when the chosen o…
Add TODO for a longer-term fix than exclude-and-repick (C7-Game#213)
Trim comments on the C7-Game#213 rework
Avoid routing through rival cities; don't send settlers to unreachabl…
Drop C7-Game#371 rival-city routing tests from this PR
Settler re-picks a destination when its chosen spot becomes unreachab…
SettlerLocationAI: invalidate yields on city owner change, don't reta…