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.

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 would like to see the VRC Avatar Parameter Driver functionality extended or a new State Behaviour that implements four arithmetic operations between parameters. It would be great if you could also add a function that allows exception handling by specifying a parameter of any bool type when a calculation result overflows or divides by zero. Another feature that would be very useful would be to add a State Behaviour that outputs the results of comparisons between Animator Parameters to a specified bool parameter. We believe that implementing these functions will enable more complex expressions and increase the readability of Animator compared to the implementation method using BlendTree, so please consider it. (The translation was done using Deepl and may contain unnatural expressions.) VRC Avatar Parameter Driverの機能拡張、もしくは新規のState Behaviourとしてパラメーター同士の四則演算を実装して欲しいです。 計算結果がオーバーフローした場合やゼロ除算が発生した場合に、任意のbool型のパラメーターを指定して例外処理などを行うことが可能な機能も追加していただけると嬉しいです。 そしてもう一つ、Animator Parameter同士の比較の結果を指定したbool型のパラメーターに出力するState Behaviourも追加していただければ非常に便利になると考えております。 これらの機能を実装することでより複雑な表現が可能になり、BlendTreeを用いた実装方法よりもAnimatorの可読性が上昇すると考えていますので、ぜひご検討ください。

The expression menu lacks various controls types and features used by VRChat's native Action Menu, limiting our approach to creating more complex toggles that depend on one another or simply to provide clearer intent/description to users. Some of the features missing include the following: * Making a control unclickable (to indicate it depends on another function, typically another toggle, such as the various personal mirror settings only being accessible once the mirror is shown, but also some of the action menu settings depending on whether you're in VR or not). * Control tooltips (as used by the Custom Emojis and stickers controls when you're not subscribed to VRC+) Alternate toggle looks: * On/off capsule instead of the spinning circle overlay (support for icons would be a bonus, with a smaller capsule and the option to choose whether it appears above or below the icon) * Alternate icons (similar to the microphone and gestures toggles)

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.

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.

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.

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

Currently, you can have an avatar rated as “Good” at 70,000 polygons, but adding even a single triangle beyond that will instantly drop the rating to “Very Poor.” Obviously, this doesn’t make much sense and can actually discourage some people from optimizing their avatars. (Why bother optimizing other stats if the polycount alone tanks the rating the moment you go over?) I’d like to suggest increasing the polygon thresholds for Medium and Poor ratings, with a gradual step-up between each level. This would make a lot more sense and give creators more flexibility! I’d really love to see this system improved. The VRC team should ultimately decide on the final values through proper testing, but personally, I think a Poor rating could go up to around 120k, and Medium could sit around 90k. Of course, those numbers are just based on my experience, and I’m sure the team can come up with even better thresholds through data and testing.