My project has upgraded to 5.7.4 this week from our 5.6 version, and we discovered immediately that our property function workflows have been severely impacted by an inability to supply data to any property function that outputs an Array. We use Actor array manipulation decently often in our StateTrees and this is quite a problem for us.
The observed behavior is quite strange - when you select the property function as a binding source, the expansion arrow on the parameter does appear but almost immediately vanishes and becomes unuseable, in the next frame or so of the editor. I am able to easily reproduce this behavior in Lyra sample of 5.7 with the attached code files and state tree asset as an example.
As a note - this will occur when attempting to bind to task data as well as parameters.
I did notice that StateTreeEditorNodeDetails got some heavy work this release to support copy paste but haven’t managed to isolate what has caused the regression myself yet - this is impacting us enough that I felt escalating it immediately was more important. 
Please let me know if I can supply any more information, but the repro is so easy I would expect you can hit this internally pretty quickly.
Sample code:
USTRUCT()
struct FStateTreeConvertActorToArrayPropertyFunctionInstanceData
{
GENERATED_BODY()
UPROPERTY(EditAnywhere, Category = Parameter)
TObjectPtr<AActor> Input = nullptr;
UPROPERTY(EditAnywhere, Category = Output)
TArray<TObjectPtr<AActor>> OutActors;
};
USTRUCT(DisplayName = "Get Actor As Array")
struct FStateTreeActorAsArrayPropertyFunction : public FStateTreePropertyFunctionCommonBase
{
GENERATED_BODY()
using FInstanceDataType = FStateTreeConvertActorToArrayPropertyFunctionInstanceData;
virtual const UStruct* GetInstanceDataType() const override { return FInstanceDataType::StaticStruct(); }
virtual void Execute(FStateTreeExecutionContext& Context) const override;
};
void FStateTreeActorAsArrayPropertyFunction::Execute(FStateTreeExecutionContext& Context) const
{
FInstanceDataType& InstanceData = Context.GetInstanceData(*this);
InstanceData.OutActors = {InstanceData.Input};
FStateTreePropertyFunctionCommonBase::Execute(Context);
}
StateTreeBugTest.zip(6.51 KB)
Steps to Reproduce
Create a StateTreePropertyFunction with any inputs an an Output parameter of any Array type
Attempt to bind an appropriate state tree parameter or input value to the property function
Observe the property function cannot be opened to supply data
Hi Kyle,
Thank you for reaching out and reporting this issue with minimal repro steps. I have been able to confirm that this worked in UE 5.6 (with quirks - the output variable incorrectly showed up in the details panel, even allowing the user to try to change it, causing a crash in that case) and stopped working in UE 5.7.
The good news is that I have also tested it in the latest source version of the engine, and it seems to be completely fixed there. Its hard to pinpoint the specific CL that addressed this problem, though, because there has been continued heavy work on on the whole StateTree system to this day (lots of CLs each week), with sequential changes that depend on each other.
If you are building the engine from source, you can try to integrate the sequence of CLs that affect only the StateTree plugin to the latest version (or incrementally until it fixes the issue). If this is not possible or unfeasible, I can try to reach out to the devs that own this system and see if they can help find the most appropriate CLs.
Alternatively, I also found a workaround that might be useful for you in your current engine version. You can wrap your array properties in one or more UStructs and pass those around instead of the arrays directly. This approach seems to work correctly in my tests.
I hope this is helpful. Let me know if you need deeper guidance on choosing CLs to integrate, or if you need any other further assistance.
Best regards,
Vitor
Update: I was able to track this down to CL 47885758 in ue5-main branch (github commit 34a4826). It is possible that the changes made to file [Engine/Source/Editor/PropertyEditor/Private/PropertyNode.cpp] by this CL can be integrated directly into your engine, if you want to try it.
Thank you so much for the fast turnaround over the weekend! I have cherry picked 34a4826 and it does seem to resolve this issue specifically and a number of other sporadic auto expand failures. I will let you know if anything else comes up but I think this will do it for us. I appreciate all the hard work that goes into this.
