IntancedStruct can't be serialized properly into/from configuration file

Development Platform & Builds
, ,
1

`UCLASS(config = SomeSettings, defaultconfig)
class USomeSettings : public UDeveloperSettings
{
GENERATED_BODY()

public:
UPROPERTY(Config, EditAnywhere, Category = “Data”)
FInstancedStruct Struct;

UPROPERTY(Config, EditAnywhere, Category = "Data")
TInstancedStruct<FSomeStruct> Struct1;

};`

2

Hello there,

I’d just like to confirm that loading from a configuration file is working as expected if the config ini is edited offline.

I have replicated the issue with serialisation, so I’ll a bug report when I hear back.

Best regards,

Chris

3

We’ve also been running into this issue. Our usage has FInstancedStructs in TArray and TMap. What we’ve found is that, if you trigger a mutation at the map or array level after changing an instanced struct (e.g., change whatever values you want on the instanced struct, then add a new element to the array/map and immediately remove it), the struct changes will be persisted as part of updating the array/map.

I built a reproduction project for this, which I’ve attached to this comment. If you open Project Settings > Editor > Instanced Structs, change any values and restart the editor, the values will not persist. But if you make a change to one of the structs, then add/remove an element on the array/map, when you restart the editor the struct changes will persist.

I spent some time debugging this and here a few notes I took from that:

  • SSettingsEditor::NotifyPostChange uses the first object being edited (PropertyChangedEvent.GetObjectBeingEdited(0)) on non-interactive changes to try and find the section. If there is no object, or no section can be found, then settings are not saved
  • FPropertyValueImpl::ImportText uses GetObjectsToModify, which calls into EnumerateObjectsToModify to find objects. Enumerating looks for the first complex property to find the object. When editing an FInstancedStruct the first complex property is for that struct, rather than for the config object that contains the struct, and the enumeration process doesn’t look for any other complex properties in the chain (though, in the case of an instanced struct being edited, there is one)
  • The combination of these two things means there are no objects on the property change event that SSettingsEditor receives, and so it doesn’t save the configuration.

In our case, for the moment, we’ve worked around the issue by adding our own PostEditChangeChainProperty override on our Config type which detects when an FInstancedStruct is being edited on the CDO and explicitly calls SaveConfig for GetDefaultConfigFilename().

4

Yes, editing it offline was working on my side. But I don’t know how that it happening.​

Good, looking forward to the report then.

5

Good to know. I’ve reported the issue and will reply with a tracking link when one becomes available.

Best regards,

Chris

6

Please find the report live at Unreal Engine Issues and Bug Tracker (UE\-277466\).

Best regards,

Chris

7

I appreciate the breakdown on what’s happening and the workaround. The status of an engine fix for this issue is reflected at the tracking link in the selected answer, and further developments on the issue will be reported there.

Best regards,

Chris

8

If you have any further questions on this topic, please don’t hesitate to ask. Otherwise, would you mind if I close this case for now?

Best regards,

Chris