Idk if this was removed or what, but I can’t find this node. It’s frustrating me to no end since working around it is, well, you know. Dumb. I don’t see any way to check my installation either. Has it been replaced? Is there a new name? Nothing in the Update notes. Please help
Nodes are context sensitive, if you look for it while in the PlayerController blueprint, you’ll find it. Alternatively, just untick ContextSensitive in the upper right corner:
Generally speaking, if you need to untick ContextSensitive to find a node, you’re doing something awkward. In your case, whatever you’re attempting should be handled in the PlayerController blueprint instead.
Also, when working outside of the blueprint that the node naturally belongs to, use a reference to work within the right context:
The longer you work with the system, the more you get to appreciate node filtering. One note here, if you have programming background, the way blueprints are wired may seem illogical at first. Kind of backwards 
I didn’t realize that context could mean the actual type of BP you were editing. I figured it was only based on which point on which node you were dragging from. I found it now. I also didn’t realize there was a PlayerController BP… Makes sense, I just never thought there would be one since the default character BPs contain their own input logic. Frankly I’m a bit confused as to why there is a separate Actor to give a BP to to control a character… seems kind of redundant, like maybe it should be inside of Pawns and toggle with “Can be possessed” or whatever.
In any case, thank you. This information wasn’t something I could find, I spent a couple hours looking. Maybe I used the wrong keywords. Thank you.
Frankly I’m a bit confused as to why
there is a separate Actor to give a BP
to to control a character… seems
kind of redundant, like maybe it
should be inside of Pawns and toggle
with “Can be possessed” or whatever.
You’re very close. Character extends from Pawn (character is Pawn-derived). But it’s the Controller that does all the possessing.
If you have a Battlefield type game where there is tank (a Vehicle Pawn), a plane (a flying Pawn) and a footsoldier (a specialised Pawn that already exists in UE4 - the character), you can use the controller to possess any of them. The controller sends generic input to any of the Pawns but it’s the logic in the Pawn that will be unique. Holding left arrow will turn the tank in place, roll the plane and make the soldier strafe to the side.
You could probably make a complex game without using the controller too much but it makes certain things easier.
Yeah that makes sense. I guess I just assumed that logic would be handled backwards to how it is but I can see how this is very flexible. Separate question, maybe you can answer. Since creating my Pcontroller BP some of my input actions seem to no longer actually input anything. Can there be conflict over which BP is processing which inputs? Axis mappings work fine, but the jump didn’t and then did work, and other key assignments I have seem to not do anything anymore… at the very least they aren’t executing their functions. Is there a logical hierarchical relationship to be understood between gamemode, playercontroller, and playercharacter that isn’t super straightforward that might explain this?
Can there be conflict over which BP is
processing which inputs?
Yes, input can be consumed:
- if the User Interface intercepts a mouse click (over a button, lets say), the button gets pressed, input consumed and the click is not sent to the PlayerController - meaning that the world will no longer have a chance to handle that click. However, you can deliberately allow a click to trigger an interface action and still tunnel through to yet another UI element, do its business and still allow it to go unhandled and reach the PlayerController.
In addition there are also specific Input Modes that automate this behaviour a bit, these can be adjusted dynamically during run-time:
-
Set Input Mode Game And UI - allows only the UI to respond to user input, and if the UI doesn’t -
handle it player input / player controller gets a chance -
Set Input Mode Game Only - allows only player input / player controller to respond to user input
-
Set Input Mode UI Only - allows only the UI to respond to user input
-
-
a Key Event or Input Mapping can also consume input (set as default on the left here)
If I remember correctly, providing the input is not consumed by anything and regular actors are allowed to receive input (AutoReceiveInput), they will have a chance to handle it first based on the priority:
…then the controller gets the chance and then the pawn
Is there a logical hierarchical
relationship to be understood between
gamemode, playercontroller, and
playercharacter that isn’t super
straightforward that might explain
this?
The documentation is lacking here and there but the relationship is as follows:
Explained here better than I ever could.
Wow you understood exactly what I needed to understand… If I could send you a cookie at a reasonable price I would. The documentation is indeed lacking on this topic almost anywhere. I had read that inputs are “consumed” but never considered the implications of that terminology. So I never considered that only on thing would be able to consume said input. This makes onconsume events make so much more sense. Really terrific.