Avoid spurious digital inputs with inactive sets

[vilhalmer]

This is a weird one.

For reasons I haven't yet determined, we occasionally get bActive == false back from openvr for a few frames when overlays become invisible (I think?), but only if the overlay intersects the laser when hidden. This doesn't make any sense at all which makes me suspect we have a bug somewhere else, but I can't find it. I monitored the state we send into openvr and we're never accidentally deactivating sets that I can see.

In any case, this situation causes us to clear and immediately (a frame later) re-set the input on the tracker, making it look like the user double-pressed the button. Not setting the input at all when the action is inactive matches the logic for the other types of inputs and fixes the double-press.

I will continue to investigate why this is sent. (cc @BastiaanOlij in case you remember anything surrounding this while originally adding the action set support.)

[vilhalmer]

I added some terrible logging to visualize the order of events. In my current project I have a binding that just toggles the overlay_visible state which is where I found this. Opening the overlay works normally (the first two events), but then closing it goes inactive and causes us to set the input false, then becomes active again and immediately goes back to true since the button was never actually released while it was inactive.

If I point the controller away from the overlay before closing it, this inactive state doesn't occur. I also ruled out anything except the overlay being hidden by removing my code to set it invisible. Clicking the button while pointed at the overlay but not actually hiding it also does not trigger the inactive state.

(tracker, bActive, bState)
right_hand 1 1  <- binding to toggle overlay clicked to open
right_hand 1 0
right_hand 1 1  <- binding to toggle overlay clicked to close
right_hand 0 0  <- goes inactive on the openvr side after hiding overlay
right_hand 1 1  <- apparent duplicate press when it becomes active again
right_hand 1 0

[vilhalmer]

I also noticed while fumbling around that hiding the overlay triggers a bunch of VREvent_ChaperoneFlushCache, so maybe the action sets also get reset on purpose?

[BastiaanOlij]

Sadly no clue, it's been a long time since I last used OpenVRs version of the action map.

OpenXRs actionmap has some weird gotchas around priority order, something like that may be effecting things?

You would think the action map works independently from other systems...