Happened to me on several occasions recently in 4.15, frustrating as it causes all child blueprints to lose the values that had to be manually set up and return to default.
So Iām also getting this problem and have done in multiple versions and multiple projects. It also happens around 80% of the time on load up of a project. This is really starting to ruin my experience of unreal since I am currently getting it in the latest version, on an item script Iāve written. Each item you pick up is a child of the MasterItem blueprint that contains all the variables to specify what that item is, buildable? Actor to spawn if buildable? Equipable? Etc
Iāve seen so many of these posts where theyāve been unable to replicate the problem, do you think it could be some kind of compatability issue? Hardware or softwareā¦ I know that sounds ridiculous but just seems odd that you canāt replicate it on a system that is not experiencing the issue.
Really hope you figure this out soon as for those experiencing this bug, it is so frustrating 
Try out to copy past all construction script code to all instances you made from the parent. But not sure this realy fix the problem 100%. Will see over time, if my instanced bps will reset to default. ATM it seems to work that way.
Iām agree, They realy should fix this! This is an issue, a AAA engine should not have for a such long time as it happen with this issue.
Letās try to show how this is: You painted your blue car yellow. Then at the next day your car is again blue. This is near the same, as this issue is for customers. You lose all the time your work. I love Unreal Engine, but this should be fixed, realy!
Can you guys share any info about how long the project was open on your computer? Was it a laptop or desktop? Using source control or no? Are the items that are resting placed in level or spawned dynamically?
Trying to get enough info to help figure this out. Itās really surprising epic doesnāt see this as more of a priority as itās clearly effecting lots of people. Basic nesting of subclasses should be rock solid on a engine of this caliber. Hopefully the importance of this issue is realized and they can elevate the time spent to find why itās happening.
Project open on average of 4 hours, Using desktop gaming pc. All children are present in level, not spawned dynamically. Source Control?
Project open on average of 4 hours, Using desktop gaming pc. All children are present in level, not spawned dynamically. Source Control?
Some times the project was long open, some times not, if it hapen. Desktop pc/ win 10/ Child was placed into map. Not dynamicaly spawned. No source controll.
When it happens to me, my project has usually been open for hours, my objects are not placed in the level (they spawn at runtime). I believe it has something to do with the auto-save.
It is odd that unreal donāt take this more seriously, since this is such a big issue and undermines the whole support structure of the engine. Been reading a lot of these posts for the last 6 months and always get the feeling of wellā¦ We canāt replicate the problem so it must not be there! Or we canāt do anything about it if we canāt replicate it!
I love unreal and have done since I first discovered it all that time ago but if their was another engine anywhere near as good as this, I would jump ship straight away due to this long outstanding bug. Luckily for Unreal, their are no such engines out there at the moment.
So what am I supposed to do Unreal? Not use child Blueprints? Is this still being looked into by Unreal?
As I said before, you donāt seem to be able to replicate this problem on a system not experiencing it so what are you doing instead?
It is odd that unreal donāt take this more seriously, since this is such a big issue and undermines the whole support structure of the engine. Been reading a lot of these posts for the last 6 months and always get the feeling of wellā¦ We canāt replicate the problem so it must not be there! Or we canāt do anything about it if we canāt replicate it!
I love unreal and have done since I first discovered it all that time ago but if their was another engine anywhere near as good as this, I would jump ship straight away due to this long outstanding bug. Luckily for Unreal, their are no such engines out there at the moment.
So what am I supposed to do Unreal? Not use child Blueprints? Is this still being looked into by Unreal?
As I said before, you donāt seem to be able to replicate this problem on a system not experiencing it so what are you doing instead?
I gotta agree with you. This is singularly the biggest issue with UE4 from our perspective. I there wasnāt 18 months invested in the game, we would jump ship simply because of the wasted time and rework this bug has caused. Unreal is a better engine than the others, but I would sacrifice those extra features for reliability and stability.
Epic - please - we canāt recreate the bug - we donāt know what to do!
It happens seemingly randomly. I have even put debug code in to watch for blueprint child attributes that change, and report it when it happens. Even then, and it happen frequently, I have not been able to recreate it, or understand why.
I have 400+ level actors that are not instantiated but exist in the level. Each is part of a multi-layer blueprint hierarchy, and each level adding itās own few variables. Every now and againā¦ bam! every door in my game resets to open, the mesh goes back to the default, etc. And itās not just doorsā¦ itās any one of about 40 different blueprint actor typesā¦
For example - just todayā¦ my debug code spotted dozens of actor resets and reported themā¦ when I run the gameā¦ Every item listed is a BP actor that has reset itself to defaults. Bah!
May switch off Autosave to test this ? But i donāt think autosave is the issue.
What is working at my projects, you need to copy past the construction script from parent to every child. Since i did this, i donāt got a reset. But not 100% sure this fix it over time. And it break the idea of inheritance.
Yeah, this just happened again to me. Doors for me too! UsableDoor is the base class, and even in-level instances of data-only child classes which change no default values got their vars all reset to default when I opened the map just now. So none of them are locked, because the default is unlocked. Ready to kill.
This bug is extremely serious and Iāve encountered it in ALL unreal projects that Iāve worked on within the last 1,5 years. My experience has brought me to the following theories:
-
Itās unlikely that itās hardware related. Iāve worked on different machines with different hardware and the issue happened on all of them.
-
The issue seems to need some time till it occurs. It almost never happens with a fresh project and it starts to happen when youāve invested some time in the project. WHEN it happens, you canāt get rid of it. Almost if something in the backend of the project breaks forever. From this point on you will have to deal with this bug every working session.
-
The chance for this bug to occur seems to be related to child blueprints or inheritance in Unreal in general. Chances to encounter the bug raise with complexity of inheritance. If you have a Parent actor, a child actor and a second generation child actor that inherits from the first child actor, chances rise that youāll be confronted with this issue sooner than later.
-
Inheritance in Unreal is NOT rock solid. It works, yes. But itās fragile. I donāt know if this also happens in C++ but in Blueprint the inheritance system CAN lead to unpredictable results that completely break blueprints and / or the project. As I said before: If the bug happens, you have actually no chance to solve it. Iāve worked on a project where I can cast a child actor to itās parent class via code and all the inheritance stuff works well in code but the output log tells me that this child does not inherit from itās parent class, even tough it actually does and all the blueprint stuff works. Inheritance in UE4 should be investigated by Epic with a priority of 10^36!
-
There are workarounds to avoid breaking your project but itās not really comfortable to do such workarounds. This should not be necessary in an engine like this. What you can do is to only use inheritance in a moderate amount and avoid it when itās possible. You should also initialize your child actors via a function in the construction script and not in the level editor. This is more work but it worked for me so far.
Iām really hoping that this issue will be investigated as itās ABSOLUTELY PROJECT BREAKING!
I heard, that it not hapen in C++.
can you show us a bit more details, about how you did this :
"You should also initialize your child actors via a function in the construction script and not in the level editor. This is more work but it worked for me so far. "
Thanks!
"You should also initialize your child actors via a function in the construction script and not in the level editor. "
This unfortunately doesnāt make too much sense. Every instance of an actor in the level has different a different starting state, and different variable settings. Initializing the actor in the construction function would only work if every instance of an actor in the level had the same initial values.
That would defeat the point of having the ability to have an actor in the level.
Yes, itās not a perfect way to work around the issue but I prefer it over being confronted with the bug and having to redo all my work.
All you need to do is to create a init-function in your parent class with inputs for all the variables that can be different on each child instance placed in your level. Letās say you have a parent class āMonsterā and a child class āWerewolfā. Then Iād simply setup a function called āinitā in the āMonsterā (or Werewolf) class with inputs for all variables that can vary. You end up with an init function with inputs like health, AttackDamage, etc.
Then I would call this init function from the level blueprint and set the values that need to be different for each child.
This method works for me so far but it can lead to problems when an actorās begin play function gets called before he got initialized by the level bp. This depends on your setup.
How fun? My parent have about 30 variables. Will try out my method a bit more.
Just copy past all code from parent construction script to the childs too. It seems to work that way, but not 100% sure it fixed it. At least, since then i donāt got a reset. I will see over time, if this fixed the problem.
Hi everyone,
Thank you for the feedback. Our developers are aware of this issue but without a reliable repro case its not possible for us to effectively investigate the bug. If anyone finds a way to reproduce this, please post it here.
As for the ongoing discussion, we ask that you create a forum post and reference this report. This will make it easier to find useful info in this thread in the future.
TJ
Unfortunately it seems this bug becomes evident after some time in the editor and if spending to much time on one problem (even one as critical as this) is not possible, then iām afraid we will never have a reliable repro.
I can only speak for myself but Iāve tried to take time and help with clues on the issue. It really does exist, itās not some phantom problem. The copy paste response is a bit off putting. Basically claiming if you cant tell us exactly why this is happening we wont fix it. I realize this is not your decision alone and donāt mean to pass blame.
Hereās to hoping someone more talented than myself chimes in. Dollars to donuts this is hidden in some method deep in the engineā¦ I canāt begin to try and solve it on my own.
**EDIT
Maybe itās possible to enable some advance logging? so when the issue happens I could submit the log??