Say Goodbye to the Animator! NEW Unity Plugin Showcase 

Would be nice to have a tool to bake this automatically. Specifically the animation names as well. You should be able to generate the enum code block from a animation controller pretty easily.

Duude, you are a genius for finding that bug. I really couldn't have made this plugin without this community. Most of the ideas for this plugin came from you all. Really appreciate all the feedback and suggestions. I have committed a new version with these changes on the github page.

@@SmallHedgeHQ[Edit] The above methods works fine there was a mistake in myside of the code that was causing it to through an error. Hello there this is very important, Please replace the array of the coroutines with a list, otherwise the plugin will give not work but remain stuck on the default animation. private List currentCoroutine = new List(); /// Sets up the Animator Brain public void Initialize() { AnimatorValues.Initialize(); //Animator animator = GetComponent(); layerLocked = new bool[animator.layerCount]; currentAnimation = new Animations[animator.layerCount]; // Coroutine[] currentCoroutine = new Coroutine[animator.layerCount]; currentCoroutine = new List(animator.layerCount); // this.animator = animator; for (int i = 0; i < animator.layerCount; ++i) { layerLocked[i] = false; currentCoroutine.Add(null); int hash = animator.GetCurrentAnimatorStateInfo(i).shortNameHash; for (int k = 0; k < AnimatorValues.Animations.Length; ++k) { if (hash == AnimatorValues.Animations[k]) { currentAnimation[i] = (Animations)Enum.GetValues(typeof(Animations)).GetValue(k); k = AnimatorValues.Animations.Length; } } } //rest of initialize} And later in the Play function if (layerLocked[layer] || currentAnimation[layer] == data.animation) return false; if (currentCoroutine[layer] != null) { StopCoroutine(currentCoroutine[layer]);} layerLocked[layer] = data.lockLayer; currentAnimation[layer] = data.animation; animator.CrossFade(AnimatorValues.GetHash(currentAnimation[layer]), data.crossfade, layer); if (data.nextAnimation != null) { currentCoroutine.Insert(layer, StartCoroutine(Wait())); IEnumerator Wait() { animator.Update(0); float delay = animator.GetNextAnimatorStateInfo(layer).length; if (data.crossfade == 0) delay = animator.GetCurrentAnimatorStateInfo(layer).length; yield return new WaitForSeconds(delay - data.nextAnimation.crossfade); SetLocked(false, layer); Play(data.nextAnimation, layer); } } I hope you will see this comment and change the Repository again. There is some problem with using an array. Using array only works when there is no next animation for some reason.

@@OrbitZeroStudios hmm that is really bizarre. I’ll look into it tomorrow. Thanks for letting me know

@@SmallHedgeHQ I am such an idiot. It was working fine I had a typo there in the initialize Please remember the following text: "Coroutine[]"was added by mistake currentCoroutine = new Coroutine[animator.layerCount];

@@OrbitZeroStudios aha that would make sense!

Good idea. Having a different list of Enums for each unit. The reason why it was set up like this was so that it’s all in one place and easy to setup.

:) Just wanting to help out best I can

Love for animal Controller

Very important and valid questions. 1. I am not aware how the Unity Animator functions under the hood (other than it is a FSM), so I can't do a direct comparison. In terms of the performance of AnimatorCoder, everything is converted to hashes and the AnimatorCoder.Play() method is O(1) (unless you chain animations together), so it is very quick. The user is in control of how performant it is. Whether they want to do a bunch of checks every frame to play animations, or play animations due to an event. The performance is in the users hands. 2. First I will point out that is heavily depends on preference. If you are a natural programmer, converting all animations into code can make animations much more intuitive and logical. It is quite frequent in the Unity Animator that every state needs to be connected to every other state, and that takes a lot of time to set up the animator parameters and transition attributes. By default, the states in AnimatorCoder are already connected to every other state. It also allows you to alter the animation transitions at runtime. Since you can easily chain animations together with AnimatorCoder, you can create you own mini FSM and have then cancel whenever you want to. The main advantage of AnimatorCoder is it is quick, efficient, and simple and only requires one line of code to run AnimatorCoder.Play()

Sorry for late reply! Took time off and slowly getting through comments. I got asked a lot about blend trees. Unfortunately this is set up to optimise single state transitions, not blending multiple animations together. Best bet is to add more crossfade (transition time) to have walk left, right, forward, back animations and transition between them.

You might be onto something, can you clarify what you mean with code examples?

The most likely explanation is the enum value passed in Play() does not exist as a state in the animator. For example, if your animations enum looks like Enum Animations { RUN, WALK, IDLE } Then there must be a state that is named RUN, IDLE, or WALK

@@SmallHedgeHQ Ok, I'll try looking at that again! Thanks!

I suppose this is where there is a balance for convenience and optimisation. This method prioritised convenience (having one global AnimatorValues) and ease of use rather than each animator having their own set of values. A design decision that I thought was a good trade off.

AnimatorCoder.Play() is O(1) by default, so it depends how you use it in your scripts. I had a quick look at the Mesh Animator asset. If all the animations are baked, could you combine AnimatorCoder and Mesh Animator together by changing what AnimatorCoder.Play() does?

@@SmallHedgeHQ how can i combine while 1 is an animator and the other is a sprite sheet of animations ?

The parameter check only needs to occur when you are in the specific animator state. This was eliminating the need to check parameters each frame when you don’t need to.

Each layer holds one singular current animation at a time and is tracked through an enum. So to pick a random animation, you could do Animations[Random.Range(0, Enum.GetNames(TypeOf(Animations)).length] to get a random animation. Or make a list of Enum values to randomly choose from. Each Enum value is given an integer, which allows you to look up them through an array.

Bro’s really making fun of his accent, how petty can you get

Unfortunately it does not support blend trees and I agree. This plugin excels when the only form of blending are simple cross fade transitions. Which typically occurs in 2d projects and certain 3d situations. I did make a video using this plugin in 3d with multiple animator layers. One animator layer was the Upper Body and the other Lower Body. Then the animation logic in code was done in a way to try simulate blend trees by playing forward, back, left, and right walk animations when conditions were met. So like any plugin, it has great strengths and also some limitations, it would be just knowing what situations to use it and when not to use it. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Db88Bo8sZpA.html

AnimatorCoder does allow transitions and overridable animations. Transitions: In the Play() method, you can set the crossfade of the animations so transition them over a number of seconds. Fully played: When you call Play(), it will automatically override the current playing animation. Unless you set LayerLocked = true, then no other new animations can play while the animator is locked. So you can play animations fully if it is an important animation. Or set it to be overridable by other animations.

It might happen!

Someone else had a similar question! So I'm just going to copy paste the response. I suppose you can treat AnimatorCoder as Animator.Crossfade+. Here's a list of additional features it gives to Animator.Crossfade(): 1. Hold the CurrentAnimation: So you don't use Animator.Crossfade() on an already playing animation 2. Ability to lock/unlock layers: Some animations need to play all the way through without interuption 3. Play consequent animations: When an animation finishes, choose what animation to play next 4. Select animations through enums: Passing through an enum to play an animation is quick and easy In a nutshell, it adds a bunch additional checks to Animator.Crossfade() to ensure the requested animation is allowed to play.

@@SmallHedgeHQ oh I get it now thanks. It's more like you upgraded state machine side of things. Cool. I'll have a look at it.

I deliberately set it up that way! In the demo scene, there was the samurai and the wizard and they shared their state names. Using AnimatorCoder.Play(Animations.ATTACK1) on the samurai triggers the swing animations, while it triggered the firebolt animation on the wizard. Try to overlap them as much as you can. Most units have a RUN animation, WALK animation, multiple IDLE animations, multiple ATTACK animations, JUMPSTART JUMPAIR JUMPEND animations etc. It was done this way so you only need to set up AnimatorCoder once and not for every single unit you create.

Hello! Sure thing. Playables are like nodes connected in the PlayableGraph, It is a FSM. Playables Workflow: Have a PlayableGraph and add nodes (new animations) when you need them. Link the nodes together and now you have a FSM. It runs in the background and it will play the desired animations dependant on how it's set. Pros: Replicate the FSM nature of the animator into code Cons: Takes a while to setup Animator Workflow: Link animation states together using transition lines which play depending on animator parameters Pros: Highly visual, quick to setup, lots of features (blend trees, transition options, behavior states etc) Cons: Becomes more complicated the bigger it gets. Gets hard to keep track of everything AnimatorCoder Workflow: Create a list of conditions that need to be met to play an animation and use AnimatorCoder.Play() to play them. It will execute a bunch of O(1) checks to validate the request and then the animation is played. Pros: Quick to setup and requires only one universal setup, easy to use, minimal code, highly intuitive Cons: Doesn't provide functionality for blend trees We worked on AnimatorCoder because it is an animation system that works no (or very little) setup and works straight out of the box. It's the most intuitive animation scripting design I know.

Sounds like you’re going to use multiple animation layers and ik positions. Start small and pick one of them to start off with. If you would like an example of multi-layered animation workflow in 3d, I would check out the previous video on animations ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Db88Bo8sZpA.htmlsi=V5b2KJ-YV4BWuAYc

xD

I haven't give visual scripting a go so not too sure! If you are able to play methods from specfic scripts attacted to gameobjects, you should be able to!

​@@SmallHedgeHQi am gonna try it today

I suppose so is the Unity animator window xD

​@@SmallHedgeHQ Well, at least the unity Animator window doesn't list all parameters of all animation controllers in a single window You can introduce generic type parameters in your AnimationCoder class to force the inheritor to pass in their own enum classes for both the Animations and Parameters

yes but you can search them. i use a similar approach where i hash the animations before hand. if you play something in code you can always look up where it is triggered and from what.

The problem with structs is you can’t reference itself and can’t chain animations together. Otherwise I would be using them! Edit: You can create the classes in the Start() method and locally store them so you’re not calling new() each frame

@@SmallHedgeHQ yeah that makes sense. Perhaps just keeping a pool of them would sort it out.

@@SmallHedgeHQ Just realised you can make AnimationData as a struct have a reference to an AnimationData if you make the declaration AnimationData? - this creates a Nullable that is still a value type and is legal for recursion.

In plain C, you would be able to use AnimationData* nextAnimation and that would be legal. However, using Ref AnimationData nextAnimation triggers CS0501 error and states it must declare a body. Could you paste the code you had in mind for struct recursion?

@@SmallHedgeHQ what about if each struct is in one global array. and you use the index to push to a global_list_of_chained_animations[] ?