Blueprint corruption through native code changes

I think this is a general issue with a fairly wide range of cases, which has always been around. I just wanted to highlight a particular case of blueprint corruption which has clearly affected a number of people, and make some suggestions.

First off, some links to more information on the problem:

Forum thread about trying to rectify a component that had become nulled in blueprint

Detailed discussion of repros relating to modifying a component’s type in c++

Another case, with note on how this relates to property name and corruption remaining in the BP

To sum up, there are various ways in which a blueprint can wind up having an inherited component set to null. There is an ugly way to rectify it by temporarily setting the component property to EditAnywhere and then clicking the ‘Reset to default’ arrow on the property (this workaround was actually made impossible in 4.7 but appears to be doable again in 4.8).

Suggestions:

  1. Allow components to be easily reset to their parent class default, for example via a context menu in the components tab of the blueprint editor. Ideally this should be possible without having to go into code and temporarily change the component property to be editable. (Having a ‘Reparent blueprint’ context menu accessible for a blueprint in the content browser would also be helpful for solving similar corruption issues).

  2. Perhaps there should be a prompt to confirm doing such a reset whenever a blueprint is loaded and a serialized property cannot be reconciled with the native base, rather than just setting the property to null as appears to happen currently.

  3. I’ve often had these issues as a result of refactoring code and moving classes into a new module. The active class redirects solution is awkward, and also if forgotten and an autosave kicks in, it seems data can be lost. Perhaps whenever a class cannot be found, a check could be made to see if there is a class available of the same name but different path, and if so a prompt given to confirm updating the serialized property to the matching class.

Bump due to posting in wrong section.
If anyone else has input on related problems please add info here, I know this is a problem encountered by quite a few people.

Hi ,

Due to the nature of this post, as it is highlighting bugs that have been reported instead of reporting new bugs, I’ll be moving this post to our Everything Else section. I assure you that we will look into these other issues and take your suggestions into consideration.

Have a nice day,

No problem , thanks for the response. I just wanted to bring attention to this issue since it had been brought up in places other than the bug reports section. If there is an existing bug report regarding this particular problem, I wasn’t aware of it. Cheers.