scruffydude/project-awry
Watch
1
0
Fork
You've already forked project-awry
 0
Code Issues Pull requests Projects Releases 22 Packages Wiki Activity Actions

Fix win overlay blocking input after all items placed #13

Merged
scruffydude merged 1 commit from fix/win-overlay-blocks-input into main 2026-10-01 23:12:02 -04:00
Conversation 0 Commits 1 Files changed 1 +2
scruffydude commented 2026-10-01 23:11:58 -04:00
Owner
Copy link

Same bug class as #12: WinOverlay/WinLabel are Control nodes and inherited the default mouse_filter = STOP, so once the win overlay appeared it absorbed every click underneath it — including clicks meant to pick a placed item back up. I deliberately left these two out of the earlier fix on a wrong assumption that blocking input post-win was fine. Set mouse_filter = 2 on both.

Verified headlessly that _unhandled_input reaches item nodes for a click while the overlay is visible (previously swallowed by the overlay). Full click-to-drag still unverifiable in this sandbox for the same pre-existing, documented reason as #12 (fake headless mouse position) — unrelated to this fix.

Same bug class as #12: `WinOverlay`/`WinLabel` are Control nodes and inherited the default `mouse_filter = STOP`, so once the win overlay appeared it absorbed every click underneath it — including clicks meant to pick a placed item back up. I deliberately left these two out of the earlier fix on a wrong assumption that blocking input post-win was fine. Set `mouse_filter = 2` on both. Verified headlessly that `_unhandled_input` reaches item nodes for a click while the overlay is visible (previously swallowed by the overlay). Full click-to-drag still unverifiable in this sandbox for the same pre-existing, documented reason as #12 (fake headless mouse position) — unrelated to this fix.
Same bug class as the click-not-registering fix: WinOverlay/WinLabel
are Control nodes (ColorRect/Label) and inherited the default
mouse_filter = STOP. Once the win overlay became visible, it silently
absorbed every click underneath it - including clicks meant to pick a
placed item back up - so there was no way to un-place anything once
you'd won. I'd deliberately left these two out of the earlier
mouse_filter fix on the (wrong) assumption that blocking input after
a win was fine; it isn't, since winning isn't meant to be a hard
freeze.

Set mouse_filter = 2 (ignore) on both nodes.

Verified headlessly that _unhandled_input now reaches item nodes for
a click while the overlay is showing (previously it would have been
swallowed by the overlay first). Could not verify the full
click-to-drag result in this sandbox for the same already-documented
reason as before: get_global_mouse_position() returns an
environment-dependent value unrelated to the synthetic event's
position in headless mode (confirmed non-deterministic across runs
here), not something tied to this fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
scruffydude/project-awry!13
No description provided.