FWorldConditionQueryDefinition Does not update in child actors

We are trying to use conditions (FWorldConditionQueryDefinition) in a BP because we want to add some inheritance when using smart objects with preconditions. This is because we don’t want to have to make a definition for every different use case needed for different preconditions. We have a solution where we add conditions to the blueprint and then add those to the EditableConditions in a duplicate of the Definition of the smart object. This works for blueprint instances in a level. However, it doesn’t work when we create a child blueprint because the child will not properly get data when the parent is updated. The issue seems to come from the condition field in FWorldConditionEditable.

WorldCOnditionQuery.h

FInstancedStruct Condition;

The condition will not be populated in the child blueprint. However the reset button does get set when you compile the parent blueprint. So the system does know that the data is different. If you press the reset button the child blueprint will get the data from the parent.

We are trying to figure out why the condition is not updated in the child blueprint, or if there is a different way to solve Smart object definitions having different preconditions without having to make a new definition for each one as that creates a scalability problem.

Steps to Reproduce

  • steps to reproduce
    • Create a default UE project
    • Add a new FWorldConditionBase
    • Add a UProperty of type FWorldConditionQueryDefinition to an Actor class
    • Create a blueprint and then a child blueprint
    • Add a new condition to the property
  • Bug
    • The child actor will not have the data from the parent blueprint
    • Specifically you will see that the property adds a new row but does not populate the condition
    • However the reset button will show up and you can reset the child actor to the data in the parent
  • engine version
    • Version: 5.6.0-43139311+++UE5+Release-5.6

I believe it does not update the child BP classes due to using FInstancedStructContainer to store conditions in FWorldConditionQueryDefinition. When adding the items to the InstancedStruct container, it is as instanced structs which do not automatically propagate down to child classes. I think there are ways to automate the fix-up of these members using Editor Utility Blueprints or python scripts, but it would still require manually running either option.

I know in some projects that multiple SODDs have been created to support different property values for the SODD, but I do not know that we have encountered the issue of the same SO needing different world conditions. I know we have some open JIRAs for investigating more modular SODDs, but I do not have an ETA for when that will be done.