Default widget values aren't spreaded properly when using TMap > USTRUCT

Development Programming & Scripting UI
, ,
1

To reproduce the issue, all you need is bulding this architecture :

  • World > UserWidget (HUD) > UserWidget (Widget) > TMap > USTRUCT

Struct values edited in the Widget won’t be applied to the HUD, no matter if it’s EditAnywhere or EditDefaultsOnly.

I tested the same behavior with Actor and ActorComponents but it seems fine with them, it happens only on UserWidgets.

[Attachment Removed]

2

Steps to Reproduce
[Repro steps - From TestNew template]

  • Open W_TestWidget from Editor
  • Edit TestFloat, TestMap1 and TestMap2 values from A to B -> Save & Compile
  • Open W_TestHUD from Editor and inspect values
    • TestFloat is updated -> expected behavior
    • TestMap1 isn’t updated -> unexpected behavior (showing A values)
  • Launch PIE and look at logs -> TestMap2 isn’t updated, showing A values instead of B
  • Restart Editor
  • Open W_TestHUD and inspect values -> TestMap1 values are now B values
  • Launch PIE -> Values are not updated (showing B values)

There’s an even worst case, if you changed TestMap2 keys, you may see that the instance in W_TestHUD has multiple values even after a restart and I found no other way to clear it except by removing the instance and adding it again.

[Attachment Removed]

3

I also tried building everything in Blueprint without C++ and the issue can be repro.

[Attachment Removed]

4

Hi,

We recently fixed the more general case of this issue (where it happened regardless of property type), but maps/sets aren’t fully implemented yet. IteratePropertyPathRecursive (in PropertyPathHelpers) has a note about this, so that’s likely why it’s falling over in your repro case. I’ll raise this with the team, but I fear it might be a pretty heavy lift to finish out that implementation for maps/sets.

It’s not a perfect workaround, but you can avoid this issue by changing defaults within the Class Defaults of the Graph tab (instead of within the Designer tab), as this uses the standard blueprint propagation path and should work properly.

Best,

Cody

[Attachment Removed]