I just wanted to bring up what people prefer to do with their input and where to implement the pawn/character movement.
Currently the PlayerController receives input first and can decide to take care of control and then consume the input so that the pawn wont receive the event. Since this is where the ‘will’ of the player (ie me and you), belongs, I think it would be easy (in the case of if we are switching the possession of pawns) to keep control logic here and call ‘addMovementInput’ from inside the PlayerController.
However, the player has the ControlRotation variable which we can add to using the pawn’s AddControllerYawInput and related functions and use this along with the bUseControllerRotationYaw option so that it will always use the ControlRotation of the playerController.
Why do we have the PlayerController have the controlRotation but not controlLocation?
It gets even more confusing when we have the characterMovementComponent that has the orientToMovement option that ignores the controlRotation of the PlayerController and just does what says and makes the character orient to it’s velocity direction. (in the youtube third person videos, they do this but then have the camera spring arm use the PlayerController rotation).
So I’m still unsure about the way the game framework is intended to be used as most content examples implement controls directly in the Pawn/Character but use the PlayerControllers controlRotation in some fashion. If I’m honest, I don’t like the separation between Location and Rotation between the PlayerController and the Pawn it possess. Add on top the Physics RootComponent the pawn/Character will have and then the movement component which sits in the middle of it all.
The Documentation isn’t completely clear on the way things are meant to be set up. A clear write up on the relationship between PlayerController, Pawn, MovementComponent and Physics component would be greatly appreciated. I’m picking apart the sourcecode myself to get an understanding. If someone from epic or anyone else could clear this up then I’d be very grateful.
This is an area that has annoyed me since launch. I have a game where I would like the AI Controller and the Player Controller to use the same inputs to drive the pawn, so in my case it makes more sense to do the input in the Player Contoller and the AI Controller can simulate the inputs. Then use events on the Pawn to do the correct actions but the separation makes is quite hard to do.
Well you can still handle any logic you want to inside the Controller whether it’s a player or AI. The player receives inputs and the AI can do whatever it wants. I don;t understand what you mean about AI using the same inputs. You can just do whatever logic you want and then call addMovementInput on your pawn to move it.
I don’t think the separation is hard, as the controller and pawn both have references to each other and can simply call on each other as needed. My post is mainly about the concept of where the control is implemented and why we have a controlRotation on the playerController at all and why just the rotation and not anything else. If there was a ControlTransform and it was explained that it’s just there as a convenience then I might understand that a bit more. But having location in the pawn and rotation in the controller is a basic design issue in my mind.
+1 to some sort of doc to explain the differences between the classes better.
It took me a long time to figure out what to expect from the physics and I’m still at it. A pawn can’t see hit events when no physics are involved, but changing my pawn to a character created the capsule which doesn’t have this limitation. Currently I’m struggling to add multiple capsules to a character, I’m thinking it’s not possible or at least not recommended but can be wrong here.