SDK Bug & Feature Requests

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! : /

This is important for Asset searching. By default, Unity hides any and all assets that are located inside Packages. In order to make sure searching for Assets from areas such as Inspector fields to show items located inside the SDK by default (such as Menu Icons, Prefabs, etc.), the following line must be added to the package.json: "hideInEditor": "false" This will ensure this button (see screenshot) doesn't need to be toggled to find example assets in the SDK.

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 ?

My seat trigger colliders are inside of a physical hull collider. The hull is on a custom layer called PhysicCollider and I use the "Interact Passthrough" setting to make it transparent to interaction. Live I can interact with the seats. That was uploaded with SDK 3.5.0. But when I upload my world with SDK 3.6.0, the interaction isn't possible anymore. I have to crawl to reach the seat collider inside. I guess, that feature broke with the layer changes in SDK 3.6.0. The first two images shows live SDK 3.5.0 vs my testworld SDK 3.6.0.

UdonSharp reports Utilities.ShuffleArray (the T type) as not exposed to Udon, despite it working just fine in an UdonGraph program. The int[] version of this function does compile in UdonSharp.

Using methods like Material.SetFloat and Material.SetColor works fine if you provide the string of the property name every time, but this is bad for performance. Using VRCShader.PropertyToID to get an int ID in advance works fine in the Unity editor's play mode, but when building an actual world, it no longer works. (Interestingly, when I try with a shader that uses a variable named "_Color" rather than "_MyColor", it DOES work -- is there a hardcoded list of permitted values or something?) As a reminder, this is for things like SetColor on a material , NOT on VRCShader.SetGlobal, so the "_Udon" prefix requirement should not apply (as demonstrated by it not being required when using the string version of SetColor).

When constraints, contacts, physbones and physbone colliders are inspected via the "Overrides" popup on prefabs, they frequently fail to draw, usually failing due to initialization issues or reusing objects that have been disposed. This appears to primarily happen on modified components (ones that are already part of the prefab but had a property modified), new components (only present on the current instance) don't seem to reproduce it, at least not nearly as frequently.

When testing udon networking with RequestSerialization, networking events such as OnPre/OnPost Serialization are never called. This makes patterns such as the below one difficult, which are useful in helping avoid bug-prone netcode. public override void OnPostSerialization(SerializationResult result) => _ApplyNetwork(); public override void OnDeserialization(DeserializationResult result) => _ApplyNetwork(); private void _ApplyNetwork() { // Perform tasks here } I will attach a shim I made that patches over this issue, though it doesn't correctly handle all cases that VRChat performs, and the OnDeserialization behavior here can actually clobber data - so an official implementation should probably either do nothing if not owned, or run OnPreSerialization() first in this case. It's a bit of a hack, but it helps with some testing. It also doesn't do anything for continuous sync, this is just a minimal shim I made for my own use. Shim: https://gist.github.com/TapGhoul/c8a8b59c495f546187517d964b953b75

When using Toon Standard (Outline) with the "Color from Albedo" property, the outline is rendered fully lit even when there is no light. The outline is also not affected by the "Albedo Hue Shift" property. Compared to Poiyomi Toon 9.2 (right side in images), where the outline is lit as expected. Demoed in Unity, but this effect appears in-game as well. This is a pretty effect though, so It would be neat to have an option for the outline to retain this "unlit" behaviour.

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.