SDK Bug & Feature Requests

〇 Environment OS: Windows 11 Pro 25H2 Build 26200.8457 Unity: 2022.3.22f1 VRCSDK: 3.10.3 〇 Summary When performing local world tests using Build & Test Your World or Test Your Last Build, launching multiple clients simultaneously may cause the second and subsequent clients to become stuck on a black screen. Launching clients with a delay between each instance can partially mitigate the issue. 〇 Steps to Reproduce Open the VRChat SDK in Unity. Run Build & Test Your World or Test Your Last Build. Launch multiple clients at the same time. The second and subsequent clients may remain stuck on a black screen and fail to proceed. 〇 Additional Reproduction Conditions Based on investigation, this issue appears to be indirectly related to log output. The issue occurs consistently under the following conditions: Disable debug log output for the client. Launch the first client. Launch the second and subsequent clients. The additional clients will consistently become stuck on a black screen. 〇 Possibly Related Issue A potentially related issue, also suspected to be caused by log output, was observed: When two clients are running in a local test and are in the same world, performing a rejoin from one client causes VRChat to crash. After this occurs, VRChat will continue to crash consistently when rejoining the same world, even when running only a single client. This issue can be resolved by deleting the log files in the following directory: %HOMEPATH%\AppData\LocalLow\VRChat\VRChat 〇 Suspected Cause It is likely that a deadlock or similar resource contention involving log files is occurring, causing clients to freeze or crash. 〇 Expected Behavior All clients should launch and enter the world normally when running multi-client local tests. Rejoining a world should not cause crashes regardless of log file state. 〇 Actual Behavior The second and subsequent clients may freeze on a black screen when launched simultaneously. Under certain conditions, rejoining a world causes VRChat to crash persistently until log files are deleted. 〇 Notes This issue significantly impacts local multi-client testing workflows and should be addressed with high priority.

ClearAvatarData is called, as expected, which should clear the blueprint id, however HandleAvatarSwitch doesn't return, so it continues further down and winds up calling _visibilityPopup.value = null. Since _visibilityPopup's formatter is selected => selected.Substring(0,1).ToUpper() + selected.Substring(1), this immediately throws an NPE and crashes the dialog until it's completely restarted. hasRemoteAvatarRecord should probably be false in the cases when ClearAvatarData is called, rather than remaining true for these invalid flows.

A object with the "VRC Pickup" script that has "Synchronize position" in "Udon_Behaviour" or "Synchronize Physics" in SDK2 "VRC_Object Sync" checked lags behind and jitter locally. A pickup object without these checked behaves as expected. Players that observe the synced object see no issues. Example clip: https://i.imgur.com/xrCmVUa.mp4

TLDR; if an AudioClip on avatar is set to "Decompress On Load" which doesn't have "Load In Background" enabled (Which at least from my experience is literally how Unity imports AudioClips) - the avatar goes through the build process just fine, but then gives out an error "Avatar Validation Failed". It's really just annoying and has no place making creators play a guessing game.

If you run "Build & Test" and the world build fails, the client/s still start. I don't think this makes much sense, because an old build is ran. This is confusing and if someone misses the build error they will proceed to waste time checking/testing an old build. There are other options for testing the last build and they use the wording of "last build" clearly, so this one shouldn't do that.

Issue A bug with the current SDK requires the GameObject which a VRC_Station is attached to, to be enabled on upload. As a result, stations are on by default if safety settings block user animations. This is BAD. Stations may be added by creators for special purposes, such as carrying other players, or animation-tied amusement. Having these on by default can create experiences where a player with stations receives UNWANTED interactions if animations are disabled. This is especially true for Quest/Mobile/Android, where animations are more likely to be disabled by default. This therefore poses a safety risk that is not mitigable by avatar creators. Potential Resolutions Add a "Disabled by Default" dropdown to the script with the options "Never"; "Always", which would disable the GameObject the VRC_Station is attached to on enable; and "Collider Only", which would disable only the provided box collider itself on enable. This would account of different creator preferences. — Whilst VRChat officially recommends disabling the collider only, the behavior of disabling the GameObject itself may be highly desirable in some case, and some popular station add-ons use this behavior. Giving developers the ability to choose between implementations allows for greater flexibility, and prevents breaking existing animations. Allow uploading with script disabled. — If the script can be disabled on upload, it won't matter anymore, as the station will be disabled when the avatar loads, making it opt-in via animation, not opt-out.

SDK Version: com.vrchat.worlds 3.10.3 When running EditMode tests in the Unity Test Runner, CheckHelpURLsForSystemNodes fails with: URL does not resolve for Const_SystemBooleanArray: https://docs.microsoft.com/en-us/dotnet/api/system.array?view=netframework-4.8 Expected: True But was: False Root cause: UdonGraphExtensions.cs has hardcoded docs.microsoft.com URLs for several Udon node entries. Microsoft migrated their docs to learn.microsoft.com in 2023, and the old domain now returns HTTP 301 redirects. The test ( GraphNodeTests.cs:30 ) uses UnityWebRequest.Head and checks Result.Success , which does not treat 301 as success → test fails. Note: Lines 192/194 of the same file are already updated to learn.microsoft.com , so this is an incomplete migration. Affected URLs (still using old domain): https://docs.microsoft.com/en-us/dotnet/api/system.array?view=netframework-4.8 (and several other entries in UdonGraphExtensions.cs) Fix: Update remaining docs.microsoft.com URLs to learn.microsoft.com in UdonGraphExtensions.cs .

SDK Version: 3.10.3 When a UdonSharpBehaviour contains an SDK-proxied event method (such as public void OnAudioFilterRead ) that isn't referenced externally elsewhere in the program, the UdonSharp compiler fails to export the symbol under the expected proxied event name. The entry point ends up exported as something like __0_OnAudioFilterRead (the internal/mangled name) instead of _onAudioFilterRead . This causes the entry-point check inside UdonBehaviour to fail, so the event proxy is never registered and the user's method silently never fires. Reference code path on the SDK side: if (_program.EntryPoints.HasExportedSymbol("_onAudioFilterRead")) { RegisterEventProxy<OnAudioFilterReadProxy>(); } Because HasExportedSymbol("_onAudioFilterRead") returns false, RegisterEventProxy<OnAudioFilterReadProxy>() is never called and the proxied event is never delivered. Steps to reproduce: Create a UdonSharpBehaviour with public void OnAudioFilterRead(float[] data, int channels) . Don't reference the method from any other script, UI event, or SendCustomEvent call. Enter Play mode with an audio source that should drive the filter. Observe that OnAudioFilterRead is never invoked. Inspect the compiled program's exported symbols — the entry point is __0_OnAudioFilterRead instead of _onAudioFilterRead . Note: OnAudioFilterRead is also not available in udongraph

Since VRChat added support for iOS (mobile), the VRChat clients have been generally copyedited from "Quest compatible" or "Android compatible" to "Mobile compatible". The text for SDK avatar dynamics robot samples hasn't been updated for this change yet, which seems unintended. Avatar Dynamics Robot Avatar PC Avatar Dynamics Robot Avatar Android Steps to reproduce: Open your avatar project and go to 'VRChat SDK > Samples.' Expected behavior: "Avatar Dynamics Robot Avatar Mobile" Actual behavior: "Avatar Dynamics Robot Avatar Android" Additional info: VRChat SDK - Avatars (3.10.3)

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