The first layer holds all the drivers, which take Boolean parameters from senders and receivers, and depending on which hand is detected and whether i’m grabbing the collider, should set the BusterPosition Int parameter to a number from 0-3.
The current Booleans above are activating the “Right 1” animation…
… which should be setting the “BusterLocation” Int parameter to 1
However, the Int parameter is not being set to the corresponding value. This is the case for all other Boolean states in the animator layer.
Manually changing the BusterLocation parameter to the corresponding number value does activate the second animator layer, which holds all of animations transitioning the Buster sword to the different parent constraints, so I know for a fact that the issue is with the parameter driver itself, rather than the parent constraint animations not working.
So it’s clearly detecting the colliders when you grab the sword and setting the proper booleans. The one thing that strikes me with those screenshots is the BusterLocation.
If you have a Paramerter Driver in Right1 that is setting the BusterLocation but the transition is also testing the value of BusterLocation, could there be something happening there where values are actually being set but now they fail the test for the transition.
On first glance it doesn’t seem so - the ParameterDriver looks like it’s setting BusterLocation to 1 and the test is checking to see if it’s Not 2 - so it should pass but that series of testing a variable that you’re then changing looks like it could cause problems.
Have you tried it in game and enable debug logging?
And just another dumb question - but if your BusterLocation is meant to be a networked variable, are you certain that it’s in your Parameters file and spelled correctly with case sensitivity?
Yes, so the parameter booleans are being detected correctly in-game, but yet nothing is occurring. And you’re also right that the transition is checking for the BusterLocation parameter, and the Driver should be setting it, but since the driver is occurring after the transition detects the right booleans, it shouldn’t have any conflict unless it is interrupted, but the transition should be more/less instant. I do have it all networked, and they are all spelled correctly with case sensitivity. I have also reinstalled the SDK to ensure it wasn’t something missing in it.
The fact that I see the transition fully go into effect and supposedly activating leads me to believe the transition is working, but the parameter driver, or some setting within it.
I’m not sure what debug logging is, but if you’re referring to the debug menu in the avatar3.0 options, then yes I have enabled it, and I can see the proper booleans activate, yet the BusterLocation parameter remains at the default I set it to initially, usually 0.
I use Parameter Drivers extensively in my own avi to set and reset variables as to generate random numbers so I know that they work, but I do recall having a problem similar to what you’re seeing.
The one thing all my parameter driver states have in common is that they either have ‘Exit Time’ enabled or they have a transition out of the state that contains the driver.
Maybe try implementing either of those mechanisms and see if that has any effect?
Checking the exit times, adding an exit time of 0 and even .01 result in no change in behavior upon testing unfortunately… If it helps any, I’m following a Youtube video for the logic setup, and I believe I have followed it accurately, specifically going over the parameter driver logic. They get it to work, though something has bugged me that they have a slightly different UI for the parameter driver despite me being on the same version of the SDK and everything… Maybe there’s something else funky with the SDK going on? I have the video attached at the bottom.
The image here is what my parameter driver looks like; highlighting the different UI underlined in red, and the description is in one big block of information above the driver settings:
And this is what their parameter driver UI looks like, and it’s missing the [Add, Up, Down, Delete] buttons, and the description of what it does being in two separate information boxes above the settings:
Not sure what that means, but it looks like they’re using a different version of the SDK or Unity, or I’m using a different verison, but I checked their unity window in the video, and we have the same version… no clue if that is a big deal or not, but hopefully that helps.
Are you using the Companion Creator utility to create your Unity projects?
I used it to create my Avatar project and have been using it to also keep my SDK and accessory versions up to date.
My SDK Base version is 3.1.10
My SDK Avatars is 3.1.10
Maybe if you haven’t used the Companion Creator, you could give that a try and migrate your current project over and see if maybe is installs something that you’re missing.
You can also ‘Add’ your own project to it, but I don’t know if it will update your packages automatically or not. Once you have a project created, it will show up in your Projects list and show you all the SDKs for that project and allow you to update them if they’re out of version in the future. You can also open your projects from there too, which just launches Unity with your project:
Hopefully it will import/add something that you might be missing. It’s a shot in the dark without actually having your project in-hand to try to examine all the pieces and try to debug.
Just checking in here - did you ever reach a solution @swift3r ? Running into the exact same issue as well. Migrated project to creator companion standards, my parameter driver interface looks just like yours w/ base & avatar SDKs at version 3.1.11
The parameter driver is hit in play mode when the controller transitions to the state that hosts it, but the driver never… actually sets the parameter, in this case to a random value b/w 1-4.
Short of starting from scratch in a whole new project I’m kindof at a loss - I configured the transition out of the state w/ the parameter driver to have an exit time & transition duration of 0.0001 just in case that might help too but no luck.
Rather puzzling as to why it’s not working, ahaha. Nothing in the documentation or elsewhere I’ve been able to find on it of course - this post is the sole mention of this particular problem.
Hi! Unfortunately I never figured out the issue, and while I haven’t officially given up on this problem, college work has gotten in the way of my experimenting with Unity. If I’m honest I think my Unity is just cursed somehow.
If you find out any solution to this issue I’d love to finally figure it out, but as it stands right now I don’t have the time at the moment to work on it.
I’m sorry if that’s not the answer you were hoping to get, and I wish that I could be of more help to you in this instance, but all the power to you for tackling this! It’s a bit vindicating knowing I’m not alone in this issue feels like I’m being gaslit by Unity itself… @_@
I’m not sure if this will help or hurt, but maybe you can glean a bit of info that might help. I use parameter drivers in quite a few places, and I’ll show you what I do with them below.
I use them to do random twitch animations on occasion whenever I change a gesture on my hands. I have two variables declared in both my Parameters file and my layer: ‘RND’ and ‘Twitches’
RND is used to determine IF I should play a twitch, and Twitches is used to determine WHICH animation to play.
Whenever a gesture happens, I have a default transition with an exit time (No parameters) going to my ‘Set Twitches’ state, set as local, which generates a random number for RND.
In another layer (Please excuse the mess), I test the value of RND and Twitches. Ignore all the other stuff here - it’s not necessary to know what it does - just focus on the highlighted transition. I only want a twitch to play if there isn’t one already playing.
If RND > 75 and Twitches is 0 (No animation) then I’ll again randomly set the Twitches variable to a non-zero number and let the transitions figure out which one.
Again, I’m not sure if this will be helpful at all, but I figured that maybe seeing all the values of some working drivers might reveal something. All these layers on on my FX controller, so that might be a clue too, I don’t know.
feels like I’m being gaslit by Unity itself… 
