Generic Rig gets stuck when emoting.
closed
Shin
Any generic rig that does an emote from the emotion menu will be stuck in a loop performing the emote regardless if the emote was for generic rigs or humanoids. The only ways to escape the loop is to change worlds or wait for a full minute(?)
The rig I was using used the animation controller template. This also affects emotes place in custom override animation controller slots.
Log In
Euan
closed
Tnomic Vierling
Made an account just to upvote this. Recently finished my first import+animations only to find myself sticking in the emote. Kind of disappointing to see after the work done and wanting to see it work properly.
Claudia Cota
I really hope they fix this, it would make custom animations so much easier to implement.
s
spearmonkey
Think I've got some extra details on how this bug occurs after fiddling around with the Animation Controller Template provided in the SDK, but sadly no solution we can implement as players at this point.
-----------
Context/background info:
From the StandingIdle state, the animator is effectively told to go and play one of the 8 emote choices when a parameter called "Emote" is greater than 0 (specifically, it transitions to the Emotes layer, which has 8 different choices depending on the exact value of the "Emote" parameter). Normally, the animator is told to return to the StandingIdle state once any of the emote animations has finished playing (or more specifically, it exits the Emotes layer, and presumably gets back to the StandingIdle state either directly, or via the Entry node on the Idle layer).
-----------
Set up of the test (using a Generic Rig):
I created a dummy state called "DelayDummy" on the Idle layer, and then set up a transition such that the Emotes state exits to DelayDummy with no delay once the emote animation finishes (Has Exit Time, Exit Time = 0). I then created an exit transition from DelayDummy to StandingIdle, switching between the following conditions for various tests:
- Has Exit Time/Exit Time = 0 (i.e. transition into StandingIdle once the assigned animation for DelayDummy has finished playing)
- Conditions: "Emote" parameter == 0 (the assumption here being that the emote looping is actually caused by the StandingIdle state continuously sending us back to the Emotes layer if the Emote parameter value hasn't been reset when we exit the Emotes layer).
-----------
Results:
- When Exit Time is used on DelayDummy, the animation assigned to DelayDummy will play once in its entirety before the selected emote is looped again (changing the length of the assigned animation will change the amount of time between the selected emote plays again). This implies that the looping bug isn't caused by any of the loop settings on the animation clip itself, but that the Emotes layer is being repeatedly called, like we're returning to the StandingIdle state but being continuously sent back to the Emotes layer for some reason.
- When the DelayDummy state is only allowed to transition to StandingIdle if the Emote parameter is equal to 0, the emote only plays once without looping -- but [playing] continues to show on the VRC emote select screen for at least a minute, and we're unable to move the avatar around with the WASD keys or jump until the [playing] text resets to the emote names. This implies that the Emote parameter value is set to 0 at some point by VRC, or else DelayDummy should have never been able to transition back into StandingIdle.
-----------
"Conclusions"/Implications
This seems to suggest that the emote looping on Generic Rigs is caused by VRC returning us to the StandingIdle state without resetting the Emote parameter value to 0 -- it's not that the animator fails to exit the Emotes layer or that the emote animation is never exited, but rather that the game acts like we're repeatedly pressing the same emote button over and over because we're returned to the StandingIdle state with that same Emote parameter value, which makes it automatically transition into the Emotes layer again.
It would also imply that Humanoid rigs correctly reset the Emote parameter value to 0 at some point before the animator exits the Emotes layer.
There's a hint that the Locomotion layer can't take effect while the Emote parameter value is greater than 0, but the evidence for this is a bit weak since the DelayDummy state may be missing some hidden functionality of the StandingIdle state (additionally, this would likely be a non-issue if the Emote parameter value issue is fixed directly).
Claudia Cota
spearmonkey: wow thanks for the info, I've been looking everywhere for answers and a solution but this is the best information I've been able to find after hours of searching.