let’s say i have Hold and Press (release only) same time:
if hold was performed, then press won’t start/perform after release the button
if hold was canceled, then press would start&perform
the document says
“If multiple Interactions are present on a single Binding or Action, then the Input System checks the Interactions in the order they are present on the Binding”
is this a bug or i misunderstand things?
meanwhile, another “bug-like” behavior in hold interaction is, action.ReadValue() will return 0, after action.triggered even i still hold button, if i bind this action to a Axis control (gamepad trigger), action.ReadValue() will jump between 0 and actual axis between Update calls, that’s really confusing to me.
It’s expected behavior (though, granted, not the most intuitive one; plus docs need improvement).
Basically, the list represents an order of priority. An interaction higher up in the list preempts an interaction lower down.
So here, Hold is driving the entire sequence to completion. Press never gets a shot. When Hold is performed, the action considers the input sequence to be complete and resets the entire chain.
Here, Hold again gets first shot but then basically aborts and says “I can’t handle this input sequence”. So with that, the system goes to the next interaction and Press gets a shot.
Yup agree, it’s confusing behavior of Hold. The problem has come up multiple times in different forms and I’m about to change Hold to stay in performed state until the button is released (which will implicitly fix the problem you’re seeing here).
Is it just me, or is the above broken now? It seems to, in the example above, only call hold start, hold can, press can, and completely misses the press start
