SDK Bug & Feature Requests

With the SDK 3.10.2 update, the Avatar Expressions Menu editor received the following UX change: When targeting a Boolean parameter, the Value attribute is now hidden and is always treated as enabled, since that's the only valid option for a Boolean (true when activated, false when deactivated). While I understand the reasoning behind this change, it removed a useful workflow that was previously possible. Before this update, it was possible to create two menu controls targeting the same Boolean parameter: one with Value = True and another with Value = False. This allowed both controls to toggle the same parameter while only the control matching the current state would appear visually active. For example: Badge toggle (Value = True) Nameplate toggle (Value = False) When the Boolean is true, only the Badge toggle appears active. When it's false, only the Nameplate toggle appears active. This made it possible to represent two mutually exclusive states using a single Boolean while providing clear visual feedback in the Expressions Menu. Since the Value field is now hidden and always forced to true, this behavior is no longer possible. I'd like to see the Value option restored for Boolean parameters, even if it's tucked behind an advanced setting or warning. While the current behavior is simpler for most users, the previous implementation enabled legitimate use cases that are no longer possible.

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

For compatibility with other shaders, and also just general sanity, please either change your hue shift to a range from 0 to 1, or change the property name to not conflict with other popular shaders.

It would be a big help if constraints that do rotation had angle limits just like physbones have. Currently when I need an angle limit I need to use a physbone with an inside-out collider that is then constrained, which is wasting an entire physics simulation just to limit the rotation angle. This is becoming increasingly important since physbones have gotten so jittery and unstable that its difficult to use them with colliders at all anymore.

While double-checking how to get a timestamp that's consistent for multiple users, I arrived at GetServerTimeInSeconds, and then nearby noticed this: "CalculateServerDeltaTime(double timeInSeconds, double previousTimeInSeconds)" Which seemed weird? Why would there be a function for that, when you could just subtract one from the other with ordinary arithmetic? I asked on the Discord, and someone informed me that it's because GetServerTimeInSeconds can wrap ; apparently despite being a double, it's only a wrapper on GetServerTimeInMilliseconds, which is only an int. If this is true, it would be good to mention this somewhere in the summary for GetServerTimeInSeconds, and/or CalculateServerDeltaTime, I think! i.e. in this table: https://udonsharp.docs.vrchat.com/vrchat-api/#networking And honestly, it might also be nice to just provide some non-wrapping double too? (Maybe even just a convenience wrapper around GetNetworkDateTime().Ticks/10000000?)

I have been running into an issue with the player collision mode where it seems its very easy to get into a loop of a raycast pulling itself closer if the Result Transform has a collider on itself. I have been attempting to make a collider that uses a Raycast to place a collider on another player to effect physbones, but it results in the sphere approaching the ray casters source when turned on over and over, as it casts upon itself and moves the collider closer each time. It would be nice if there was a toggle to allow the raycast to ignore the colliders on the player that is firing it to avoid this

Exposing ParticleSystem .Play() in the same way VRCPlayAudio exposed AudioSource .Play() , we could finally do away with the jank-ness of buffer particles and wasting extra particle systems in the performance ranking.

The contact system is limited to 60 updates per second, in scenarios over 60 fps, the contacts will maintain information from a prior frame, for systems expecting an update every frame, this leads to incorrect assumptions, which can break logic in unexpected ways. This can be prevented by adding a parameter to indicate whether contacts have updated this frame (i.e. ContactUpdate ), this would allow us to short-circuit every contact-based transition to only evaluate when we know contacts have up-to-date values, avoiding these problems. An inverse of the parameter (i.e. ContactUpdateSkipped) can currently be implemented by using a Proximity contact and setting it's value to non-0 every frame, on frames that the contact receives an update, the value will be overridden back to 0, adding the parameter as a boolean in the controller means that contacts have updated when the parameter is false (can undo the inverse behavior by adding an overlapping sender, but that adds another runtime component).

In VRCSDK3 Avatars, if BlendShapeNormals in FBX is Calculate, the validation is displayed. If I press AutoFix here, LegacyBlendShapeNormals will be enabled. But I think LegacyBlendShapeNormals is an old method as it is named Legacy. Since relying on AutoFix in VRCSDK is not a way to get out of the old method, we would like to change it to use the new method. Instead of enabling LegacyBlendShapeNormals, I would like to change BlendShapeNormals to None. Incidentally, depending on the new Blender FBX export settings, LegacyBlendShapeNormals may break mesh normals. So I am trying to find a way to avoid using LegacyBlendShapeNormals. I am using VRCSDK3Avatars 3.6.0. Thanks.

The laser pointer that is used in world UI or to point at an interact/pickup currently does not have a native way of checking where that is nor what VR hand is showing the laser. This requests for a function or event to get the hand and Ray (to be used with a Physics Raycast) that references where the laser pointer is and a way to request for the Ray in the off-hand. This would be extremely helpful in creating pointer based controls (like click drag) for 2D color pickers, showing both lasers for an in-world keyboard, custom interactions, drawing on a 2D canvas, etc. I made an Udon prefab that's able to estimate these pointers but it would be nice if this was a native SDK feature: https://bobystarvrc.booth.pm/items/5007241