This is an issue I have seen mentioned in the past without a repro case (and I believe resolved because of the lack of one) - I couldn’t find a current thread on it.
The issue: When you make a custom component, and add it dynamically, the Add Component node after running successfully for several iterations becomes corrupt - it gets a compile error saying “Error: Failed to find class for pin Return Node”. This makes custom components almost unusable as there is no other way to dynamicall add them, and this error re-appears frequently.
The node will now complain about circular references on saving occasionally. Which error goes away just as randomly (by compiling and then saving, generally).
The key factor (I believe) is that the custom component contains an array of structures. I’ve created a minimal project which reproduces this behavior.
In the case of my minimal repro project, there is a simple buff class called “MyCustomComponent” with an array of structs containing the ID of a stat and the amount to adjust it by. It is otherwise exactly the Third Person base project with the character adding this component to themselves via the “B” key.
To reproduce:
Make a new clean Third Person base
project.
Make a new Actor Component-parented blueprint class called MyCustomComponent.
Add a simple struct with an int and a float in it called MyStruct.
Add an array of MyStructs to your Actor Component.
Have the third person character add a MyCustomComponent to itself via the Add MyCustomComponent node.
Enjoy things working well for 3 or four new changes of adding print strings to myCustomComponent
Watch as the AddComponent node stops working.
The circular references may need MyCustomComponent to make a simple manipulation on it’s owner - however, I’m not sure how you could avoid having the character know about the component and the component knowing about the owner (don’t all components do this?* edit: self-answered in Update 2 below.)
Thanks. How do I upload the repro project for y’all if necessary?
Update: Even changing the variables to be arrays of non-structs causes the repro case. Is Add Component allowed to be called by Blueprints? There is a comment inside the code for it saying for internal use only, but it’s certainly exposed to be called by blueprints and there is no other way I can find to dynamically add a component to an actor.
Further update: I have grokked the essence of using interfaces and Event Dispatchers to avoid the above mentioned circular references. However, the initial issue still persists even with zero circular references in the project.
Yes, this happens to me all the time, is so annoying.
The only way to ‘fix it’ is delete the node and create it again, but I repeat, is super annoying.
I have the same problem. I am using custom components for some gravity behavior on pawns/actors since I don’t want to implement the functions in every object or derive everything from parent classes. My gravity component is attached to pawns/actors from beginning and not attached dynamical. When I am working at my project randomly, but quite often a save problem occurs, where it is said, that the parent class which has the custom component can not be saved. Some reference to Engine/transient.
The only solution is to delete the custom component and adding it again. It’s very frustrating because all the nodes which has that custom component needs to be fixed after adding it. I need to constantly fix my project…
Hi Savadiv - a common issue causing that behavior with components in my experience are circular references in the components.
For instance, the parent is often aware of the custom component’s blueprintable class because it owns one, and the component is aware of the parent’s class commonly so that the component can operate on the class.
However, that’s forbidden in blueprints and causes issues like you describe, or causing class references to be replaced by REINST_CLASS or TRASH_CLASS, or crashing on project load/compile, or failing to save because of a reference to Engine/Transient.
Using interfaces and/or binding callbacks to event dispatchers has worked well for me to avoid those - for instance if there is an iReceiveGravityEffects interface implemented by your owner actors (or one of several other ways of structuring this) then the component can deal with the owner via just an actor reference using that interface. If there is no casting or referring to the actual, non-native blueprint class - no more circular reference.
At the end of 2 weeks of rooting out circ references in our project, everything compiles much faster, crashes are gone, and random issues of changing class references/not being able to save until compiles as you’ve seen/etc. are all better.
Ironically, the original issue from this thread still remains however even though I was (after lots of learning) sure it was a circular reference causing the issue (I cleaned it all up after our hell-weeks stripping out circulars and the minimal test case still shows the issue, sadly)
Other ways of solving the references: Bind to event dispatchers, implement one class in C++ and use that interface (which are immune to circular references as long as you aren’t exposing (for instance) class-reference variables to blueprints). It can be rather clunky, but in a project of any size it appears necessary.
If your issue isn’t circular references and you’re all over those, let us know if you find an answer!
Hi DeGaffer! Thanks for the detailed and helpful answer. After understanding the problem clearly thanks to your explanation I was indeed able to fix my project and voila - everything is fine again. Thank you, sir!
