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.

Attampting to upload avatar without adding tags is bugged. It gives an error stating: "tags must be an array: null, tags must be a string: 'null'" The error wont be given if you add atleast 1 tag. Running VRChat SDK - Base and VRChat SDK - Avatars at version 3.10.4

Some visual elements in the new sdk are left aligned and others are centered. Other items are fixed width and others stretch to fill the space. The SDK should be more consistent with various sizes.

Create an Excellent avatar (Robot). Add 3 particle systems, each with 2147483647 max particles and 2147483647 max lights using one shared point light prefab. Add 3 point lights. Check the SDK builder for alerts to review. Expected result: Show a Very Poor performance alert in the SDK builder about 2147483647 lights. Actual result: No alert, the lights counter has overflowed into negative integers (-2147483648 lights), "Excellent". Additional info: No effect on the avatar's stats itself if the avatar is published to VRChat. Having only 2 point lights reports 2147483647 lights in the SDK (screenshot 2), as intended.

Something that takes a lot of time when publishing avatar bases for my customers is going through every variant (pc, quest etc.) and ensuring that the pipeline manager is cleared before exporting the unitypackage. Is it possible somehow to restructure the pipeline manager so that the id is saved in the editor or something instead of in the scene/prefab. I feel like this could also greatly help with confusion around the pipeline ID since it really should be in the SDK UI instead of having to go back and forth between the SDK and the object to change an avatar ID.

The SDK occasionally gives errors advising the user that they do not have humanoid bones mapped, when in fact they are mapped in the humanoid bone selection menu. The fix should be to check the humanoid, and not the hierarchy.

NotImplementedException on "Copy Udon Name" ## Overview When using the VRChat SDK, right-clicking a class in the Class Exposure Tree and selecting Copy Udon name triggers a NotImplementedException . This occurs because the method responsible for computing and returning the Udon name is not yet implemented. ## Environment VRChat SDK Version: 3.8 (World and Base) ## Relevant File UdonTypeExposureTree.cs ## Key Methods Involved ** UdonTypeExposureTreeView.GetMemberUdonName ** Supposed to compute and retrieve the Udon name, but is currently unimplemented. ** UdonTypeExposureTreeView.OnClickCopyUdonName ** Handles the "Copy Udon name" context menu action. ## Steps to Reproduce Open Unity Editor: Launch the Unity Editor with VRChat SDK version 3.8 (World and Base) installed. Access the Menu: Navigate to VRChat SDK > Udon Sharp > Class Exposure Tree . Load the Window: Allow the Class Exposure Tree window to load completely. Select a Class: Click to select any class from the list. Right-Click Action: Right-click the selected class to open the context menu. Copy Udon Name: Choose the Copy Udon name option from the context menu. Error Occurrence: The Unity Editor displays a NotImplementedException error message, indicating that the feature is not fully implemented. ## Proposed Implementation I created a custom implementation to address this issue. You can review my implementation here .

While normal map textures still show the preview as the normal lavender-ish color for normal maps, but the it seems like the generated mipmap levels are light-red, as visible in the lower project window texture preview icon. (screenshot attached) This causes everything in my world that uses a normal map to be excessively shiny/reflective, and lights bleed through walls and floors. As a workaround, I can individually switch all my normal map textures to Box instead of "Kaiser", but then the world upload linter then warns about these and pressures me to let it switch them back to (the broken) "Kaiser". I have had to disable DPID for my world for the time being.

Properties like TMP_Text.fontMaterial cannot be accessed if the object reference type is TextMeshPro even though it inherits from TMP_Text. You end up having to cast back to the TMP_Text type to use the property: var fontRenderer1 = renderer.GetComponent<TextMeshPro>(); f(fontRenderer1 != null) fontRenderer1.fontMaterial = ...; // Throws not exposed in Udon error. var fontRenderer2 = renderer.GetComponent<TMP_Text>(); // Can throw an error if there is no TextMeshPro component on the object if(fontRenderer2 != null) fontRenderer2.fontMaterial = ...; // Accessible in Udon var fontRenderer3 = (TMP_Text)renderer.GetComponent<TextMeshPro>(); f(fontRenderer3 != null) fontRenderer3.fontMaterial = ...; // Accessible in Udon

When creating a tween with VRCTweenHandle.SetSpeedBased() , there is no way to call VRCTweenHandle.ChangeEndValue() and have the tween refresh its duration. This is due to the fact that internally dotween doesn't call Tween.DOStartupDurationBased() within Tween.DoChangeEndValue() unless a duration is specified - because VRCTween doesn't provide a duration, it calls it with -1, which means that it never calls the duration update. Additionally, because VRCTweenHandle.SetDuration() sets the duration directly via reflection, there is no chance for it to recalculate the tween, and VRCTweenHandle.SetSpeedBased() - and thus TweenSettingsExtensions.SetSpeedBased() - this only sets it so other hooks update their values, which means that the value is never propagated. This renders speed-based tween values useless for continuous motion. Sample code to prove it: class Blah : UdonSharpBehaviour { public float value; private VRCTweenHandle _handle; public void _FadeUp() { _TweenTo(1, 0.1f); } public void _FadeDown() { _TweenTo(0, 0.1f); } public void _TweenTo(float target, float speed) { if (_handle.IsActive) { _handle.ChangeEndValue(target, true) .SetDuration(speed) .SetSpeedBased(); } else { _handle = VRCTween.TweenFloat(value, target, speed, this, nameof(value), "_DummyCall", VRCTweenEase.Linear) .SetSpeedBased(); } } } If you trigger _FadeUp and _FadeDown, you will see that if the tween is not freshly created, it will result in it ignoring duration. No matter how you change the ChangeEndValue branch (aside from recalculating the values yourself) you will see it will never result in a consistent transition speed. SDK version is worlds 3.10.4, unity version 2022.3.22f1