[1482] VRC Parent Constraint doesn't syncronize state in mirror
complete
lackofbindings
- Turn on mirror
- Do action that animates constraint sources weight
- See that everything works normally.
- Turn mirror back off
- Do same action that animates sources weight
- Turn mirror back on while in that state
- See that constraint on the mirror clone retains the same state it had before the mirror was turned on.
Expected behavior: The state of the mirror clone should line up with the state of the real avatar.
Here is an avatar ID that exhibits this behavior: avtr_f668428d-1f87-40af-a634-633551cfda36 This is an avatar that has been upgraded from regular constraints via SDK3.6.2-constraints.3. The non-upgraded version of the avatar behaves normally on live. The parent constraint is on the baton, grab the baton with your right hand to test.
Log In
StormRel
updated the status to
complete
Dexvoid
updated the status to
available in future release
Dexvoid
updated the status to
tracked
Dexvoid
updated the status to
needs more information
Dexvoid
By my understanding, this has been an issue ever since constraints were whitelisted to be used on avatars. It pre-dates VRChat constraints and is an inherited problem.
The non-converted avatar avtr_c32b6dbf-e8f8-46a4-a338-4828d68e307e appears to exhibit this same issue in live. As you've claimed that it works correctly on live, can you please confirm? Make sure that there are no mirrors active at all when testing, including your personal and face mirrors.
Photo Viewer
View photos in a modal
lackofbindings
Dexvoid Ah I apologize, upon further testing it appears you are correct. My actual issue was caused by the game allowing animators to run before parameters are set. I was able to work around the issue by adding
TrackingType > 2
to all of my transitions.Dexvoid
lackofbindings: Many thanks. This issue will remain tracked, but it will be lower on the list of priorities since it's a pre existing issue rather than one specifically introduced by VRChat constraints.
lackofbindings
Noticed that this also happens if the avatar is auto-upgraded by the client. The SDK 3.6.1 version of this avatar also exhibits this behavior when viewed on the beta avtr_c32b6dbf-e8f8-46a4-a338-4828d68e307e It behaves as expected when viewed on live.
StormRel
updated the status to
tracked