Potential bug when Linked State Tree Overrides are checking for ContextData compatibility with the RootStateTree

Development Pipeline & Plugins
, ,
1

My company is using 5.6.1, but I am also seeing this in the 5.7.3 and Main branches as well.

In FStateTreeExecutionContext::SetLinkedStateTreeOverrides, there’s the following code block:

if (!RootStateTree.HasCompatibleContextData(*ItemStateTree))
{
	STATETREE_LOG(Error, TEXT("%hs: '%s' using StateTree '%s' trying to set override '%s' but the tree context data is not compatible."),
		__FUNCTION__, *GetNameSafe(&Owner), *GetFullNameSafe(GetStateTree()), *GetFullNameSafe(ItemStateTree));
	bValid = false;
	break;
}

Because of the way “HasCompatibleContextData” is set up, this will check if ItemState’s context actor/AI controller (if an AI Component Schema) is a child class of RootStateTree’s context actor/AI Controller.

I believe the intended behavior here is backwards; for any given state tree setup, we can assume that the RootStateTree should be a child class of ItemStateTree (i.e. RootStateTree’s context actor “ACharacter” vs ItemStateTree’s “APawn”), but it’s not safe to assume that ItemStateTree is a child class of RootStateTree (i.e. RootStateTree’s context actor “APawn” vs ItemStateTree’s “ACharacter”).

Looking at the other usage of HasCompatibleContextData in FStateTreeExecutionContext::SelectStateInternal also supports this theory, where it has the following code block:

if (!NextLinkedStateAsset->HasCompatibleContextData(RootStateTree)
    || NextLinkedStateAsset->GetSchema()->GetClass() != RootStateTree.GetSchema()->GetClass())
{
	STATETREE_LOG(Error, TEXT("%hs: The linked State Tree '%s' does not have compatible schema, trying to select state %s from '%s'.  '%s' using StateTree '%s'."),
		__FUNCTION__, *GetFullNameSafe(NextLinkedStateAsset), *GetSafeStateName(CurrentFrame, NextStateHandle), *GetStateStatusString(Exec), *GetNameSafe(&Owner), *GetFullNameSafe(CurrentFrame.StateTree));
	break;
}
2

Hi there,

I apologize for the delay in the bug report. I’m actually going to instead escalate this case for the epic team as I think this will require a subject matter expert to speak on the implementation.

Cheers,

Louis

3

Hi Hunter,

I believe we spoke about this particular issue in another thread. The check is backwards as in you can set an linked asset override that uses a Character when the base tree is only using Actor/Pawn. This leads to a failure in SelectStateInternal so still bad. We currently only support exact matches of context data, and we also realize this is not ideal and sucks for users. We are talking over ways to make some of this possible, but I do not have a full picture of how we want to enable this or when the work will be done.

-James

4

Hi Hunter,

I spoke with one of the devs on StateTree as I thought this should be a supported case. We are going to look into it as the condition is backwards regardless in SetLinkedStateTreeOverrides. I believe this will be fully supported with changing the order to be ItemStateTree->HasCompatibleContextData(RootStateTree). I have not had time to get that reviewed, but I created a bug report in our JIRA about it. There was so confusion on our side when we were discussing it originally. Good find and thank you for letting us know.

-James

5

Hey James,

While related to the topic of that other thread (which was a feature request), this specific thread is a bit different because I thought it might be a bug. After all, it’s generally safe to assume that a Pawn is an Actor, but not safe to assume an Actor is a Pawn. Wanting to support both directions does make sense, and is something I addressed in my suggestion for the feature request thread. However, since the system doesn’t support non-exact matches of context data in general, this particular issue by itself is kind of at moot point anyway.

Thank you for the clarification!

6

Thanks for the update, James!