StateTree Linked Asset parameter bug?

I’ve started to encounter a weird issue where it looks like the parameters that should be set on a linked asset are not being copied.

I have a shared state tree, called ST_Move_Shared that I use as a wrapper around AI locomotion. It handles a variety of traversal flows, smart object usages, etc, so it is useful to reuse in a variety of substates that need to perform locomotion that may need to take traversals.

For instance, here is a working instance of it.

[Image Removed]

[Image Removed]

This usage works properly, however, another usage, elsewhere in the tree, seems to only be copying context properties, and none of the parameters on the linked asset state.

[Image Removed]

[Image Removed]

I’m at a loss for why the exact same external linked asset used here is receiving none of its parameters, while an earlier usage is working fine. The result is of course the move fails because it’s not getting critical parameters.

If I trace backwards from FStateTreeTasks_AIMoveTo::EnterState, where none of the parameters are set, I noticed an issue(I think) with FStateTreeExecutionContext::EnterState

EnterState has an outer loop for the frame index, and an inner loop for the states within each frame.

In this situation, Frame0 is what has the linked asset, so the properties get copied, which I can confirm, in the inner state loop. [Image Removed]But this gets freed with the FCurrentlyProcessedFrameScope

[Image Removed]So when it iterates the outer loop, into the next frame, that data is lost when it calls EnterState on the task in the new frame.

If I step into the property bindings in the next frame index loop, when it goes to copy the MoveTarget within the new frame, it’s copying null.

[Image Removed]

This is bizarre. The other use case seems to go through the same process, leading me to think that the issue probably isn’t this scope destruction., but rather why are the values null in the binding copy before EnterState

If I compare the CopyBatchOnActiveInstances between

  • FrameIndex[0], in conditional EStateTreeStateType::LinkedAsset
    • I can see the expected, valid values are copied to a TargetLeafProperty in a PropertyBag_e3eec93be55051f1
  • FrameIndex[1], prior to calling Task.EnterState
    • The SourceLeafProperty is PropertyBag_bacd01dfcfde7827

I suppose it makes sense that there is a property bag on frame0 on the actual linked asset node. And then the linked state tree has its own global parameters property bag. So copies the values from one to the other?

Seems that I can fix this issue by commenting out this bit, to ensure parameters are always copied.

In light of the other debugging, this would seem reasonable to me, because commenting out the state type conditional seems to apply bindings that copy between the 2 property bags that I identified earlier.

[Image Removed]

Edit: I also noticed that if you have a state tree like this

  • RunEQS
    • MoveToEQSResult(In a linked state tree asset)

MoveToEQSResult(from the linked state tree) will not receive updates to the RunEQS result that may run periodically. I think this too is due to similar conditional checks around the CopyBatchOnActiveInstances

Such as this one in ::TickTasks(const float DeltaTime)

[Image Removed]

Is it known/expected that linked state tree assets don’t seem to see updated copies of data that is bound to their parameters?

Commenting out the conditional here fixes the issue. Why would the parameter bindings only ever copy for linked states? That conditional will copy from the Frame0 scope into the global parameters property bag of the linked state(Frame1), but then what is supposed to copy them from the global parameter bag into the tasks?

Hey Jeremy,

I know there has been work around linked assets recently and chasing down some issues around parameter access in subtrees and parent trees. I am waiting to hear from some of the team if this is a known issue or possibly even addressed in recent changes.

As for the issue of not updating the parameter for a LinkedAsset while it is running, this is due to not copying or updating state parameters during tick. We do have a couple call outs and todo’s around this in our StateTree tests. It is certainly something that we are aware of possibly needing.

-James