Some Inherited Blueprint Variables Breaks After Upgrade to UE 5.5

[brainfart82]

UPDATE

I start getting the feeling that this is a multi-layered issue or it’s really several very similar issues regarding parents/childs/inheriting…

This is a screenshot of our feature testmap playing as a host/server in a shipping build:

The red arrow points at lootable chests that have one(?) of the issues described above. These are child blueprints that inherit the logic and interaction abilities from the parent blueprint but have their own skeletal/static mesh assigned - yet they also show the parent’s dummy geometry.

Clients would also see these chests with the same issue.
However, the only reason why clients can see these chests at all is that we added this to their “begin play”:

So on those childs we created variables with the same meshes as used in the mesh components, and on “begin play” we basically set/assign them once again. Otherwise clients would not see them.

Now adding “-NoZenLoader” to project config → packaging settings had no effect.

However, adding “-NoZenLoader” to the packaged game’s executable (launch options in steam in my case), fixed the chests to not show the white unreal sphere anymore.

Unfortunately, from my understanding that means that the “-NoZenLoader” option fixes the parent blueprint meshes from being shown if the parent had something assigned… but it does not fix showing what the child blueprints have assigned. Let me explain:
In the feature testmap screenshot above, clients would not see any of those dropitems/pickups like trinkets, potions, weapons, armor… because none of them have the soft reference fix on begin play added to them, i only added that to the chests.
It seems to me that the -NoZenLoader option only fixes the parent blueprint stuff from being shown but it does not fix showing the assigned child blueprints stuff.
As mentioned above, we confirmed the issue happening for static & skeletal mesh as well as geometry collection components on child blueprints.

Now, I don’t want to make everyone nervous, but scrolling through various Discord servers that I’m on, I found myself complaining about similar issues being introduced with UE 5.4.4… not sure anymore if we found a workaround back then or if we simply ignored the issue until now that we want to release a demo and do more sophisticated testing, but in case you are investigating, the mentioning of this may having started with the 5.4.4 update might be helpful.

[wilberolive]

I think I might be running into a related issue. When I try to upgrade a project from 5.4 to 5.5 a number of the blueprints break and no longer compile. The issue is that any variables set to an actor base class type have been changed to some sort of PLACEHOLDER variable type.

For example, I have a class called BP_BaseUnit and then child classes of this. Some blueprints have variables set to BaseUnit as the type so it can work with any of the child classes. After upgrading to 5.5 I notice that the types of these variables has changed to:

PLACEHOLDER-CLASS BP Base Unit C 0

[Angius]

@brainfart82

Hey there, the link you provided leads to a 404 page.

https://www.unrealengine.com/en-US/ue-on-github

[Origins (Ganesh)]

Any solution found. My project too broken

[JanHxH_de]

This helped us with our issue with Fatal errors occuring at startup for a packaged shipping build.

Setting to use “IO Store” in the Package Settings/Packaging helped as well but we are going with patching our engine source. That worked as well.

[Major_A398]

I just created a parent weapon where it has a couple of variables, then created a child off of that and it is not showing the variables in the child in unreal engine 5.5.1:

[Major_A398]

Looks like they changed how child blueprints work found it, you have to click on the component then look at details at the top under default:

[m5m]

Hi! Are there any news about the bug that happens in packaged builds? Has it been fixed in 5.5.2, as @dave.jones_epic said (not sure if that was the editor bug only, tho)? If it’s not been fixed yet, do you have an issue tracker link that you can share?

Thank you!

[m5m]

Just in case anyone comes across these bugs and thread:

We encountered the bug that users @/brainfart82 and @/invulse reported in this thread that caused overriden skeletal meshes in child blueprints to be reset to the default value of the parent blueprint in packaged builds.

We waited for the 5.5.3 Hotfix to avoid the new bug related to skeletal meshes that was introduced in 5.5.2, as advised in this post, and after updating we have found that:

-The original bug seems fixed: child blueprints maintain their assigned skeletal meshes in packaged builds.

-However, for actors of the parent class that were placed on a level and whose default skeletal meshes had been replaced directly in the level, their skeletal meshes have been reverted to the default asset. This means that these actors of the parent class are all using the same default mesh instead of the particular mesh we had assigned to each of them in the level. They do keep their assigned materials and animation assets / blueprints.

So, I’m not entirely sure that the 5.5.3 hotifx has indeed fixed the 5.5.2 issue, but at least child blueprints do keep their overriden values…

[Carlos_ECarvalho]

I´m having a bug like this.
I´ve tried to upgrade from 5.4 to 5.5 a couple of times, but always have a new bug.
Now I have some child weapons that when I equip the values always comes from the parent BP. Every variable set in the childs BP are ignored.
Going back to 5.4 for now.

[Skowroshima]

It looks like @PixelFireXY 's issue still exists. It looks to be related to to multiple tiers of class inheritance and not just an issue related to upgrading (In testing, i was figured out how to reproduce the issue on new variables).

For explanation assume the following hierarchy: Base Class → Enhanced Class. Then blueprints that will be instanced can inherit from the Base Class or the Enhanced Class.

I did a fresh upgrade from 5.2 to 5.5.

Variables in the “Base Class” that are overwritten by child class of the “Enhanced Class” don’t have the overwritten value when being instantiated (Both in the editor and packaged builds). Classes that directly inherit from the “Base Class” correctly have their values when instantiated.

If I make a NEW variable (post upgrade) in the “Base Class”, and then override it in a child of the the “Enhanced Class” , the overwritten value now DOES correctly get set when being instantiated. That is until you restart the editor, then it no longer has the overwritten value when being instantiated.

Practically how this is used for our game: we have spells. There is a Base Spell class, enemy attacks inherit from this base spell class. Then we have a Player Spell Class that inherits from the Base Spell class. All the player spells inherit from this and are broken after upgrading to 5.5.

No amount of reentering correct values in the child class, recompiling the base, enhanced, or the child classes, and restarting the editor seems to resolve the issue. @ZhiKangShao, Was there ever any resolution to how to solve this issue? I can’t find the case created for @PixelFireXY 's issue.

[Skowroshima]

Bump

[PixelFireXY]

This is the confirmation email received on Wednesday, 20th, 2024.

I have no idea why the case is not available.

If you feel it, please fill out a new one.

Thanks.

[Skowroshima]

After more testing here is what changed in 5.5. If a variable is exposed on spawn and has a different default value from the base:

Before 5.5
If the Spawn Actor didn’t explicitly overwrite the spawn value, it would correctly pull the default value for the class being spawned.

After 5.5
Regardless of the value being set in the Spawn Actor, the default value of the base class type is used when spawning. To fix, you now have to get the class defaults yourself and plug them into the Spawn Actor.

Example of how to get the same results in 5.5:

@ZhiKangShao, As you made that whole guide on troubleshooting defaults, you should be interested in this result. Was this an intended change?