SDK Bug & Feature Requests

The UdonSharp/UtilityScripts folder and it's contents are recreated upon Recompile or Asset Reload for some world projects. Data loss can occur if a creator modified or added content to the existing scripts. This also changes their GUIDs which creates unnecessary changes on worlds shared via git. Related: https://feedback.vrchat.com/sdk-bug-reports/p/vrcdefaultworldscene-sometimes-is-recreated-upon-project-launch

Description Modifications to the VRC Default World Scene will be reset silently (without any confirmation). In VRCSDK Worlds 3.5.0, VRC Default World Scene template is added and VRC Default World Scene based on the template is created if no scene is existing in the Assets folder. However, because AssetDatabase.FindAssets returns an empty array on [InitializeOnLoad] , if AssetDatabase cache is missing, Worlds Sample Scene will be created even if scenes are in the Assets folder. In addition, Since SceneTemplateService.Instantiate will override the existing scene silently, modifications to Assets/Scenes/VRCDefaultWorldScene.unity will be reverted. This problem is very problematic because AssetDatabase cache is missing when restoring a project from backup. Backup created by VCC will not include Library folder, so the first startup of Unity doesn't have AssetDatabase cache. Steps to Reproduce Create and open VRCSDK Worlds 3.5.0 project Modify VRCDefaultWorldScene and save Close Unity Remove Library folder Reopen project Modifications to the VRCDefaultWorldScene are reverted. Suggestions Currently, In the VRCSceneTemplateInitializer.cs , AssetDatabase.FindAssets is called on the [InitializeOnLoad] and Instantiated scene in delayCall. I confirmed moving AssetDatabase.FindAssets into delayCall will fix this problem. In addition, I think it’s better to just instantiate VRCDefaultWorldScene template without saving a scene for several reasons. (I mean pass null for third parameter of SceneTemplateService.Instantiate ) First, saving to the exactly same path will cause to unexpectedly override our scene on importing unity package. Many VRChat creators don’t understand unity much. Some (especially for beginners) creators use Assets/Scenes/SampleScene.unity of the initialized unity project for contents creation. However, since the GUID of the SampleScene is exactly the same for all projects in the world, It’s happening to replace modified SampleScene.unity (or renamed ones) with SampleScene.unity from unitypackage unexpectedly. (GUID of VRCDefaultWorldScene.unity is different for each project, but the path is the same, so It is still likely to override VRCDefaultWorldScene.unity unexpectedly.) Users should be aware of which file is included in unity package, but I think it’s good to avoid this problem. Secondly, not saving to disk initially will force creators to think about where the scene is. As mentioned above, beginner VRChat creators do not know about scenes, and I often see them confused when a previously opened scene does not reopen upon startup. I think letting creators think about scenes is good. not save default scene automatically, just open in-memory scene on the startup and let users save a scene manually because it lets users know something is saved to file. Conclusion Modifications to the VRC Default World Scene will be reset silently, so please fix the problem. This problem is very problematic because VRC Default World Scene will be reset silently when restoring the project from backup. As one of the ways to fix this problem, I think it might be good to let creators choose the scene path manually instead of automatically save to Assets/Scenes/VRCDefaultWorldScene.unity .

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.

Summary: The VRChat SDK is causing Unity to falsely detect prefab overrides when no actual changes have been made. This issue occurs both during general SDK activity (not just when opening the SDK tab) and specifically when uploading or updating avatars. It often flags the Avatar Descriptor component as "changed," even when untouched. Steps to Reproduce: Open a Unity project with VRChat SDK (SDK3 - Avatars). Create or load a prefab-based avatar. Upload or re-upload the avatar via the SDK. After upload completes, observe that the avatar prefab now shows "Unapplied Overrides" in the inspector. Open the prefab and inspect the VRC_AvatarDescriptor — Unity claims it's been modified, even though no changes were made. Expected Behavior: Uploading or interacting with the SDK should not trigger false prefab overrides when no values were changed. Avatar Descriptor and other components should remain untouched unless explicitly edited. Actual Behavior: Prefab instances are flagged with "Unapplied Overrides" after uploading or interacting with the SDK. The VRC_AvatarDescriptor component is frequently shown as modified, despite no visible differences. These overrides appear without user input, leading to confusion and unnecessary prefab management. Known Triggers: Uploading or re-uploading avatars. SDK interactions during project use (not limited to opening the SDK tab). SDK updates that introduce new systems like (often re-introduce the bug): PhysBones, Constraints, Per-platform Avatar Overrides Impact: Disrupts normal Unity workflow and prefab integrity. Forces creators to manually check or apply overrides to maintain consistency. (Sometimes not even working and getting stuck in an override change loop) Risk of unintentionally applying unwanted changes or overwriting important prefab data. Time-consuming and frustrating for creators managing large or complex prefabs. Additional Notes: This issue has persisted across multiple SDK updates and is easily reproducible. It appears tied to how the SDK modifies or refreshes component data internally. Given how fundamental prefabs are to Unity projects, this issue should be considered a high-priority bug — especially for avatar creators relying on clean and reliable prefab behavior.

Please fix multi-client "Offline Testing" or provide a better way to test networking without a full world upload. The SDK provides two buttons for testing. One is for local testing and the other is for full uploads. Local testing, or "Offline Testing", still requires a network connection and also provides an option for the number of clients. While some things appear to work with only one client, when using more than one client, local testing breaks and behavior is unreliable. Since this is built right into the SDK, people believe that it is correct functionality and think that their world is broken, wasting many hours of debugging and more bad testing. Known issues: -Network IK only sends for master -OnPlayerJoined/OnPlayerLeft triggers do not fire -Sitting in stations force all clients to the same position -Object ownership does not act properly between clients -Sometimes only the master can execute ANY triggers -Some clients do not make it to the same instance -Some clients are kicked to home Previous canny relating to multi-client local testing was closed with the response that using the same account for the same instance is not supported. Users are required to log into different accounts. This is not a solution. The general user does not know they are required to have multiple accounts to test their own worlds properly. Multiple accounts can only enter the same world if the world has been fully uploaded. Some users also have a very slow or limited connection and uploading a full world is impractical. https://vrchat.canny.io/bug-reports/p/multi-client-bugs

An Udon API function to recenter the player to the station's Enter Transform. This would recenter the player's XZ position plane to the station's Enter Transform. An optional parameter (or secondary function) would be given to recenter the player's view as the new reference forward direction. Ideally a call like station.RecenterLocalPlayer(bool reorientRotation = true) would by default do both position and rotation realignment but reorientRotation can be set to false to only handle positional recentering (caused by play-space movement). This would alleviate the problem of a player getting into a vehicle or mounting any station in the wrong direction or moving too much, requiring them to leave and re-enter the station to recenter themselves. This would also give the opportunity for a custom station based character controller to utilize play-space movement as a mobility option without having the feet IK get stuck in one position for VR.

if you have some avatar that is not Good avatar in the scene, fallback avatar button is always disabled (SDK Panel says "This avatar cannot be used as a fallback. Check Validations below for more info".) even if crossplatform Good avatar is selected in Android platform.

With SDK version 3.7.5 several settings were migrated from the static class VRCSettings , existing within the VRCSDKBase-Editor.dll library provided alongside the SDK to VRCPackageSettings , the change also included a refactor of the class, introducing a static property Instance , used to get or create an instance of the class, an instance is attempted to be created by the PerceptualPostProcessor as DPID settings were part of the migration, however this fails because of a null exception: VRCPackageSettings.Instance.dpidMipmaps within PerceptualPostProcessor executes VRCPackageSettings.Instance_get VRCPackageSettings._instance is null so Create() is called, which calls Load() Load() and calls within it, including EnsurePathExists() expect GetPath() to not be null, causing a null exception when it is because GetPath() calls GetPathFromType(GetType()) which calls UnityEditor.PackageManager.PackageInfo.FindForAssembly(t.Assembly) and returns null when executed by a worker process, GetPathFromType then returns null (a comment assumes this would only occur when the SDK is not located within the Packages folder) but this execution path was seemingly never tested and so methods that expect valid strings such as Directory.CreateDirectory within EnsurePathExists() throw null exceptions. Simply resolving the null exceptions is not enough as the current implementation would cause Load() to not load any data when it's meant to, leading to VRCPackageSettings.Instance to contain default values when executed by worker processes ( AssetDatabase.IsAssetImportWorkerProcess() ), you cannot simply abort execution because that invalidates the use of Parallel Import and would cause textures marked as "dirty" to not actually be updated to have mipmaps re-generated, a proper solution leading to the same settings file must be implemented, the whole dependency on the assembly's package info seems extreme. This can be easily reproduced on any 3.7.5+ project with Parallel Import enabled (Project Settings -> Editor, mine is configured with 8 desired workers and 2 on standby) by enabling/disabling "Override Kaiser mipmapping" in the SDK settings.

Since 3.10 came out the option for "mobile multiply/additive" are broken!! across all SDK versions!! They work in unity and the sdk allows us to select them, but they break in game! I AM aware "vrc does not support transparency on quest" yet myself and MANY other creators have been using these shaders for at least over a year and have had NO issues until now!! I ask that you please look into this as MANY of us cannot create for quest until you fix it! : /

Problem : The default scale of (100, 100 , 1) does not line up with Unity grid, and shows the lines at a meaningless arbitrary interval. Cause : This is due to the default GridFloor_udon material has a tiling of 8 by 8. Solution : Rescale the Floor object to (64, 64, 1) will line up the texture with Unity grid perfectly.