Bug Bug in transition priority? [workaround found]

Hi.
It would appear that transition priority is being ignored. This was tested in 2019.2.1f1 and then 2019.3.15f1.
Am I doing something wrong? is there a workaround I could use right now?

The scenario:
In frame A, current state is "right", triggers SpinLeft and Laser are activated. The current state has the transition to "Spin L" (with trigger "SpinLeft") with higher priority than transition to "laser_right" (with trigger "Laser").

What I expected:
In frame B, after frame A, Animator should have seen both possible transitions with triggers that have been activated and pick the transition with the higher priority in the current state, which is right->Spin L.

What actually happens:
In frame B, after frame A, Animator picks the right->laser_right transition instead, while the SpinLeft trigger remains activated. If I stop activating the "laser" trigger in subsecuent frames, Animator will pick the "SpinLeft" trigger and transition to "Spin L", as if it was a lower priority.

Notes

• I tried adding an interruption from current state to right->Laser, which you can see in the screenshots, but it made no difference.
• I tried reversing the priority, but it made no difference either.
  
• state "right" has two behaviours, one of them is disabled (as that was a bug). The behaviour clears the trigger with the given name. I provide code for the behavior at the end of this post.

In the screenshots you'll see (taken in 2019.2.1f1, but behaviour in 2019.3.15f1 is the same):

1. The animator's state in frame A, before the transition:
2. The animator's state in frame B, after the transition:
3. The current state's properties in frame A:
   
4. The Laser transition's properties:
   
5. The SpinL transition's properties:

Code for the behavior in "right" state (ResetTriggerOnEnter.cs):

Code (CSharp):

1. using UnityEngine;
2.  
3. public class ResetTriggerOnEnter : StateMachineBehaviour {
4.     [Tooltip("The trigger you wish to reset")]
5.     [SerializeField]
6.     private string _trigger;
7.  
8.     override public void OnStateEnter(Animator animator, AnimatorStateInfo animatorStateInfo, int layerIndex) {
9.         animator.ResetTrigger(_trigger);
10.     }
11. }
12.  

Am I doing something wrong or is this a bug? Is there a workaround I can use right now?
Thanks!

 

oh boy.
I tried a workaround of unsetting the "laser" trigger before setting the "SpinLeft" trigger, but still it picks up "laser" first.
It doesn't work because I can still set laser again by mashing the fire button. This is why priorities exist!

Halp.

 

Is there a way to debug this? Going frame by frame as shown in screenshots above I can clearly see priority is being ignored.

Edit: I tried the pinned animation recorder, but when playing back it's a mess. I'm not sure how I'm supposed to use it, and I don't think it will add new information (as the thread says triggers are "tricky to debug").
Are triggers broken?

 

So I guess I have to work around the Animator, as so many people had told me they did too.
I was hoping they were just doing it wrong but...

 

Yeah, there's not really anything you can do to debug the logic of an Animator Controller because you simply don't have access to the source code and the necessary details aren't exposed at all.

You might be interested in Animancer (link in my signature) which has all the logic in C# built on top of the Playables API so you can debug it properly. Though something like this wouldn't be a problem in the first place because Animancer doesn't try to simulate its own logic like Animator Controllers, it just does whatever your scripts tell it to.

 

Thanks, I did see Animancer on my research.
I have started building a tool to help build state machines, which could help such things in the future, but in the meantime I did find the issue:

The transition with the high priority had a transition time, while the other one did not. Setting the transition time to 0 made it pick the one I wanted.
I feel like this is a bug, will file it later with a case to be reproduced, along with some feedback: since transitions can be chosen for different reasons, there should be a way to see why the last transition was chosen, for debugging purposes.

Thanks!