Avatar Bugs & Feature Requests

Add a new type of expressions menu control that allows a user to select RGB or RGBA values. The values would update 3 separate floats (0-1). It is possible for an avatar creator to create this functionality in the current system, but the end result is not a very user-friendly interface for in-game users. The in-game color picker could be a color circle with darkest values at the edges, white at the center, and full-saturation in-between.

When adding a VRC Contact Sender and changing the size of it, it limits at 20 which is not documented in https://creators.vrchat.com/avatars/avatar-dynamics/contacts page. But when you go into the negatives of the Radius for a Capsule shape it inverses and goes past these limits in the Unity editor.

In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit." This additional information could be exposed as parameter suffixes, just like _Stretch on physbones. Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts: * X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact) * Whether the nearest collision is self or others (or world?) * Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame) * Velocity of the sender (change in sender position since last contact update / time delta) * Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1

I've been noticing and increasing number of issues with physbones over the past couple of months. 1. Immobile used to work with Gravity, but now bones with gravity always shake violently while the avatar is moving quickly, completely ignoring immobile. Example: avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 avatar uses that to determine the up vector for the cat, walking around causes the cat to jump around, it never used to in older versions. 2. Physbones resting on or inside colliders vibrate, sometimes even to the point where they seem to struggle to stay inside inside-out colliders. This used to be stable with no vibration. In minor cases this can sometimes be mitigated with "physbones as spheres", but it never used to be necessary. Example: avtr_04a9d322-e228-4934-93b1-6e20b62cfded The boxing gloves on this avatar are long physbones with squish that are held back by inside-out colliders, they now vibrate violently at all times, they used to stay calmly in place.

I think it would be very beneficial to have a native VRC parameter "IsAgeVerified" such that I and other creators can lock certain functionality behind the age filter.

One of my friends has been using their original official avatar for over five years. The last update for this avatar was in 2023. Every time the SDK gets updated, the standard conversation becomes, “It might stop working soon.” The data might not even exist anymore, but since there are people who still cherish avatars from way back, I'd be happy if updates could continue.

I tryed to send "/avatar/change" osc message but it does not work. I also sended "/avatar/parameters/..." together and it works. osc.send({address: "/avatar/parameters/BustSize", args: [0.5]}); // works osc.send({address: "/avatar/change", args: ["avtr_0eb0aeff-5a47-4c01-86e7-943cfcc1e8b5"]}); // not working

User is unable to change into an avatar using the "/avatar/change" OSC unless it is a favorited avatar. The user however should supposedly be able to change into any of their own uploaded avatar or a recent avatar, as stated in the 2025.1.2 Update Log. "You can only change to avatars in your favorites, your recents, or that you've uploaded yourself." https://docs.vrchat.com/docs/vrchat-202512

Currently, the shader type called Hidden that can be specified as a fallback shader is introduced on the following page as: > Hidden // (this will hide the mesh from view if the shader is blocked, useful for things like raymarching effects.) > https://creators.vrchat.com/avatars/shader-fallback-system/ However, if a mesh using this shader has an animation that sets the _Color alpha parameter to 1 , the mesh that should have been hidden by the fallback shader becomes visible. My guess is that this happens because the Hidden fallback shader is actually reusing an existing shader (such as Unlit/Color ) and simply sets the color alpha to 0 in order to hide the mesh. When an animation overrides the alpha value, the mesh ends up being rendered. As a solution, I would suggest either providing a dedicated Hidden shader, or adding a special “hidden” flag to the existing shaders so that polygons are not rendered at all.

Tried uploading an avatar with the latest SDK version - it'd fail at the last second, claiming there's no thumbnail when there IS one set for sure (tried with multiple kinds + in-scene capture). But the avatar could be seen as uploaded on the VRC website, but not in game... and when the 'change to avatar' button was clicked, it'd claim there's no avatar there. I rolled my SDK back to 3.8.2 and it uploaded just fine.