SDK Bug & Feature Requests

I developed a prefab that uses finalIK raycasts, but switched to VRC Raycasts for convenience's sake People started reporting that the prefab was triggering when it shouldn't, so I looked into it My raycasts are set up to snap to end and disable the object when the raycast doesn't connect, and in-editor it does, but in-game it doesn't. The two contacts floating out is where the prefab is always supposed to reset to, but as you can see in the second image, if I walk through one of the raycasts it gets stuck. Also they are not disabled The objects being controlled by the raycast aren't parented to the raycast if that's relevant

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.

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

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.

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

The UdonBehaviour[] (Array) variable cannot be resolved and used in UdonGraph.