Layout receives input state meant for TAB menu

[Chadnaut]

local a = fe.add_artwork("snap", 0, 0, 400, 400);

function on_tick(tick_time) {
    // Press "1" or "2" (number row) while in the TAB menu
    a.x = fe.get_input_state("Num1") ? 50 : 0;
    if (fe.get_input_state("Num2")) fe.signal("reset_window");
}

fe.add_ticks_callback("on_tick");

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,

[oomek]

Would you please test the fix and report. https://github.com/oomek/attractplus/actions/runs/11205677843

[Chadnaut]

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.

[oomek]

This case is a bit more complicated, I cannot just return false because the return value of cb_get_input_pos() is an int

[Chadnaut]

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.

[oomek]

https://github.com/oomek/attractplus/blob/master/Layouts.md#feoverlay-1 😉

[Chadnaut]

That section of the readme was a bit dusty... fe.overlay.is_up is at least 10 years old now! RTFM.