New inputsystem - prevent double handling of input by both UI and Game

When the UI is open, mouse-scroll should influence scrolling in e.g. listboxes.
When the game is running mouse-scroll should zoom in/out.

What happens is that both the UI and the game handle scroll input, so when the UI is open and a listbox is scrolled, you can see the game reacting behind the UI. How is the order of events determined, and how can an event be flagged as "handled" (and prevent being passed into the next system?)


Note that in this case I could work around it by checking if the UI is open and not handling any "Camera" input, but the issue gets more complex when there are overlay-buttons running in the game. If I left-click on a button (holding it down and starting dragging, I don't want this to turn into a unit-selection rectangle).

Any hints on how to approach this?

 

If I understand you correctly, this is one of the reasons to have separate action maps, as you do have there. I would suggest just getting a reference to the "Camera" action map, and whenever your UI is supposed to be enabled, just...

Code (CSharp):

1. map.Disable();

...and just re-enable it when you go back to your game, of course.

 

Thank you for your reply. With fullscreen menu's you can just disable an entire actionmap (as you suggest), but the moment you have any UI-control overlaying your game that solution doesn't work anymore. In that case you need to handle both UI and Camera/Player events, but only 1 of them (with priority to the UI - so if you clicked on a UI element, you don't want the Camera/Player actionmaps to also handle it in addition). So in the overlay-case you can't simply disable an entire actionmap.

Hmm... so what if you duplicate all UI actionmap-actions into the Camera/Player actionmap - then you could disable the Camera/Player actionmaps while in fullscreen (only react to UI). And then in the game disable the UI-actiomap, but you'd have double-mapped actions (e.g. scroll is up/down when hovering over a listbox, but zoomin/out when not hovering over any UI control) - so you'd have double-mapped controls and need to be sure about the order in which they are executed (UI-related ones first). Doubt that'll work, it basically boils down to the same problem (execution order and only the first handled should 'stop' the chain of signalling).

 

Not sure I follow you, you mentioned "when the UI is open and the listbox is scrolled," so I assumed you meant this was a situation only when the UI is open. I'm assuming now that you must mean a sort of menu that you can open and close during the gameplay.

So, I don't personally know if the new input system specifically has the functionality of "bubbling up/down" etc... If it were me, I'd probably try to catch it in code. I haven't done it in a while, but I think a UI image can be a raycast target, like buttons, etc...that interact. One cheap way would be to set a global variable when you hover over on and off the UI element in question, and then check that variable when you perform your gameplay scroll behavior.