Closed Chadnaut closed 1 week ago
Would you please test the fix and report. https://github.com/oomek/attractplus/actions/runs/11205677843
Key inputs and mouse buttons are now blocked during tab menu, which is good.
Mouse position still passes through to the layout however.
If you have a gun-oriented layout that uses activate-on-hover mechanics you can still trigger signals during the tab-menu.
if (fe.get_input_pos("Mouse Left") < 0) fe.signal("reset_window");
It's a very fine edge case, since it requires admin to be setting up at the same time eager players are fiddling with controls.
This case is a bit more complicated, I cannot just return false because the return value of cb_get_input_pos()
is an int
Yeah would probably require maintaining a state, and returning that instead of the current value - which feels like unnecessary overhead.
Maybe in future an extra flag for the layout to check the tab menu is open, so it can stop doing stuff on_tick.
That section of the readme was a bit dusty... fe.overlay.is_up
is at least 10 years old now! RTFM.
Most signals are prevented ("select", "back", "exit") but some still get actioned ("reset_window"). Most apparent when the arrow keys trigger a change (ie: OSK), or the mouse state updates a pointer/hotspot implementation.
Would expect the layout to not receive input state while the TAB menu is open,