I just noticed that sometimes when I set a property on one of the offending actors in a sublevel, source control doesn’t ask me to check the level out. I don’t know if that is related or not, but I thought I would mention it. I’m using 4.15.2 and P4.
OK so I’ve managed to reproduce this very easily in a new project 100% of the time:
- Create a First Person template project
- Create a new Blueprint Actor
- Connect a Get All Actors Of Class node to Begin Play, and set it to the FirstPersonCharacter class
- Create a public variable in the parent Blueprint (I used a boolean and left it false), compile/save
- Create a Child Blueprint from this parent and drag an instance of it in the map
- Change the boolean of the child instance in your map to true
- Compile the FirstPersonCharacter Blueprint
- Close the editor (it will ask you to save the map which you must do)
- Open the project again and notice the public variable you changed is now back at default value
- Hope that these steps reproduce the issue for and this long standing bug gets fixed
You should now also be able to change the variable in the child blueprint again, compile the FirstPersonCharacter blueprint (might work with any blueprint you’re getting all actors of class with), save and restart, and it will keep resetting back to default over and over, 100% of the time.
You’re genius! With your method I’m able to reproduce the bug 100% of the time! Hopefully Epic can confirm this and handle this issue finally. Thanks for your effort
Best regards,
EDIT:
**It seems to work even without the “GetAllActorsOfClass” node for me. **
Hi akka,
Thank you so much for posting this repro! I was able to finally reproduce the bug and I’ve been testing in different version.
I was able to reproduce this in 4.15.2 and 4.16 Preview 3. However; I wasn’t able to repro this in our internal version of 4.17.
In his Forum post, N explains the overhaul that was implemented that he believed should fix this issue. Thanks to your repro, we can confirm that it is indeed fixed for this use case. Hopefully will see similar results when this version is released.
I posted this on the AnswerHub thread as well.
Cheers,
TJ
Weird, I tested again and I definitely DO need to get all actors of class FirstPersonCharacter, although casting to the First Person Character blueprint reproduces the bug as well.
Good to hear! I had to come up with a workaround to the issue but it’s not ideal so I’ll wait and see if it’s resolved for me in 4.17.
Thanks for testing this on your end I’ve done some more experiments and came to the following conclusion:
You’re right: It does **NOT **happen without the “GetAllActorsOfClass” node. In my initial test I did the repro exactly like you recommended. After that I disconnected the node instead of deleting it and the bug still showed up altough the node was disconnected. Then I created the whole setup from scratch without the node and the bug did not occur.
So I think the blueprint gets corrupted as soon as the node is plugged in and stays corrupted even if you disconnect the execution pin. Pretty strange thing.
And yep, I also can confirm that the bug happens if you use a cast node (Get Player Pawn -> Cast to FirstPersonCharacter)
[MENTION=4891][/MENTION]:
I’m just curious about the reason for this bug. Can you share some information why this happens?
Best regards,
Hey polygon and ,
We created a JIRA internally to figure out exactly why this was happening and make sure the compilation manager truly fixes it. We hope to have more info to share soon.
Hey everybody,
It looks like 4.16.0 release version may fix some of these errors. It seems to have fixed the repro akka provided above. If anyone has time, please feel free to test it there and let me know what you get.
If it’s still happening, then we will likely have to see if the compilation manager in 4.17 fixes the issues.
I’m soooo glad I found this thread. Not because it’s helpful for me in the moment, but this BUG caused me days worth of grief and SOOO much wasted time when adding a game mode to a large project recently. Worked fine in the editor until reopening the level. All of the BP’s in the level were various children of a parent with a bunch of config vars that would change their behavior. Packaging the game and opening the level… all the bps would be reverted to parent’s default! I’d spend two hours customizing each one in the level to function how it should… and bam all undone. After two or three times I got wiser and just edited one or two for testing… never got a resolution (but i did make a workaround)
I reported the issue in answerhub and cited previous chains of people having the issue. But of course I ended up with the standard (maybe understandable but extremely frustrating) response of “if you can’t reproduce it in a fresh project we can’t help you”. Well my last comment on the thread was “well I can’t repro it in a fresh project… but its 100% a bug and its in the editor not in my code.” Then its just been lodged in my as one of those annoying things that eat at you.
So I’m glad something is getting done about it finally. The repro steps I’ve seen above don’t match my issue… I didn’t have a get all actors node and wasn’t using a template of any kind… but the issue is probably still the same. I’ve added ridiculous macros and pipe them into “begin play” that essentially just have every variable SET node i need to customize at runtime and then it sets them all on begin play.(setting in the editor panel doesnt resolve, i tried) Silly work around, and if you want to use const script to do this customization in the editor and see the updates real-time you’re SOL.
Reference to my thread from a couple months back just as an FYI:
We had a similar issue:
The skeletal mesh property of a Child BP would be reset to empty upon saving and closing the editor.
Reparenting to the c++ parent fixes the issue.
The weirdest part of the issue was that the uasset itself would not change.
Occured in 4.15.
This is happening to my project in 4.16.2.
If I take all references to the parent, out of the animation blueprint , the children get the reference to the animation blueprint back on restart.
Same blueprints in a new project work fine.
I got this bug after a crash, when I was setting the animation blueprint in the child.
Something similar happened to me with 4.16.1
Without changing anything related to the Blueprint in question, one of three pretty much equivalent child Blueprints lost its skeletal mesh reference every time I restarted the editor. The sibling Blueprints were fine.
The hierarchy was C++Class->BlueprintClass->BlueprintClass.
The reference viewer revealed that a Redirector had a reference to the Blueprint. Weirdly, even after deleting and recreating the Blueprint, the problem persisted until I deleted the Redirector.
After deleting the Redirector and the Blueprint and then recreating the Blueprint, the bug no longer occurred.
Maybe this is helpful.
I’ve found that references to the child character breaks the childs mesh or animation reference or changed default settings(even in a new blueprint with no circular dependency).
I can , however, reference the children in an array in the parents blueprint(the only blueprint that will allow a reference to them) without this happening.
So my workaround is to pick up this array from the parent in the gamemode at runtime, and use it as a reference to the children . Seems to work so far.
Yep, I think the bug is somehow related to the redirectors or at least can be caused by some redirector problems. Will the redirector system be improved in the upcoming releases? They seem to do some quite strange stuff from time to time (“Ghost” folders after deleting assets, empty and unused .uassets after deleting items from the content browser and so on)
Best regards,
@polygon, did you turn on ‘show redirectors’ and fix up the redirectors? Tiny ‘ghost’ .uasset files in a folder are redirectors that haven’t been fixed up yet.
Cheers,
The 4.17 preview 1 build is available in the launcher now: Unreal Engine 4.17 Preview - Announcements - Epic Developer Community Forums
It includes a significant number of bug fixes and improvements to Blueprints and has resolved several repros for data loss we’ve gotten. There’s no guarantee that your case will be fixed (many different issues have similar symptoms), but I’d recommend giving it a try on a copy of your project both to see if it works better for you and to catch any potential regressions before 4.17 final goes out (we did change a lot of things ^_^).
Note: You may see an increase in warnings or errors as part of 4.17; there will be more info in the upgrade section of the full release notes, but the summary is that we now catch and warn on various problems that either silently failed in previous releases or worked only intermittently (e.g., in uncooked but not in cooked builds). These warnings are much less likely to affect BP only projects or recent BP + C++ projects, but in long-running BP/C++ projects, there will almost certainly a be a few warnings about missing BlueprintType or BlueprintReadWrite, etc… Related to this, we also introduce the concept of orphaned pins which make refactoring issues easier to catch and recover from. As an example, if you rename a parameter on a function in BP 1 that was called by BP 2 and save 1 but don’t save BP 2, then close and reopen the editor, BP 2 will now report an error about a missing parameter with the connection to the old pin preserved, rather than silently dropping the connection on the ground.
Cheers,
Sweet jesus. Yay.
Finally, on 4.12 and 4.13 my Machine learning project will not upgrade to 4.14 or higher because of this exact problem. I hope 4.17 fixes this.
I fixed my issue by migrating everything to a new project on 4.12, updating it to 4.13, migrating it to a new 4.13 project, then i was able to migrate it to a new 4.14 project and onward. Without variables getting reset. Although it was seemingly random and i had to do it a few times, maybe it will work for someone else.
hmm still happening on 16.2 … 
is there any good fix pls