Why is some of the Input handled in ACharacter?

Why is some of the Input handled in ACharacter? (e.g. MoveForward)

Shouldn’t it all be handled in APlayerController?

There, some information on player controller and where to implement stuff.

I understand the concept of the controller, which is what led me to my question. Shouldn’t all of the input be handled in the controller?

My character class (MyProjectNameCharacter) seems to be listening to input - SetupPlayerInputComponent. Why not listen to it only in the controller?

It seems like in the second link you attached Jeff Farris brought up the same point:

That’s why I’m surprised that by default some stuff are being listened to in the Character rather than in the PlayerController, unless it’s a symbolic piece of code to show it is supported like he mentioned.

Either that or I’m missing something.

Well you obviously didnt read what BiggestSmile’s linked there.
Here you go

Everything depends on your final goal, if you’re developing a MMO with ability to change pawns during gameplay, like entering vehicle/helicopter/whatever, it would be better for you to implement input processing directly in pawns, if you’re developing simple single player game, you’re most likely to implement input processing in player controller.

Myself i implement pawn-related input in pawns, and player-related input, which does not depend on selected pawn, in player controller.

Please read my edit as well, seems like we posted at about the same time.

My bad I didn’t read all they way down, could you please help me understand what are “input triggers” and why they are needed? Why not have the input in controller and from there initiate the matching action in the pawn? I’m not entirely sure I understood his example.

On input triggers i meant “process” when player does some action(presses button, moves mouse).

You’re totally free to do it how you want, but it would be logical to implement input that depends on selected pawn in pawns and so on, read my edit above.

Just a little edit:
If you’re going to have multiple types of pawns in game and going to implement input in player controller, you’ll have to get pawn controller currently posses, then cast it to corresponding pawn or check if it’s subclass of some spawn, and only then start processing input. If you implement pawn-related input directly in pawn, you would not need to do all of that, input will be processed automatically.

Yes I didnt see your edit when I posted.Like BiggestSmile stated,if you dont have more than a single pawn in your game,you dont need to process input inside Pawn.But if your game has a lot of pawns,each pawn may need to have different inputs,like vehicles.Then you need to check which pawn is possesed in your player controller and switch input processing accordingly,which is hell of a work.The best way to deal with this is if you have more than 1 pawn,input processing should be done inside Pawns.

I guess it’s logical if that input is only related to that specific kind of Pawn, which isn’t the case with what they did in MyProjectNameCharacter. (If I understood you correctly)

I’m developing a single player game, also with the ability to change pawns. Why would it be better to implement input processing directly in pawns in MMOs?

Read my post closely please, it’s all there, and i didn’t state it being just some MMO…

I think I understood you, so MMO was just a scenario in which different pawns with different inputs may be needed. Right?

I think this is generally a good model. It’s normal to have some input handling that isn’t pawn-specific which makes sense to handle in PlayerController. e.g. Handling the Pause key or having Esc bring up the ingame menu – you don’t want to have to duplicate those bindings in every possessable pawn type.

One thing I want to point out about the architecture is that all input flow happens through the PlayerController, since input devices are tied to a particular player. This means the PlayerController is the dominant object in terms of input handling. By default, it chooses to recognize the bindings for certain other Actors (possessed pawn, level script), but it has the final authority over where input goes and in what priority order.