SDK Bug & Feature Requests

SDK version 3.10.3 The explanation states that if you set the Playback order in the Play Audio Behaviour component to Parameter, depending on the number of the int, it will play said audioclip. no matter which element number or parameter int number, no audio gets played. When I check the Audio Source afterwards it should have played something, the "AudioClip Field" is completely empty, even though there is a registered audioclip in the Behaviour component. If I add more clips to it and change the parameter int to any number that corresponds to the clip number, still nothing gets played.

When physbone rotations are limited, the effects of physics settings such as gravity, as well as pulling on the physbone, will cause the "locked out" rotation to travel up the chain, for example: Making a vertical line of 3 bones and limiting the rotation to 10 degrees, then grabbing the bone at the bottom and moving it beyond 10 degrees will cause the parent to then rotate to follow it (since they're linked together) However this same behavior does not extend to collisions, pushing the bone described above with a collider will only cause it to move and lock out at 10 degrees, and won't travel up the chain to push the parent, I see this as a bug as the behavior differs depending on interaction method. Please allow the forces induced by colliders to travel up the chain (note that some physbones may have depended on the old behavior, so a physbone version bump i.e. 1.2 might be necessary). This currently makes setups like the ones in the attached images only function for grabbing, not collision (hinge rotation on root bone affects the glasses, collision radius set to 0.015 but reduced to 0 on the root bone via curve, dummy bone set to to overlap the glasses frame with collision, to provide a wider point of contact than what would be possible otherwise, hinge rotation set to 0 on the dummy bones, immediately locking out their rotation, which should cause any force induced on them to travel up the chain).

SDK Version (Base and Avatars) 3.10.3 When pressing 'Auto-Fix to re-parent in the VRChat SDK Builder, the pop up gets stuck on VRCSdkControlPanel.MouseUp. Attempted twice, both times it loaded for over an hour and didn't fix the issue. Had to force close unity and re-open the project.

1) Create new project 2) Load up your asset(s) and modify the avatar 3) Go to SDK and login 4) Once logged in, Builder tab is completely locked out 5) Go to other tab (Authentication etc.) 6) Go back to builder tab -> all options are now unlocked And by locked out, I mean all options are greyed out. I do have faint memory of this happening as well when I come back to the project after closing Unity and wanting to update the avatar, but I am not entirely sure. OS: Win 11 Pro (latest at the time of writing) SDK: 3.10.3

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 ?

With SDK version 3.7.5 several settings were migrated from the static class VRCSettings , existing within the VRCSDKBase-Editor.dll library provided alongside the SDK to VRCPackageSettings , the change also included a refactor of the class, introducing a static property Instance , used to get or create an instance of the class, an instance is attempted to be created by the PerceptualPostProcessor as DPID settings were part of the migration, however this fails because of a null exception: VRCPackageSettings.Instance.dpidMipmaps within PerceptualPostProcessor executes VRCPackageSettings.Instance_get VRCPackageSettings._instance is null so Create() is called, which calls Load() Load() and calls within it, including EnsurePathExists() expect GetPath() to not be null, causing a null exception when it is because GetPath() calls GetPathFromType(GetType()) which calls UnityEditor.PackageManager.PackageInfo.FindForAssembly(t.Assembly) and returns null when executed by a worker process, GetPathFromType then returns null (a comment assumes this would only occur when the SDK is not located within the Packages folder) but this execution path was seemingly never tested and so methods that expect valid strings such as Directory.CreateDirectory within EnsurePathExists() throw null exceptions. Simply resolving the null exceptions is not enough as the current implementation would cause Load() to not load any data when it's meant to, leading to VRCPackageSettings.Instance to contain default values when executed by worker processes ( AssetDatabase.IsAssetImportWorkerProcess() ), you cannot simply abort execution because that invalidates the use of Parallel Import and would cause textures marked as "dirty" to not actually be updated to have mipmaps re-generated, a proper solution leading to the same settings file must be implemented, the whole dependency on the assembly's package info seems extreme. This can be easily reproduced on any 3.7.5+ project with Parallel Import enabled (Project Settings -> Editor, mine is configured with 8 desired workers and 2 on standby) by enabling/disabling "Override Kaiser mipmapping" in the SDK settings.

The error "You must provide a path to the thumbnail image when creating a new avatar" which is intended for new avatar uploads blocks updates to existing blueprints if the build is started before the thumbnail is (down)loaded. Repro: Have an existing avatar project, with the SDK panel hidden (closed or docked but tabbed away) Open a new session of Unity for the project (thumbnail not cached) Open/switch to the SDK panel and immediately hit "Build" In theory between 2 and 3 you'd have made changes to the avatar and then decided to upload, which is exactly when I encountered this, after thorough testing in Unity I decided to upload to test in VR, but it was the first time I tabbed into the SDK this session. Likely affects most/all SDK versions with the newer build panel. Update (Jan 19 2026): This also happens on new uploads somehow, if an existing upload's data was loaded (avatar object A) but then the list is refreshed (A is disabled or removed, but now B exists and is selected), if you're fast enough you'll be able to hit upload, this happened to me because I assumed I had already copied the blueprint ID but I forgot, the upload failed after the build executed.

The Resolver class within the package initializes on load and checks whether a window should be opened, this code executes on Unity's worker processes as well and due to a Unity bug calling ShowWindow causes it to open uninteractable white windows on the worker processes. This can be resolved by aborting execution when AssetDatabase.IsAssetImportWorkerProcess() returns true .

The Creator Companion 2.5.0 update introduces multiple new keys, including onboardingCompleted and enabledRepos , these new keys are missing from the current Package Resolver Tool release (0.1.29) and no "beta" has been made available. The Resolver class provided within the same package executes several methods that lead to Settings.Load() and internal calls to Settings.SanitizeUserRepos() (which performs Settings.Save() within Settings.Load() ) Additionally, while not exactly documented and not part of the "public API" (and thus could be broken at any time), the package contains full functionality to add/remove repositories from VCC, as well as add/remove packages, when said functionality is utilized, Settings.Load() and Settings.Save() may be used as well. This results the settings.json file being written with an older version of the data structure, removing the newer keys from the file. Updating the package will address the data structure mismatch for now, but this issue will come up again with future updates to the data structure, and projects using older packages will persistently be an issue (more-so than VCC being downgraded, which would cause similar issues). There are several ways to tackle this this: Split the newer properties to a separate class/file Downside: Same issue arises if either file contains new properties in the future. Migrate to a file-name versioned "settings.json" i.e. "settings-v2.json" Downside: Older packages may reference outdated data within older-versioned files (i.e. repositories list may no longer match) Use one of various ways to preserve keys that aren't present in the "current" data structure. Downside: Does not address older package versions that do not contain this functionality, so this may need to be combined with #2. Also posted on GitHub with additional context and reproduction steps https://github.com/vrchat-community/creator-companion/issues/598

When Reload Scene is enabled, and you have an udonbehaviour on an editoronly object: ClientSimRuntimeLoader.OnBeforeSceneLoad -> StartClientSim -> DestroyEditorOnly fails to do anything because the scene has not yet been loaded, so scene.GetRootGameObjects returns nothing. ClientSimRuntimeLoader.OnAfterSceneLoad works as expected. The VRCSDK then continues happily When Reload Scene is disabled, and you have an udonbehaviour on an editoronly object: ClientSimRuntimeLoader.OnBeforeSceneLoad -> StartClientSim -> DestroyEditorOnly works because the scene is already loaded. The EditorOnly objects are destroyed. Then, it calls into ClientSimNetworkingUtilities.ConfigureNetworkIdsForClientSim, which tries to lookup the udonbehaviour, it doesn't exist, and an InvalidObject error fails out play mode. DestroyEditorOnly should just be removed from StartClientSim since it never does anything in the "working" case anyways.