Credit Baritone, and adopt its octile + Y heuristic shape#9
Open
XaXayo12 wants to merge 3 commits into
Open
Conversation
Two follow-ups from review: 1. Specific Baritone credit. The cost constants and the heuristic come from Baritone (Leijurv & contributors, https://github.com/cabaletta/baritone, LGPL-3.0). Named the exact sources (ActionCosts, GoalXZ, GoalYLevel) in costs.ts, goals.ts, docs/MovementCosts.md and a README Credits section. 2. Heuristic, compared to Baritone. Baritone splits the estimate into a horizontal "octile" part (GoalXZ: diagonal run + straight run) and a vertical part (GoalYLevel: jump up / fall down), and scales by the SPRINT cost so it is admissible (optimal paths). Adopted that SHAPE (heuristicXZ + heuristicY in goals.ts) instead of the rough 3D-Euclidean distance. Kept the WALK weight rather than Baritone's sprint weight, for a measured reason: this A* uses a plain binary heap with no f-tie-breaker, so the admissible sprint weight floods an equal-cost plateau on open ground (a flat 150x40 goal: ~4300 nodes visited vs ~150 with the walk weight, same path). Baritone avoids that with tie-breaking + short segments we do not have. Walk weight keeps the fast beeline; node counts are identical to before. Verified: build + ts-standard clean, 31/31 tests pass, deterministic bench shows identical visited/generated node counts to the previous heuristic.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bd349ee80e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ristic Review catch (chatgpt-codex): isEnd() used heuristic() as a distance gate (`dist > this.distance + 3`). Now that heuristic() is the octile+vertical TICK estimate, a normal close look (e.g. standing diagonally adjacent to a floor block, ~1.3 blocks away) scores ~7.6 ticks and is rejected before the raycast; the old Euclidean-scaled value was ~6.1 and passed. Use distHeuristic() (real block distance) for the gate, which is what `this.distance` is measured in. Affects GoalLookAt and its subclasses GoalMineBlock / GoalPlaceBlock.
Review catch (deep review): GoalBlock.distHeuristic multiplied by COST_HEURISTIC (tick units) while every other goal's distHeuristic returns raw block distance (GoalNear, GoalNearXZ, GoalLookAt, GoalFollowEntity). The only magnitude consumer is PartialPathProducer.maxPathLength = min(partialPathLength, goal.distHeuristic(start)), compared against result.path.length (a move COUNT). So GoalBlock's inflated value (~4.6x) let a GoalBlock partial segment grow ~4.6x longer than the same-distance GoalNear/GoalNearXZ segment before being cut. Pre-existing inconsistency surfaced while reviewing the heuristic changes; drop the factor so all goals agree. Verified: build + ts-standard clean, 31/31 tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #8 (tick-based costs), which merged before these two review items landed.
1. Specific credit to Baritone
The cost constants and the heuristic come from Baritone (Leijurv and contributors, LGPL-3.0). Named the exact sources where they are used:
costs.ts: theActionCostsinterface for the tick constants.goals.ts:GoalXZ/GoalYLevelfor the heuristic.docs/MovementCosts.mdand a new README Credits section.2. Heuristic, compared to Baritone
Gen asked to compare
goals.tsto how Baritone handles its heuristic. Baritone splits the estimate into a horizontal octile part (GoalXZ: a diagonal run plus a straight run) and a separate vertical part (GoalYLevel: jump up / fall down), rather than one 3D straight-line distance. I adopted that shape (heuristicXZ+heuristicYingoals.ts), which matches how the bot actually moves.Where we deliberately differ (with measurements)
Baritone scales by the sprint cost (
costHeuristic≈ 3.563), which is admissible, so its A* is guaranteed optimal. We keep the walk cost instead, for a measured reason: this A* uses a plain binary heap with no f-tie-breaker, so the admissible sprint weight floods an equal-cost plateau on open ground.Benchmarked (deterministic node counts, flat goals):
Same path cost, but the admissible weight does up to ~28x more work here. Baritone avoids the plateau with tie-breaking and short path segments this implementation does not have. Walk keeps the fast beeline; node counts are identical to the current heuristic, and the suboptimality bound is ~1.3x (walk/sprint).
Verification
npm run buildandnpx ts-standard -yclean.npm test31/31.