This makes the behavior of Enhanced Input consistent with the Legacy input system when UPlayerInput::FlushPressedKeys is called (loss of focus to the viewport, or it is otherwise called from gameplay code).
Enhanced Input was incorrectly determing if a key was down on the previous frame if the input was flushed because its RawValue would be reset. We now check if the input is currently being flushed on this frame, and if it is then we can determine if the key was down on the previous frame based on it's "Value" in the key state map. If the "Value" is non-zero, but the "RawValue" has been reset to zero, we know it has been reset from the FlushPressedKeys function.
This behavior is Default ON, but can be toggled off in the Project Settings > Enhanced Input.
#jira UE-165730
#rb jodon.karlik
#preflight 6467858975696d2bd7de8254
[CL 25549173 by ben hoffman in ue5-main branch]
There is an editor preference to change what pins show up by default in blueprints, but this change will hopefully point people towards using Input Triggers more instead of relying on undefined input behaviors and improve the first time user experience.
#jira UE-169056
#rb trivial
#preflight 645571d7d77a82d6a790be89
[CL 25395035 by ben hoffman in ue5-main branch]
The Input Editor module has several features that are using the K2Nodes from enhanced input when it doesnt need to. The Blueprint Node logic should be kept in its own module.
This will allow the K2Nodes to actually read from editor settings and preferences in the rest of enhanced input, which would otherwise cause a circular depedency in the build graph.
This change is really just moving some functions from one module to another, neither module is publically exposed so no deprecation is required.
#rb trivial
#rnx
#preflight 645914ab4c3ec54e6e1070ec
[CL 25375925 by ben hoffman in ue5-main branch]
This fixes the situation where your key was not in a previous mapping context, but you still want this behavior.
For example:
1. You have an IMC with no key mappings to X
2. Your player presses and holds X
3. While they are holding X, you add an IMC with a mapping to X.
4. That input action should not trigger until the _next_ press of X.
#jira UE-156910
#preflight skip
#rb jodon.Karlik
[CL 25343918 by ben hoffman in ue5-main branch]
=> code from CL 17423372 was disabling it explicitely, but I couldn't find any reason or have any repro. The comment talk about disabling between an item and its child, while with a EItemDropZone::BelowItem, it correspond to the bottom part of an item, and not the bottom item, so having the child item expanded or not won't change the drag n drop behavior.
- Fixed drag n drop issue for Input Mapping Context, where drag n dropping could give deterministic but incorrect result when more than 1 mapping exists for a group.
=> the reordering algorithm used requires that the content of the array is ordered by group, while it was not necessarily the case. Starting from this CL, it will (slower but safer algorithm).
- Prevent the drag n drop for Input Mapping Context between rows that are not part of the same parent node.
Tests:
-opened various Input Mapping Context from QA Game, like /Maps/Framework/EnhancedInput/EI_HelperAssets/Controls_3rdPerson/IMC_3rdPerson_Controls.uasset, that was failing 100% on some actions. Drag n dropped groups (collapsed or expanded), even on the last one, and on individual entries with 100% success. Did a lot of drag n drop test (between close elements, first and last, last and first, first and middle,...)
-tried to drag n drop across entries from different parent => it was blocked as expected.
-undo/redo after those operations.
-used drag n drop in other contexts (media play list, data table), no regression noticed when drag n dropping elements.
#jira UE-157906
#rb nate.strohmyer, karen.jirak
#preflight 644fd08e1c2846595c454ffa
[CL 25284259 by yohann dossantos in ue5-main branch]
