SDK Bug & Feature Requests

Summary: VRChat's own VPM packages are getting distributed with missing licence information. A change request for the documentation about VPM License files. According to UPM docs ( https://docs.unity3d.com/Manual/upm-manifestPkg.html ) Licence: > Identifier for an OSS license using the SPDX identifier format, or a string such as “Refer to LICENSE.md file”. > Note: If you omit this property in your package manifest, your package must contain a LICENSE.md file. LicenceUrl: > Custom location for this package’s license information, specified as a URL. For example: > "licensesUrl": " https://example.com/licensing.html " > Note: If the Package Manager can’t reach the URL location (for example, if there is a network issue), it does the following: > - If the package is installed, it opens a file browser displaying the LICENSE.md file in the package cache. > - If the package isn’t installed, the Package Manager displays a warning that offline license information isn’t available. According to VPM docs ( https://vcc.docs.vrchat.com/vpm/packages/ ) > We also highly recommend listing the license of your package in the package manifest. Unity requires this field if you do not have LICENSE file in your project, but we recommend specifying it even if you do have a LICENSE file. This field might be displayed in the VCC interface in the future. The license should use the SPDX format. None of the above is done by VRChat itself. Instead VRChat distributes a licence.txt file inside vpm packages with an URL to the license. Moving (or copying if there is a need for the LICENSE.txt) the licensesUrl from inside Licence.txt to the LicensesUrl key inside package.json seems to be the needed change. VPM (uses LICENSE) and UPM (uses LICENSE.md ) using different license filenames. Is this an oversight? Why did this got changed? Can we have some more clearification about it?

The new 3.8.1-beta.1 SDK adds a bunch of new camera accessors. However, something that is missing that would be incredible for effects that involve funkier render passes and effects that need udon-side help is the ability to read the per-eye oblique matrix. While there are ways to get this as-is, it requires some manual math to derive and requires digging into unity innards. It'd be great to be able to get these values directly off of the camera. An example of this is to make a custom VRCMirror that has an arbitrary origin to more easily make better portal-like effects, as this requires being able to put a camera on the receiving side - doing this in a stereo-correct way is currently a tricky task. Having these values as getters or methods on the new VRCCameraSettings API would be incredible. Worth a note here: while we have accessors for eye position/rotation, this is not enough to correctly do stereo rendering. See the VRC Mirror component for details.

Within a render callback such as OnWillRenderObject, it's useful to be able to check which camera is rendering. Unity has "Camera.current" for this, but it's not exposed to Udon. The new camera API is awesome, but without a property like that, I still can't make my UdonPortals prefab render correctly in the hand-held camera because there's no way to tell which camera is currently triggering OnWillRenderObject. I'd like a property to tell which camera is responsible for the render. A really simple implementation would be a new read-only property like: VRCCameraSettings.CurrentCameraType: An enum consisting of the values "ScreenCamera" or "PhotoCamera". However, I think this API could be extended further to be even more useful. In particular, if a Camera that was created by the world (and so is already accessible to Udon) is rendering, it would be great to be able to access the actual Camera object! Just like Unity's "Camera.current", but only limited to world-created Cameras. An API might look like this: VRCCameraSettings.CurrentCameraType: Enum consisting of the values "ScreenCamera", "PhotoCamera", "WorldCamera", or "Other". "WorldCamera" would be any camera created by the current world, i.e. a Camera that's accessible to Udon. "Other" would be anything else that isn't (yet!) accessible to Udon, e.g. avatar cameras or the screenshot camera. VRCCameraSettings.CurrentCamera: A reference to the current Camera object, just like Unity's Camera.current, except it's only set when CurrentCameraType is "WorldCamera". Otherwise, it's null.

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

I've been fiddling around with new drone API since it is public, but I found out sometimes it is quirky when calling VRCDroneApi.TeleportTo() with Udon(sharp). Whatever what coordinate you want to teleport the drone to, the drone will always drift back to the same y-level it was. I don't know if this should consider a SDK bug or drone bug.

This new version seems really emjoy hanging in Scheduler.Tick. Maybe I got too many avatars?

I'm trying to merge scenes before build in OnBuildRequested. What is happening is that it creates a successful build and then cancel the upload. The only thing I do is copy all open scenes into a new scene and build that one instead. This is happening in 3.8.0 and in eralier versions as well. It seems to create a vrcw file just fine and reports that the build is successful. If I use an older SDK that still got upload last build as an option the file can be uploaded and works without any problems. (same build and publish problem is there as well though) Build and test also works flawless. Setup: Use the default world scene, add another scene with some cubes or something. Have a script create a new scene and move the content over to that scene when OnBuildRequested is run. After it has copied everything unload those scenes. When clicking Build & Publish it runs as expected until it reaches upload Where it just says "Upload cancelled" Tried to clean up some things in here. My code: https://gist.github.com/Tummy-git/8d5e1ee754abf2e321aa04d07a4754ae EDIT: We figured out why, and it's not technically a bug, so this is now a feature request. Make it ignore scene changes during preprocess and upload!

VRCExpressionParameters files should not clamp a parameter's defaultValue if Synced is unchecked. Unsynced variables aren't clamped, so the parameters file should allow this.

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.

Steps: Create a scene Create a gameobject with a slash in the name, or a gameobject as a child of another gameobject with a slash in the name (basically, scene path has a slash in it) Attach a component that makes it networked, such as VRCObjectSync or an udon script with networking on it Generate and export network IDs Attempt to import the network IDs As a result of the file using slashes as separators, the network IDs will fail to import for these objects. Unfortunately, using slashes to signal section (for example, "/// PATREON ///") is a common practice among many creators, and this causes problems for transferring network IDs between projects when a separate PC vs Quest scene or unity project is used.