So I have a controller that contains the necessary variables for my animation blueprint to function and over time I’ve noticed that the list of casts just for logic states is getting longer and longer making for a very noisy BP and I’ve been considering a few ways of cutting down the cross BP chatter and before doing so it would be a good idea to vet the idea as to soundness.
Cast to the controller for the variable when needed once the connection is made in the animation BP setting a single local var. This is where I’m worried that I’ll break something but the logic says why convert to local when the required var is already available?
Convert game logic to arrays with in the controller. Done this way the animation BP only needs to cast for and set a local variable for that on var.
I’ve already tested the theory but a bit concerned that most examples that I’ve seen, or tutorials, have shown examples of converting to local with out explaining as to the reason for doing so and seems like a duplication of something already available. As it stands the animation BP contains dozens of state changes that requires an almost constant state of casting on animation updates and I figure there must be a better way of cutting down on the chatter
If you implement a blueprint interface in your controller, you can make calls on it without casting. You just have to write interface functions and events to process your data.
If you’re spending so long moving data in and out of the controller, it’s probably not the right place to have the data. A lot of tutorials I see on youtube randomly choose to do things inside the controller or game mode, that make no sense whatsoever. Is there somewhere else you could more easily use and process this data?
I typically set references on initialization so I’m not constantly casting all over the place. For example in my character class I create a reference for the controller. In my anim class I create a refence to the character. Anywhere that I’m going to refer to class A Lot I just create a reference.
As far as controller and pawn are concerned I keep pawn logic in the pawn. Inputs in controller that call events in the pawn.