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.