Animator transition from Entry state to multiple states in Unity 5

I am making a 2D game. In this game I will have torches. When the scene starts there are two options for torches:

  1. They may be burning
  2. Or they may be not burning and have no flame on them.

Whether the torches should burn or not is determined by a public boolean value "IsBurning" in the script attached to the torch, so I can decide which of them are lit up in the beginning of the scene and which are not burning.

I have made all animations for Burning and not burning states and for transitions between them. Here is how the Animator is looking right now:

48246-torchanimator.jpg


What I want to achieve is:

If I set IsBurning in editor to true, my torch will immediately appear burning in the scene. If I set it to false, it will appear to have no light on it.


What I have tried so far is making two transitions from Entry State, but no matter what conditions I put in there (tried triggers, booleans), it automatically switches to the default state NoLight.
Then, I have created a shortcut transition from NoLight to Burning State that uses a Trigger. I set this trigger in my script’s Start() method, but it does not seem to work either. Instead it is taking a long root. From NoLight it goes to LightsOn, which is gradually bringing up the light and the flame appears slowly, and only then to Burning.

I have checked the order of transitions for NoLight State. My shortcut transition to Burning has higher order than transition to LightsOn, but it still chooses this longer route to get to burning state.


What am I doing wrong here?

Any help is greatly appreciated.

Has anyone figured out how to get this to work correctly?

According to this: Having fun with the new Mecanim features | Unity Blog

We should be able to use this feature trivially, yet I can’t get it to work at all in my project…

Edit (Solved?):
I think I figured out the problem.

I don’t know exactly the correct terminology to use for this… but basically what seems to be happening (for me at least) is that if I attempt to rely on the multiple transitions from the Entry node when the specific statemachine has been entered automatically, it directly selects the default animation and ignores the conditions on the Entry node. However, if you enter a sub-statemachine using a transition (up or down), it works fine. I’m not sure if this makes sense, but it seems to be working for me.

In my current game I wanted to use an animator with multiple sub-statemachines for each stance (weapon type) a player can use. I have an int parameter for the stance and I want to be able to switch between them. Originally I tried to use the conditional transitions from the Entry node to choose which stance to enter and then I’d use the Exit node on each of my stances below when the stance changes so it’d go back to the Entry.

This did not work since whenever you first start your animator up OR whenever you exit up into the top layer using the Exit node, it jumps DIRECTLY to the default state instead of analyzing the conditions on the Entry node.

However, if you instead use transitions targeting the layer above directly (less clean since it can’t be as reusable… but for my purposes it’s fine), it will correctly target the next stance because it will hit the Entry Node correctly. I still have an issue with the INITIAL start up. It still goes directly to the default. To fix that, I’m going to set the default state to something in a sub node of some T-Pose-esk stance that will immediately jump back out to the base layer. This might cause a slight character flicker when a character is first created, but it’s a decent work around for now.

TL;DR
I’m almost certain that this is a bug. The entry node is skipped/ignored and the animator jumps DIRECTLY to the default state UNLESS you are ENTERING the state machine from another state machine. It’s possible that this is the intended behavior, but it seems strange. At the very least, I’d like to have an option to change the behavior.

Use a StateMachineBehavior, and OnStateMachineEnter() inside of it to CrossFade() into the needed state. Otherwise a default one will be chosen

Looking closely at that blog post, I can see his example is actually in a submachine. Note that he has a diamond “state” that represents the base layer.

For whatever reason, the conditions that would select a transition from the entry node to a state other than the default state have no effect on the base layer when the machine starts. Indeed, even his example code, which subclasses StateMachineBehaviour, does not get called if you add it to the entry node of the base layer machine.

However, if you add multiple transitions to the entry node of a submachine, these do have the desired effect. In fact, you don’t even need to write any code to test it. If you create an entry node with two transitions, the default and one more that you add, and you create a boolean for your machine and condition the second transition on that boolean being true, you can have the base layer machine transition into your submachine and the entry node will immediately transition to the default if your boolean is false, or else it will follow the second transition if your boolean is true. You change the setting of your boolean in the state machine editor while it’s running see the submachine switch to one state or the other, each time it is entered, based on the setting of your boolean.

Note that, if you do have a subclass of StateMachineBehaviour on your base layer’s entry node, it will have its code called when you re-enter the base layer (either by exiting the submachine, or transitioning within the submachine to the diamond state that represents the base layer and selecting the state machine itself).

This certainly is odd behavior, as one would expect the methods in your StateMachineBehviour subclass to be called when the state machine starts for the first time, but this just isn’t what seems to happen. There was some forum discussion about it here: https://forum.unity.com/threads/statemachinebehaviour-onstatemachineenter-exit-broken-in-5-0-2-5-1.331466/, but it’s not clear to me if the conclusion was that this is a bug, or if there’s a reason for it.

For people having the same problem. The SOLUTION that worked for me - in settings of my transition from NoLight to Burning state there is an option “Has Exit Time”. It has to be unchecked. After unchecking this, everything works properly.

Using Unity 5.5. You can change the default transition for the Entry State by right-clicking on Entry and choosing/highlighting, Set StateMachine Default State. Then drag the arrow-line to the State that you want as the new Default.

BTW, I’m using a Mac so if you are a Windows user or a Linux user, use the commands that are equivalent. I don’t know them off the top of my head.

Hope this helps.