I’ve recently started to convert a project to support multiplayer before things become too messy - However, I’m unsure what the best method of utilizing player controller is.
In all examples I’ve seen, all of the movement logic is dumped into playercontroller, rather than just handling the inputs. Is this correct? Or should I just let the pawn be a collection of meshes and collision detection variables?
If I do move all the movement to PlayerController, how would I go about, say, applying torque to a component in the pawn?
I just use the player character if you are only controlling one character. Things where I control multiple pawns I would put more logic in the player controller. Thats just me tho.
I would keep movement on the pawn. It’s cleaner keeping functions you only do on a character on the character. PlayerController is better for anything you can do while unpossessed or while possessing an actor like menus, maps, score screens. I can’t fire when I’m not possessing an actor so why would I need firing script on my controller.
If you start putting movement or firing on your controller you have to start doing blueprint communication for everything. On top of that, if the class you are possessing isn’t the same class you cast to or saved a reference for your movement script goes out the window unless you get less specific or use interfaces
Or if you have 2 classes that share the same Input key but do 2 different things, like a spectator spawn that changes cameras when you press fire and a character that fires, your player controller then needs to know what it is possessing to perform the right function instead of just performing an InputAction on the pawn itself.
It’s not like you have to do movement on every character blueprint, just make a base class with movement/firing and all it’s children will have movement and firing
There is an input hierarchy or stack in place, player controller is the top I believe, UMG Widgets can be pushed to the top.
If the player controller doesn’t have an InputAction using a certain key then the possessed actor takes the input and checks if it has an action using that key, if it does it performs the action. When you create an InputAction in your Project Settings it is available in all actor blueprints and PlayerController so there is no need to pass inputs, just put them in the right place
I mean, how do I, say, get InputJump in PlayerController to communicate with the jumping logic in PlayerPawn - From what you’ve just described, I don’t need to have anything in the PlayerController.
I find this confusing, as we understand that a PlayerController is needed online games where players can die and respawn, or otherwise take another role (spectating, specificly).
A PlayerController gets created locally when launching a game and only exists on the client. The GameMode is what assigns the player controller to a pawn, it is where you put your spawning script as well. The PlayerController blueprint can be completely blank, it is by default. It is the interface for a client to send input to the game using the UObject PlayerInput that is coded in the PlayerController class.
Your playercontroller doesn’t jump, PlayerInput takes in the keystroke. When you hit Spacebar, the keystroke goes through the stack until it finds an InputAction using Spacebar. Input Jump is on the character blueprint, if you put it there.
InputComponents are most commonly present in Pawns and Controllers, although they can be set in other Actors and Level Scripts if desired. The InputComponent links the AxisMappings and ActionMappings in your project to game actions, usually functions, set up either in C++ code or Blueprint graphs.
The priority stack for input handling by InputComponents is as follows (highest priority first):
- The Actor with the most-recently enabled “Accepts input” - this can be anything from a door to a pickup item. Even though this is the top of the stack it only really applies if you trigger input enabled on an overlap event for example
Controller
Level Script
Pawn
If one InputComponent takes the input, it is not available further down the stack. This functionally can be bypassed by setting the “Consume Input” boolean to false on the input action
Input Processing Procedure
So if your PlayerController doesn’t have anything using Spacebar, it goes to the level blueprint and checks, if it isn’t in the level blueprint it goes to the controlled pawn. This is why you don’t want menu inputs on a pawn because if you aren’t possessing it you can’t bring up the menu (UNLESS it is a menu that you only want possible when the player is possessing that pawn), this is also why you don’t need anything that only a character does on your PlayerController
