How to see an animator controller parameter in VS debugger

I'm trying to understand why NetworkAnimator isn't causing my client to switch from idle to walking. I'm in the NetworkAnimator code, I see that the parameter is having SetFloat called to set the Speed parameter to a value > 0.1, which is the transition for going from idle to walking. I just want to confirm that the Speed parameter is being updated, but when I look in the Visual Studio debugger, I see all of the attributes of the animator parameter, but the value of the parameter isn't there. See the pic: the value (which has just been set to 0.1957...) is not an attribute of the parameters[0], but everything else about the parameter is shown there.


Is it not possible to see the value of an animator parameter when debugging, or is it somehow stored in some other place that is viewable? I realize that it must be set to this value, since that line of code just ran, but since the transition from idle to walking isn't happening even though the speed is now > 0.1, I'm looking for anything that might be the cause.

Thanks!

 

Animator Controllers are already hard enough to debug on their own, so I don't envy you having to add networking to the mix.

Could you just make a property in your own script which calls GetFloat on the parameter so you can use the debugger on your property?

Maybe, maybe not. Calling Play will only change the current state next time the Animator Controller updates (and calling it multiple times in the same frame will ignore them all after the first) so I wouldn't be surprised if it was doing some similar nonsense for parameters.

 

I can, but that still leaves me wondering just where the parameter values are actually stored. I feel like if i cant see the actual value in the debugger, I can't know whether other events and code might be messing with it without me knowing it. I can't have a breakpoint on it when it changes, for instance.

 

It's probably in a block of unmanaged memory somewhere that the Animator Controller allocates internally for the sake of optimisation, so I doubt there's much chance a managed debugger will be able to see it. Animator Controllers really aren't designed for programmers; you can't debug them properly, you need magic strings everywhere, and even simple concepts like separation of concerns or encapsulation are impossible. If you use them you basically just have to accept that you'll be writing hacky workarounds for every second thing you try to do.

 

Cool. That's what I was hoping wasn't the case. I appreciate the reply.