Dominik Roth
6a61bffb22
OCR (src/fenigma/ocr.py):
- A "taking fire" report's reporting unit was added as a hostile Target,
not a friendly Ally -- no "Friendly"/"Hostile" prefix word exists in
that grammar for the usual inference to key off of, so it silently
defaulted to not-ally. Fixed with an explicit force_ally override
(_TAKING_FIRE_RE), and the shell/deadline (which an Ally tuple has no
fields for) now always splits into a synthetic StrikeRequest target at
the reporting position, even for the no-offset "on our position" case
that previously kept them on the entity itself.
- "Enemy <Type>#<id> Destroyed" kill-feed lines were silently dropping
for shorter/less distinctive type words (e.g. "Enemy Field Gun#1") --
_ALLY_PREFIX_RE only ever stripped "Friendly"/"Hostile", never
"Enemy", so the whole "EnemyFieldGun" token got alias/fuzzy-matched
against "Artillery" and missed by a mile. Longer type words
("Enemy Mechanized Infantry#2") only ever worked by fuzzy-match
accident. Now strips "Enemy" too (lookahead guards a BARE "Enemy#N"
report, which IS TargetType.ENEMY itself, from being stripped to an
empty, unresolvable string).
- "Field Gun" added to _TYPE_WORD_ALIASES as plain Artillery under
another name (confirmed by the user), not a missing unit type.
7 new/updated regression tests, 54 total passing.
Windows build (packaging/windows/): three real bugs found and fixed by
actually booting and driving the build VM live (VNC), not just guessing
from the README's "UNTESTED end to end" note:
- install.bat's MSYS2/WiX provisioning previously left NOTHING behind
once C:\OEM stopped existing (a 2-day-old BUILD_REQUEST sat unclaimed
the whole time) -- the build.bat/watch_build.bat persistence fix
(C:\FenigmaBuild instead of C:\OEM) is real and now confirmed live:
after a full container restart, the watcher auto-starts on login and
picks up a pending request with zero manual intervention.
- pip install pytesseract needs --break-system-packages (MSYS2's
mingw64 Python enforces PEP 668).
- mingw-w64-x86_64-opencv is the C++ library only; the actual Python
bindings are the separate mingw-w64-x86_64-python-opencv package,
never in install.bat's dependency list.
With all three, import fenigma.app succeeds and a real build attempt
gets through source copy, sanity check, dist-tree assembly, and WiX
harvest+compile -- further than this pipeline has ever gotten. Full
findings, including the still-open light.exe timeout and the OCR
multi-shell/deadline-phrasing/phantom-header gaps found along the way,
logged in TODO.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
35 lines
1.3 KiB
Batchfile
35 lines
1.3 KiB
Batchfile
@echo off
|
|
REM Runs persistently from login (see install.bat's Startup-folder entry --
|
|
REM this file itself gets copied to C:\FenigmaBuild\ and to the Startup
|
|
REM folder by install.bat, not run from C:\OEM, which does not reliably
|
|
REM survive past Windows Setup finishing, see install.bat's own note).
|
|
REM Polls the host-shared Z:\ drive for a build request and, when one
|
|
REM shows up, runs build.bat against it. This is what lets build_windows.sh
|
|
REM on the Linux host trigger a build without any RDP/remote-exec: it's
|
|
REM all just files dropped on the shared folder in both directions.
|
|
REM
|
|
REM UNTESTED (see install.bat's note).
|
|
|
|
:wait_for_share
|
|
if not exist Z:\ (
|
|
timeout /t 5 /nobreak >nul
|
|
goto wait_for_share
|
|
)
|
|
|
|
:loop
|
|
if exist Z:\BUILD_REQUEST (
|
|
REM Claim the request before acting on it -- if watch_build.bat somehow
|
|
REM ended up running twice this boot (install.bat starts it once
|
|
REM immediately, a fresh login could also start another copy), only
|
|
REM one of them wins this move and actually builds.
|
|
move /y Z:\BUILD_REQUEST Z:\BUILD_REQUEST.claimed >nul 2>&1
|
|
if exist Z:\BUILD_REQUEST.claimed (
|
|
del Z:\BUILD_REQUEST.claimed
|
|
del /q Z:\BUILD_DONE 2>nul
|
|
del /q Z:\BUILD_FAILED 2>nul
|
|
call C:\FenigmaBuild\build.bat
|
|
)
|
|
)
|
|
timeout /t 5 /nobreak >nul
|
|
goto loop
|