StateTree Category = Input validation doesn't validate child properties

Development Programming & Scripting
, ,
1

Normally if you have a property in your state tree instance data of the input property(Category = Input), when you compile the state tree, you will get errors if the property does not have a binding.

However, if you have a struct property, and within the struct is a Category = Input property, the compile process will not validate that bindings exist for these properties.

Expectation: All Category = Input, even nested ones, would be validated

For example:

// Property inside a task instance data
// Provides ability priority groups
UPROPERTY(EditAnywhere, meta=(TitleProperty=Ability))
TArray<FExecuteAbilityPriority> AbilityPriorities;

USTRUCT(BlueprintType)
struct FExecuteAbilityPriority
{
    GENERATED_USTRUCT_BODY()

    UPROPERTY(EditAnywhere, meta = (Categories = "Ability"))
    FGameplayTag Ability;

// is not validated for a binding
    UPROPERTY(VisibleAnywhere, Category = Input)
    TStateTreePropertyRef<FGameBehaviorDefinition> RuntimeAbility;
};
2

I do not think this has come up before in any of our use cases. This seems like an edge case of allowing binding for individual elements of a container. Have you noticed any other cases where this is happening?

-James

3

It is intentional to allow binding to elements in the array! It was not in the engine for a while, but we needed this for other projects so it was added. We find it very useful as well.

What is not intentional is that the properties marked as inputs should not be validated when compiling. Our intent is that it should behave the same as any other binding in StateTree. I tried a few things to attempt to force the bindings validation to work but was unsuccessful. I have logged a bug report for this which can be found here on our public issue tracker. Of note, it can take a couple days for the public tracker site to update as things need approved and mirrored. I do not have an ETA on a fix for this currently, but it is a bit lower in priority with other work being done around StateTree.

-James

4

Just in the nested binding situation.

Are you saying it’s unintentional to allow nested binding? It’s quite useful, and seeing as it is explicit, with the category tags, it seems like a nice feature.