SDK Bug & Feature Requests

VRCSceneTemplateInitializer does not create the default sample scene when the UDON preprocessor symbol is already defined on the first launch. Steps to reproduce Prepare a VRChat Worlds template with the UDON preprocessor symbol already defined. The original report used a project template generated by ALCOM 1.1.5 or earlier. (We added a workaround in 1.1.6.) However, the issue can also be reproduced by modifying a VCC template to include the UDON preprocessor symbol in ProjectSettings.asset . For reference, ALCOM's Worlds template included the UDON preprocessor symbol to reduce the initial Unity launch time by avoiding recompilation of most assemblies. Launch Unity. VRCSceneTemplateInitializer should create the default scene, but it does not. Cause of the bug This bug is triggered by the combination of the following conditions: UdonSharpDataLocator does not exist in the project. This causes Assets/UdonSharp/UtilityScripts to be generated during the first assembly load. The UDON preprocessor symbol is already defined before the first compilation. This causes [InitializeOnLoad] in VRCSceneTemplateInitializer to run during the first assembly load. The sequence of events is as follows: Unity compiles scripts normally. Unity calls the static constructor of VRCSceneTemplateInitializer because of [InitializeOnLoad] . VRCSceneTemplateInitializer checks SessionState.GetBool(HasRunStateKey, false) , which is false , so it sets HasRunStateKey to true and registers an EditorApplication.delayCall to generate VRCDefaultWorldScene . Unity calls some [InitializeOnLoad] methods from UdonSharp, and UdonSharp generates Assets/UdonSharp/UtilityScripts . Unity recompiles Assembly-CSharp and reloads the domain. Note that the registered delayCall is never executed before this reload. Unity calls the static constructor of VRCSceneTemplateInitializer again because of [InitializeOnLoad] . This time, SessionState.GetBool(HasRunStateKey, false) returns true , so nothing happens. As a result, the logic that generates VRCDefaultWorldScene is never executed. (The order of steps 2 and 3 may differ, but the result is the same.) For comparison, the following sequence does not cause the bug when the UDON symbol is not initially defined: Unity compiles scripts normally, but the VRC.SDK3.Editor assembly containing VRCSceneTemplateInitializer is not compiled because of "defineConstraints": ["UDON"] . Unity calls some [InitializeOnLoad] methods from UdonSharp, and UdonSharp generates Assets/UdonSharp/UtilityScripts . EnvConfig.cs checks for VRC.Udon.UdonBehaviour and adds the UDON preprocessor symbol. Unity recompiles all assemblies and reloads the domain. Unity calls the static constructor of VRCSceneTemplateInitializer because of [InitializeOnLoad] . SessionState.GetBool(HasRunStateKey, false) returns false , so it sets HasRunStateKey to true and registers an EditorApplication.delayCall that generates VRCDefaultWorldScene . Unity executes the EditorApplication.delayCall , and VRCDefaultWorldScene is generated correctly. Suggested fix The issue is that HasRunStateKey is set to true before the EditorApplication.delayCall is actually executed. I believe moving the HasRunStateKey assignment into the EditorApplication.delayCall lambda would fix the issue.

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

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.

Unity Version: 2022.3.22f1 SDK Version: Base 3.8.0, Worlds 3.8.0 Following the documentation on the VRChat website , I have disabled Auto compile on modify , yet any time I save an UdonSharp script, Unity will refresh and recompile. I'd like to disable auto compile and just have the option to compile manually, but the options in the Project Settings menu seem to have no effect.

Once out of beta would vrchat still be open to expanding the suggested collision tags? And if so would it be from canny posts, or when they think a tag is popular enough. with contacts being added to worlds the standardization for tags I think is going to be getting a lot bigger. especially if people design systems that use a bunch of specific tags. To take some of the load off of vrchat, having a way people can either create their own tag list or download a list by someone else. and have it show up in editor would help making standard tags people make easier to use.

It's just a proposition to use Unity's built-in "EditorUtility.DisplayDialog" to display the message, instead of rendering it in place of the "Build" button. I can't count how many times I clicked "Build" and walked away from the computer, only to realize later, that nothing had built :)

Constraint and contact components keep showing up as prefab overrides, even though nothing has changed. There are no properties highlighted as changed, even in debug mode. This gets very annoying trying to keep prefabs clean and organized.

My seat trigger colliders are inside of a physical hull collider. The hull is on a custom layer called PhysicCollider and I use the "Interact Passthrough" setting to make it transparent to interaction. Live I can interact with the seats. That was uploaded with SDK 3.5.0. But when I upload my world with SDK 3.6.0, the interaction isn't possible anymore. I have to crawl to reach the seat collider inside. I guess, that feature broke with the layer changes in SDK 3.6.0. The first two images shows live SDK 3.5.0 vs my testworld SDK 3.6.0.

Currently, UdonSharp does not recognize Version Defines, so we can't switch the script code based on version defines. When we distribute asset that integrate with external VPM/UPM assets, Version Defines allow us to flexibly adapt our asset to breaking changes and new features of external assets. Otherwise, we would have to split it into a separate script or package, or drop support for older versions. Related Links: https://github.com/vrchat-community/UdonSharp/issues/85 https://feedback.vrchat.com/feature-requests/p/add-assembly-version-defines-support

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