I am using the 4.7 branch from yesterday, so I don’t have to latest 15 commits inside of my build.
If I create a variable which is of type struct in a blueprint and set default values for it, close the project, open the project again, the default values are reset to 0.
The default values of the struct itself (the values I can type after double clicking the struct in the content browser) are saved properly. After reopening, the values of the variable of the struct are 0, not the default values of the struct itself. It’s strange.
But I only have issues with structs, not with anything else. And the “fix” Ben mentioned in the answer there is already inside my version of the engine, so it has to be a different issue.
Thank you for the report. I believe you are correct, this seems to be a different issue altogether. It has been entered as JIRA UE-7817 in our tracking software. Our developers will be investigating it further and we will update here as soon as we can.
Thanks! This bug is extremely annoying since I can’t set any values in structs because they are always reset back to default. This is causing a lot of problems in my game since I have a lot of stuff “struct config driven”. So hopefully you will be able to get a fix for this in 4.7.3
I noticed that actually not only my structs but also normal variables like booleans and object variables which are not inside a struct get reset. So maybe my issue is not a different issue than the other issue mentioned in the post. The normal variables actually stay set after compiling and only get reset after a project restart.
My game is absolutely unplayable since without correct variables all is very weird, and I can’t set 200 variables every time I have to restart the project (which is quiet often due to crashes).
Since you did not ask about further details this means you are able to reproduce this?
Thanks for the additional information! I tested this in our latest internal build that is ahead of 4.7.3 and it is fixed now. You should see that hit in either the 4.7.3 Preview or the official release.
Ok, unfortunately it is not fixed. I don’t know why it worked when I tried it 4 hours ago, but now after a restart of the project I get the same problems as always again. So it’s still happening what you see in the gif above
And yes, I double checked that I launched the new version of the Engine which I compiled today.
Just to clarify, because you mentioned 2 issues. Are you seeing the original issue where the variables inside of a struct keep resetting or the standard variables?
I am getting the original issue where variables inside of a struct keep resetting, but since I have most important variables in structs there may be also standard variables which get reset without me noticing it.
It’s also a bit random. Sometimes the variables get reset as I showed you on the gif above, directly after hitting compile. But some other times the same variable in the same struct is actually staying the same after compile and is only reset after a restart of the project. Whether it’s resetting on compile or not does not change while the project is opened, it only changes after a restart of the project, as far as I have noticed.
Okay, in that case the original issue was submitted in the JIRA I mentioned above (UE-7817). It’s still be investigated by the developers. I’ll post back here with updates as they come.
In the meantime, feel free to post a small test project and I will attach that to the JIRA as well.
Since it’s extremely easy to setup, here is a small test project. One struct, one actor with one variable. Just try to change the default value of the struct of the actor. Not the default value of the struct itself but the default value of the variable of the actor. It changes back to the structs own default’s after hitting compile.
Thanks for the project! After looking into this further I believe the root cause of this issue is different than the JIRA I mentioned above. So I’ve entered it as a new JIRA, UE-12128.
If 4.7.4 is released it ‘may be’ included because of the commit Slonopatamus just made. Please keep in mind that 4.7.4 hasn’t been confirmed (even internally) so it could very well be 4.8.
Well, since your 4.7 branch on github is already updated with new commits and changed to version number 4.7.4 I think there will be a 4.7.4 And since I don’t want to wait until 4.7.4 is released I will just wait until you have merged Slonopatamus commit into 4.7 and compile it myself.
