The rest of the UI already adapted to system theme automatically via
libadwaita, only the hand-drawn Cairo map (grid lines, markers,
overlays, everything in grid_widget.py) was hardcoded to the dark
palette. Added a parallel light palette (first-pass guesses, same as
the Shell descriptions were, flagged for correction) and hooked
Adw.StyleManager's dark/light state, including its own live-update
signal, so switching the system theme while the app is running
repaints the map with the other palette immediately, not just at
startup.
Verified: rendered both palettes side by side with the same board
state (legible in both), and a live theme-switch test confirming the
module-level color names actually change value when the StyleManager
signal fires, not just once at construction.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gdk.Rectangle(x=..., y=..., width=..., height=...) silently ignores
every constructor keyword argument in this PyGObject version (verified
directly: it always built a zeroed rect regardless of what was passed
in), so popover.set_pointing_to() was always pointing at the canvas's
top-left corner. Fixed by constructing the rect and assigning its
fields afterward, which does work.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Column/row legend labels: the one matching the hovered cell gets an
underline and a blue accent color (not yellow, which was already the
overlay/placement-preview color elsewhere on the map and would have
meant two unrelated things looked the same).
- SUBGRID_LINE (the fine per-cell lines added earlier) was accidentally
given a distinct blue hue on the first attempt at fixing its
visibility, overcorrecting: the actual ask was a shade sitting
between the background and the main grid line's white, not a
different color altogether. Now a neutral warm gray instead.
Verified with a rendered screenshot showing both together: the K/6
legend in blue with an underline, the subgrid a visibly distinct but
still neutral gray, not competing hues on the same map.
Tracks the hovered large cell (col, row) separately from marker
hit-testing, since it needs to update on any cursor motion, not just
when crossing a marker's hit radius, redrawn only when the actual cell
changes, not on every pixel of motion within the same one. Lines drawn
inside the existing clip region so they never bleed past the visible
viewport at any zoom/pan state, dimmer than the main grid lines
(0.6x alpha, tuned down further after an initial too-loud pass) so
they read as a subtle aid, not competing visual noise.
Verified with a rendered screenshot: the subdivision lines appear only
within the hovered cell, correctly clipped, and stay faint against the
main grid.
Below ICON_MIN_CELL_PX (42px cell width) everything still draws as the
plain colored dot it always has, a game icon at that size would just
be an illegible smudge. Past that threshold, Nest/Target/Ally markers
switch to the game's own unit icon for their type, drawn as a Cairo
surface (raw Cairo draw_func, not GTK widgets, so this loads PNGs
directly via cairo.ImageSurface.create_from_png(), cached per path so
a repeat draw doesn't re-hit disk).
icons.py's target_icon_path(type, is_ally) is the TargetType -> icon
file mapping, best-effort guesses the same way the Shell descriptions
were (flagged for correction): most types map onto the game's own
Enemy_*/Friendly_* unit icons (is_ally picks which set, falling back
to Enemy_ if a given type has no Friendly_ counterpart), TANK reuses
the Armor_Mechanized artwork (no dedicated tank icon exists), and
STRIKE gets its own crosshair (assets/icons/misc/Crosshair.png, not a
unit icon at all, a planned impact point) rather than a unit icon.
An ambiguous candidate (hollow, dashed-ring marker) never switches to
the icon regardless of zoom, an icon there would look more confident
about an unconfirmed position than the dashed ring is supposed to
convey.
Verified with rendered screenshots at both zoom levels: plain dots
below the threshold, real icons above it (Tank/Infantry/MarineGarrison/
Nest all confirmed showing their correct icons), and the Strike
crosshair specifically.
The quick keyboard-entry sequence (type a letter then three digits to
fill X/Y/x/y in one go) is the whole point of the Exact tab, but the
picker buttons are deliberately non-focusable (keyboard focus stays on
the dialog itself, see _make_picker's comment), so nothing was
auto-scrolling the group you're about to type into view the way a
real focused field would, on a dialog taller than its visible area
you'd end up typing digits blind past the fold. _scroll_to_stage() now
scrolls the upcoming picker group (or the Identity group, once all
four digits are in) to the top of the scroll area after each
character, and hands real keyboard focus to the id field once there's
nothing left for the digit sequence to fill.
Hit and fixed a real crash while wiring this up: translate_coordinates()
actually returns a plain (x, y) tuple on success in this PyGObject
version (not the documented (bool, x, y)) and a falsy value on
failure, unconditionally unpacking three values crashed immediately on
the very first keystroke. Verified directly against a live widget
before trusting the fix, not just against the docstring.
Verified with a GTK smoke test driving the real key-press handler
through a full X/Y/x/y sequence, confirming the scroll position
advances monotonically at each stage.
Every menu popover (Units/Spotters/Reference Points/Targets/Scout
Flights) stayed open on top of the modal dialog or map-click placement
its own 'Add <thing>' button just triggered, holding onto focus that
should have gone to the new dialog or the map instead. _add_row() now
takes a close() callback (threaded through from _make_menu_button,
which already owns the Gtk.Popover) and pops the popover down right
before calling on_click().
Verified end to end with a GTK smoke test: opens the real 'Scout
Flights' popover, clicks its real 'Add scout flight' button, confirms
the popover is no longer visible afterward.
Nest had its own single-entry popover for no strong reason, and Allies
was its own separate one right next to it, both are 'your own side of
the map'. Merged into one 'Units' popover, Nest always first (there's
only ever one), Allies listed below it, and moved to the first spot in
the header's row of menu buttons.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two related changes:
1. TargetType.HOSTILE_ARTILLERY/HOSTILE_TANK renamed to ARTILLERY/TANK,
dropping the baked-in hostility assumption from the type name
itself (a type describes the unit kind now, not an allegiance).
Migration entries added for both, plus the already-existing
COASTAL_BATTERY one, so old save files still load.
2. A friendly contact ('FriendlyTank#1:', detected by stripping a
leading 'Friendly'/'Hostile' word off the type word before matching
it, see ocr.py's _resolve_target_type()) is NOT a Target with a flag
flipped, it's tracked as a new, entirely separate Ally
(Board.allies), with its own id namespace: an ally Tank#1 and a
hostile Target Tank#1 are two unrelated things that happen to share
an id, not a collision (verified directly, see the rendered
screenshot both coexisting). Ally intentionally has none of Target's
firing-relevant fields (shell/powder_charges/assignment/alive),
allies are never fired on. 'Hostile' and no prefix at all both mean
a regular (non-ally) Target, not-ally is the default.
Wired through: Board.add_ally/remove_ally, placed_entities_all()/
ambiguous_entities_all() (new 'ally' category, cyan on the map,
distinct from every other category's color), solver.resolve_board()
(allies' own clues resolve too), find_by_name() (an ally can be a
clue reference target), save/load round-trip, a new 'Allies' header
popover mirroring Targets' (position/hide/geo-overlay/remove, no
shell/charge/alive controls), and ParsedInfo.allies as a same-shaped
but separate dict from ParsedInfo.targets, merged by a new
_merge_allies() alongside _merge_targets() in _merge_all().
Verified: full test suite (added a dedicated OCR test for the Friendly/
Hostile/bare-prefix routing), a GTK smoke test round-tripping an ally
through save/load and the popover build, and a rendered screenshot
showing an ally Tank#1 and a hostile Target Tank#1 both on the map at
once with the same id, distinct colors, no collision.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same pattern already established for AMMO_CACHE -> SUPPLY_CACHE: a
'Coastal Battery' is just a heavy fixed-emplacement HostileArtillery
under a different name in the game's own text, not a meaningfully
different unit type worth its own enum member. Removed the
TargetType.COASTAL_BATTERY member, added 'CoastalBattery' to
ocr.py's _TYPE_WORD_ALIASES (so 'Coastal Battery#2:' still parses,
now as a HostileArtillery), and a models.py migration entry so any
save file written before this change still loads correctly.
Verified the migration directly (COASTAL_BATTERY -> HOSTILE_ARTILLERY,
existing AMMO_CACHE -> SUPPLY_CACHE unaffected) and updated the one
test that asserted the old type.
Every fix here was verified directly (numeric checks against the view
math, rendered screenshots, GTK smoke tests), not just reasoned about,
after the previous zoom/square pass shipped with real problems still
in it.
Map fixes:
- Off-viewport entities bled through onto the canvas when zoomed in:
_km_to_px() has no inherent bound, an entity actually elsewhere on
the map still got projected and drawn if the result happened to land
within the canvas's pixel bounds. Clipped all marker/overlay/arrow/
scout-flight drawing to the grid's own visible rectangle.
- Gridlines themselves bled into the label margin above/left of the
grid: the line-drawing loop deliberately over-generated a couple of
lines past the true viewport edge (meant to cover a trailing partial
cell, which doesn't need its own line, just the whole-integer lines
already bounding it). Switched to ceil/floor bounds that only ever
produce in-range lines, verified directly against the view math for
a fractional zoom/pan (no clip needed for this half, the bug was
generating the wrong lines in the first place, not failing to hide
them).
- Square-cell letterbox padding stayed pixel-identical at every zoom
level (verified: same padding at 1x/2x/5x), which meant the fixed
bands ate a bigger and bigger share of an already-zoomed-in view.
Once actually zoomed in with square_cells on, the viewport's own
aspect now follows the canvas shape instead of staying locked to the
full map's 20:10 ratio, so cells come out square with zero
letterboxing rather than fixed padding. The whole-map view (zoom=1)
is unchanged, that's the one case that has a real reason to keep the
fixed 20:10 shape.
- Added drag-to-pan, active once actually zoomed in (at 1x the whole
map's already on screen, nothing to pan to). Guards against a drag's
release also firing as a click-select via a small pixel threshold.
Popover cleanup (Nest/Spotters/Reference Points/Targets):
- Removed each popover's own 'Load all from screenshot' bulk button
and every row's individual 'set this one from screenshot' button:
the universal clipboard button in the header already re-parses a
fresh screenshot/paste and merges it into everything it recognizes
by name, these were redundant category- and item-specific ways to
trigger the exact same merge. Deleted the now-dead
_set_*_from_screenshot_info() methods along with them.
- The trailing 'Add spotter'/'Add RP'/'Add target'/'Add scout flight'
rows are now a single full-width button (new _add_row() helper)
instead of the full two-button _row() layout, there's nothing to
screenshot into for something that doesn't exist yet.
Verified: full pytest suite, direct numeric check that no gridline
lands outside the grid rectangle at a fractional zoom/pan, a rendered
screenshot at 4x zoom confirming off-viewport entities no longer
appear and gridlines terminate cleanly at the edges, and a full-app
smoke test exercising drag-pan end to end including the post-drag
click-suppression.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Refactored GridCanvas's geometry around a single _View namedtuple
(cell_w/cell_h/grid_w/grid_h/pad_x/pad_y/viewport origin/visible
extent) instead of threading cell_w/cell_h/grid_h separately through
every draw and hit-test method, that's what makes the two new features
below tractable without a parameter explosion.
- Square-cell toggle (header button, 'view-grid-symbolic'): forces
cell_w == cell_h, letterboxing (padding) whichever axis has leftover
space instead of stretching cells to fill the widget. Off by default,
recovers the exact previous stretch-to-fill behavior.
- Scroll-wheel zoom: 1x (the whole 20x10 map, the old fixed behavior)
up to 10x, anchored at the cursor's last known position so the km
point under it stays under it as the zoom level changes, panned/
clamped so the viewport never hangs off the grid's edge. Grid lines,
column/row labels, and every marker only draw for the visible
viewport, not always the full 20x10 grid.
Also two bugs found and fixed along the way:
- The header's cursor-location readout showed AZ/distance-from-nest
numbers even when the cursor was off the map entirely:
bearing_deg_point()/distance_km_point() are happy to compute on any
raw km point, on- map or not, only the coord label itself checked
bounds. Now the whole readout is just 'off map' whenever the cursor
genuinely isn't over the grid.
- That bounds check initially reused solver.point_to_coord()'s own
tolerance, which deliberately forgives up to 0.5km past an edge
(rounding slop for noisy OCR'd coordinates), the wrong call for 'is
the mouse over the map', a cursor visibly off the drawn grid still
passed it. The cursor readout now uses a strict 0<=col<=COLS/
0<=row<=ROWS check instead.
Verified with GTK smoke tests: zoom in/out and pan-anchoring math,
square-cell letterboxing padding, hover/hit-testing, the toggle wired
end-to-end through the real header button, and the full app launching
and surviving the exact scenario that crashed it earlier in this same
session (an incomplete mid-refactor commit referenced _on_scroll before
it was defined, caught immediately by re-running the app, fixed by
finishing the refactor properly instead of patching around it).
Also, on the firing card: swapped the shell icon to come after the
powder-charge segments instead of before (per feedback), and gave the
assignment cycle button (L/R/-) the same 'image-button' style class its
icon-only siblings get automatically, it was visibly wider than them
for carrying a text label instead of an icon.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
_on_cursor_move() only checked map bounds for the coord label itself
('off map' vs a real grid ref), the AZ/distance-from-nest numbers next
to it were computed and shown regardless, bearing_deg_point()/
distance_km_point() are happy to run on any raw km point, negative or
past the 20x10 grid included, so a cursor genuinely off the map could
still show what looked like a real reading. Now the whole label is
just 'off map', no numbers, whenever point_to_coord() says there's no
real grid position there.
The previous 20px min-width/height looked like a regression (smaller
than before) once the button.<class> selector fix actually started
taking effect: before that fix, the rule was being silently ignored
entirely and the theme's own (bigger) default button min-size was what
users were actually seeing by accident. Now that the rule genuinely
applies, bumped to 28px, verified directly against the real allocated
widget size (28x28), not just the requested CSS value.
Several rounds of actually looking at the running app instead of just
the code, in order:
- The icon-only shell button on a firing card, and the popover-based
picker, both fought a genuine GTK sizing quirk: Gtk.Picture's natural
size is the source image's full native resolution (512x256) no
matter what set_size_request() says, so the button's own requested
size swung unpredictably depending on layout context (sometimes
comically wide, sometimes squeezed tiny). Fixed by pre-scaling the
actual pixel data with GdkPixbuf first (preserving real aspect ratio)
and wrapping the already-correctly-sized result, nothing left for
the surrounding layout to guess about.
- The shell icon PNGs themselves carry a lot of built-in transparent
padding around the actual artwork. Cropped all of them (except MSTD,
see below) to the same shared bounding box, computed as the union of
every file's real content so nothing gets clipped and every icon
stays aligned the same way.
- MSTD (mustard/YX blister agent) removed from the Shell enum entirely:
its own game icon is stamped 'UNAVAILABLE IN DEMO', it isn't actually
a real selectable shell in the game.
- Extra empty chrome around icon-only buttons turned out to be GTK CSS
specificity, not a missing property: GTK's CSS has no !important at
all (confirmed, its parser rejects it outright), and separately,
Gtk.MenuButton's CSS node is literally named 'menubutton', not
'button', so a 'button.<class>' selector silently matched zero
elements on it. The actual leftover padding lives on MenuButton's
internal child button node, reached with a child-combinator selector
('menubutton.<class> > button').
- The Add Strike dialog's shell picker is now an inline radio-style
grid (build_shell_grid(), Gtk.ToggleButton.set_group()) instead of a
button that opens a submenu popover: it's a 'pick one before
proceeding' dialog with room to just show every option up front,
hiding them behind an extra click didn't earn anything. The firing
card and its tighter row still use the popover version.
- Grid is 3 columns (was 4), sized bigger now that padding is real
content, not just empty canvas.
Also two unrelated but real bugs found and fixed while chasing this,
from actually reproducing what screenshots showed instead of taking
them as pure cosmetic complaints:
- Selecting a firing card shifted every icon/label inside it inward by
2px: only .firing-card-selected had a border, unselected cards had
none at all, so gaining a border on selection shifted the box's
content instead of just changing a color. Border is now reserved at
the same width on every card, always, selection only changes its
color from transparent.
- Changing a target's powder charge visibly shifted the whole card:
the charge segment buttons had no valign, so once the row got taller
(the bigger shell icon next to them), they silently inherited the
default FILL alignment and stretched into ovals instead of staying a
fixed circle. They also relied on plain 'flat'/'suggested-action' for
their off/on look, which draws no border at all when off, making an
unselected segment invisible against the card background. Both fixed
with a dedicated fixed-size, always-outlined CSS class and explicit
valign/halign=CENTER.
- The AZ column's screen position depended on the ELEV value's digit
count (elevation recalculates per charge picked), fixed with a
reserved width_chars on the elevation label.
Verified at each step by actually rendering the affected widget/dialog/
card to a PNG and looking at it (including a real FiringPanel card
before/after a charge change, pixel-diffed to confirm nothing but the
intended fill state moved), not by reasoning about the code alone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three real bugs from the first pass, all from actually looking at the
running app instead of just the code:
- Icons rendered tiny regardless of source resolution: Gtk.Image caps
displayed size to GTK's icon-size classes (built for symbolic
16/32px icons) no matter what you load into it. Switched to
Gtk.Picture, which sizes by the image's real dimensions.
- The popover's plain vertical list of rows squeezed down to a near-
unreadable width: ScrolledWindow sizes to its content's minimum, not
natural, size unless told otherwise, and a wrapping description
label's minimum width can shrink to almost nothing. Replaced with a
FlowBox grid (icon + blast radius under it, full description as a
tooltip) with an explicit natural width.
- That grid's column count was pinned to a fixed minimum, so a
popover that didn't have the room for that many columns overflowed
sideways and grew a horizontal scrollbar. min_children_per_line
dropped to 1 (lets it reflow to fewer columns instead) plus
hscrollbar_policy=NEVER as a hard backstop, not everyone has a
horizontal scroll wheel.
Also: the firing card's shell button now shows the icon alone (it
already has the shell's short code baked in, a text label next to it
was redundant on an already-tight row), sized to 64px wide/32px tall
to actually be legible, and a new small CSS rule trims the excess
button chrome around an icon-only face so the button isn't visibly
much larger than the icon it holds.
Both places the app asks for a shell (the Add Strike dialog's
Adw.ComboRow, and the firing panel's per-target shell popover) used to
show just the bare enum name in a plain list, nothing conveying what
the shell actually is. New icons.py builds a shared MenuButton +
popover from the game's own shell icon set (assets/icons/shells/,
already named to match Shell.name exactly): each row shows the shell's
icon, name, description, and blast radius, and the button face updates
to match whichever one gets picked.
Verified via a GTK smoke test that the button and its popover build and
open without crashing.
Pulled from the game's own GameAssets/Assets/Texture2D (gitignored as a
whole, not redistributed wholesale) into a tracked assets/icons/ so
they're actually usable in FeNigma's UI instead of us redrawing
equivalents:
- targets/enemy/, targets/friendly/: one marker per game unit type
('Enemy_*.png' / 'Friendly_*.png', the source files spell the latter
'Frendly_*.png', corrected on copy).
- reference_points/: the four lettered RP markers ('Refrence_Point_*.png'
in the source, typo corrected the same way).
- shells/: one icon per Shell enum member (shells.py), named to match
exactly so they're a direct Shell.name lookup, no mapping table
needed. A few source files don't carry the shell's short code in
their name (Mustard Gas_DemoBlocked -> MSTD, Tear Gas -> TEAR,
Propaganda -> PRPG, Phosgene -> PHGN, Nuclear -> ATMC), documented in
assets/icons/README.md.
- nest/IronNest.png: the Iron Nest/FDC unit icon.
- misc/ScoutPlane.png: fits the scout-flight planning feature.
Also commits the (already-made, previously uncommitted) .gitignore
entry for GameAssets itself, which is what makes pulling individual
icons out into a tracked directory sensible instead of contradictory.
Latent inconsistency flagged during the ocr.py refactor: solve_location()
already excludes a compass-word bearing (bearing_tolerance_deg set) from
its own bearings list before triangulating, since a toleranced bearing
names a sector, not a precise ray, and shouldn't be treated as if it
were one. explain_unresolved()'s bearings list didn't have the same
exclusion, so a toleranced-only bearing plus a distance clue could get
described as inconsistent geometry ('the bearing from X never crosses
the Ykm circle...') when the real reason nothing resolved is just that
the bearing was never usable for that math in the first place. Locked
in with a new test.
ocr.py grew through many incremental patches and had accumulated the
same two shapes copy-pasted with minor variation across the file:
- The full coordinate shape ('H3 5:5', letter + big-cell number + sub-
grid x:y) was hand-restated as a regex literal in six places
(_COORD_RE, _GRID_COORD_RE, _REQUESTED_ON_COORD_RE, the FO-report
patterns, _NAMED_AT_COORD_RE, _STATION_LINE_RE), each pairing its own
copy with its own try/except Coord(...) construction. Factored into
one _COORD_FRAGMENT regex piece and one _coord_from_groups() helper,
every call site now just embeds/calls it.
- The '<word><junk><digits>' type-id shape ('AmmoCache#3') was
similarly restated across _NAMED_HEADER_RE, _REF_NAMED_RE, and
_DESTROYED_RE. Factored into _TYPE_ID_FRAGMENT.
- Dropped _SEP, an unused leftover regex fragment.
No parsing behavior changed: every format ocr.py understands (standard
target/RP blocks, calibration line, destroyed reports, train-arrival
intel, ad-hoc Enemy installations and their destroyed reports,
Listening Post/Coastal Battery, Marine Garrison fire-support requests,
multi-word RP names, bare-name-header targets, bold-span coordinate
squashing, FO-report triangulation, the '<ref>: <value>' clue grammar,
16-point compass tolerance, grid-only coords) is still covered by the
full test suite, all 21 tests pass unchanged, plus a direct re-run of
the exact 'Enemy#name' example that prompted this session's bug report
to confirm detection by name still works.
No test suite existed before this, which is exactly how a real
regression (the bold-span coordinate-squashing bug, and the
'Type#id:'/'<ref>: <value>' header collision, both from this session)
went unnoticed until manually re-triggered. One test per format,
cross-referenced against the full commit history so nothing already
shipped gets silently dropped by a future change:
tests/test_ocr.py: standard blocks, the calibration target line,
destruction reports (digit and letter id), train-arrival intel,
ad-hoc Enemy installations (+ their destroyed reports), Listening
Post/Coastal Battery, Marine Garrison fire-support requests, multi-
word RP names, bare-name-header targets, the bold-span coordinate-
squashing regression specifically, forward-observer report
triangulation, the '<ref>: <value>' clue grammar (+ its header-
collision regression specifically), 16-point compass tolerance, and
grid-only coordinates.
tests/test_solver.py: direct bearing+distance resolution, two-bearing
triangulation, genuine two-distance ambiguity, the nested-circles
compromise-point fallback, toleranced bearings never being used to
triangulate, and manual coord overrides clearing a stale note.
Runs via ============================= test session starts ==============================
platform linux -- Python 3.14.6, pytest-8.4.2, pluggy-1.6.0
rootdir: /home/dodox/Projects/FeNigma
configfile: pytest.ini
plugins: anyio-4.13.0
collected 21 items
tests/test_ocr.py ............... [ 71%]
tests/test_solver.py ...... [100%]
============================== 21 passed in 0.72s ============================== (pythonpath configured in pytest.ini), dev-only
dependency in requirements-dev.txt so the app itself stays
dependency-light. Documented in the README.
New shapes, all genuinely new features (checked full git history, none
of this ever existed before):
- '<ref>: <value>' clue grammar (Spotter#2: 4.04km / Spotter#3: 298deg
/ Spotter#1: West), no keyword, no 'from', reference comes first.
This collided hard with the existing 'Type#id:' header shape,
'Spotter#2: 4.04km' is structurally identical to a real header like
'AmmoCache#3:', so it was hijacking the block before any clues could
attach to the entity above it. Fixed by checking whether a would-be
header's trailing content is itself just a bare clue reading with
nothing else (_BARE_CLUE_VALUE_RE); a real header's never is.
- 16-point compass words ('North Northwest'), alongside the existing
8-point ones, longest-alternative-first in the regex so the compound
form doesn't get cut off at the bare first word.
- A compass word names a whole sector, not a single ray, so a clue
built from one now carries a bearing_tolerance_deg (11.25deg, half a
16-point sector) and solve_location() deliberately never tries to
triangulate it into an exact point, precise math on an imprecise
reading would misrepresent the confidence. The map draws it as a
wedge (two bounding rays + fill) instead of a single ray.
- 'Reported active in grid D10': large-grid-cell-only, no sub-grid x:y
at all, defaults to the cell's rough middle (5:5).
Verified against the exact reported example end to end (parse ->
solver correctly resolving what it can and leaving the rest
unresolved -> map draw with the wedge overlay) plus the full existing
regression sweep across every previously-added format.
Three related fixes/additions, found together while working through a
batch of new intel formats:
1. squash_span_content() only handled the 'Enemy X Y' and 'Type#N'
shapes, so a plain multi-word bold name ('The Mole', "Dockmaster's
House") passed through untouched and got silently truncated at the
first space by every downstream single-token assumption
(_RP_HEADER_RE, the (\S+) clue-reference capture). Added a generic
fallback: collapse any multi-word bold span into one alphanumeric
token, UNLESS any word contains a digit, that's very likely a
coordinate span ('C9 7:9') instead of a name, and squashing THAT the
same way corrupted it into garbage ('C979') rather than a name, a
real regression caught immediately by testing against nest/spotter
parsing before committing.
2. A bare '<Name>:' header (no 'Reference Point'/'Enemy' keyword, no
digit id, e.g. 'HMS Rockingham:') was previously dropped entirely,
nothing recognized it at all. Added _BARE_NAME_HEADER_RE as the
last-resort header check (colon required, not optional like every
other header regex, nothing else anchors this match). Resolves to a
Target (TargetType.UNKNOWN), not a Reference Point, a named thing
giving its own clues is being spotted, not a fixed landmark.
3. Forward-observer reports ('FO#5 Audio report on HMS Rockingham:
2.24km From I8 6:9'): each FO's position is a literal one-off
coordinate, not a name referencing some known entity, and isn't
meant to be tracked as a real board entity. parse_fo_reports()
triangulates immediately using a throwaway scratch Board (reusing
solve_location()'s exact geometry/priority) and keeps only the
resulting coordinate, discarding every ephemeral FO position
afterward, nothing leaks into the real board.
Also added a 'convert to Target/Reference Point' action (RP and
Target rows both), since bare-name-header classification is a guess
that can land in the wrong bucket, this fixes it without losing the
position/clues already worked out.
Verified against the exact reported examples plus the full existing
regression sweep (standard blocks, Enemy names, Listening
Post/Coastal Battery, Marine Garrison, nest/spotter parsing) and
through the real GTK merge flow.
New shape: '<Name>#<id> pinned!' followed by '<Shell> Shells requested
on <coord>' and 'Requested before - <T-time> -'. Different from every
existing coord shape (no 'Grid' keyword), so it needed its own
extractor (_extract_requested_on_coord), plus new ones for the shell
code and the deadline string. New TargetType.MARINE_GARRISON, its
multi-word name + real digit id already works through the existing
squash_multiword_ids() pipeline (same as Coastal Battery/Listening
Post) with no new header regex needed.
Target gained a requested_time field (raw string, this app doesn't
track a game clock to compare it against), persisted through
save/load and shown on the map below the coord label. The requested
shell sets target.shell directly rather than staying a suggestion,
matching how a manually-picked shell already works.
info.targets' value tuple grew from 3 to 5 elements (raw, clues,
coord, shell, requested_time); updated both call sites in app.py
that unpack it. Verified end to end: parse -> merge -> save/load
round trip -> map draw.
_DESTROYED_RE requires a digit-shaped id ('SupplyCache#2 Destroyed'),
but an Enemy installation's id (after squash_enemy_names()) is
letters ('Enemy#SignalStation'), so 'Enemy Signal Station Destroyed'
silently matched nothing and never marked the target dead. Same
digit-vs-letter split every other Enemy-aware regex in this file
already needed, just missed here. Added _ENEMY_DESTROYED_RE alongside
it, verified through the real _merge_targets() flow for both an
already-known target and one whose destruction is the first mention
of it at all.
Scrollbar: the ScrolledWindow left horizontal policy on AUTOMATIC (the
default), so a vertical scrollbar's own width could shrink the
content area enough to trigger a horizontal scrollbar too, perturbing
card heights and tripping vertical scrolling that wasn't actually
needed. Pinned horizontal off outright, this is a fixed-width sidebar,
never wanted anyway.
Reorder: the card sort key forced every Strike above every non-Strike
on *every* refresh, not just at creation, silently undoing any manual
drag-reorder that moved a strike below other targets. The 'new
strikes go first' behavior only needs to happen once, at creation
(already handled by _add_strike_at's reorder_target(target, 0)); the
sort key was redundant with that and actively fighting the user
afterward. Removed it.
Session produced a working prototype (docs/map_vision_wip.py, not
wired into the app yet) for the image-based map-screenshot marker
pipeline: label OCR, pitch estimation from label spacing, a matched-
filter grid-intersection detector, whole-grid crossing prediction, and
RANSAC homography fitting, each validated against real screenshots
with diagnostic images along the way.
Found a real remaining bug before pausing: crossings are currently
all predicted from one single reference label using one global pitch,
so predictions drift with distance from that reference under genuine
perspective distortion (confirmed: ~2-4 degree measured tilt, not
noise). Documented the fix (BFS grid-growing: expand one cell at a
time from every confirmed point, using local rather than global
spacing) as the next step, not yet implemented.
New shapes:
- 'Listening Post#1 at K6 7:8 ...': a named anchor given inline rather
than as its own block, parse_named_at_coord() picks up any
'<Name>#<id> at <Coord>' anywhere in the text, RP-shaped like
everything else that resolves to a name+coord.
- 'Distance 6.28km South-East from X': a listening post gives distance
readings with an approximate 8-point compass direction instead of a
precise degree bearing, different word order too (the direction sits
between the distance and 'from', no separate Bearing keyword). New
TargetType.COASTAL_BATTERY for what these turned out to report on.
- 'Coastal Battery#2' / 'Listening Post#1': multi-word type names with
a real digit id already attached (unlike the Enemy case, nothing to
invent), squash_multiword_ids() collapses the embedded space so
_NAMED_HEADER_RE and every from-<ref> clue pattern see the single
token they expect.
Also: squash_bold_spans(), prompted by the observation that a rich-text
paste already tells us exactly where a multi-word name starts and ends
via its own <b>...</b> wrapping, no need to guess from capitalization
the way squash_enemy_names()/squash_multiword_ids() do. Runs before
strip_html() while the tags are still there, using each span's own
content as an authoritative boundary. Those two whole-document regexes
stay as the fallback for plain OCR text, which never has markup to
lean on, but squash_multiword_ids() first shipped with a real bug this
caught: 'Distance 6.28km South-East from Listening Post#1' matched
'East from ListeningPost' as if it were one multi-word name, backward
through the lowercase connector word 'from'. Fixed by requiring
Title Case on every word in that whole-document fallback path (the
scoped bold-span path never had this problem, it can't reach past a
span's own boundary). Verified end to end against the exact example
text, including through the real _merge_targets()/_merge_reference_points()
app flow, plus the full existing regression sweep (Enemy names, train
intel, standard blocks, calibration target).
Previously _draw_geo_overlays() only ever looked at
placed_entities()/ambiguous_entities(), so a target that failed to
resolve entirely (no coord, no potential_coords, e.g. two clues that
don't quite geometrically agree) never got its bearing/distance lines
drawn no matter what, there was no way to see why on the map itself.
Selection is now also a trigger alongside hover/show_geo_desc
(matching how firing arrows and blast radius already key off
selection), and the candidate list comes from board.reference_points
+ board.targets directly rather than the resolved-only views, so an
unresolved selection still shows its clue geometry. Lets you eyeball
whether a bad reading is plain wrong or just off by a bit, bearing
readings apparently carry some real-world error margin.
Selecting text in-game copies it to the clipboard, screenshots were
never the only way in and are now explicitly the fallback for when a
selection isn't practical. Also mention scout flight planning and the
clipboard auto-watch toggle, both added since the last README pass.
'Enemy Signal Station:' and its ilk are named in plain English rather
than the usual Type#N shape, and get referenced the same way
elsewhere ('Bearing 034 from Enemy Signal Station'), breaking two
assumptions everywhere else in this module: headers/references are a
single whitespace-free token, and an id is digit-shaped.
squash_enemy_names() collapses 'Enemy' + up to 4 Title Case words that
follow it into one token in our own id shape ('Enemy#SignalStation')
before anything else parses the text, so every existing from-<ref>
clue pattern and the named-header matcher keep working unmodified.
Wired into both parse_text() (OCR/clipboard) and
parse_clues_from_text() (manual description tab).
Two follow-on fixes this surfaced: _clean_reference() previously
assumed a named reference's id is always digit-shaped and would
truncate 'Enemy#SignalStation' down to 'Enemy#Sig' via
_fix_id_digits's letter-to-digit mapping; and the letter-id header
check needed to run *before* _NAMED_HEADER_RE, whose digit class
overlaps plain letters (S/B/Z/G/O/I/L) and would otherwise
partial-match and mangle the id first.
New TargetType.ENEMY carries these. Verified end to end (including
the solver resolving the cross-references between them) through both
parse_text() and the real _merge_targets() app flow.
A different intel shape entirely: a station's absolute grid ref, the
rail's bearing from it, and waypoints given only as a distance along
that same bearing. ocr.parse_train_intel() turns the station and each
waypoint into RP-shaped entries (bearing+distance-from-station is
solve_location()'s simplest case), merged through the exact same
_merge_reference_points() path as any other RP, no new UI or entity
type needed.
The T=HH:MM:SS timestamp on every line is deliberately never parsed,
there's no game clock to compare it against.
Verified end to end against the real screenshot: MainStation resolves
from its own grid ref, and all three waypoints resolve correctly along
the bearing at their reported distances.
Previously two distance-only clues whose circles didn't actually
intersect (real typewriter data isn't perfectly consistent, a
misplaced spotter or an off-by-a-bit distance reading is enough) just
gave up entirely, even when they were nearly touching.
solver.closest_compromise_point() picks the midpoint between each
circle's point facing the other, the standard notion of the closest
approach between two circles. It stays well-behaved even when the
centers are nearly coincident, unlike projecting along the center
line the way a real intersection's formula does, which diverges as
the centers get close while the radii stay far apart, exactly the
near-coincident case this is for.
The result is flagged rather than treated as a clean fix: Location
gained a field, set whenever solve_location() had to use this
fallback, cleared by any subsequent coord.setter call (manual or
solver), shown in the entity's status label and toasted after a
manual clue edit. Persisted through save/load.
Circle-circle intersection (and the other solvable shapes) already
worked correctly, verified with a direct test: two distance-only
clues resolve to potential_coords whenever the two circles actually
cross. What was missing was feedback when they don't, e.g. two
distances that put one circle entirely inside the other given the
references' real positions looks identical, from the dialog's
perspective, to a reference that's just not placed yet.
solver.explain_unresolved() distinguishes 'waiting on <ref> for a
known position' from 'these two readings are geometrically
inconsistent', wired into _apply_and_refresh's toast after a manual
Description-tab edit.
A ScoutFlight anchors to the center of whatever large grid square the
cursor is in, with its bearing read off where in that square the
cursor actually sits, decoupling a clean anchor point from fine
direction control. The plotted rectangle extends 0.92km back and
13.04km forward along that bearing, 1.21km to each side
(solver.scout_flight_corners), previewed live while placing (see
GridCanvas.start_scout_flight_placement) and drawn as a filled
rectangle once committed.
New 'Scout Flights' header dropdown lists them with replot/hide/remove
per entry, plus a header button to plan a new one. Wired into
Board.clear() and save/load (SAVE_FORMAT_VERSION bumped to 3, old
saves load fine via the new key's default).
Board.clear() drops the Nest position, spotters, reference points, and
targets; wired to a header button behind a confirm dialog since it's
not reversible.
The clipboard-watch toggle connects to Gdk.Clipboard's 'changed'
signal and re-runs the merge-all OCR flow automatically whenever the
clipboard gains new image content, skipping non-image changes (e.g.
text copied elsewhere) so it doesn't spam toasts. Off by default.
Disconnected on window destroy.
'Target is at- Q4 4:2' (no #id, unlike the usual block shape) is how
the game's very first order gives the target. Store it as a fixed
(UNKNOWN, "1") entry since there's only ever one.
Same style fix applied to the README earlier, extended everywhere:
replaced " -- " with commas/colons/periods (picking whichever reads
right per occurrence, splitting into two sentences where the clauses
were independent), fixed a few user-facing strings along the way
(entity list rows, placement/strike toasts, ambiguous-candidate tag,
shell picker button label). Left three intentional non-prose uses
alone: the "unassigned" dash glyph in firing_panel.py (and its
docstring diagram), and ocr.py's dash-variant regex character class,
which needs to literally match em/en-dashes in OCR'd text.
Also caught and fixed a stale models.py docstring claiming "no solver
yet" (solver.py has existed for a while) while touching that
paragraph anyway, and a formatting artifact in coord_dialog.py's
docstring left by the sed pass (misaligned comma from a since-removed
alignment gap).
Verified: py_compile across all files, the 9-screenshot OCR
regression sweep, and a GTK smoke test exercising the edited
toast/placement code paths.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- src/ironnest_assist/ -> src/fenigma/
- run.sh invokes -m fenigma.app
- APP_ID: eu.dominik-roth.IronNestAssist -> eu.dominik-roth.FeNigma
- window title, IronNestApp class -> FeNigmaApp
- __init__.py docstring, README pgrep hint updated
IRON NEST (the game's own name, e.g. NEST_KEYWORD in ocr.py) is left
untouched, only our own project/app naming changed. Verified: clean
import under the new module path, install.sh still builds the venv
correctly, and the OCR regression sweep (9 known screenshots) still
passes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
install.sh creates a --system-site-packages venv (so it can still see
the system-installed PyGObject bindings, which pip can't build
reliably) and pip-installs the rest of requirements.txt into it.
Checks for PyGObject (GTK4 + libadwaita) and tesseract up front and
prints per-distro package hints if either is missing, rather than
failing deep into pip install. run.sh now prefers .venv/bin/python3
when it exists, falling back to system python3 otherwise. README gets
an Install section describing this.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Shorter pitch focused on what the app actually automates for the
player: screenshot orders -> geo puzzle + trajectory solved -> ready
fire commands; screenshot the field log -> kills/new contacts picked
up automatically; strike planning with blast-radius preview. Mentions
the map's geometric derivation overlays and ambiguous-intersection
handling. Drops the old deep technical dump in favor of pointing at
code comments for internals. Adds icon.png (used in the header) and
showcase.png (embedded screenshot); icon_alt.png kept as an unused
alternate for now.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
