[1088] Locomotion not being disabled when it should
tracked
1
Video of the bug happening here:
As seen on the video the function of disabling the locomotion animations from happening is broken on open beta but works perfectly on live.
Log In
Franada
1As mentioned in the documentation, when an avatar is loaded, the TrackingType parameter is not accurate for a few frames. So dead end system will have issues.
By checking the debug menu, they are probably in the 3 PT system of LocomotionFix system.
Franada
Update my locomotion prefab. Hope now is future proof, plz don't hurt me. If it detect a change in VRMode or TrackingType. It get send to an exit.
Afromana
marked this post as
tracked
After further investigation, it appears that the timing on some avatar related calculations have changed, and "TrackingType" is incorrectly set to 2 for a few frames.
The animators in question appears to expect a very specific timing, and their states reach dead ends after load, which is something we would discourage. (The 3.0 documentation has been changed to reflect this)
In particular, these animators get stuck on the wrong "TrackingType" state, while the parameter itself ends up being correct, "TrackingType" may change for different reasons, if these animators supported the potential change of them, they would still work.
This will be reviewed further, but for the moment will release as is.
Tupper - VRChat Head of Community
1: In particular, you can fix this controller by changing this transition to be false when TrackingType is 2-- right now, I think it includes 2 in its conditional.
TrackingType == 2 && VRMode == 1
is an invalid state and should be considered a "the avatar isn't ready yet" state.Either way, the animator should be designed to handle
TrackingType
changing to a different value after avatar init, otherwise us doing possible future things like enabling/disabling FBT or VR on the fly will break the avatar.1
Tupper - VRChat Head of Community: Yep, already did my band-aid fix like so after reading the updated docs after Afromanas response, so all good. Thank you
Gireison
Tupper - VRChat Head of Community: I was one of the guys who designed that thing. I am a bit surprised by that behaviour change, especially due to whenever I disabled my three trackers for example and went into the menu my avatar did reload causing the locomotion animator as well to start "anew" with its default state. I asked others and all told me that they had the same behaviour. I dont really understand why it got changed now, since a proper recalibration if you turn trackers on/off is almost necessary anyway. (meaning reloading the locomotion layer in this case)
That said, even if I include a reinitialize state (which i did right now, going to test that later) I am sort of worried how often you might change the trackingtype parameter and if it may cause jitter through reinitializing the layer itself. Any indication when and how often it changes?
Gireison
I just did test the new changes I made and fixed the issues of this controller. However: everything that changed from last patch to this one is, that for some reason the TrackingType Parameter jumps to two as mentioned in here already. When having FBT on and turning trackers off VRChat still stays at TrackingType 6 until I open the menu and that causes the avatar to reload - reinitializing the locomotion layer as well. Meaning the ability to shift "TrackingTypes" on the fly right now is purely to avoid the trackingtype = 2 flapping and has no other use as of now. Going from half body to full body (trackingtype 3 to 6) its the same. I have to manually press on calibrate to get trackingtype to change .
(If the comment sounds harsh or too direct, its only meant to put as much info in here as possible.)
Afromana
I have not been able to reproduce this on the beta, I have tried adding a state that transitions to "proxy_stand_still" on both the main locomotion layer, and a separate layer on the locomotion animator, both work as expected.
Have you configured your animator in some different way? Are anyone else experiencing this?
Asovrix
Afromana: I can confirm this behavior was happening on Sunday Community Meetup. I am using custom locomotion layer included in franada's Locomotion Master, which can be found in VRCPrefabs database, version 2.2.2.