I have the following sample state tree setup:
[Image Removed]
“Trigger Timeout Event” is a custom State Tree Task that will send a State Tree Event after X seconds with the tag “Example.Transition”.
Both “Listen” nodes have Event transitions that listen for this tag; High-Prio has a Priority of “High”, Normal-Prio has a Priority of “Normal”. No conditions are set on any Transitions or Nodes.
Expectation: The State Tree sees that there are two transitions in the active hierarchy listening to “Example.Transition”, and will prioritize triggering the one with higher priority. In this case, when “Timeout” occurs, the tree should transition to “High-Prio Event Response”.
Actual: The State Tree only evaluates the first “inner-most” transition that passes its conditions. In this case
While this specific sample tree may seem a bit silly for this use case, we have a case where a “subtree” (a linked asset state tree, which we use across several state trees) is listening for a tag to tell it to do something after, which we want to happen in most cases. But we have one state tree that uses this “subtree” where we want it to do 90% of the logic in that subtree, but would rather it execute different logic after that specific transition occurs instead.
This is the intended flow for this tree setup. We check transitions from leaf to root looking for the first valid transition.
In testing some cases with this, I did stumble onto an issue where having multiple transitions using the same event on the same state picks the first transition in the list even if it is not the highest priority event transition. This seems to be due to how the event is consumed by the first transition in the list and no longer exists for other transitions. Non-event transitions will still pick the highest priority transition, and that behavior should be the same for events as well. We will look into this issue.
-James