IE_Released doesn't always trigger for bound multi-key actions

Development Programming & Scripting
1

Branch: Source build (without further modification from Epic’s github)

Build version: 4.2.1-0+UE4

Description:
For key presses involving a modifier key (ctrl, alt or shift), functions bound to the IE_Released event of an action involving them are not called if the modifier key is released before the main key.

Repro steps:

  1. Set up an action mapping ‘Example’ with a key combination involving a modifier (e.g. Control + LMB)
  2. In the SetupPlayerInputComponent of a pawn class, bind the IE_Pressed and IE_Released events, using InputComponent->BindAxis.
  3. Start play.
  4. Press and hold the modifier (e.g. Ctrl) then press (and continue to hold) the main key (e.g. LMB)
  5. Release the modifier
  6. Release the main key

At this stage, the bound keys will both have been released, but the function mapped to the IE_Released event will have not been called.

I have tried this with non-mouse keys (e.g. Ctrl + W) and it does the same thing. Similarly, replacing Ctrl with Alt or Shift will also triggers this bug. Note that if the main key is released before the modifier, the IE_Released event will be triggered as expected. I have been testing this in a C++ code project; I am unsure if the corresponding problem happens with the blueprint version.

2

To elaborate with slightly more code, in step 2:

InputComponent->BindAction("Example", IE_Pressed, this, &AMyPawn::BeginExample);
InputComponent->BindAction("Example", IE_Released, this, &AMyPawn::EndExample);

and then, it will be the function ‘AMyPawn::EndExample’ that is not called when it is supposed to be.

3

Hi AJPGarner,

Thank you for the information you have provided. I have documented this issue and sent it to the Developers for further investigation.

Thanks,

4

Hi AJPGarner,

I received a response from the developer who worked on the input action mapping logic, and the behavior that you described seems to be the way the Engine is intended to work in this scenario. He actually posted a response to a very similar question (that I completely missed when I was responding to your question) explaining why it is set up this way.

There are certainly ways to get around this limitation, but they would require some additional planning and coding.

5

Thanks for the response. I had suspected there may have been some design reason why what I described was in fact the way it was supposed to behave (i.e. this is more of a ‘gotcha’ than a bug!)

I will think of some specific solution for my game. In my set up, the press and release toggle between a ‘move around’ state, as I am making a strategy game with a mouse cursor, so I don’t want to the screen to start rotating on mouse-movement unless the player explicitly tells it to by holding down the mouse cursor. Interestingly, from the code in the link to the last time this question was asked, I seem to be in almost exactly the same scenario as the previous person who wanted to implement this behaviour.

My solution is to explicitly poll whether both keys are still down on the axis events triggered when this ‘movement mode’ flag is on; and to manually call the release function if they are not. I didn’t want to implement this as a ‘hack’ until I was sure that the engine was indeed behaving as it should be! I will have to think more carefully how to make sure this approach continues to work if other keys are also bound to the ‘toggle’ action - but in lieu of a generic solution, I can certainly make this work for some particular key chord.