Repository navigation
Conversation
…odel The planner searches for the cheapest legs (hold one direction, then the next) and prefers legs that end against a wall. Each game supplies what one press of a direction does; the planner doesn't know any tile legend. Tested on a small made-up game. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Holds one leg while watching for what can stop it part-way. On an interrupt, a leg to a wall is held again and an open leg walks what is left, estimated from when the interrupt was seen. The bookkeeping is a plain function, tested with scripted holds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Routines that mash a button or hold a direction for a fixed time break when an input drops or a stray press opens a menu, and nothing notices until much later. run_screen_machine() is the closed-loop alternative: it reads the screen (two frames must agree), takes the one step that state calls for, and fails on a screen the previous state cannot lead to, a state seen too often or too many times in a row, eight steps that change nothing, or the timeout. A capture that drops out for up to 10s is waited out. StepTrace logs each change of recognized screen with a numbered screenshot and each input, and a failure lists the screens that led to it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
std::function is copyable: copying it forks a stateful lambda's state, and it cannot hold move-only captures. MoveOnlyFunction is an alias of std::move_only_function where the standard library has it, and a minimal R(Args...) fallback for Apple's libc++, which lacks it. Tests: move-only capture, moving keeps one state, empty and nullptr comparison, reassignment; copy is rejected at compile time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
The leg walker takes its mover as a MoveOnlyFunction. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
LegMover had one method, so it is now a MoveOnlyFunction that holds a direction for a duration. walk_leg() takes it by reference, since calling a MoveOnlyFunction is non-const. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
The search's maps and queue become a Search struct, and relaxing a node, expanding a node, the goal search, tracing the moves back and the final turn each get a function. The search visits nodes in the same order, so the plans are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
… tests The standard does not make std::move_only_function's move assignment noexcept, and MSVC's STL does not. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Picks up the test fix for MSVC's std::move_only_function, whose move assignment is not noexcept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Move-only: Pokemon_TileGrid.{h,cpp} and Pokemon_MapSet.{h,cpp} are copied
unchanged from bdsp/floaroma-mvp, where the BDSP AutoStory MVP added them,
so the grid and map set sit with the planner and walker they build on.
Their tests stay with the BDSP map data they check.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
dayfine
added a commit
that referenced
this pull request
Oct 31, 2026
…fset) and the MVP plan Section 14 of the lessons: measured movement (D-pad taps are whole tiles, stick holds drift), the clip-to-wall then D-pad offset route model, what the screen tells, and the process mistakes. AutoStory-MVP-Plan.md: run 1 stays on fork #68; the compact series stacked on #66 follows it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
…a search cap Three planner changes the BDSP run made on its branch, ported to the core: RobustPlanCosts::exact_open_tiles (open legs up to that length land exactly: D-pad taps move whole tiles), per_open_tile (a long open leg costs more than a short step after a wall), and max_searched (the set search gives up after 20000 sets: all of Jubilife from six start tiles ran for minutes, r224a; town costs or a cropped map are the answer, not a higher cap). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
Both games plan on Grid and LegPlanner, so those stay here. The rest served one game each and moves to its user: ScreenMachine/StepTrace to common/screen-machine, LegWalker to frlg/brock-mvp (where LegMover is a small abstract class, so MoveOnlyFunction is no longer needed here), TileGrid and MapSet to bdsp/tilegrid-mapset. The MoveOnlyFunction copy of #72 goes with them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E
This was referenced Nov 1, 2026
dayfine
changed the title
Owner
Author
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
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.
FRLG and BDSP each built a grid planner for AutoStory, and the two copies share the same ideas but can't serve each other, because each planner is tied to its own map type. This adds the part both games plan on: the grid types (tile positions and directions) and a leg planner that asks the game's step model what one press does and prefers legs that end at a wall, tested on a small made-up game. Everything else that was here moved to where its user lives: ScreenMachine/StepTrace to #108 (BDSP's new-game intro, no navigation dependency), the leg walker to FRLG's #67 (its
LegMoveris now a small abstract class, so this PR no longer depends on #72 and carries no copy ofMoveOnlyFunction), andTileGrid/MapSetto #109 for BDSP's walker and maps, to come back into the core when FRLG adopts them. The plan isdocs/design/AutoStory-Navigation-Stack.mdon #42.🤖 Generated with Claude Code
https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E