Properties not serialized when moving actor/component depending on unrelated specifiers

When an actor is moved on the level editor viewport, it is reconstructed along with its components, which at first makes their properties reset to their default state. Thankfully, this does not happen because properties are saved before the movement and restored afterwards. The problem is that, depending on the property flags/specifiers (like VisibleAnywhere, BlueprintReadWrite, or InstanceEditable), in some cases its value is not restored properly, which in the user's point-of-view means an unexpected and undesired reset of the property value. This happens for:

• C++ actors: Properties marked with "BlueprintReadWrite" but not marked as "Visible" or "Editable" on Instances.
• C++ components: Properties not maked as "Visible" or "Editable" on Defaults and/or Instances.
• BP actors: Properties not marked as "InstanceEditable"
• BP components: None.

These unexpected property resets are perceived by engine users as a bug (especially since today so many things can be changed by in-editor-callable functions, including tick). They might be motivated by some concern about the interaction between these property restorations and the rerun of construction scripts (for example to recreate a MaterialInstanceDynamic or rebuild a SplineMeshComponent), but even if that is the case, it does not seem to be appropriate to tie the restoration to a visibility and/or editability flag. In the current state, not only the behavior is inconsistent between actors and components, but it is also forcing engine users to make properties visible/editable for the sole purpose of making them persist better, even when they would rather have the properties hidden. If a non-persisting property is really needed, maybe the reset should depend on another flag instead ("transient" or another one)?

I've got another JIRA report related to case https://udn.unrealengine.com/s/case/5004z00001sjBPIAA2/properties-without-any-specifiers-are-not-serialized-when-component-are-recreated-in-editor

Repro Project: [Link Removed]

On the repro project, there is a test actor instance which has properties from a variety of sources (C++/BP, Actor/Component) and with a variety of flags/specifiers. All these properties start as false on construction, which can be attested by a "print" button on the details panel. They can then be all set to true with another button. Finally, after moving the actor on the viewport and printing the property values again, we can see that some of them were unexpectedly reset. Using the "diag" button, we can see exactly which properties were affected.

Steps:

• Part 1 (Preparation):
• Download and open the repro project at link
• On the outliner, select actor "TestActor"
• Open the output log, clear it, and keep it open

• Part 2 (C++ Actor):
• On the details panel, click on button "Actor Print", then "Actor True"
• Move the actor on the viewport
• On the details panel, click on button "Actor Print", then "Actor Diag"
• Output:
• FFFFFFFFFFFFFFFFFFFFF (starting property values)
• TTTTTTTTTTTTTTTTTTTTT (after setting all to true)
• TTFTTFFTTTTTTTTTTTTTT (after moving, some are reset)
• MyActorProperty_ED_BPRW
• MyActorProperty_VD_BPRW
• MyActorProperty_BPRW

• Part 3 (C++ Component):
• On the details panel, click on button "Comp Print", then "Comp True"
• Move the actor on the viewport
• On the details panel, click on button "Comp Print", then "Comp Diag"
• Output:
• FFFFFFFFFFFFFFFFFFFFF (starting property values)
• TTTTTTTTTTTTTTTTTTTTT (after setting all to true)
• TTTTTTFTTTTTTFTTTTTTF (after moving, some are reset)
• MyCompProperty_BPRW
• MyCompProperty_BPRO
• MyCompProperty

• Part 4 (BP Actor and Component):
• On the details panel, click on button "BP Print", then "BP True"
• Move the actor on the viewport
• On the details panel, click on button "BP Print", then "BP Diag"
• Output:
• FFFF (starting property values)
• TTTT (after setting all to true)
• FTTT (after moving, some are reset)
• Actor Bool