I see that in this block, it’s selecting the parent frame as FrameIndexToStart, which causes completion transitions to be considered from the parent down. This doesn’t make sense to me.
[Image Removed]
The comment doesn’t even seem to agree with what is going on. The last completed state isn’t the parent state(Patrol). The last completed state should be the one that failed, which is (GuidedPatrol). This seems to be why GuidedPatrol failed transitions aren’t being considered.
Am I wrong about something here?
[Image Removed]
This entire new ExecutionContext::Private::bGlobalTasksCompleteOwningFrame just skips the frame level that actually errored.
Why does it loop to find the FrameIndex that failed, but not give anything on that level the opportunity to handle it?
The fallback code, below this, loops through and sets FrameIndexToStart and StateIndexToStart to the failed state/frame
Judging by the comment associated with the bGlobalTasksCompleteOwningFrame, this new chunk of code is meant to be new 5.6 behavior, but why would it be proper or desirable that a frame has no ability to handle its own success/failure states? That seems entirely counter intuitive.
[Image Removed]The reference to Global taskcan only mean that it’s meant to handle the completion state of a globally running task on the state tree, but the task that is failing here is just on a regular state, in a regular linked node, and this ‘global task’ code is causing it to fail from the parent frame upwards, which makes total sense for a global task, but not for this situation. How do you make a distinction between global tasks and any other task on any other state?
Sure enough, turning off StateTree.GlobalTasksCompleteOwningFrame fixes the issue and gets my behavior working again.
The takeaway here seems to be that the code for this cvar, at least in TriggerTransitions(), is being applied too broadly. If it’s truly meant to only be applied to global tasks, not just any task, it’s bugged. If it’s meant to be applied to any task in any frame, then a) that doesn’t really make much sense, and 2) everything about how it is documented in the cvar suggests otherwise.