SDK Bug & Feature Requests

Please check out the following rules and use the provided template when posting a bug report! Off-topic posts will be deleted.http://bit.ly/vrchat-bug-reports
[3.10.2,3.10.3] VRCSceneTemplateInitializer does not create sample scene if UDON preprocessor symbol is defined at first launch since VRCSDK 3.10.2.
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.
11
·
Bug Report
UdonSharp compiler doesn't export SDK proxied event methods unless they're referenced externally, breaking event delivery (e.g. `OnAudioFilterRead`)
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
1
·
Bug Report
·
tracked
[BUG] [SAFETY] Avatar Stations On By Default
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.
3
·
Bug Report
·
tracked
Load More