Brain hurting from taking notes on the animator refactoring

These are the notes I was taking while Sam was refactoring, I feel as though he was not super clear in how he phrased himself. Can someone make sure I actually understood what was happening correctly from my notes.

Thanks in advance.

1 Like

Looks like you’ve got the gist of it. :slight_smile:

As confusing as Sam’s explanation appears, it’s partly because of how complex Unity made things in the first place…

The Animator Controller field (runtimeAnimatorController) can take either an AnimatorController or an AnimatorOverrideController. The only way to know which one is currently loaded is to attempt to cast it as an AnimatorOverrideController… if the cast succeeds, then you know that the controller is an override not a regular controller. if(overrideController!=null).

An AnimatorOverrideController contains a field runtimeAnimatorController which is the parent Override controller. Unlike an animator’s runtimeAnimatorController, this can only take a regular AnimatorController (which it must have so it knows what animations to override), not another AnimatorOverrideController, so you can set the animator’s runtimeAnimatorController to the overrideController’s runtimeAnimatorController.

I wish there was an easier way to explain this, but there isn’t… it would have been much much easier if they would have named that field controllerBeingOverriden or something like that, not runtimeAnimatorController.

All of this being said, I find it much simpler just to have an override controller for each weapon, including the fireball.

3 Likes

Thank you, seems like I was kind of understanding it then. Yeah the Unity vocabulary is awfully limited in describing what is happening for sure.

Thanks for the time as always Brian!

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms