Improve Stall Targeting Mode 'FIRST'

[candour]

The 'FIRST' targeting mode for stalls now uses the actual travel distance an enemy needs to cover to reach the goal, rather than just their progress through their current list of waypoints. This ensures consistent behavior even when enemies have paths of different lengths or when the path is redirected.

The implementation uses a BFS-calculated distance map ('pathDistances') that is updated only when the board geometry changes, maintaining high performance during the main game loop. Targeting now calculates the total remaining distance by summing the pre-calculated distance from the enemy's next waypoint to the goal and the axial distance from the enemy's current position to that waypoint.

---

PR created automatically by Jules for task 3429988393333102126 started by @candour

Summary by CodeRabbit

• New Features

  • Improved target selection for stalls so “First” targeting now follows path progress more accurately.
  • Game state now keeps track of route distances across gameplay transitions for more consistent behavior.

• Bug Fixes

  • Fixed cases where target selection could rely on the wrong enemy ordering.
  • Updated gameplay actions like placing, selling, and removing objects to refresh route distance data consistently.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Warning

Review limit reached

@candour, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 24 minutes and 40 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 53e099e9-d5df-448f-ba5c-7eb487242167

📥 Commits

Reviewing files that changed from the base of the PR and between c4917cd and 72dbbc8.

📒 Files selected for processing (2)

• app/src/main/java/com/messark/hawker/registry/Registry.kt
• app/src/test/java/com/messark/hawker/TargetingTest.kt

📝 Walkthrough

Walkthrough

The PR adds pathDistances to game state, recomputes it from the end position and blocked hexes across game-state transitions, and passes it into stall targeting. TargetMode.FIRST now scores enemies using those distances, with a new unit test covering the selection rule.

Changes

Path distances and targeting

Layer / File(s)	Summary
Distance state and helper app/src/main/java/com/messark/hawker/model/GameModels.kt, app/src/main/java/com/messark/hawker/utils/Pathfinding.kt	GameState adds pathDistances, and Pathfinding.calculateAllDistances() computes reachable axial distances from an end coordinate.
Lifecycle state recomputation app/src/main/java/com/messark/hawker/MainViewModel.kt	MainViewModel recomputes pathDistances during game setup, resume, reset, and level advancement before publishing state.
Board edit recomputation app/src/main/java/com/messark/hawker/MainViewModel.kt	MainViewModel recomputes pathDistances after stall placement, stall sale, undo sell, and pillar removal.
Targeting signature and FIRST scoring app/src/main/java/com/messark/hawker/registry/Registry.kt, app/src/main/java/com/messark/hawker/MainViewModel.kt, app/src/test/java/com/messark/hawker/TargetingTest.kt	selectTarget accepts pathDistances, DefaultStallBehavior uses them in TargetMode.FIRST, handleStallFiring() passes the state map through, and the new test covers the selection result.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• candour/towerpower#188: Updates the same StallBehavior.selectTarget / DefaultStallBehavior path and TargetMode.FIRST logic that this PR extends with pathDistances.
• candour/towerpower#149: Touches MainViewModel.handleStallFiring(), the same call site that now forwards state.pathDistances into target selection.
• candour/towerpower#156: Modifies the targeting pipeline around StallBehavior.selectTarget, which this PR continues by adding a new input to the same API.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 6.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly reflects the main change: improving the FIRST stall targeting mode.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch improve-stall-targeting-mode-first-3429988393333102126

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Build Successful! 🚀

Download APK

Note: This link will be removed when the PR is closed.

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0533f2bc-7c75-4ae7-94e4-644fed737ff7

📥 Commits

Reviewing files that changed from the base of the PR and between 4db6fc5 and c4917cd.

📒 Files selected for processing (5)

• app/src/main/java/com/messark/hawker/MainViewModel.kt
• app/src/main/java/com/messark/hawker/model/GameModels.kt
• app/src/main/java/com/messark/hawker/registry/Registry.kt
• app/src/main/java/com/messark/hawker/utils/Pathfinding.kt
• app/src/test/java/com/messark/hawker/TargetingTest.kt

[github-actions]

Build Successful! 🚀

Download APK

Note: This link will be removed when the PR is closed.