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

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.

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

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.

I believe it is time to get a solution to the most plaguing issue (in my opinion) of AVPro: Audio Filters I do not think this is a "can't fix" situation. In this proposal I will go over the problem, considerations that have been discussed historically, and the solution I believe is feasible to implement with working sample code. ### Previous Cannys 1) https://feedback.vrchat.com/open-beta/p/986-avpro-player-ignores-lowpass-reverb-and-other-filters 2) https://feedback.vrchat.com/sdk-bug-reports/p/avpro-video-player-audio-filter-issue 3) https://feedback.vrchat.com/sdk-bug-reports/p/sound-effects-are-not-applied-to-audiosource-using-avpro-that-comes-with-sdk3 4) https://feedback.vrchat.com/feature-requests/p/usharpvideo-stream-audio-does-not-support-filters ### Crux of the issue As previously discussed in above canny #1, the current way of handling the AVPro speaker component (type named AudioOutput ) is that the component is implicitly created via AddComponent on the same game object. This has the critical drawback of being unable to respect any audio filters due to the DSP filter chain being _component order dependent_. The second half of this issue is that Unity has no runtime native way to change the ordering of components without fully reconstructing the references. This causes very obvious issues in regards to dependent scene references. (TCL's comment in canny #1 clarifies this as well) ### What has been considered Detecting and destroying/rebuilding known filter components after the implicit component is added. This is bad because all scene references to those components would be lost (eg: UI Events or public Udon variables). To avoid the lost components issue, a full scene search would be required in order to update the references which is costly and fragile. Placeholder components (shims) for each filter type that gets implicitly created after the implicit AudioOutput This is bad because it does not allow users to reference the actual filter components in the inspector (namely an issue for UI Events) Allow adding the AudioOutput script manually in scene and have the speaker search for it before trying to implicitly add the component. This is bad because it requires that the user import the AVProTrial package to be able to use built-in unity audio filters. This needs to be compatible with situations where the user does not wish to import that package so the dependency is decoupled from the feature itself. ### Proposed Solution A shim script that inherits from the AudioOutput class combined with a compiler flag for detecting if AVPro is present, and if not, then have a stub type of the _same namespace and type name_ which is _ONLY_ present in the sdk. Then update the VRCAVProVideoSpeaker to check for the existence of the shim component before creating an implicit AudioOutput, using it instead if found on the game object. This ensures that when the main shim script is loaded in editor, it is already a valid AudioOutput component and the component order is correctly retained so the Audio Filters will work correctly. In the SDK, the script type will check for the existence of AVPro through a version define, and if NOT present, will enable the AudioOutput stub class of the same namespace. An example of what it might be like: https://gist.github.com/techanon/41efc336604e148dde55862bff1778d9 I've tested this specific example in editor and it works there. Can't test in-client obviously.

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.