I had a quick question about circular dependencies, and I was wondering if someone could give me an insight into how to avoid these in blueprints.
Let’s say I have a HUD class and a UMG class. The HUD class would create and destroy the UMG widget and store the reference to it. The HUD class could also tell the UMG widget to update a percentage bar for example:
HUD->UMG Widget->UpdatePercentageBars
But what if I want the UMG widget to close or open another UMG widget? I’d be calling PlayerController->GetHUD to get the reference to the HUD. Then I’d be referencing the HUD and calling a function to open a new widget:
I don’t think I quite understand your question. A widget is capable just like any other BP, of opening other widgets assuming some sort of event took place. If you could clarify a little more as to what you want to do I may be able to help.
Also it’s worth noting that there is no need to destroy the widget after creating it and is probably a bad idea if you plan on keeping it updated. The widget can stay instantiated without being seen as long as you don’t “Add To Viewport.” Using a “Bind” in your widget for the health bar, creating a separate variable to accept the new health percent and applying it through the bind, will ensure your widget is always and properly up to date
Well this is a question that came about over the course of a year or so of working on a game. We began to notice that load times were taking significantly longer, as “dirty” blueprints must be recompiled.
We were also unable to upgrade our project to 4.8, and really didn’t ever get a solution to the instant-crashes when we opened a blueprint in our project. Some people had suggested that it could be circular dependency issues (causing both problems).
Because I am not exactly sure what examples would be considered normal within blueprints and which ones would lead to the issues that we haven’t been able to resolve, I was asking in here, hoping that someone with some engine experience would be able to give me some examples of circular dependencies in blueprints and possibly how to avoid them.
This may enable me to look at my code and see if there is anything that I am doing wrong in it.
The best way to avoid circular dependencies in blueprint is to use interfaces:
I myself got many problems with this in 4.6 and 4.7, but in 4.8 Epic worked a lot on fixing problems caused by circular dependency, so I don’t care about it at all now, I have a lot of circular dependency in my project and it’s fine in 4.8 But 4.7 was really a pain to use if your project has much circular dependency.
That makes sense. I’m still unable to update to 4.8 on the current project that I am working on. I haven’t had the heart to try 4.9 yet. I’ve been looking into interfaces though in C++ and have been having issues getting them to compile. Thanks for the help.
But 4.7 was really a pain to use if your project has much circular dependency.