SDK Bug & Feature Requests

Please check out the following rules and use the provided template when posting a bug report! Off-topic posts will be deleted.http://bit.ly/vrchat-bug-reports

UnityEventFilter removes events from non-whitelisted components

UnityEventFilter interferes with non-VRCSDK related components, causing UnityEvents to be wiped out on any object in the scene if they target forbidden types, methods or objects. I'm heavily relying on UnityEvents for build actions, making the creator workflow significantly easier by allowing the utilization of several build time callbacks to invoke UnityEvents, however, UnityEventFilter's overzealous reach breaks this functionality for no apparent reason. I would suggest comparing the list of components for filtering against the already existing component whitelist that exists in the SDK, since the build action components will be removed on build regardless, they just need to exist for the duration of the scene processing to get their job done, after which they are not a concern in the scope of the scene to be uploaded. As far as I'm aware this problem exists in all versions of the SDK where UnityEventFilter is in use. [UnityEventFilter] Events on 'X' were removed because one of them targeted a prohibited type 'X', method 'Y' or object 'X'. UnityEngine.Debug:LogWarning (object,UnityEngine.Object) VRC.Core.Logger:LogWarning (string,string,UnityEngine.Object) VRC.Core.UnityEventFilter:LogRemoval (string,UnityEngine.Object) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:442) VRC.Core.UnityEventFilter:FilterUnityEvents (System.Collections.Generic.HashSet`1<object>,VRC.Core.UnityEventFilter/TypeInfo,object,UnityEngine.Component) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:360) VRC.Core.UnityEventFilter:FilterUnityEvents (System.Collections.Generic.ICollection`1<UnityEngine.Component>) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:322) VRC.Core.UnityEventFilter:FilterUnityEvents (System.Collections.Generic.List`1<UnityEngine.GameObject>) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:278) VRC.Core.UnityEventFilter:FilterEvents (System.Collections.Generic.List`1<UnityEngine.GameObject>) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:254) VRC.Core.UnityEventFilter:RunFilteringOnPlayModeEntry (UnityEditor.PlayModeStateChange) (at ./Packages/com.vrchat.worlds/Runtime/VRCSDK/SDK3/UnityEventFilter.cs:125) UnityEditor.EditorApplication:Internal_PlayModeStateChanged (UnityEditor.PlayModeStateChange)

[SDK 3.8.1-beta.4] Support VRC Light Volumes in Toon Standard

VRC Light Volumes is a voxel based light probes replacement for VRChat. https://github.com/REDSIM/VRCLightVolumes Once it's introduced to avatar shaders, their appearance would be amazingly improve in appropriate worlds. Major shaders like lilToon and Poiyomi already support this system in the latest version. It would be great if Toon Standard also support this. Mobile users also can get benefits. Shader developers documentation: https://github.com/REDSIM/VRCLightVolumes/blob/main/Documentation/ForShaderDevelopers.md Japanese summary: Toon StandardでVRC Light Volumesをサポートしてほしいという要望。MobileプラットフォームでもVRC Light Volumesを利用できるようになる。

[SDK 3.8.1] Console spams 'Force-enabling Fog'

The log generates an 'Force-enabling Fog' entry every time a change occours in the inspector. This seems to be introduced with the SDK 3.8.1.

tracked

Update the "AssignSceneNetworkIDs" error message with indications how to fix the issue

I often see people on various servers (pretty much on a weekly basis) wondering what that error means and how to fix it, in which I always reply with : > Open the "Network ID import/export" utility and fix the Network ID errors. That error prevents worlds to be uploaded and also prevents play-mode to work. It would be great if the error message actually explains how to fix that issue. The current error message is really confusing especially for less experienced creators and creators who aren't part of any Discord servers related to world development.

[VRCSDK 3.8.1] VRCSDK throws exceptions when encountering an avatar descriptor with an empty animation layer list but "customize animation layers" on

tracked

Only one custom event is showing up in the "Events list" in Graph.

In the Graph of 3.8.1 the custom events list will only display one.

tracked

[3.8.1] VRCStation crashes random unrelated scripts in ClientSim

This was figured out after an hour and a half of debugging. Turns out, the ClientSim staiton helper script has a bug that results in broken editor behaviour. Here's a writeup of what went wrong and my quick fix of the issue - the ideal fix is probably to use a GUID instead, but hey. There's a TODO in the SDK on the line that broke. This reproduces in 3.8.0 too, as well as earlier versions. From my postmortem - this was a mysterious crash in AquaFloat, but the bug is not in AquaFloat's code, which is why it sent us on such a wild goose chase. Postmortem: The script was crashing in a GetComponent<Floater>() in OnTriggerExit. GetComponent against an UdonBehaviour works by getting all UdonBehaviour components and matching their internal ID/name/signature (due to it not being a real type at runtime - standard U# behaviour) This was triggering when an object with a VRC Station left its bounding box. The reason why this broke is due to a ClientSim fumble. On game start, if in the editor, ClientSim attaches an UdonBehaviour, and tries to attach a default station behaviour to that. The problem is, the way it does that is it looks for a given .asset under the Assets dir (specifically vrc example stuff) - but VRC no longer places those assets there (or some other script was removing it). This caused an empty UdonBehavior component to be added without an associated Udon VM instance. When the GetComponent lookup ran, it tried to hit the VM instance to get public vars, in order to get the signature. The VM instance was null as a result of this failed load, which caused GetComponent to fail, which crashed the calling script. My quick fix (quick after 1.5 hours lol) was to modify the ClientSim station helper and fix up the path. Hilariously, there's actually a TODO comment talking about finding the asset file "properly".

tracked

[SDK 3.8.1] VRCCameraSettings.ScreenCamera.FieldOfView wrong at start

The FOV returned at start reflects not the current setting in desktop. Steps to reproduce 1) Add a script with these lines somewhere in your world: private void Start() { Debug.Log($"Start FOV: {VRCCameraSettings.ScreenCamera.FieldOfView}"); } public override void OnVRCCameraSettingsChanged(VRCCameraSettings cam) { if (cam.CameraMode == VRCCameraMode.Screen) Debug.Log($"OnVRCCameraSettingsChanged FOV: {cam.FieldOfView}"); } 2) Set your FOV in the graphics settings to something different than 60° (e.g. 80°). 3) Join the world and check the log. You will see: Start FOV: 60 Expected behavior The log should show: Start FOV: 80 Or maybe addtionally later in case the user setting is not available at start: OnVRCCameraSettingsChanged FOV: 80

tracked

Avatar buttons displaying as "Button Text" and do not function.

[SDK version(s) 3.7.6, and 3.8.0._]This bug is a resurgence of this bug described in https://feedback.vrchat.com/sdk-bug-reports/p/372-beta2-action-menu-buttons-are-blank This bug occurs any time I attempt to add a button to an avatar in the most recent SDK builds, and in 3.7.6, and older builds that featured this bug, the solution was entirely random. From changing parts of the animator, to replacing the boolean value with a trigger, I've done just about everything to try and fix this myself, and yet it still has the same outcome. I've even tried changing the name of the parameter, but with no luck. The only time this works is if I change the button to a toggle, but that would ruin the Idea I had. This did not occur in versions older than 3.7, which leads me to believe something related to buttons may be the cause of this bug, and the problem gets worse over time. I've been trying to fix this bug for a while now. I can't think of any way to get a button to work on this avatar specifically. Further information: Upon first upload, this avatar's toggles were all functional, both buttons I had added displayed without an icon, and were labelled "Button Text". First attempt to fix: I double checked that the transitions had conditions where they were needed, and cross referenced with an older avatar I had made with the same feature. I found no differences between the old, and new avatars. Second attempt to fix: I remembered what another person said about buttons only working with triggers in some cases, only to realize that didn't work either. Third attempt to fix: I deleted my old animator controller, menu, and parameter in order to start from scratch, adding one feature at a time. The charged attack was the first feature I worked on to attempt to see if this would fix the problem. The bug persisted. ONLY solution known so far: Replace all buttons with toggles. The only time the menu properly interfaces with this layer is if I change the button to a toggle. I want to use a button so you hold the button to charge the attack, or tap it to use an uncharged attack. I have determined that because ONLY toggles work on this layer, that it must be the result of a bug within the SDK.

tracked

Toon Standard incorrect/unexpected backface lighting

On the new Toon Standard shader if culling is set to Front or Off, the backfaces are rendered darker than they should be compared to the commonly used PC shaders. This is caused by the backface normals facing the wrong direction. The solution for rendering backface normals as expected it so flip the normals. This is the default in Poiyomi, and an option in Liltoon. Expected: Front and backfaces render with the same lighting. Actual: Backfaces are rendering much darker. Provided image shows four copies of the same avatar. The small feathers face the viewer like normal. The bottom right avatar is the traditional version, where the large feathers were duplicated and flipped, so they face the viewer. This avatar renders as expected. The remaining three copies have only one layer of the large feathers, all facing away from the viewer. Top left is the backfaces being rendered with flipped normals. Top right is a demonstration that when the backfaces are not flipped the results match the current output of Toon Standard. Bottom left is Toon Standard, which is not flipping backface normals. SDK Version: 3.8.1

tracked

→

Boards