TStateTreePropertyRef<FText> causes crashes in GetPropertyRefInternalTypesAsPins

Development Programming & Scripting
, ,
1

TargetRefField = {UField *} NULL

TargetTypeName = {FName} “FText”

Exception = Exception 0x80000003 encountered at address 0x226d0df40df

RefProperty = Variable is not available

ContainerType = {EPinContainerType} None

TargetTypesString = {FString} L"FText"

TargetTypes = {TArray<FString, TSizedDefaultAllocator<32>>} Num=1, Max=4

[Attachment Removed]

2

Steps to Reproduce

Create a new State Tree Task with the following structure:

USTRUCT()
struct FSetTextParamTaskInstanceData
{
	GENERATED_BODY()
 
	UPROPERTY(EditAnywhere, Category = "Input")
	TStateTreePropertyRef<FText> Property;
	
	UPROPERTY(EditAnywhere, Category = "Parameter")
	FText NewValue;
};
 
USTRUCT(DisplayName = "Set Text Parameter", Category = "StateTreeData")
struct FSetTextParamTask : public FStateTreeTaskBase
{
	GENERATED_BODY()
	
	using FInstanceDataType = FSetTextParamTaskInstanceData;
 
protected:
	virtual const UStruct* GetInstanceDataType() const override { return FInstanceDataType::StaticStruct(); }
	virtual EStateTreeRunStatus EnterState(FStateTreeExecutionContext& Context, const FStateTreeTransitionResult& Transition) const override;
};

Then select the task from any state tree. This will cause a check in GetPropertyRefInternalTypesAsPins as it cannot identify the type “FText” as it expects the typename to be “Text”.

The issue appears to be that the auto-population of the RefType metadata property by TStateTreePropertyRef uses the C++ typename provided, but the BP friendly name is expected by the property ref helper code. I would expect this issue also occurs for any other basic type where the C++ typename and exposed BP typename are different. This problem does *not* occur when using FStateTreePropertyRef directly, e.g.

UPROPERTY(EditAnywhere, Category = "Input", meta = (RefType = "Text"))
FStateTreePropertyRef Property;

[Attachment Removed]

3

Good catch! I saw in my testing that the same issue occurs if using FName or FString with TStateTreePropertyRef. We are looking into a fix for this currently to address the incorrect type names but want to ensure the BP versions and existing property refs in projects will continue to work once the names are changed.

-James

[Attachment Removed]