I managed to resolve the issue by cherry picking an older uasset blueprint check-in and rebuilding the blue print. I think in my case the issue related to some bad read/write of the uasset and the inability for it to fix itself. I wish there was some way i could make the uasset human readable and then i might be able to hand delete the malicious portion.
For me it happens if I reference my class in a data table. Somehow it just appeared for no reason and then suddenly disappeared just to come back few days later.
I feel like if you can’t repro it then you should refactor it. Clearly the data we lose is still in the uasset, it’s just not loading properly. But who am I anyway
I also lose data many many times, it’s the most annoying thing. You carefully set some transform only to find out that you lose them after a compile, a restart or whatever. Shame this still happens in the otherwise fine engine.
Just throwing in my voice that this nasty bug has effected me too.
Hey gang,
First, I just wanted to surface some fixes in this area. This thread dates back to 2017 so the list won’t be exhaustive, but is a summary of work I did in the 4.21/4.22 timeframe:
4078822 - During reinstancing we started reusing the subobjects that were already contained in a uobject, this fixed a wide category of bugs involving data loss in nested objects (UE-59135)
4433763 - Added a call to resolve some object instances that were loaded as placeholder values that were not always being resolved (UE-62928)
4454677 - Fixed loss of attachment information when repeatedly compiling blueprints that have compile errors (UE-64816)
4525227 - Fixed for issue during reinstancing that could cause attachment information to be lost (UE-66020)
4516935 - Removed some legacy compilation logic that could cause ClassDefaults to be overwritten - the only known repro of this data loss bug involved nativizing blueprints (UE-65011)
4703596 - Fixed logic error in reinstancer that resulted in new versions of objects often not having their references updated, resulting in lost object references during compile (UE-68249)
4746847 - Included the old version of the ‘ClassDefaultObject’ in the reinstancing map, so that references to this object are updated during reinstancing rather than cleared, done at the request of a licensee (also required 5696482, a change slated for 4.22.1 hotfix)
4815337 - Fixed crashes and data loss that occur when reloading a blueprint that has child types already loaded (UE-58685)
Other engineers have contributed fixes in this area as well! Please reach out if you even think that you have a way to reproduce a data loss issue - a new thread , on answerhub or in the BP forum is an efficient way, but if you have sensitive assets a private message to myself is a great avenue.
Fix velocity in this area has been trending downward after some unfortunate regressions related to the blueprint compilation manager so internally we think we’ve made strides on the editor data loss front. Our best practices may contribute: in general we try to avoid deep UObject hierarchies (both in terms of subobjects and class hierarchy) and strive to avoid strongly coupling assets at all, mainly because it slows down refactoring and iteration.
We definitely understand that it isn’t always possible to nail down a repro so feel free to continue discussion , but also keep in mind that as the above list indicates you may be encountering similar but ultimately different bugs. Don’t be shy about starting new threads or messaging me with your repro.
Edit: also I’ll take the to plug this bug submission form
2 Likes
Thanks Dan, I really appreciate you taking the time to update us in the thread!
Personally I’ve been less affected by this in recent years since it pushed me toward more data-driven approaches where the data I was losing before is now no longer stored in the class itself, and I use inheritance less in general. Basically hiding my data in places where BP bugs couldn’t clear it lead me to discover better ways of doing things. 
I was just building a new project, where I was using inheritence from a base BP class, and had this crop up. Didn’t know about it before. But The child instance I have in the scene which has a bunch of exposed variables, seems to be resetting them.
My actors are completely being reset as of 4.22.3. Pawns, Door Blueprints they are all reverting to 0,0,0 for their location and rotation you can view it occurring randomly on my devs twitch stream we’ll go in to load a level and the actors are completely all gone and reset to a new position. The new position always be 0,0,0 this is completely new
My particleSystem are being reset as of 4.22.3. If i manage to reproduce this random bug, i will open a thread .
4.22.0, source built. Ran into this bug for the first time. An edit of a blueprint(namely deletion of 1 unused event) that has several child actor BPs, triggered reset of templates on all of them.
I was running Unreal 4.18 until I encountered this bug on my personal project. I migrated all my assets to 4.23.1 In hopes that the newer version would be more stable but I still ran into the issue after a single day of dev. The bug manifested itself after relaunching the engine but has also been encountered previously mid session. All variables on child have been rolled back to 0.
Running into such a major issue makes me wonder how we actually deal with that in larger productions (I use unreal at work). I would guess a solution for that already exist in bigger studio. Have you ever reached out to devs to know if they encountered that? I don’t see how a major production could live with such a bug.
Hopefully this gets resolved at some point.
I also always get a specific Blueprint (and all its Children) reseted, every time i close the Engine. This is super frustrating, when you have to redo your Items over and over…
I’ve manage to get a repro rate of 100% with specific steps.
The bugs is due to the map and not the actual blueprint itself on my end.
Once the child is placed inside the problematic map saved and relaunched its variables get reseted to 0.
But as long as the child is not placed inside the corrupted map the issue doesn’t happend on save and reload.
Gladly the map that was corrupted was a simple showroom where I tested mechanics and the amount of work lost is manageable.
I hope this helps other who encounter the issue.
Repro steps:
Open project MR_Potato_423
Load map L00_ShowRoom_01
Create a Bp child from BP_Creature
Name it BP_Creature_Test
Inside BP_Creature_Test change the static skeletal mesh material to Crycrow_evo01
Save all
Close the engine
Open unreal
Reload the project
Place the BP Inside the world
All variables have been set back to 0
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.