BroadcastFieldValueChanged doesn't broadcast for associated Field Notify Properties/Functions

When a property is marked as Field Notify, you can select additional properties/functions that will broadcast changes when the main property is updated. This is done by generating intermediate BP nodes via GenerateFieldNotificationSetNode and GenerateBroadcastFieldNotificationNode functions in FKismetCompilerUtilities, which generate function calls to UFieldNotificationLibrary::BroadcastFieldValueChanged/BroadcastFieldValueChanged.

Unfortunately, since the logic of broadcasting to additional properties/functions is done at the compilation level for specific BP nodes (ie. the field notify property setter w/ broadcast), trying to broadcast manually using the UFieldNotificationLibrary functions will only broadcast for the specific fields passed in. This is a little surprising, as the Field Notify metadata makes it seem like broadcasting a change to a property will always propagate the broadcast to the additional properties/functions, but more importantly it makes it quite cumbersome to do manually as you now need to manage a list of fields to update both in the metadata of a property, and in a variable/node that calls BroadcastFieldValuesChanged. This only applies to the case where you need to manually trigger broadcasts, mainly when working with arrays as adding/removing doesn’t use the setter node and thus doesn’t trigger change notifications.

Is there any possibility of exposing this functionality in a new BP node or function so that manual broadcasts work identically to setters on field notify properties? We’re looking into building a custom BP node implementation ourselves solve this, but would love to hear if this is something others have reported.

Thanks in advance!

Alex

We would love to unify and simplify the existing property notification behaviors:

* FieldNotifies

* Native Setters/Getters

* Custom systems

But we do not have any plans at the moment. It’s likely that a simple improvement to UFieldNotificationLibrary could be made and we’d love to review a PR, but with that in mind we also want to keep behavior forward/backward compatible to ease upgrades to future engine versions. Often users make a change that ‘works for them’ but would cause headaches for others, even though the change represents objectively better capabilities.