Case 893600 - Any State transitions to Sub State Machines ignore Interruption Source

Hi there,

We have been running into an issue with any state transitions that we have reported to QA but they are having issues reproducing with our steps, even though we seem able to reproduce it literally 100% of the time in all tested versions of Unity between 5.5.2 and 2017.1.

The issue is that while an Any State transition is occurring it cannot be interrupted by the next state getting a valid transition, even though the interruption source is set to Next State.

I have attached our repro project, as well as a gif of the issue occurring, if anyone else could try and reproduce this and see if it happens to them, it would be great, as the QA thread has devolved into being told to check hardware.

To reproduce with the attached project, do the following:

• Press Play.
• Select the GameObject.
• Open the Animator window.
• Confirm the Progress parameter is true.
• Set the Reset trigger parameter.
• Observe that the animator will not transition into State 2 until the Any State transition is complete even though the Interruption State is set to Next State.

Any help either confirming or working around this issue, would be much appreciated!

Thanks in advance!

 

Bump! Any ideas anyone?

 

It's because the transition from State 2 to State 3 is "exit time", so it won't transition until the 1->2 is finished..

"Exit time" is the worst name in the entire Unity API. It means "the animation will transition when you have gotten this far into the animation". This means that the exit condition for your 2->3 is "90% of state 2 has played". That won't interrupt the transition 1->2!

Try setting the transition from 2->3 to be dependent on a bool instead, and you'll see that the interruption works as expected.

 

The problem is that it does not interrupt the Any->1 transition with the 1->2 transition, even though its flag is set and the Any->1 interruption source is set to Next State.

The transition from 2->3 is only there for clarity, so that it idles on a state that is not the state we want to monitor, otherwise state 2 would have had a progress bar at all times, which may look confusing.

Basically, the set-up between Any->Entry and 1->2 is as you said and it does not work, it waits until the Any State transition is complete before taking the next transition, completely disregarding its interruption source. The same is true even if the any state transition leads to state 1 rather than the state machine entry.

 

I've attached a gif with a reduced time scale to show the issue more clearly.

 

Ah, I see. Yup, you're right, the transition is broken.

Your repro case is a bit too complicated, though. The sub state machine is not neccessary. The bug is simply:

"An interruption source on a transition from the any-state node does not work"

I've checked with both current state and next state as interruption sources, and both are ignored even when all states are on the base layer.

 

You are entirely right. Stripped our repro down to the base layer, removed the extra state, in case QA gets confused by it like you did and increased the transition times to 1s each, to accentuate the problem.

Also, yeah, you're right, none of the interruption modes are working. Enabling Can Transition To Self and setting an interruption source of Current State results in the Reset flag being ignored until the transition is complete.

 

Hi guys,

I just did some investigation on this case and this is expected by design.
If you look closely at your transition from any state to state 1 you can see that Ordered Transition is checked which mean that the order of transition matter.
If you look at the documentation for Animations Transitions
https://docs.unity3d.com/Manual/class-Transition.html
The transitions in AnyState are always added first in the queue, then other transitions are queued depending on the value of Interruption Source
The interruption order works, conceptually, as if transitions are queued and then parsed for a valid transition from the first transition inserted to the last.

So in your case since Order Transitions is checked only an Any state transition can interrupt an Any state transition.

Uncheck this and it should work

 

All of the transitions in the latest gif has "ordered interruption" grayed out, so the fix you're suggesting is not possible. "Ordered Transitions" is not a thing, so I guess "ordered interruption" is what you mean?

Also, oh my god this is increadibly convoluted! Have you ever sat back and realized that your entire system is way to complex for any real human to actually get anything done ever using it? Like, you have to know, somehow, magically, that any state transitions has some special order in some undocumented queue that makes the normal transition logic not work?

I made a game with this and looking back I don't understand how that happened, because OHMYGOD what?

 

You hit the nail directly on the head here. The documentation is sorely lacking on explanations for anything beyond the basics. The documentation (manual) should be ALL encompassing and should be the go to place for everything related to the engine, especially when dealing with mecanim - where all developers who use it have a different setup.
I just pointed another developer to a youtube video and a answers question related to mirroring in mecanim. Because the information in the documentation is so minimal - its frustrating.

Documentation needs to be and should be updated with ALL information about mecanim.
Even if the system is complex and un-intuitive -- if the documentation was relevant we could muddle our way through it.

Just look at zbrush as a comparison. Some workflow/processes using zbrush are just plain bass-ackwards but the documentation and learning content is overly fulfilling enough so most anyone who wants to use it can,, although the interface and processes are still convoluted and disorganized.

 

So just to clarify, should an Any State with Can Transition To Self checked be able to interrupt itself with Order Transitions checked or is that transition queued after itself and must finish before triggering again?
Just want to confirm this as it is not clear in the documentation if this is what should be happening.

 

Sorry I mean Ordered Interruption, I have no idea why on the screen shot they are all grey out, but I did the same test on 5.5.3, 5.6, and 2017.1 and it does work

 

Any progress on this problem? I've run into this bug too and managed to make a temporary fix for it but I really would love this to work as designed because I had to add additional code, values and "any state" transitions to work around this issue.

 

Actually not a clue why it was ghosted on that animgif either, I had a look and Ordered Interruptions is indeed editable.

 

@Quadropups yes there is no bug, ordered Interruption was checked in this case and any state transition have the highest priority in the system as mentionned in the doc