Blueprints have got to a point where I simply recommend they are avoided whenever possible in professional projects. This issue and the issue where blueprints that use blueprint structs set all their references to placeholder classes have cost hundreds of man hours.
I hope this is being investigated, it has been a huge timesink and is a giant bummer when it happens – I end up having to spend the next few hours/days resetting variables depending. If UE4 is supposed to be elegant and intuitive, this bug completely undermines that effort.
Just wanted to pop in and let people know that we take data corruption issues very seriously and try to fix any that we can (both in Blueprints and across the rest of the engine and editor any issues that cause loss of data are a high priority).
We’re not seeing much in the way of Blueprint data corruption across several internal games that make heavy use of Blueprints. I am very emphatically not saying there are no problems with Blueprint cyclic dependencies causing data loss, just that they are by no means universal or easy to reproduce. There were some issues with Robo Recall but some fixes were made and additional logging was added to try to track down any additional issues, but the issues didn’t reoccur. However, we’re working on a overhaul of how compilation of Blueprint dependencies happens (both at compile-on-load and interactive compiles where you press the Compile button), which results both in faster load times and a more robust, predictable compilation order. This work wasn’t ready in time for 4.16 but should be a part of 4.17 (it’s been on by default in the Dev-Framework branch for a few weeks now).
We think that the Blueprint Compilation Manager will help significantly with some of these hard-to-repro issues, but we can’t be certain without repro cases to verify against. At the very least it should make the testing environment more consistent.
@JoeW: I’m kind of grasping at straws, but you mentioned above that blowing away Saved and Intermediates made the problem temporarily go away, which should normally have no impact on anything that happens when loading the editor RE: content and BP compilation. Could you add ‘uses hot reload’ as an entry on the survey (something like never, rarely, sometimes, frequently, all the time)? That’s one variable that we don’t tend to use at all on our large internal projects.
Cheers,
Not to beat a dead horse or anything, but Child Actor Components are probably one of the most critical things in my workflow to keep things consolidated and cohesive, but they also have led to a whole lot of lost work. I still think there’s an outstanding issue in 4.15 where if you have a child actor component that is in any way based on a C++ class, if the class ends up changing too much, any blueprint that derived from it, other than the top-most one maybe, would just crash the editor. Which made setting up an inheritance structure… Not great.
At this point, I’ve just started doing everything in C++ right from the get-go because, otherwise, it’s just too difficult to know when and where a blueprint will get irrecoverably broken. I still use Child Actor Components in my C++ code, but they’re almost always transient, as that’s the safest way I’ve figured out how to keep their use reliable and stable.
Granted, based on some conversations I’ve had and there, I don’t think there were ever intended for quite how I ended up using them. But, hey, REASONS.
I haven’t used child actor components in so long. They are formally banned at a couple of places I work at for these reasons and I learned not to rely on them in my own projects fairly soon after UE4 was released.
They’ve gotten a lot better the last couple of releases, but yeah, still not production ready.
If I’m ever doing something complex enough in BP where it would be vulnerable (IMO) to one of these bugs, I normally have nothing to hot reload either because the game is made through BP only or because the C++ has been laid down completely and is not changing (But when I do compile, I almost never hot reload- not that its a factor with these BP bugs). I don’t have a record or copy of most of my older projects that would have been effected by this bug though, so I can’t provide a test case. Maybe I’ll try something with decent complexity in BP again once the compilation manager is out.
I would, but that site wants to charge me for adding more questions than 10. Will check out the actual pricing in a bit and see if I’m willing to make the sacrifice 
For whatevs it’s worth, I do no C++ stuff (just using a few code plugins) so I never hot reload.
Don’t worry about it then, still mystified that deleting intermediates and saved had any impact though. The next time you see issues do you mind cloning off the entire project dir (intermediates and all)?
Cheers,
I could do that right now, but I’m on Australian internet so it’d take…a million years? to upload it anywhere you could get it.
I could just get you some svn deets and you’d probably repro, then if not I could try packaging up saved/intermediate? The answerhub folks haven’t wanted to do that in the past, maybe because of legal issues? But I’ll sign whatever if it helps
Its formal policy at one company I work for to delete saved and intermediate before every time you open a project. Those folders have a reputation for affecting basically everything, so if they aren’t supposed to affect anything, something has been badly wrong with the engine for quite some time.
I wanted to chime in and say I also have resets saved in perforce I could upload if you think it will help.
From what I gather there is something wrong with the compile order of the very first compile Unreal does as it opens up.
I always get a warning that “Projectile Core System is not a child of Mother System, cast would always fail.” error that only occurs whenever I open the editor.
Since Projectile Core is a child actor of Mother, I do not get the error in my other compiles.
I tried literally everything but, creating the blueprint even from scratch does not help. Copying does not either. So the only option I have to create everything from scratch, which is also not something I cant do anymore.
Just my 2 cents.
Thanks for posting this over . Repros help a ton 
, if I’m understanding what you’re saying, this is a different issue and it’s a bug that that even seems like it should work. An asset class ID cannot store a pointer to an actor in a world.
To make sure we’re talking about the same thing, is the BP mentioned in step 2 the level script for the level that contains the Note actor from step 1, or an asset blueprint created in the content browser?
Cheers,
Is that a no on just downloading my project from SVN and reproing in that then?
I came up with a work around that works for my situation. I’m using a save game object to store configurations for each relevant BP. I’m using a bluetility to iterate through all of the objects that I care about and save/load the variable values from the editor. After I configure the actors, I run the SaveConfig function; If I open the project and configuration is borked, I can run the LoadConfig function to restore the data. It’s not ideal, but it’ll save tons of man hours until the bug is fixed.
@Freestyledork & @JoeWintergreen I’m going to send you PMs directly to coordinate the repro projects you mentioned.
I’d already asked to coordinate that.
Cheers,
I’ve run into this a few times myself, but sadly I do not have a repro on it. To avoid it I’ve adjusted my workflow to have all data stored in tables, with the sole exception of an ID for each item. When the issue occurs I just fix the IDs on each and every item (it’s a pain, but it could be worse) based on a tracker I keep outside the engine.