Dominik Roth
136492b197
map_vision.py: marker shape test only matched diamonds, so friendly
(rectangle) markers could never be detected regardless of color match.
diamonds() now takes a per-side ideal shape (diamond for hostile, full
rectangle for friendly) with fill-ratio bands measured off real markers.
Merged tests/fixtures/map_shots/more/ into the main fixture set: 2
screenshots that solve fine (now 15.png/16.png, with hand-transcribed
ground truth) and 8 that are too low native resolution for the label
reader (same class as the existing 12.png) into too_hard/ as
17.png-24.png, with an explanatory README entry. Updated map_vision.py's
docstring numbers (9/12 solve, 104/131 points correct) to match.
TargetType: expanded from 11 to 44 members to cover every icon in
assets/icons/targets/{enemy,friendly}/, including 7 friendly-only types
(King, Police, General, Hospital, Fort, Civil-Military, Mechanized
Anti-Tank) with no enemy equivalent. UNKNOWN/ENEMY stay icon-less by
design (both are literal words the game's OCR'd text uses, confirmed via
ocr.py's _TYPE_BY_SHORT, so neither can be dropped without breaking real
parsing) and draw the same plain-dot fallback the map itself uses.
icons.py: collapsed the icon lookup into one canonical table
(_TARGET_ICON: TargetType -> (enemy_basename, friendly_basename), one
explicit row per type) instead of a basename table plus two exception
dicts layered on top -- with a startup assertion that every TargetType
has a row. Added build_target_type_grid(), an icon-grid picker (icon +
name, same idea as the existing Shell picker) that replaces the old
plain-text dropdown/list everywhere a type is chosen, and only offers
types the given side actually has real art for.
coord_dialog.py: Add/Edit Target and Add Ally now use the icon grid
instead of Adw.ComboRow. Fixed a resulting horizontal-scroll bug (an
unbreakable long word was blowing out cell width) and locked the
coordinate pickers back to 5 columns.
app.py: right-click quick-add now offers Spotter/RP alongside
Target/Ally/Strike, opens a real modal (not a Popover, which turned out
unreliable for a wide multi-row grid) to ask for a type instead of
silently defaulting to UNKNOWN, and doesn't repeat the coordinate on
every row. The type grid listens for "clicked" rather than "toggled" --
a grouped ToggleButton doesn't emit "toggled" when you click the one
that's already active, which meant confirming the pre-selected default
type silently did nothing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
Screenshots we deliberately do not try to solve
Kept for the record, excluded from the evaluation set. These fail for reasons that are properties of the screenshot, not of the algorithm, so working around them would mean guessing:
06.png,14.png— exactly ONE grid label visible. A single label cannot be cross-checked, so a misread would silently shift the whole board with nothing to contradict it. Two mutually consistent labels is the minimum safe anchor.12.png— 710x594 native. Too few pixels per cell for the label glyphs to correlate; measured, the best label score stays ~0.44 at every working resolution, so it is not a tuning problem.17.png-24.png— same class as12.png: native resolution too low (605-1789px wide, vs. 1392-2400px for the fixtures that do solve) for the label glyphs to correlate once warped to the canonical cell size; measured, the best label score stays ~0.45-0.52 at every working resolution tried (including the 2400px retry pass), well short of LABEL_ACCEPT (0.62) and inside the documented "wrong read" band (0.40-0.56), not close enough to call it a tuning problem. Two of the ten screenshots this batch came from (now15.png/16.pngin the main set) were high enough resolution to solve -- the same camera distance/game zoom just wasn't consistent across the batch.
"Too zoomed in" and "too low resolution" are legitimate hard rejections.