StateTree ensure triggering when opening State Tree asset

Whenever I opened up my State Tree Asset it would trigger this ensure in SStateTreeViewRow::GetOperandText

ensureMsgf(false, TEXT("Unhandled operand %s"), *UEnum::GetValueAsString(Operand));

Issue:

GetOperandText only handled And and Or operands, firing ensureMsgf(false) on any condition at index > 0 with the Copy operand (the hidden default meaning “pass result through”). This triggered on every open of our State Tree Asset.

Fix:

Added a Copy case returning FText::GetEmpty()

else if (Operand == EStateTreeExpressionOperand::Or)
{
   return LOCTEXT("OrOperand", "OR");
}
// Fork Begin: Copy is the hidden default operand meaning "pass result through" with no AND/OR label.
else if (Operand == EStateTreeExpressionOperand::Copy)
{
	return FText::GetEmpty();
}
// Fork End
else
{
	ensureMsgf(false, TEXT("Unhandled operand %s"), *UEnum::GetValueAsString(Operand));
}

[Attachment Removed]

Steps to Reproduce
Issue repro’d whenever I opened the state tree asset up in the editor

[Attachment Removed]

This code should only be triggered by conditions, and I do not believe we allow the Copy operand on them. I believe it is by design that it is not allowed as I don’t know how copy operand would work in the conditions that are expecting boolean operands. For example, we do not support multiply operand in StateTree conditions either.

Can you elaborate more on how you are using the copy operand in conditions? Perhaps there is a case we have not considered, but currently, I don’t foresee us changing this.

-James

[Attachment Removed]

This code should only be triggered by conditions, and I do not believe we allow the Copy operand on them. I believe it is by design that it is not allowed as I don’t know how copy operand would work in the conditions that are expecting boolean operands. For example, we do not support multiply operand in StateTree conditions either.

Can you elaborate more on how you are using the copy operand in conditions? Perhaps there is a case we have not considered, but currently, I don’t foresee us changing this.

-James

[Attachment Removed]