UStateTreeComponent::SetStateTree crashes if called without having a state tree already set.

Development Programming & Scripting
, ,
1

In UStateTreeComponent::SetStateTree(UStateTree* InStateTree) it crashes from the FStateTreeReadOnlyExecutionContext getting passed a null state tree from StateTreeRef.GetStateTree(). Presumably this should be wrapped in an if and only check the running context if there is tree in the statetreref.

Just want to make sure I am not missing why StateTreeRef.GetStateTree() not being null is a requirement for SetStateTree.

2

Steps to Reproduce

  1. Add a state tree component.
  2. Call SetStateTree without setting a tree on the component.
3

So the error in the logs is from the call to UStateTreeComponent::InitializeComponent which attempts to validate the StateTree asset. Since you are setting the asset dynamically at runtime rather than having a default set, I would recommend creating your own custom component and overriding InitializeComponent but do not call the Super implementation. I believe the comment for the function (InitializeComponent) should say something along those lines, but I don’t remember if that comment is there in 5.6.

-James

4

Should have peeked at 5.7, you have the fix I was asking about where you check for an active tree and don’t just pass it in to FStateTreeReadOnlyExecutionContext.

	if (const UStateTree* ActiveStateTree = StateTreeRef.GetStateTree())
	{
		// Can't change the StateTreeRef on a running tree. It might change the instance data while running tasks.
		FStateTreeReadOnlyExecutionContext Context(GetOwner(), ActiveStateTree, InstanceData);
		if (Context.GetStateTreeRunStatus() == EStateTreeRunStatus::Running)
		{
			STATETREE_LOG(Warning, TEXT("%hs : Trying to change the state tree on a running instance."), __FUNCTION__);
			return;
		}
	}