After upgrading to Unreal Engine 5.5, I’ve noticed an issue with inherited Blueprint variables, but it only affects certain variables. Specifically, some variables created before the upgrade behave unexpectedly. When I change their values in a child Blueprint, the parent’s default value is retained instead of the child’s modified value. Additionally, these specific variables reset to their defaults whenever I restart the editor.
This issue doesn’t affect all variables. Variables created after the upgrade seem to work as expected, and some older variables still behave normally. However, for the affected variables, I’ve confirmed that they are marked as instance editable and not private.
I’d appreciate any insights into why this is happening or potential solutions. If this is a known bug, I hope it can be addressed in a future update.
After upgrading to 5.5, I made several edits to the project. When I attempted to downgrade back to 5.4, everything broke—including the default level. I couldn’t migrate my work on the actors from the 5.5 project to 5.4 because the actors themselves were incompatible (even the ones I didn’t edit). As a result, I had to spend an entire day manually copying and pasting all the changes I had made, which was both time-consuming and frustrating.
We just realized that we’ren having the exact same issue: certain variables do not seem to be inherited properly anymore. In the editor everything is working fine, it’s the shipping builds that have problems.
In our case we’re using blueprints for wall pieces in a dungeon, and sometimes they simply are not shown at all, it seems to be random.
So we have parent blueprints - some of them might have been created back in UE 4.27.
It’s basically an actor with 2 static mesh components. We use those to switch between fully and partially visible walls, to ensure the player can be seen at any time. The children are simply referncing different wall designs.
Initially we thought that the children are not loaded at all in shipping builds as nothing could be seen.
At some point I checked the parent blueprint and realized that while it held all the nodes to take care of blending between the two static meshes, the parent itself had no meshes assigned.
So I assigned a dummy sphere and a dummy box to those components and guess what: that’s what is shown instead of the meshes that the child actors have assigned.
I already deleted the static mesh components in the parents and recreated them, but that did not help unfortunately. My next test would now be to re-create the parents and children from scratch with new file names, to ensure there are no leftovers from the old stuff.
Did you find any solution? We realized that every blueprint that has static or skeletal mesh components seems to be affected (e.g. weapon pickup we placed in the levels), but the problem only occurs if the blueprint is supposed to be loaded when the level is first started. If we spawn something in the running game, the variables and their references seem to be fine.
EDIT: I recreated all parents and children, got to a point where I thought it was a problem with specific meshes or materials as sometimes it helped reimporting he FBX files and creating new material instances for them, but in the end it all collapsed and behaved completely random again.
Any help would be very much appreciated!
Also, I noticed that when I reverted the entire project, there was a float variable in the parent class called “Lifespan.” However, every time I restarted the editor, this variable reverted to its default value. After some trial and error, I realized that Unreal Engine was interpreting it as the built-in variable “Initial Lifespan” without any warnings. Therefore, I recommend checking your variable names and considering renaming them, as it may resolve the issue.
I have a similar problem with destructibles. They are placed as blueprints in level instances, and the issues occur only in packaged builds, either as clients or servers.
We confirmed the issue happening for static & skeletal mesh as well as geometry collection components.
For now we were able to circumway the issue by adding variables for these components on the parents and on the child blueprints, we assigned the same values(meshes) used for the components to those variables. On begin play of the childs, we load those meshes dynamically from that soft reference and that makes it working for now…
For some reason I can’t edit my last message anymore, but it migh be worth mentioning that this seems to only be happening with level instances being involved.
I’m also seeing this issue and its so significant it basically means that we can’t upgrade our project to 5.5.1 until we find a workaround for this.
So far its reproducible with a static mesh component that has the static mesh set on child blueprints, but it only occurs in WorldPartitioned levels in a packaged build.
Not really sure how to debug this either… I’ll probably start throwing some logging in the serialization during cooks, but given that it works in non-world partitioned levels makes it seem to me like its actually a world partition issue with loading an actor.
So apparently this happens with any variable on any child blueprint thats placed in any level, and this is 100% reproducible even in the 5.5 launcher version!
The following screenshots are from a blank project using the launcher 5.5 version of the engine (I have also confirmed this with our studios own 5.5.1 merge)
Here is the parent blueprint… it has a static mesh component with no static mesh set, and a text component with the text Base Class set.
I don’t like to use hyperbole often when dealing with this engine, but in the 10+ years I’ve been working in Unreal this is THE WORST bug I’ve ever seen shipped. This makes the engine completely unusable in all cases and should have been caught by QA easily. In fact I have no idea how this actually got out to the public. Fortnite does not use a custom engine version and generally the mainline p4 stream matches what they’re using (I believe it lags a bit as they merge back and forth between streams). Assuming their unreal mainline is mostly up to date with FN, this bug would be present in FN which I just cannot comprehend being possible.
I was looking through cls on relevant files but couldn’t find any that said they addressed this.
I think I found the cl that may have caused the issue but it was fairly large and related to a couple of other cls which makes trying to undo it locally very difficult.
I am wondering if this was actually reported properly so Epic is aware of it and its severity?
Couldn’t find it on https://issues.unrealengine.com/ - at least not with the aforementioned number:
Hey folks, just wanted to say here that we have seen this thread as well as @invulse your thread on Reddit here.
I’ve also looked up your report @PixelFireXY and it hasn’t been turned into a Public Issue.
To clear up some confusion, I do believe we are talking about two separate issues since @PixelFireXY 's bug happens inside the editor while @brainfart82 and @invulse your bugs happens only in packaged builds.
We’ll be investigating that latter bug since that’s indeed a big problem. I’ll come back here with a public issue tracker link once that’s created.
@PixelFireXY For values that already misbehave in-editor I’ve written a tutorial here that should help with finding out where things don’t work as expected: Investigating blueprint data loss issues. You mention: “When I change their values in a child Blueprint, the parent’s default value is retained instead of the child’s modified value.” Does that parent default value get retained when:
As soon as you modify the value on the child blueprint’s defaults?
When you press recompile?
Or only on editor restart?
That’ll be key info to investigating this. In Section 3 of the tutorial you can use that flow chart to go to the relevant section that describes what should happen. If you use that and find anything that’s off, that would be incredibly useful to us in investigating your editor-time issue.
As for this:
“When I attempted to downgrade back to 5.4, everything broke—including the default level. I couldn’t migrate my work on the actors from the 5.5 project to 5.4”
Reverting project files via source control will be more fruitful than trying to downgrade a project with assets that have already been resaved in 5.5.
Thanks for the repro project. We investigated the issue, and it should be addressed in 5.5.2. The root cause is that the new Zen loader was enabled as the default loader for 5.5. However, other issues were discovered, which led to it getting disabled for cooked, loose files in 5.5.2 (eg: Blueprints with cyclic dependencies could trigger a stack overflow).
Here are some workarounds for 5.5.1:
Loading is most broken when not using the IoStore. By default it uses IoStore whenever using pak files are used (like when packaging for a specific platform), but the Quick Launch option does not use pak files by default. To fix Quick Launch, go to the advanced settings next to quick launch and change “Pack Files for Launch” to “Use pak files without compression”. This should fix the issue for most people.
If you are seeing problems with loading in other situations, you can tell it to use the old loading code from 5.4 by adding -NoZenLoader to the command line.
If you can modify source, you can change the default value of GUseOldLoaderAsFallback to true in AsyncPackageLoader.cpp, this tells it to use the old loader when IoStore is not available and is the fix we are looking at for 5.5.2. Alternately, just cherry-pick the following change from GitHub: https://github.com/EpicGames/UnrealEngine/commit/dfa44397bdbbe6799fa5082674a9877ab57d9d7d.
Hey there, the link you provided leads to a 404 page.
Also, in our case where the problem occurs in shipping builds only, I did not understand how to follow your workarounds:
#1 quick launch refers to the epic games launcher or something? can’t find options like “use pak files without compression” #2 in the command line when starting the game executable or the editor before creating a shipping build? #3 i only work with blueprints, still i found asyncpackageloader.cpp and could make the change, but wasnt allowed to compile/override my unreal installation it seems.
Was the workaround solely for people having the issue in the editor and not for people having the issue in packaged builds?
In case that helps, this is my shipping build config:
I use that to create a shipping build and upload it to steam for example.
From when I first read your suggestions, I thought it would help to disable “save all content in a single file” and also deactivate “Enctypt ini files…”, but I can already confirm that this did not fix the issues with child blueprints and their components values as described above.
