SDK Bug & Feature Requests

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

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

Exposing ParticleSystem .Play() in the same way VRCPlayAudio exposed AudioSource .Play() , we could finally do away with the jank-ness of buffer particles and wasting extra particle systems in the performance ranking.

Similar to the VRChat Keyboard, it would show both lasers from each hand on any VRC Ui Shapes with a setting enabled on it. This would be handy for any in-world ui that may require both hand lasers to be readily visible like a control panel or custom world keyboard.

The laser pointer that is used in world UI or to point at an interact/pickup currently does not have a native way of checking where that is nor what VR hand is showing the laser. This requests for a function or event to get the hand and Ray (to be used with a Physics Raycast) that references where the laser pointer is and a way to request for the Ray in the off-hand. This would be extremely helpful in creating pointer based controls (like click drag) for 2D color pickers, showing both lasers for an in-world keyboard, custom interactions, drawing on a 2D canvas, etc. I made an Udon prefab that's able to estimate these pointers but it would be nice if this was a native SDK feature: https://bobystarvrc.booth.pm/items/5007241

I am having constant crashes with VRC with DiscordHook64 being the faul code I keep getting. I have attached a screenshot of the report in Windows Reliability, and have plenty more of these screenshots for different times this occurred, all showing DiscordHook64 as the fault code. This has been an on going problem for 2 weeks and I have tried multiple fixes that don't do anything. I believe this is the EAC confusing DiscordHook with malicious software and therefore crashing the game. I have tested all of my hardware and have found no faults or defects I have performed a clean install of both Discord and VRChat I have attempted to force Discord to stop connecting to VRChat, unfortunately, all of these are reconnected once I open VR again and Discord detects it. This is not something to my knowledge I can permanently disable. I have noticed if I do not run Discord at all, as in force ending the task in task manager, the crashes stop happening.

〇 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.

Similar to the weight slider on constraints, I would love a weight slider on the physbone component. The slider would smoothly blend between the rest pose and the current physics simulation. This would allow for easier blending up/down as part of a blend tree, which have become increasingly popular due the performance considerations of animator layers.

I would like to be able to specify a specific instance for the world SDK portal prefab. Different friendgroups of mine have custom worlds we spawn in using a launch parameter into a specific instance, I would like to "connect" them so we can visit each others shared launch instances without having to use weblinks or navigating menus. It would be much more fun and immersive to be able to just travel through in-world means and build a shared, persistent neighborhood that spans across multiple worlds.

* Place a spawnpoint at -500,0,0 * Enter play mode * Teleport to 0,0,0 * Your player will slowly drift sideways It seems that Character Controller expects to be a root game object, unlike ClientSim which puts it inside a parent that is set to the spawn position. Moving the PlayerController object to the scene root immediately solves the issue.