Fishing gauge native read - #14
Merged
Merged
Conversation
The shot's vertical velocity is vy = -2.9 + 0.7*cos(phi), sampled when the ball leaves the hand -- exactly 49 logic ticks after the input that triggers it (measured: 49 every time, sd 0, n=12). The helper predicted from the phase at PRESS and in fact passed cosPhi as null, so the oscillator term was absent entirely. Over 49 ticks the phase advances 35.035 degrees (G16[0] += 1.3 per 2 ticks, angle = G16[0]*1.1 deg), which is most of the reason the arc swung. Correcting it with source constants and nothing fitted took the arc error from sd 70.6px to 28.7px. The same correction applied at PRESS phase instead bought only 18% and 30% on the same shots, against 49% and 54% at release. That gap is the load-bearing comparison because it is invariant to the flight time: an early pass had the flight time wrong by 4x and release still beat press, 9% to -1%. Three runs agree. Separately, ghostMade tested the wrong thing. The game scores on a 25px-radius circle around (p95+39, p96+113); the helper tested whether the arc crossed the detected rim bar's y inside a horizontal window. The detected rim sits ~24px above the real scoring point (session A -24.23 sd 2.84, session B -23.63 sd 2.98, n=82 pooled after checking the sessions agree). Both target and criterion now match the game, with point-to-segment distance so sub-sampling does not bias the minimum high. What this does NOT do, stated plainly: overall ghostMade agreement is flat -- 64% before, 62% after, inside the noise at n=42. That is because most makes in this game are BANKED (20 of 26), and no ballistic arc can predict a ball that rattles in off the rim. On the makes a clean arc can predict, the change is real: missed swishes fell from 7 to 3. Residual arc error is still ~30px against a 25px hole, so this is necessary and not sufficient. The old uL/uR oscillator correction is removed rather than left disabled -- it was fit against the wrong phase and never moved outcomes. Its measured coefficients are kept in a comment so it is not re-derived by accident. calVer is unchanged: the learned shotA/shotL/shotR stay valid as the cos=0 case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Widening the scoring radius to catch bank-ins is the obvious next idea and it
is a dead end. Most makes in this game are banked (20 of 26 in one session) and
a ballistic arc cannot predict a rattle-in, so a wider radius looks like the
fix. It is not: the predicted distance barely relates to the outcome at all.
Over 43 shots, ghostMinDist against whether the shot scored:
mean | made 42.4px mean | miss 43.2px AUC 0.474
Fitting the best threshold on half the shots and scoring it on the held-out
half gave 29% and 55%, straddling the 51% always-say-miss baseline. There is no
threshold to find, and the split is what shows it -- picking a cutoff on all 43
would have produced a plausible-looking number.
The same circle test applied to the game's own ball trace scores AUC 1.000, so
the criterion and the geometry are correct. The arc is simply not accurate
enough at the rim to discriminate: residual sd 29-49px against a 25px radius.
The live lead is session dependence, not physics. On identical code, arc error
sd ran 28.7, 35.3 and 49.3 across three sessions, and rim detection noise
(rimDy sd) ran 2.84, 2.98 and 6.95, degrading as the score climbed and the hoop
moved to new positions. That points at rim detection reliability rather than
the trajectory model.
Also recorded: overall ghostMade agreement swung 62% -> 44% between two
sessions of the SAME build, so that metric is not comparable across sessions at
n = 43. The 64/56/62 progression in the previous commit was reading noise; the
arc improvement it reports stands on arcErr, which is measured per shot.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
No description provided.