curious why stack event queue instead?

I have not tried this new system yet, only watched the introduction video.. but something stuck out to me about the event handling.

why does it use stack queuing instead of something like an observer pattern to simply broadcast the input event, and let those objects that have registered themselves to the provider decide if that event needs to be processed or not?

it seems like if I have these two use cases, that I will end up with a lot more code in my "update" cycles that need to handle 'watching' for events to process:

(case) multi-key combo actions:

• say fighting player game where pressing "X" "J" "I" "2" does a super-fly-punch-kick

1. I would need to have many checks and flags setup in Update for this player script to check then for each key press? (I like how UniRx approaches this with LINQ)
2. This is just one action based on multiple key-combo event... what if I need to watch for 20 possible combos?.. ugh

(case) simultaneous actions with corresponding audio events

• say player 'dodges' left by pressing "shift-A while pressing right-mouse-button to move forward" and the game Audio Manager makes a grunting noise while doing so (basically)

1. How many key events do I need to watch in my Update cycle for the player control object for the game to then send an event to Audio Manager of "Hey, play that grunting sound"...?

Does any of this work for multi-touch systems?

 

I haven't memorized the entire video and am not sure what stack queuing you're referring to. Maybe the ActionMapInputs getting a chance to use the events in turn?

We can't use a simple observer pattern since each thing that handles the event can potentially *use* it, in which case it shouldn't be sent to the subsequent ones. And they need to get their chance to use it in a specific order.

First of all: With these use cases it sounds like you'd want to listen to actions rather than raw input from devices, so that you can take full advantage of multiple control scheme support and so on without making your gameplay code more complicated.

We have not implemented support for getting actions via events yet, but it's on our todo-list. This might indeed take the form of simple delegates you can register to (observer pattern).

However, I'm not sure how that would make your use cases easy. Or if it would, maybe you can show me how?

It sounds a bit like what you're after is specifically the Rx style observable sequences? I don't believe it's something we use anywhere in Unity APIs yet and I'd have to discuss with some other people whether it's an approach we might want to take. In any case, I suspect it would not be too difficult to build Rx style extensions on top even if it doesn't come included with the input system itself?