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.

Currently, the VCC always creates Windows projects by default. When installing Unity, the VCC should install the modules required for Android and iOS. It would be nice if users could choose Android or iOS directly instead of switching to it after project creation.

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.

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

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.

VRC Light Volumes is a voxel based light probes replacement for VRChat. https://github.com/REDSIM/VRCLightVolumes Once it's introduced to avatar shaders, their appearance would be amazingly improve in appropriate worlds. Major shaders like lilToon and Poiyomi already support this system in the latest version. It would be great if Toon Standard also support this. Mobile users also can get benefits. Shader developers documentation: https://github.com/REDSIM/VRCLightVolumes/blob/main/Documentation/ForShaderDevelopers.md Japanese summary: Toon StandardでVRC Light Volumesをサポートしてほしいという要望。MobileプラットフォームでもVRC Light Volumesを利用できるようになる。

The avatar rating system could use some fine-tuning, as I've tested two copies of the same avatar in different sizes (one about 0.5m tall, another about 2m with long limbs) and while the small version rates as Medium, the alert for the expect avatar size bounding boxes being broken automatically pushes the large version into the Very Poor rating which makes no sense as its performance (the intent of the rating system) is going to be identical. The size alert shouldn't be bound to performance, instead if you're worried about super-mega-scale avatars being a nuisance, this should probably be its own safety toggle of something like "Hide avatars taller than X meters in height" in the game client.

I'd like to suggest changing how avatars that exceed the bounding box limit are ranked. Right now, they're automatically marked as "Very Poor," but I think they should be marked as "Medium" instead. Here's why: 1) Avatars that are "Very Poor" only because of the bounding box still show up, even when people have settings to hide "Very Poor" avatars. Changing them to "Medium" would make the filtering less confusing. 2) With avatar scaling now available, any avatar can be huge, making the bounding box limit feel outdated. 3) If the goal is to stop giant avatars from being fallbacks, marking them as "Medium" or "Poor" should be enough.

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.