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.

The Content Manager tab in the SDK has "Make public" and "Copy ID" right next to each other. This is a footgun with plausible legal or contractual consequences of shooting one self in the foot, including plausible suspensions from VRChat. "It's too likely to accidentally make avatars public." Upload a private avatar. For this fictional example, you may be awarded additional thoughtful rewards if the avatar includes controversial topics, sensitive, intimate, or provocative material, or extreme horror or “shock” content permissible in private, or licensed content permitted on a private avatar but not to be made available to the public due to copyright. Go to the Content Manager tab. Find small "Make public" and "Copy ID" look-alike buttons next to each other. Get into the mindset of wanting to press "Copy ID", but not the "Make public" button. Optionally, press the "Make public" button and see an avatar being made public immediately without a prompt. Then rethink the consequences of the action you've just made - or pretend you didn't notice this action being taken for this example. The safety was off and the footgun may have been loaded. This is a rephrased duplicate of a Feature Requests board topic: https://feedback.vrchat.com/feature-requests/p/confirm-button-when-making-avatars-public-to-avoid-accidental-ban OP had accidentally shot themselves in the foot by pressing "Make public" instead of "Copy ID", which doesn't have a confirmation prompt when pressed and went unnoticed. OP was aclaimedly banned from VRChat for a week for this. In comparison, the "Delete" button has a confirmation prompt. The legal consequences of accidentally making an avatar public are common with BOOTH style avatars, which allow avatars to be uploaded with Private status only. An avatar set to Public status would often be a license violation and may be subject to a DMCA takedown notice. The contractual consequences of accidentally making an avatar public may result in conflict with VRChat's Creator Guidelines and subsequent suspensions, if the avatar content intended for private but accidentally made public has controversial topics, sensitive, intimate, or provocative material, or extreme horror or “shock” content, which is not permissible for public content. According to avtrDB 's reported statistics, there are 1,567,380 public searchable avatars, and 4,003,344 private avatars (avatars that have never been made public). The number of private avatars seems to significantly outweigh the number of avatars intended for the public. It's often plausible to copy an existing avatar ID from the Pipeline Manager component attached to the avatar root gameobject, but there are cases where that may not be plausible, requiring a click of Copy ID or a visit to the VRChat Home website to acquire an existing avatar ID. When using the VRChat Home website, the avatar ID is in the URL and nowhere near the "Make Avatar Public" button. In the Content Manager, these buttons are close to each other. For reasons stated before, I think this UI/UX design is unintended or anti-UX and should be considered an UI/UX bug. Expected behavior: Larger buttons, prompts to confirm to make public, change the colors of the buttons, or simply don't place these buttons close to each other or on this Content Manager tab. Anything to remove the footgun, the anti-UX, and the severe consequences of accidentally and potentially shooting yourself in the foot. Actual behavior: "Make public" is a small button that can be misclicked (especially in SteamVR with a laser pointer from controllers) and doesn't have a prompt, with plausible legal consequences or unintended violations of Creator Guidelines, when an intent may have been to "Copy ID" instead. SDK 3.10.3 Reported-by: Ƙiri

it seems when a recursive loop is made, the SDK doesn't seem to know how to handle it, resulting in the --enable-udon-debug-logging error message being thrown when the flag is there. This was causing a lot of confusing when trying to debug, suggestion to add a unique error exception for when this happens, if able.

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.

After testing, different of standard unity editor behavior where turning off auto graphics API for linux lets you reorder the graphics APIS and make unity try to first load with vulkan, VRC SDK on editor unload re-enables Auto Graphics API for linux, meaning that on the next project startup it will launch on OpenGLCore which is a broke renderer, and much slower, and since it is a different renderer this also triggers the assets to be rebuilt making the startup time infuriately long. This behavior is different of standard unity editor behavior that maintains the selected option across many restarts of the editor, this behavior only happens when VRC SDK is installed on the project. Tested with an empty VRC Avatar project to confirm it is in fact VRC SDK causing this behavior. Attached are 2 images, showing how OpenGL is rendering in a completely broken manner, while vulkan renders normally. Hardware & Software Specs: Operating System: CachyOS Linux KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0 Kernel Version: 7.0.3-1-cachyos (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 4600G with Radeon Graphics Memory: 32 GiB of RAM (27.3 GiB usable) Graphics Processor 1: AMD Radeon RX 7700 XT Graphics Processor 2: AMD Radeon Graphics Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C96 System Version: 1.0 Unity 2022.3.22f1 Available Graphics APIS: Vulkan OpenGLCore Tested on an empty project created with Unity Hub (shows correct behavior) And on a VRChat Avatar project created with ALCOM (shows wrong behavior [keeps resetting to OpenGL on editor exit]) Created from: https://help.vrchat.com/hc/en-us/requests/692576

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.

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