Sort of, I meant casting to the specific class so that we can access the component variable, as opposed to having to call “get component by class”. It’s still tedious to do though, and part of my problem on dependencies is that getting component classes directly causes dependencies on components.
I’m also worried of the performance cost of having so much code go through interface messages, and having to search for components so often.
Like mentioned in the above post, I ended up with animation montages that have dependencies on half my components because their anim notifiers call functions on the components.
The engine generally seems to handle those kinds of dependencies, except when it doesn’t. I have data assets breaking and losing all their data when closing/reopening the editor due to obscure UE5 bugs that don’t seem to have any solution but seem to be caused by circular dependencies, so I was trying to organise my code in a way that minimises hard references.
The main goals are just:
- Avoid hard dependencies as much as possible to limit the risk of circular deps
- Have as little boilerplate code needed as possible for something to interact with a component on an actor
The lack of ability to use events is really a problem for me too… I end up with a lot of code checking values on tick to detect changes, not ideal. Blueprints don’t seem to allow a lot of async/delegate/event programming, outside of very specific circumstances, sadly.
There is one possible thing that might help with this which is macros. Macros, unlike function libraries, get inserted in the event graph. This means they can have execution pins and I think should allow using delegates. I haven’t looked into what would be a good way to use macros to solve this problem yet, but something might be doable to make things easier.
Of course you still have the limitation that none of this can be used in functions, so it would only work in event graphs