SDK Bug & Feature Requests

The world SDK always tries to clone whole contents in UdonSharp/UtilityScripts folder into Asset folder and forcibility overrides them even if exists. It's really annoying because it makes unnecessary changes for git commit and unable to remove sample scripts. Please remove auto sample cloning after first project creation. Steps to reproduction: Create a World SDK project. Open the project with Unity. After script compile, try to remove Assets/UdonSharp/UtilityScripts Expected results: You can remove its folder and should not be cloned again. Actual results: Its folder is cloned after removal and reload the project.

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.

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.

Rather occasionally, the SDK will "brick" itself, spitting out the attached error. Reloading the SDK immediately remedies this problem. I am unsure on what is required to reproduce it, but it is common enough to be problematic on multiple avatar projects with varying configurations.

I am the creator of gimmicks etc. for VR Chat When operated from the expression menu in SDK 3.9.0, the animation that changes the object's Transform does not work (such as changing Scale from 0 to 1). If it's SDK 3.8.2, it works fine, but if you update to 3.9.0, it won't work. These events occur even after uploading to VR Chat on Unity. Changes such as material changes and shape key operations move. Also, when each animation is played back in the Animation window in the editor, it is displayed without problems. The data is managed using VRChat Creator Companion. Also, when I had someone else test it, the animation worked without problems even in the SKD 3.9.0 environment. Even when they both created new projects and installed packages had exactly the same configuration, I was the only one who encountered the bug, and the other person had no problems. It seems that the probability of occurrence is rare even when searching the internet, but I'm in trouble because I don't know what kind of difference it occurs.

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

SDK Version: 3.9.0 When a Player Data value like a string is set to Null, the ClientSim PlayerData UI will run into a NullReferenceException. Udon and the rest of the ClientSim continues to function as expected. Example script: public class Test : UdonSharpBehaviour { public override void Interact() { PlayerData.SetString("test", null); } } Log after opening the ClientSim PlayerData UI: NullReferenceException: Object reference not set to an instance of an object VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.<UpdatePlayerDataList>g__Truncate|42_3 (System.Boolean isMultiline, System.String value) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:767) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.UpdatePlayerDataList (System.Collections.Generic.Dictionary`2[TKey,TValue] playerData, VRC.SDKBase.VRCPlayerApi player, System.Boolean redraw) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:558) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.LoadPlayerData (VRC.SDKBase.VRCPlayerApi player, System.Boolean broadcastPlayerDataUpdated) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:336) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.RefreshPlayerData () (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:856) UnityEngine.UIElements.Clickable.Invoke (UnityEngine.UIElements.EventBase evt) (at <332857d8803a4878904bcf8f9581ec33>:0) [...]

I consider this a minor visual bug. In the SDK, the message box doesn't dynamically update it's height anymore when more than a certain number of characters. The "32000" just clip down.

As the title suggests, when using a particle system on an avatar, attempting to upload it when the particle material uses Alpha Blended results in the SDK refusing to upload, indicating it is an "unsupported" shader. Then tells us to use shaders from VRChat/Mobile …which is where this very shader is from. This is objectively bad. Either move the AlphaBlended shader out of VRChat/Mobile (E.G. VRChat/PC ), or whitelist AlphaBlended on Quest when used with a particle system. SDK version 3.8.2 Similar feedback: https://feedback.vrchat.com/sdk-bug-reports/p/some-vrchatmobile-shaders-are-labelled-as-non-compatible https://feedback.vrchat.com/sdk-bug-reports/p/cant-upload-to-quest-with-vrchatmobile-shader https://feedback.vrchat.com/avatar-30/p/unhelpful-error-message-about-alpha-blended-shader-not-supported-on-android Notes Fax says that transparency is not supported on Quest, hence its refusal to upload, but this is actually not true. Transparency is not supported on mesh renderers only. Particle systems do support transparency.

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 ?