Struct has wrong default value in packaged game

I again have problems with default values of structs… I hoped all of them would have been fixed with the 4.7 hotfixes and the 4.8 update, but it seems it’s not the case.

I have a parent blueprint which has one struct variable, it has one child and in the construction script of the child I print out one bool of the struct. I have set it to true in the parent and to false in the child, placed the child in the level and in PIE and in standalone I get the correct output “false”, while in the packaged game I get “true”.

Now the strange thing is, I can’t reproduce it in a clean new 4.8 project. There I get the correct output in PIE, standalone and also packaged game. But why? I print the bool out as the first thing in the construction script, so before anything could change the bool, right? So it has to be the engine itself which makes the bool change from “false” to the parents default “true”. I have this struct in my project since 4.5 or 4.6 so it could be that this bug only occurs on projects which have been converted multiple times to the newest version, but would this make sense? I mean, a struct is a struct, no matter when it was created. I have already once changed the default value in the parent from true to false and back to true, so all childs got updated to true in the editor (by the way, is this intended that the childs change their value (which I changed to something custom) to the parents default value after I change the parent’s default value?) and then set all the child where it’s needed to false again, but this has not solved the issue.

Again, PIE and standalone works fine. I’m using 4.8.1. I have never checked whether this bug occurred in older versions of the engine because packaging never worked there, in 4.8.1 it works so I can finally check what parts of the game I created during the last 7 months are not working in a packaged game. I know ideally it should be checked a lot more often whether the game behaves the same way in packaged as in the editor or standalone.

can anyone look into this?

Hello ,

I was unable to reproduce this issue on our end. I have tried in a clean project as well as projects that were upgraded from 4.6.1 up to 4.8.1 and other variations in between. Every time I packaged out the game the child’s print string showed that the struct was the correct value (false in this case). Would it be possible for you to supply the project that you are working on so that I can take a closer look at how you have things set up?

Hi Rudy,

thanks for looking into this. Sending the project seems to be the only way to show you the bug… I have migrated the child blueprint to a new project but everything in my game references all the other stuff so I guess almost the whole project was migrated. Have placed only the child blueprint in the level so if you hit play you see an output that the variable is false, and if you package the game you see an output that the variable is true.

Will send you a link to the project in the forums.

Hello ,

I spent some time digging through your project and I found that when I set the variable within the blueprint it’s self that it would then update and print correctly in the packaged game. I have included the setup that I used below. The problem does not seem to be the struct itself but rather it could be some logic. I hope this information helps.

Make it a great day

Hi Rudy, thanks, but I don’t quite get what you mean?
If you set the variable on Event Begin Play it of course is set as you set it, the problem is not that the variable can’t be set in the game but that it does not use the correct default value which is specified in the child but instead the one from the parent. I know I could basically set the structs in the construction script to the correct value, but this is not the way it should work, right? Setting the value in the details panel should work too. And it does in PIE and standalone, just not in the packaged game.

are you still looking into this?

Hello ,

After digging through your project I was able to see the issue that you have reported. I tried to find a workaround for the issue that you are seeing but was unable to do so. However, I found that when I tried creating a new struct in your project that it worked as expected (event after parenting) in both PIE and the packaged game. There is no guarantee that this approach will fix the issue that you are seeing. I have also found that this issue is very similar to an issue that has already been reported (UE-17464). I will add any pertinent information from this thread to the existing issue. Thank you for your time and information.

What I have done in similar situations:

In general when I find that I have “strange” issues that cannot be reproduced in clean projects that have been through multiple older versions of the engine, I begin to systematically recreate any problematic blueprints. I have found that this helps to eliminate any stale code that may be left over from the transfer. This also has the side effect of giving me a chance to rework/replace old methods with new features that have been implemented.

Make it a great day

Thanks Rudy! Hope this will get fixed soon, these struct bugs seem to be in UE4 since 4.6.

Regarding your suggestion to “systematically recreate any problematic blueprints”, well, I’m now working on my game for 8 or 9 months and I’m not sure whether I really want to “systematically recreate any problematic blueprints” every time I find a problem, since it’s just way too much work. When a struct is used in 50 blueprints its really not nice to “systematically recreate” these “problematic blueprints” :slight_smile:

Hi Rudy, I just tested it in 4.9 and the bug is still not fixed, although UE-17464 was planned to be fixed in 4.9 :confused:

Hello ,

I went ahead and double checked on this issue for you. You are correct in that the solution has not be implemented into the preview build of 4.9. However, please keep in mind that this is not an official release but that it is a preview. I did some digging and compared the change lists, it turns out that the cut off point for the preview was before the integration of the fix for UE-17464.

Make it a great day