SDK Bug & Feature Requests

The Harmony package, used by Udon Sharp, and a handful of third-party community plugins for runtime patching in the editor, has been updated to officially support ARM64 on all platforms (Windows, Linux, and yes, Mac). This will correct any in-editor issues when running the Unity Editor on these platforms. Whilst VRChat itself may only support PC & Android, the Unity Editor is a cross-platform utility, and there are a variety of folks with ARM-equipped machines who use such hardware for primary development, and therefor experience issues with the editor without patching. With the advent of full iOS support on the horizon, this may further increase the # of Mac-based content creators. Please update the provided package. Release notes for version where ARM64 support was added Addendum An experimental VPM package can be found here which installs a debug release of Harmony 2.4.1. Unity appears to, in initial testing, prefer the package's copy of Harmony over VRChat's included version. It may also be installed using the following repo: https://misutaaasriel.github.io/Dreemurrs-Repository/index.json Note The release builds when built alone or downloaded from the main project currently output a mangled DLL that Unity Burst is incompatible with. However, building Lib.Harmony against the DebugFat target or building it for Release against net452 at the solution level creates a successful drop in replacement. A bug report is open on this here For further reference, the original copy of Harmony is built against .NET 4.5.0, which is no longer a valid target. 4.5.2 was chosen as its nearest replacement.

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.

Currently if you want to animate most of the features on the new Toon Standard shader any other material on the same mesh will also be animated. It would be amazing if you could have a feature like Poiyomi's rename feature where by renaming the specific component of that shader when animated it will only affect that specific material within the mesh. For example currently if I have an Eye material and a Skin Material on the same mesh and I wanted to have two different floats on my avatar, one for Eye hue, and one for Skin hue using this shader and I animate them accordingly it would not work. Both my Eye and Skin would animate together, and currently the only work around one would have for this is to separate anything that animates the same settings onto separate meshes. I would need an Eye mesh and a Body mesh instead of having them combined on the same mesh in order to have them not affect eachothers animations. https://gyazo.com/54fc87aa945f3821301077af006e7a7d (Visual Example)

This would be usefull if as a world creator we dont want stikers on video players, mirrors or user posters and menus. But at the same time we dont want to prevent users to post stikers anywhere else.

I'd like the ability to delete an avatar PER-platform. Nothing to explain really, just have the ability to be able to delete an avatar for a specific platform. EG; Preserve PC but delete Android/IOS. Thanks!

The last SDK version I was able to successfully test was 3.8.1. This one allows for lighting to bake successfully On latest SDK 3.8.2 (And 3.8.2-beta.1): 'Generate Lighting' with unity built in lighting menu -> Background task stuck "Waiting for shaders to compile" - The time to completion continuously rises and never moves past 5% I am using an AMD rx 5700xt, screenshot attached is from another user who has the same issue and is using NVidia.

Currently, the VCC always creates Windows projects by default. When installing Unity, the VCC should install the modules required for Android and iOS. It would be nice if users could choose Android or iOS directly instead of switching to it after project creation.

An Error or Warning should be shown in the SDK build window when a spawn transform is found to be at or below the respawn height y value. This can be done on accident and isn't something that would be obvious to end users (even with the new respawn plane handle). Especially since it causes the Quick Menu to close, meaning you practically soft lock the client if all respawn transforms are underneath the respawn height. I imagine quite a few creators would not be able to make the connection that their player being locked with no access to the Quick Menu means they are being respawned constantly.

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

Currently, upon reviewing the request headers, there does not seem to be any way to differentiate between string and image loading requests for the same URL. With the limitations of VRCUrl, it would be very nice to have a way to tell them apart. Some potential solutions include specifying a value for the Accept header, extending the User-Agent header, or adding a new VRChat-specific header. I believe the last option would be the least likely to break any existing worlds, but there are various pros and cons of each. An example use-case would be a system to download a mesh (binary data, string loading) and its texture (image loading) using a single URL. The server could use the headers to determine which content it should respond with. This would also be useful for decreasing the size of VRCUrl pools as used in YTS and other worlds. We are already using useragent-dependent responses between video player and string loading useragents, but we'd like to do the same with image loading too.