Observed Input Event handling order doesn't appear to match documentation

Development Programming & Scripting Blueprint
1

The documentation for Input (https://docs.unrealengine.com/latest/INT/Programming/Gameplay/Framework/Input/index.html#inputcomponent) says that the order for handling inputs is:

  1. The Actor with the most-recently enabled “Accepts input” (which I assume means an Actor that has been enabled by the Enable Input node) Input handling proceeds through all Actors with “Accepts input” enabled, from most-recently enabled to least-recently enabled.
  2. Controller
  3. Level Script
  4. Pawn

The order I’ve observed is:

  1. Input enabled Actors.
  2. Possessed pawn. (It would be nice if the documentation noted that pawns can’t be enable for input if they aren’t possessed, that had me scratching my head for a while as the log message about it was getting lost in the other messages)
  3. Level blueprint.
  4. Controller.

Reproduction: Create a blank project and add blueprints for all the above. In each one create a key press event in all the graphs for the same key and un-check consume. Have the events in each tied to a simple print string saying which thing did the printing.

Is there something I could be doing wrong to get this ordering? Is the documentation out of date? Bug? Other?

2

You’ve stumbled across a bug. Took me a while to figure out what was going on, but I believe I have it fixed now.

The documentation is correct in terms of what the order in which the components get the opportunity to process the input. However, after we collect up all the delegates to call we sort them so that if there are multiple key presses in the frame the delegates are executed in the order in which the keys were pressed. So, for example, if you had K and M pressed in the same frame (in that order) and the controller handled M while the LevelScript handled K, the LevelScript delegate would fire first and then the controller delegate would fire. The problem came that in the case where all of the components were handling the same key the sort could reorder the delegates such that the order of the events was not consistent with the input stack.

I just checked in a fix to our main branch for this, apologies for the oddity.