Execution order of constraints and physbones incorrect on the local client after recent patches
tracked
Rycia
I made a post about this in the VRChat Discord server here, I'll just reencite my issue from there.
I'm having a very weird issue, this is 100% a bug. It has slight physics so it's definitely on the right object and not disabled, and it doesn't move correctly, The torso is kinda shaky and buggy, It's not world specific.
If the object has physics at all, it should have the overlay for it. It do9esn't even show on the overlay.
I have taken some of the suggestions and done more testing. It is important to note that I have not updated the avatar for a few days, and there might of been a recent patch within the last couple days. It worked prior to this patch. It also works fine in editor. Here's a .gif screencap of that.
This uses Gesture Manager, without locomotion, and the physics here work fine. The Physbones and the anchor points go to an object that are seperate, so that shouldn't be the issue. I also set all the bones to be Simple to help jitter, but that wasn't an issue to begin with. I have also removed all the toggles with just the constraints and with the physbones, and even just the physbones. It works fine with just the physbones. My SDK is entirely up to date.
Even the in-game overlay shows physbones entirely incorrectly, and to a degree, the physics are still getting applied to the bones as shown within the first .gif recording.
I need this issue fixed pretty immediately because its inhibiting my work on something I plan to release as a product. Thank you!
I can provide more information if needed.
Edit: Done some testing with a few friends. It pinpoints to being a problem only locally with execution order of vrc constraints coming after physbones, when it should be physbones before constraints. When users clone my avatar, they have the issue, but from my side it looks fine, and I look fine to them.
You can test this with two people using this avatar, and you'll see the local-global difference. https://vrchat.com/home/avatar/avtr_a74070b2-cad9-4ffd-9356-3630b0634d34
Log In
Rycia
I have since identified the issue further, though its still a bug. I temporarily added an Avatar Descriptor nested in an avatar at one point for use with some editor tools (Pumpkin's Avatar Tools) on only a specific part of the avatar to translate some (not all) physbones. In the process, a second Pipeline Manager was generated, and when I deleted the descriptor, I never got rid of the auto-generated pipeline manager. It took a while to identify it. The avatar was then eventually uploaded with this accidentally nested Pipeline Manager component. It's weird that something like this would be allowed through an upload, actually successfully upload, let alone cause weird issues pertaining to execution order of other components.. even though on a surface level, all the pipeline manager does is identify the ID of an avatar when uploading to VRC's servers. Given it causes these isues, and if it is tied into how execution order works within VRChat, I would say the best fix would be to disallow uploading avatars with more than one Pipeline Manager component henceforth from the SDK in a later SDK update, and have an auto-fix for removing the lowest nested Pipeline Manager component until the root one is left and/or is only located by the Avatar Descriptor component at the avatars root. It's a weird issue users of certain third-party Unity editor tools may encounter, so that would be a great safeguard for the future of the VRC SDK. It may even be worth it to look into combining the VRC Avatar Descriptor component with the Pipeline Manager component for ease, because knowing issues can occur, the Pipeline Manager component should really always be beside/with the Avatar Descriptor component in order to not cause issues by user-error.
StormRel
marked this post as
tracked