nik/ba-auto-daily
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(detector): Recalibrate SPARKLE_CLICK_OFFSET to prevent overshooting into neighboring students

Browse Source
This commit is contained in:
Nik Afiq 2026-07-17 00:17:19 +09:00
parent b4bad17813
commit 4857bd5f8f
3 changed files with 15 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
ba_auto/detector.py
View File

@ -40,7 +40,8 @@ SPARKLE_SHOT_PATH = os.path.join(config.SCRATCHPAD_DIR, "cafe_live.png")
# rather than inferred from a single ambiguous signal like the (0,0) attempt
# was. (75, 47) was oversized (the close-together overshoot bug) and (0, 0)
# was undersized (clicks the sparkle glyph itself, not the character) --
# (50, 15) is the empirically-confirmed middle ground.
# (50, 15) was the empirically-confirmed middle ground, then nudged 1px
# further right by the user after watching it land live.
SPARKLE_CLICK_OFFSET = (51, 15)
SPARKLE_THRESHOLD = 0.97

2
ba_auto/reference_notes/mapping.md
View File

File diff suppressed because one or more lines are too long

12
plan.md
View File

@ -366,6 +366,18 @@ This also explained why the game was left genuinely stuck rather than self-heali
Fixed by moving the `_dismiss_rank_up_if_shown` check to the top of `_pat_current_view`'s loop, run on every iteration rather than only right after a pat -- a delayed cutscene appearance now gets caught (and dismissed via the function's own existing Enter-press retry loop) on the very next iteration, roughly a second later, instead of never. **Confirmed live**: reproduced the exact real stuck state left by the incident (the game was still sitting on it) and confirmed a single Enter -- the same action `_dismiss_rank_up_if_shown` already takes -- cleared it back to the real cafe room view, then `navigation.return_to_home` confirmed true home afterward. The per-iteration check itself has not yet been re-exercised against a fresh live rank-up trigger end-to-end (same "could not force one on demand" caveat follow-up #5 already carried).
#### Phase 6 follow-up #7: sparkle click offset overshot into a neighboring student when close together (2026-07-17)
Reported live with a screenshot (`screenshots/cafe/bug_student_close_together.png`): "This happen when student are too close together... where the click land on student in front. The click should happen on top of the head, very close to the sparkle."
`detector.find_cafe_sparkle`'s `SPARKLE_CLICK_OFFSET = (75, 47)` was ported byte-for-byte from the original `scripts/detect_and_click.py` (see Phase 6's own writeup above) and never independently recalibrated against this project's real gameplay. A live log showed the actual failure mode: 13 of 16 "successful" pats in one run clustered within a ~10px box (e.g. `(934,522)`, `(936,520)`, `(937,521)`, `(938,521)`...) instead of spreading across genuinely different sparkles -- the offset was reaching far enough right+down to land on a *different*, closer student's body when two stood close together, which doesn't register as a pat, so the same still-showing sparkle just gets matched and "clicked" again next iteration.
First recalibration attempt set the offset to `(0, 0)` (the raw template-match center, no offset at all) after moving the cursor there against a real live sparkle and observing what looked like a hover-confirmation (a thought-bubble animation appearing above the target character). Deployed and live-tested via the real `./ba_dailies.sh cafe` CLI path -- but the user, watching directly, reported it was now "clicking the actual sparkle instead of the student head" and the run had to be killed (both the local task and the actual remote `ba_daily.py cafe` process, which kept running after the SSH command was stopped). The thought-bubble "confirmation" turned out to be a coincidental ambient animation unrelated to cursor position, not a real signal -- (0, 0) undershoots just as `(75, 47)` overshoots.
Properly recalibrated via a new interactive technique, per the user's own suggestion ("You may write number on the grid and ask me to choose"): a script matches the live sparkle, draws several numbered candidate offset points directly on a cropped screenshot of the real, current sparkle, and the user picks the correct one by eye. Run against two independent real students in different poses -- a sitting arcade-cabinet pose and a lying-down couch pose -- both converged close to the same small offset (the couch pose's second-round refinement and the arcade pose's confirmed pick landed within a few px of each other), confirming a small offset generalizes reasonably across poses even though a single fixed offset can never be exactly right for every pose. Landed on `(51, 15)` (`(50, 15)` empirically confirmed by the user via the numbered-candidate picker, then nudged 1px right by the user directly after watching a live run land).
**Confirmed live** via a fresh real `./ba_dailies.sh cafe` run with the new offset: 6 sparkles patted across both rooms, all at genuinely distinct coordinates (no repeated-click clustering), clean `[cafe] Done.` and confirmed true-home return afterward. Not specifically re-reproduced against a live "two students close together" scenario (can't force that layout on demand), but the smaller offset directly addresses the overshoot mechanism the original bug report diagnosed.
### Phase 7: setup.sh update
**Status: Done — `setup.sh` deploys `ba_daily.py` and `ba_auto/`.** `scripts/ba_dailies_legacy.sh` and `scripts/detect_and_click.py` were deleted once mailbox and cafe both migrated off them (Phases 5–6); `setup.sh` no longer references either.