megaproxy/rimlike
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

memory.md: log PC controls patch + latent backdrop-bug fix

Browse source 
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
megaproxy 2026-05-12 12:07:09 +01:00
parent 0b2e0fcd03
commit c8c9fcbb33
1 changed files with 7 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
memory.md
View file

@ -231,6 +231,13 @@ Same scope as locked in `~/claude/ideas/rimlike/plan.md`. Realistic timeline 3
- **Deferred to Phase 17.5 polish pass:** Per-pawn/per-job view layers, stockpile 4×4 chip grid, Bill UI, "no stockpile accepts X" / "bill blocked" emit wiring, DaySummaryCard visual.
- Next: Phase 18 (Audio). Music + SFX + ambient + volume sliders + mute-on-suspend. Smaller scope than 17 — 1 week target. ElvGames + Ventilatore bundles include music/SFX packs we can source from.
### 2026-05-12
- **PC controls patch shipped** (out-of-phase, for desktop testing + Steam Deck prep). New input actions: WASD/arrow pan, `=`/`-` zoom, `C`/`Home` center, `Tab`/`Shift+Tab` pawn cycle, `B`/`L`/`P`/`,` panel toggles, `Escape` priority stack (cancel tool → close topmost panel → deselect pawn), right-click cancel/deselect (RTS convention). `F` is the new `speed_cycle` binding (handler still TODO). Touch paths untouched. Commit `0b2e0fc`.
- **Pattern note: pawn cycling Shift+Tab.** First attempt used `Input.is_key_pressed(KEY_SHIFT)` to detect modifier on `pawn_next` action — this works with real keyboard but fails for MCP synthetic input (the singleton keystate isn't updated by injected events). Fix: read `event.shift_pressed` on the InputEventKey directly. More reliable AND works in tests. **Use `event.<modifier>_pressed`, not `Input.is_key_pressed(KEY_*)`, when reading modifiers tied to a specific key event.**
- **Latent pre-Phase-17 bug surfaced and fixed in same commit.** WorkPriorityMatrix, AlertsLog, StorytellerModal, LoadMenu, SettingsMenu all had `MOUSE_FILTER_STOP` Backdrop/Dim Controls that stayed input-active when the panel was "closed". Their open/close only toggled `_root.visible` / `_panel.visible` — never `CanvasLayer.visible` (self). World mouse events (right-click deselect, left-click pawn-select) silently eaten. Each `_set_visible`/`open`/`close` now toggles `self.visible` so input dispatch shuts off. **Why it went undetected since Phase 17:** Tab-select and direct script invocation bypass `_unhandled_input`; the runtime verify in Phase 17 used those paths. First proper mouse-world test (this session) exposed it.
- **Pattern recorded:** for any CanvasLayer-based UI panel with full-screen backdrop, always toggle `self.visible` (CanvasLayer) in addition to inner Control visibility, OR use `mouse_filter=PASS` on the backdrop. Apply when adding future modals.
- Delegation report: PC controls drafted by `gdscript-refactor` (Sonnet, 2 dispatches — spec implementation + polish pass). Backdrop-bug discovery + fix done on Opus during MCP runtime verification (already in context). Headless + runtime verify all green.
## External references
- **Forgejo repo:** https://git.rdx4.com/megaproxy/rimlike (private)