[SURVEY] There's A Really Really Terrible Bug Where Child Blueprints Get Their Variables Reset

I had the same problem on UE 4.24. One of the components in the blueprint would loose all properties on editor restart. Also, when changing properties the editor would not see it as a change that requires re-saving the blueprint. The component was written in C++ and the blueprint derived from a C++ class (inherting from UObject).

I found the solution for my case - it was caused by circular dependencies. The problematic component had a UPROPERTY field - pointer to its owning actor, which was initialized in BeginPlay(). So the actor would reference the component, the component would reference the actor and it repeats from there. The problem was occurring for all instances of the blueprint in the level and for the blueprint asset itself.

So I advice you all to check for such unnecessary UPROPERTY pointer fields in your classes. When you’re sure that the pointer is valid and will outlive the component and requires no serialization - there is no need for UPROPERTY. A raw pointer is fine. Btw, a good warning from UE would be very useful.

Just a heads up, the proper handling of this use-case is to use a TWeakObjPtr, not a raw pointer.

Yeah, but in that case even TWeakObjPtr is not needed. That’s what I meant by “will outlive the component”- no need to be afraid that the owner will get deleted before the component.

I have got stuck with my project due to this issue. I am on UE4.23.1, is this being worked on?

There were a number of bugs with the Duplicate and Copy/Paste workflow of Blueprints in the past. Assets created with those Engine versions may be in a broken state. The fix is to recreate the affected assets from scratch. Duplicate and Copy/Paste should now be safe to use again, but if you want to be completely safe, I’d recommend using the slower workflow via Content Browser -> Right-click -> Blueprint Class -> Select parent class, etc.

I’m experiencing this again on 4.24.3 - I don’t really have any reproduction steps, and sadly this is something I experienced back in 2016/2017 and thought had been fixed. It kind of amazes me that such a complex and deeply troubling issue still exists within the engine with the amount of destruction something like this could cause. Anyone else, and is this possibly fixed in 4.25?

I just made a video describing my problem and how i fixed it this time.

It might help somebody else or someone might be able to explain why what i did fixed it or how to avoid it from happening again next time i decide to add a new variable to my structure.

I have the same problem 4.22 after add a var in struc from my parent class and a other var changed.

My solution is to change the var in parent class and changed back and save parent class. All child class would be saved and my child class data is not lost.

4.26.1 and the bug is here…

ue4.26.2 and the bug still here

UE5 built from source today, the bug is still present.

1 Like

this bug is here 4.26.2

@Democle

Why post again - do you think Epic are reading any of this???
They’re not sadly:upside_down_face: So want it fixed??? File a Bug Report!!!
Otherwise, look forward to seeing it again in 4.27 / 4.28 / 4.29. :stuck_out_tongue_winking_eye:

1 Like

This bug still alive, in UE 5.1 from source compile ue5-main branch
My child blueprints of a common parent, have all their inherited static mesh reseted to parent setted mesh.
I try set the mesh at it, save it works in editor, but as soon i restart editor or reload the blueprint asset its gone! :sob:
It started happen suddenly, and only affects this specific blueprint hierarchy.
If i create a new hierarchy from actor base, it works normal.
So i believe this blueprint asset become somehow corrupt and always get it value reseted at the 3rd level hierarchy and above

1 Like

So for everyone who has similar issues unreal engine runs into lots of corruption issues with migrating projects new version, change control and when the engine crashes.

Most cases I think what happens is that it attempts to cache and keeps multiple save states during those things and it can’t reconcile which is the correct state leaving your project with broken child’s or incorrect BPs.

Solution that I have found worked consistently which people have mentioned earlier is cleaning up all temp/cached files. That includes if you use change control the diff folder and the intermediate folder if all else fails. I don’t believe it doesn’t happen to epics in house team and I can imagine they prob routinely cleanup those files since a number of things can easily throw your project out of wack.

I think rule of thumb if unexplained issues happening with your project wipe those files out. Can be annoying to recompile things but will save yourself a lot of brain cells later. Do like a monthly cleanup overnight or something.

Hi all,

Here is what I think I found :

  • if the root of your parent is the original default scene root, it seems to always want to go back to movable, causing problem in its children relative to mobility.

This problem still exist in UE 5.1 and its very very frustrating. My child blueprint actors keep reseting continusly everytime I close Unreal Engine. I couldnt find any solution, I delete every cache folder and problem still continues.

Not sure if this is the same issue for everyone but I noticed an issue which is 100% reproducible and as far as I can tell it means you should avoid setting values in the constructor.

Steps to reproduce

  • declare a C++ class type with, for instance, a pointer as a member (any member type will do)
  • assign that member a value in the C++ constructor
  • use this C++ type as a base class for any blue-print class.

When the C++ class is constructed the constructor for your class is invoked and you assign your value, so far so good.

Unreal allocates your object from here using an FObjectInitializer on the stack:
Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp

UObject* StaticConstructObject_Internal(const FStaticConstructObjectParameters& Params)
//... for brevity
	if (!bRecycledSubobject)
	{		
		STAT(FScopeCycleCounterUObject ConstructorScope(InClass->GetFName().IsNone() ? nullptr : InClass, GET_STATID(STAT_ConstructObject)));
		(*InClass->ClassConstructor)(FObjectInitializer(Result, Params)); // < this version of FObjectInitializer() sets FObjectInitializer::bShouldInitializePropsFromArchetype to true, and there's no way for the application to tell it not to do this as far as I can tell
	}

When the above FObjectInitializer goes out of scope it invokes it’s destructor which has the following code that is about to overwrite your value:

	if (bShouldInitializePropsFromArchetype) // recall this value was set to true in the constructor used by StaticConstructObject_Internal
	{
		UClass* BaseClass = (bIsCDO && !GIsDuplicatingClassForReinstancing) ? SuperClass : Class;
		if (BaseClass == NULL)
		{
			check(Class==UObject::StaticClass());
			BaseClass = Class;
		}
	
		UObject* Defaults = ObjectArchetype ? ObjectArchetype : BaseClass->GetDefaultObject(false); 
		InitProperties(Obj, BaseClass, Defaults, bCopyTransientsFromClassDefaults); // <- will overwrite any fields you set in your constructor with what it considers the defaults from the CDO
	}

you should avoid setting values in the constructor

So does PostInitProperties work around this?

Yes and BeginPlay() as well. It’s worth nothing that I believe the issues I was seeing is specific to things like pointers. The CDO runs the constructor so any non pointer types should be set in the CDO properly.

Here is another good post on this issue: UPROPERTY member vars reset to NULL by ObjectInitializer

2 Likes