Get Property Reference node failing in StateTree condition blueprint

Development Programming & Scripting
, ,
1

I believe I have found a bug in FStateTreeExecutionContext, when evaluating StateTree conditions.

I have a state tree running in state tree component on some Pawn. The state tree has a parameter (e.g. bool for simplicity).

I have a state as a child node right under the root of the state tree. This child state has a condition blueprint, extended from StateTreeModule.StateTreeConditionBlueprintBase. This condition has a variable of type “State Tree Property Ref”, referencing bool, marked as visible. This condition variable is referencing the bool parameter of the state tree. Inside the condition blueprint, there is “Get Property Reference” node, trying to read the bool reference variable (and through it, the parameter).

This property node always fails on 5.6, while it was working properly on 5.5.

Running “Get Property Reference” node referencing the bool parameter in global task blueprint works on both version.

Note: I would attempt to provide a template project, but the guide link [Content removed] on the instructions doesn’t work. Thus I have to check “No” to “Are you able to provide a repro of this issue?” to be able to send the question.

I have at least attached screenshots of the StateTree and the condition blueprint, the setup is very simple.

I was debugging in in code, and I found out that the reason is in TStateTreeStrongExecutionContext::GetActivePathInfo(), where the required StateID is not found among the ActiveStates, causing “Trying to GetMutablePtrToProperty while node is not active.” error.

Callstack of this fail is attached as GetMutablePtrToProperty.txt.

I have found that this StateID is set during construction of FStateTreeWeakExecutionContext, right before the condition is tested. However, at this point, Frame->ActiveStates.StateIDs (from which the StateID is taken) and Storage.ExecutionState.ActiveFrames)[0].ActiveStates (in which it is later searched for) are already mismatching. I’m not sure whether these values can mismatch at this point or the context is currently in some inconsistent state, as it is faik currently transitioning states (inside SelectStateInternal()). But I don’t see a reason to get this error for this setup.

Callstack of this constructor is attached as FStateTreeWeakExecutionContext.txt and it is the same callstack as the one inGetMutablePtrToProperty.txt up to UStateTreeConditionBlueprintBase::TestCondition (the constructor is called in SetCachedInstanceDataFromContext(), next line is already ReceiveTestCondition() that is on the other callstack).

When calling “Get Property Reference” node from global task, in GetMutablePtrToProperty the StateID is set to 0, thus skipping the search in the inconsistent ActiveStates, preventing the fail.

2

Hello Petr,

Thanks for reaching out. We made this change in the 5.6 release to support asynchronous access to InstanceStorage for Blueprint Tasks. Previously, the actions wouldn’t have been successfully performed in an async callback in a State Tree Blueprint Task. However, as you said, the Node instance data from temporarily selected states are not available from the AsyncContext. We plan to fix it in 5.7.

Since Conditions and Considerations are instant and are accessed one-off. One workaround is in UStateTreeConditionBlueprintBase::TestCondition, you cache CurrentlyProcessedFrame and CurrentlyProcessedParentFrame from the Context, and override GetMutablePtrToProperty using the cached Frame and ParentFrame to pass to PropertyRefHelpers::GetMutablePtrToProperty.

Note that in 5.5 it is not always working. If you start a new temporary frame from a Linked Asset state, it would fail as well.

3

Hello Jacob,

thank you for the answer. I currently don’t need the workaround, I was just curious (and a bit afraid) why this doesn’t work and whether I have incorrect assumptions. Thank you for the explanation!