This is an issue we’ve been fighting for some time on our project, but it’s causing an awful lot of grief and wasted time. We keep hitting this same issue where blueprint (seemingly randomly) will begin to crash when you try to compile them. The general issue of circular dependencies in BPs is not unique to 4.18, however this is the first time it’s caused editor crashes for us. And it seems very much to be related to circular dependencies in blueprints, an issue I know has existed before. Bearing in mind previously circular dependencies has only caused us build errors, this could be a misdiagnosis, but just based off the place it’s occurring and the values involved lead me to believe it IS circular dependencies.
The error we’re hitting is an ensure at like 2282 in UObjectGlobals:
ensure(!GIsDuplicatingClassForReinstancing || InClass->HasAnyClassFlags(CLASS_Native));
I’ve tried reading into this myself but without much success. It seems though, as with previous circular dependency issues, we’ve fixed it with other classes by simply making sure no two blueprints have references to eachother, although this becomes very difficult to avoid at points, and much of the time seems to cause no issues at all. That makes our repro steps very difficult, because they are essentially:
“Have two blueprints referencing each other and compile” but for weeks/months at a time, that seems fine, then just randomly one blueprint still start having an issue with it. It’s also a situation we really don’t want to have to work around as for a lot of our systems (perhaps naively) we very much want two blueprints to know about each other.
Has anyone else had a similar issue and has a better work around than simply having all the references work in one direction?
*** EDIT ***
We managed to find a more specific context for this, the crash only occurrs when the blueprint inherits from our own Character derived C++ class, and has children of its, own, if either of these two elements changes, the engine will no longer hard crash (although we do still hit an ensure).
Further to this we did actually fix the crash for us, for some reason our blueprint having ANY event dispatchers in it caused the crash, however when trying to re-produce this problem with another blueprint inheriting from the same C++ parent, and with children as well as event dispatchers, we couldn’t get the crash, so it must be some unique issue with the blueprint and its data.