In my case it destroys my project (REINST errors, only deleting (manually from windows explorer, because it can’t be unreferenced) REINST-infected widget and recreating it from scratch helps. My UMG widget “skillSlot” has “displayedSkill” variable - and in main UMG widget, in “RefreshSkillBar” function, skillSlot.displayedSkill is set to according Skill. Then, in GetPercent function in skillSlot, is gets displayedSkill.cooldown variable (to get remaining skill cooldown and visualize it) - After restarting editor, this causes REINST errors.
The Blueprint compiler (still) has problems when there are circular class dependencies, which happen when a class “A” depends on another class “B” (either by having a cast node in its blueprint, a variable of the “B” type or inheriting from “B”) and class “B” depends on “A” or on another class that depends on “A”. The size of the dependency chain doesn’t matter: “A” → “B” → “C” → “D” → “E” → “A” will cause a circular dependency.
Circular dependencies seem to work fine when you’re working with Actors and so on, but they start causing problems with:
UMG
Behavior Trees
Instanced EditInline properties (I just found out this one)
I saw a commit in the 4.7 branch involving cyclic dependencies, but I have on idea on whether it’s going to be fixed or not (after all, this problem has been around for what, six months already?).
Currently, the way to avoid such problems is to refactor your widgets and blueprints to break the cyclic dependencies. Try to keep your references “one way”, flowing like branches on a tree: your level references your root widget, which references the children widgets and so on, but never back (the children shouldn’t know about the parent). When you need “leaf” classes to interact with other classes up in the reference chain, use:
Interfaces: pass around interfaces instead of using casts or concrete-typed variables
Use “abstract” blueprint classes: place “public” functionality in a base class that does not contains references to any other classes. The “concrete” class overrides the parent’s methods and can safely reference other classes. This is basically the same as interfaces, but it allows you to add event dispatchers and variables to the base class as well.
Use event dispatchers. For example, you can create an actor class to use as a bag of event dispatchers. This class doesn’t reference any other class so everyone can reference it safely. (Be careful to avoid passing concrete classes as event inputs - this will cause circular references as well)
Event dispatchers are good because you can move functionality that needs to deal with multiple classes and could possibly cause cyclic dependencies into separate blueprints that are only references by “root” elements (like the level).
Has anoyone tried it with 4.8? I’ve read somewhere that in 4.8 many circular reference bugs should be fixed, but i can’t test it on my own at the moment.
I’ve read somewhere that in 4.8 many circular reference bugs should be fixed, but i can’t test it on my own at the moment.