SDK Bug & Feature Requests

OS: Arch Linux (but any Linux would get the same results) Unity 2022.3.22f1 Unity project managed by ALCOM (a cross platform open-source alternative to VCC) VRChat SDK version is 3.8.2 Summary Setting Build Type to Build & Test Your Avatar in the VRC SDK window, then clicking Build & Test does not place the new avatar inside %LocalAppdata%Low\VRChat\VRChat\Avatars (as per documentation ), and it is thus impossible to locally test avatars. Why This happens because that directory does NOT exist on Linux; the virtual C: drive created for VRChat by Steam is inside its specific proton prefix, and as such the right path is more likely to be located near /path/to/SteamLibrary/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/Avatars/ . This path is not right for every VRChat installation, because Steam allows for multiple game drives. Solutions I see two potential solutions; one of them requires fewer changes and is less practical for users : After building an avatar for testing, if the environment is Linux, provide users the path to the compiled avatar asset so that they can move it over to the right folder manually If the environment is Linux, inside the VRC SDK window, in the settings tab, add possibility to set the path to either the root of the virtual C: drive, or just to the folder where the user wants to export their testing avatars Please, please do ask more info if you need it, I will happily provide them, and I'd be happy to see this bug fixed I have found the location, it is inside .local/share/VRChat/VRChat/Avatars/, I have not seen that documented anywhere, maybe updating the docs would be nice... ~~Also if you just give me the path to the compiled avatar I'd be happy, I really wanted to test it out so...~~ Also, I would gladly fix it myself if the sdk was open source... is that planned ? Is it forbidden, in the meantime, to go and decompile and fix stuff for myself ? What about publishing fixed dlls ?

SDK fully functional, but the alerts tab is completely empty, no info, no alerts visible. No change after reinstalling the SDK, restarting, switching versions... I'm forced to make a new project to acquire avatar info and alerts again. I've heard there was a similar bug about embedding the control panel into the Unity UI and opening another project that uses the SDK, both of which I've done and may be the cause for it. ( https://feedback.vrchat.com/sdk-bug-reports/p/376-alerts-section-stops-updating-if-you-put-the-vrcsdk-into-a-tabbed-panel-and )

For some reason when focusing on the SDK window, it will animate/override a material on my avatar, specifically the emission 0 strength. Doesn't happen on SDK 3.8.1 or lower!

I'm going to copy the post I made in Poyiomis discord because I saw another person having the same issue I'm having with a completly different shader. This is making me question if this is an SDK issue maybe? Info - Latest Poiyomi Pro release 9.3.49, Unity 2023.3.22f1, SDK 3.8.2 When I upload to VRC or emulate in unity the discard checkboxes instantly defaults to OFF. It only happens when I have them in an animation clip (If I completely remove the FX and don't animate the properties the values stay). It also ONLY happens on 1 of my materials on 1 of my meshes. When the discard animation plays, it discards correctly on the keyframes but as soon as the animation is done, it defaults back to OFF. The animations that controls the discard checkboxes also contains other keyframes for discards on other meshes and all of those work fine. It's only this specific material on this mesh. What I've tried to fix it: I've changed the location of the UV tiles in blender (I moved them from row 0 to row 1) I've re-made the animations and layers in the FX (multiple times) I've 100% made sure that they don't get overwritten by any other animation I've re-made the material 2-3 times I've tried Write defaults on/off I let Chatgpt check my FX controller for any state machines being referenced/pointed to more than once (duplicate layers issue) I've downgraded the SDK to 3.8.1, 3.8.0, 3.7.6 - issue persists Tried with renamed discard parameters (RA) and without (A) I've looked through the locked in shader code and couldn't find anything obvious relating to it being a shader issue. Downgraded to 9.10 (pro) -> problems was COMPLETLY GONE. This lead me to think it is shader related but seeing as I saw someone have the same issue on another shader, I'm not sure anymore. The fact that it works on everything except 1 mesh also makes me more lenient towards this actually being an SDK issue. Especially with the other animated property issues that I've seen in the latest SDK. UPDATE: I just found a fix for this after days of slamming my head against a wall. I had 2 materials on this mesh. 1 material for 1 part of the mesh and another for another part of the mesh. The part I had issues with was called "bodysuit", the other part "hair". Bodysuit was in material slot 1 and hair in material slot 0. I swapped them in blender and re-exported. Now I have Bodysuit in material slot 0 and hair in slot 1. Now my discards work without any issue at all???? I have no idea if this is a unity bug, VRC-SDK bug, poyiomi bug or whatever it is but this seemed to fix it. Luckily I don't discard anything on hair on this particular mesh, cause I'm not sure if that discard works now.

AvatarDescriptorEditor3.UpdateAutoColliders and MirrorCollider should be called in a really early preprocessor hook. Without this, the collider transforms can be randomly set improperly, or randomly set to null if an fbx rig update has changed the finger bones, and the user has not opened the avatar descriptor Colliders foldout since the change. This is because UpdateAutoColliders is only called in the AvatarDescriptorEditor3 collider foldout render code. Otherwise, the collider transforms are NEVER updated. Doing this by default in the vrcsdk in a very, very early preprocessor hook would resolve these issues, and still allow vrcf/ndmf "collider tricks" to function, since they change the transforms later in the build. For now, we've started calling this method using reflection in vrcfury at preprocessor hook order int.MinValue. This is pretty bad, since currently calling UpdateAutoColliders requires making an instance of AvatarDescriptorEditor3, which is an Object. PS: MirrorCollider is also broken if the avatar's origin isn't at x=0. That should also be fixed. We're currently also fixing this in vrcf using reflection.

Summary: The VRChat SDK is causing Unity to falsely detect prefab overrides when no actual changes have been made. This issue occurs both during general SDK activity (not just when opening the SDK tab) and specifically when uploading or updating avatars. It often flags the Avatar Descriptor component as "changed," even when untouched. Steps to Reproduce: Open a Unity project with VRChat SDK (SDK3 - Avatars). Create or load a prefab-based avatar. Upload or re-upload the avatar via the SDK. After upload completes, observe that the avatar prefab now shows "Unapplied Overrides" in the inspector. Open the prefab and inspect the VRC_AvatarDescriptor — Unity claims it's been modified, even though no changes were made. Expected Behavior: Uploading or interacting with the SDK should not trigger false prefab overrides when no values were changed. Avatar Descriptor and other components should remain untouched unless explicitly edited. Actual Behavior: Prefab instances are flagged with "Unapplied Overrides" after uploading or interacting with the SDK. The VRC_AvatarDescriptor component is frequently shown as modified, despite no visible differences. These overrides appear without user input, leading to confusion and unnecessary prefab management. Known Triggers: Uploading or re-uploading avatars. SDK interactions during project use (not limited to opening the SDK tab). SDK updates that introduce new systems like (often re-introduce the bug): PhysBones, Constraints, Per-platform Avatar Overrides Impact: Disrupts normal Unity workflow and prefab integrity. Forces creators to manually check or apply overrides to maintain consistency. (Sometimes not even working and getting stuck in an override change loop) Risk of unintentionally applying unwanted changes or overwriting important prefab data. Time-consuming and frustrating for creators managing large or complex prefabs. Additional Notes: This issue has persisted across multiple SDK updates and is easily reproducible. It appears tied to how the SDK modifies or refreshes component data internally. Given how fundamental prefabs are to Unity projects, this issue should be considered a high-priority bug — especially for avatar creators relying on clean and reliable prefab behavior.

SDK versions tested: 3.8.2-beta.1, 3.8.2, 3.9.0_beta.1 Unity version: 2022.3.22f1 Discovered while working on an avatar. If an object in the avatar hierarchy is disabled, and I click to enable it, a moment later it will disable itself again. If it is enabled, and I click to disable it, it will enable itself within a few seconds. If I duplicate the object and toggle it, it will not be affected. If I duplicate the object, delete the original, and rename the duplicated object to the name of the original object, the bug returns. There is no output in the console to indicate anything is happening. Avatars running in gesture manager emulator behave as expected, as do animations played in the editor. At first I thought another script or package may be the culprit (I initially thought it might be VRCFury). I removed all scripts and packages except the VRC SDK from the project and the issue remained. I narrowed it down to the VRC SDK once I downgraded to 3.8.1 and the issue was resolved. Updating to any newer version reintroduced the bug, and downgrading back to 3.8.1 consistently resolves the issue. Sometimes, removing and reinstalling other packages appears to fix the problem, but it always returns. Only downgrading the VRC SDK to 3.8.1 resolves the problem in a way that persists through a restart of Unity.

When a humanoid collider (Head, Torso, Hand, Foot, Finger) is set to Disabled, it retains it's previous values and the transform value is still updated (not set to null, due to https://feedback.vrchat.com/sdk-bug-reports/p/custom-humanoid-collider-transforms-overridden ), in-game this results the collider still being set, even though it was "Disabled". This results broken "automatic" colliders ( https://feedback.vrchat.com/sdk-bug-reports/p/humanoid-colliders-may-divide-by-zero ) to still exist in-game.

The Harmony package, used by Udon Sharp, and a handful of third-party community plugins for runtime patching in the editor, has been updated to officially support ARM64 on all platforms (Windows, Linux, and yes, Mac). This will correct any in-editor issues when running the Unity Editor on these platforms. Whilst VRChat itself may only support PC & Android, the Unity Editor is a cross-platform utility, and there are a variety of folks with ARM-equipped machines who use such hardware for primary development, and therefor experience issues with the editor without patching. With the advent of full iOS support on the horizon, this may further increase the # of Mac-based content creators. Please update the provided package. Release notes for version where ARM64 support was added Addendum An experimental VPM package can be found at MisutaaAsriel/VRCHarmony which installs a packaged release of Harmony 2.4.1. Unity appears to, in all testing, prefer the package's copy of Harmony over the version included by the VRC Base SDK. This package may also be installed using the following VPM repository: Dreemurrs-Repository VRChat may use the DLL provided from this repository if need be, or take over the package if they so wish. — It is currently built off of the Release target of Harmony, at the solution level, with .NET Framework 4.5.2 using GitHub Actions Note Building Lib.Harmony against the DebugFat target at the project level, or building it for Release against net452 at the solution level creates a successful drop in replacement. The release builds when built at the .NET project level or downloaded from the main Harmony repository currently output a mangled DLL that Unity Burst is incompatible with. A bug report is open on this here: pardeike/Harmony/issues/728 For further reference, the original copy of Harmony is built against .NET 4.5.0, which is no longer a valid target. 4.5.2 was chosen as its nearest replacement. Edited @ EPOCH 1757603286

After a successful build, adding a network-related component to a GameObject with another network-related component causes an error relating to network IDs when the next build. Repro steps Create a new scene and put the VRCSceneDescriptor Add a network-related component to a GameObject Build the world Add another network-related component to the GameObject in step 2 Build the world You'll see the dialog (see the 1st attached image) Preprocess Callback Failed The VRCSDK build was aborted because the IVRCSDKPreprocessSceneCallback 'AssignSceneNetworkIDs' reported a failure. The network-related components here are VRCObjectSync , VRCPickup , UdonBehavior etc. That needs a network ID. VRCPlayerObject of the ongoing Persistence open beta also causes this issue. Note 1 The console shows the errors after closing the dialog (2nd attached image) Failed to assign network IDs, 1 errors encountered! Try using the Network ID Utility to resolve them. Note 2 If you press the "Build & Reload" button on step 5, you'll see the "Build Succeeded!" message in the SDK tab. But the build has not succeeded. NetworkIDs in VRCSceneDescriptor has not been appropriately updated (in particular, the Serialized Type Names of the GameObject). This (showing false "succeeded") seems to be another defect. Note 3 If you press "Build and Upload", you'll see the "This file was already uploaded" error popup. And the SDK also shows "This file was already uploaded" as details. This message is incorrect since the building file is incomplete. This also seems to be another defect. Version Worlds 3.7.2