SDK Bug & Feature Requests

For some reason when focusing on the SDK window, it will animate/override a material on my avatar, specifically the emission 0 strength. Doesn't happen on SDK 3.8.1 or lower!

Since the Most Recent Update of VRChat I’ve have been Unable to Update my private Avatar it give me an error that says: “ Object reference not set to an instance of an object” I don’t know what that’s in reference to but it’s Become Tedious and I would love to Continue Working on my Avatar ASAP, If anyone is able to Assist it would be Greatly Appreciated

SDK Version: 3.9.0 When a Player Data value like a string is set to Null, the ClientSim PlayerData UI will run into a NullReferenceException. Udon and the rest of the ClientSim continues to function as expected. Example script: public class Test : UdonSharpBehaviour { public override void Interact() { PlayerData.SetString("test", null); } } Log after opening the ClientSim PlayerData UI: NullReferenceException: Object reference not set to an instance of an object VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.<UpdatePlayerDataList>g__Truncate|42_3 (System.Boolean isMultiline, System.String value) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:767) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.UpdatePlayerDataList (System.Collections.Generic.Dictionary`2[TKey,TValue] playerData, VRC.SDKBase.VRCPlayerApi player, System.Boolean redraw) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:558) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.LoadPlayerData (VRC.SDKBase.VRCPlayerApi player, System.Boolean broadcastPlayerDataUpdated) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:336) VRC.SDK3.ClientSim.Editor.ClientSimPlayerDataWindow.RefreshPlayerData () (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerDataWindow.cs:856) UnityEngine.UIElements.Clickable.Invoke (UnityEngine.UIElements.EventBase evt) (at <332857d8803a4878904bcf8f9581ec33>:0) [...]

I consider this a minor visual bug. In the SDK, the message box doesn't dynamically update it's height anymore when more than a certain number of characters. The "32000" just clip down.

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 at MisutaaAsriel/VRCHarmony which installs a packaged release of Harmony 2.4.1. Unity appears to, in all testing, prefer the package's copy of Harmony over the version included by the VRC Base SDK. This package may also be installed using the following VPM repository: Dreemurrs-Repository VRChat may use the DLL provided from this repository if need be, or take over the package if they so wish. — It is currently built off of the Release target of Harmony, at the solution level, with .NET Framework 4.5.2 using GitHub Actions Note Building Lib.Harmony against the DebugFat target at the project level, or building it for Release against net452 at the solution level creates a successful drop in replacement. The release builds when built at the .NET project level or downloaded from the main Harmony repository currently output a mangled DLL that Unity Burst is incompatible with. A bug report is open on this here: pardeike/Harmony/issues/728 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. Edited @ EPOCH 1757603286

When attempting to upload to both Windows and Android simultaneously, the Unity editor will switch between platforms, then build and upload, and then repeat this forever until the process is cancelled.

I was making an Avatar where the Cube was 1mx1mx1m had a View Position 500 Meters Above the Model and it was fine no matter where I put it but when I change the Z Axis to be even 5 Meters Behind It, the avatar automatically switches it to the center since it was behind the model, I can't do it in front either. I was trying to have it 1000 Meters behind the Model but it still switches to the center when I was Trying to have it Behind The Model On Purpose. The Cube does not have Any Rig at all so why won't it let me do it no matter what I do. I put the cube behind the object, elongated it to be 500m long wirh the Z Axis at 500m behind the GameObject and even moved the Game Object with the Z Position and It still puts it in The Exact Middle where I don't want it to be. Is there anything I can do to Move the Z Axis for the Cube to be Behind or In Front of the Actual Model? (2022 SDK)

As the title suggests, when using a particle system on an avatar, attempting to upload it when the particle material uses Alpha Blended results in the SDK refusing to upload, indicating it is an "unsupported" shader. Then tells us to use shaders from VRChat/Mobile …which is where this very shader is from. This is objectively bad. Either move the AlphaBlended shader out of VRChat/Mobile (E.G. VRChat/PC ), or whitelist AlphaBlended on Quest when used with a particle system. SDK version 3.8.2 Similar feedback: https://feedback.vrchat.com/sdk-bug-reports/p/some-vrchatmobile-shaders-are-labelled-as-non-compatible https://feedback.vrchat.com/sdk-bug-reports/p/cant-upload-to-quest-with-vrchatmobile-shader https://feedback.vrchat.com/avatar-30/p/unhelpful-error-message-about-alpha-blended-shader-not-supported-on-android Notes Fax says that transparency is not supported on Quest, hence its refusal to upload, but this is actually not true. Transparency is not supported on mesh renderers only. Particle systems do support transparency.

OS: Arch Linux (but any Linux would get the same results) Unity 2022.3.22f1 Unity project managed by ALCOM (a cross platform open-source alternative to VCC) VRChat SDK version is 3.8.2 Summary Setting Build Type to Build & Test Your Avatar in the VRC SDK window, then clicking Build & Test does not place the new avatar inside %LocalAppdata%Low\VRChat\VRChat\Avatars (as per documentation ), and it is thus impossible to locally test avatars. Why This happens because that directory does NOT exist on Linux; the virtual C: drive created for VRChat by Steam is inside its specific proton prefix, and as such the right path is more likely to be located near /path/to/SteamLibrary/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/Avatars/ . This path is not right for every VRChat installation, because Steam allows for multiple game drives. Solutions I see two potential solutions; one of them requires fewer changes and is less practical for users : After building an avatar for testing, if the environment is Linux, provide users the path to the compiled avatar asset so that they can move it over to the right folder manually If the environment is Linux, inside the VRC SDK window, in the settings tab, add possibility to set the path to either the root of the virtual C: drive, or just to the folder where the user wants to export their testing avatars Please, please do ask more info if you need it, I will happily provide them, and I'd be happy to see this bug fixed I have found the location, it is inside .local/share/VRChat/VRChat/Avatars/, I have not seen that documented anywhere, maybe updating the docs would be nice... ~~Also if you just give me the path to the compiled avatar I'd be happy, I really wanted to test it out so...~~ Also, I would gladly fix it myself if the sdk was open source... is that planned ? Is it forbidden, in the meantime, to go and decompile and fix stuff for myself ? What about publishing fixed dlls ?