Why does Third Person Template does not have Controller Blueprint?
First Person and TopDown template have a controller Blueprint.
I know this may seem like a “dumb” question but I try to understand what logic I should put in the PlayerCharacter BP and what logic I should put in the Controller BP.
(I am working on a topdown project).
For example - All you behavior modification logic should, logically, go in controller BP.
However when you want to play a montage you need a reference to the mesh and that naturally exists in the PlayerCharacter BP so you might think that the Character BP is the most logical place.
However, playing a montage affect your behavior: attack, dash, roll all of that affect your behavior just as pressing WASD.
So frankly, there are two questions here:
Why Third Person Template does not have a Controller Blueprint?
And how do I know which logic to put where?
1 Like
The third person does have a PC, it’s just not a blueprint, that’s all.
The first person PC inherits from that code
As far as where to put what sort of logic, there is no fixed places for things. Sometimes, the player controller, game instance, game mode, player character etc will seem like a logical place and you can use it.
For instance, the ‘player controller’ sounds like it ‘controls the player’, so it sort of seems like player logic should go in there. But it’s actually the main place where input is managed, so maybe it could be called ‘input manager’. A good example is managing the ESC key. ESC can mean a lot of things depending on context
- Open menu
- Previous menu
- Close menu
- Stop using rifle sight
- Cancel
- Etc
Instead of having some nightmare web of code between a lot of different blueprints, you can make the decision on what to do in the PC. Easy.
Two rules of thumb, I would say:
-
Don’t use the level BP ( except very sparingly )
-
If you find you need to pass a lot of information back and forth between blueprints, then you probably have the code in the wrong place.
Thank you for taking the time to answer my question. But it actually left me more buffeled.
Lets start with PC is for managing the input. In that same logic the Reload command (Input ‘R’) should be placed in the PC? however, ammo count, weapon type and playing monatges are all placed in player BP or in a component in player BP.
Of course I can move all that information to the PC but it doesn’t make much sense.
Regarding the ESC input. That’s a really good example actually. I think that the ESC command should be present in many blueprints just because of the many actions it can take in many different situations.
But then again, I am a beginner so currently this is all just theory to me.
But what I get from your answer is that it doesn’t really matter as long as you don’t pass information between blueprints too much and everything make sense and easy to find if you have to change something half a year later.
1 Like
It makes sense to have reloading in the player ( or possibly the weapon ), of course. But the funneling of the R to the player is done by the PC.
The actual key handling for ESC should only be in the PC, it will then tell all the various other BPs when to do what ( probably with an interface ). That way, you’re only handling it in one place, and the all important state information is easily contained. The other BPs never have the actual ESC key event.
Correct! A lot of info passing is a sign that something’s in the wrong place.
Good luck 
