rerender on assign/alive/shell, add Windows build tooling - Board.add_target/add_ally's id auto-assignment used a bare next(c for c in string.ascii_uppercase if c not in used), which raises StopIteration once 26 entities of a group exist -- a real crash confirmed via a live traceback, and a direct regression from moving that sequence from per-type to per-group. This was the actual cause of "Accept as"/"Accept all" silently doing nothing. Fixed with _next_free_id(), which rolls over to two-letter ids instead of raising. - New TargetType.STRIKE_REQUEST: the bearing/distance-offset "taking fire" fire-support request (see the earlier two-entity split) now creates this instead of reusing STRIKE, so a radioed-in request is never confused with a strike the player placed themselves. Same crosshair icon, excluded from type pickers/dedupe like STRIKE. - The "Accept as..." popover on a detected map marker now uses the same icon grid the entity-edit "Change type" popover does (was a plain unfiltered text list of every TargetType, which also wrongly offered STRIKE/STRIKE_REQUEST as pickable). - Firing panel: _cycle_assignment/_toggle_alive/_pick_shell no longer route through app.py's full solver+dedupe+canvas+panel refresh -- none of the three can affect the solver or dedupe, and none change which cards exist or their order (except _toggle_alive in hide/sort_later mode). New FiringPanel._rebuild_one() rebuilds just the one changed card; on_visual_change is a new, lighter callback (just a map redraw) for the two of these three that actually affect it. This was a real, confirmed lag source with many units on the board: every click on any of these was previously rebuilding every card of every target. - Map right-click entity menu: added "Mark destroyed"/"Mark alive", reusing the same cheap-refresh path (new FiringPanel.refresh_after_alive_change). - packaging/windows/: a from-scratch (untested against a real boot) MSYS2 + WiX .msi build pipeline for Windows, driven from Linux via dockur/windows (KVM-in-container), no Windows machine or GitHub required. See its own README for status/caveats. - New/updated tests: id-namespace sharing + the 26-entity overflow regression (tests/test_models.py), StrikeRequest split (tests/test_ocr.py), warp_to_map's img_scale param (tests/test_map_vision_warp.py). 44/44 passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
32 lines
1.0 KiB
Batchfile
32 lines
1.0 KiB
Batchfile
@echo off
|
|
REM Runs persistently from system boot (see install.bat's scheduled task).
|
|
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, the ONSTART task could also fire the same boot), 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:\OEM\build.bat
|
|
)
|
|
)
|
|
timeout /t 5 /nobreak >nul
|
|
goto loop
|