Avatar Bugs & Feature Requests

It has been a re-occurring issue that VRChat has been banning accounts and taking down avatars for being NSFW despite the avatars themselves being completely SFW, lacking NSFW options, being completely clothed, lacking any NSFW textures, etc. There has been a recent post stating the guidelines that avatars are removed by, and it is extremely sexist in nature, as almost all of the effected avatars are female. No male avatars are taken down for the exact same reasons or more than several creators have been punished for. It is completely unfair to many creators in the community to have multiple suspension tags on their accounts for making avatars that are not, in anyway, NSFW. Bigger bodies are not sexual. Bathing suits or bikinis are not sexual. All of these listed 'violations' have taken down avatars that do not follow or have any said violations, but I see MULTIPLE avatars that don't get taken down that are far worse than targeted avatars. If these are the guidelines, then why don't the moderating staff/moderating system actually go after the several hundred avatars breaking the violations instead of going for all the ones that don't?

I changed avatars and ended up accidentally into an error robot locally (attached screenshot) temporarily, until I switched to another avatar and back into the same avatar again and then the avatar loaded correctly. This issue repeated a day after, but only remotely to another user. Logs pointed to the above error. I've not been able to reproduce the issue in the past year, and I'm unable to reproduce this again. I don't have steps to reproduce this for this bug report to be actionable and I'm not sure where the problem lies either, unfortunately. Affected avatar: Comfy MoeFT Hush_Rush （lilToon） by WubTheCaptain ( avtr_5d925964-e921-4b24-81a9-f19eef7d3eb1 ) This is an eye-/facetracked avatar, with its FT parameters controlled via OSC with VRCFaceTracking 5.4.4.1, EyeTrackVR App 0.2.5.6 and Babble v2.0.7, animated on the avatar with animations (including eyes). What typically happens when this avatar's loading malfunctions: The avatar loads with eye-/facetracking parameters saved in "on" state, then based on a random chance the eye-/facetracking animations may freeze on avatar load until switching out/resetting the avatar. Rarely, VRCFaceTracking on the host PC may crash instead or require a restart. This is the first time it's given me an error robot instead in-app.

VRCHeadChop components have no effect on any non-humanoid avatars. I tested multiple avatars and settings. The bug occurs with or without custom animator layers, so it's not an issue with animations overwriting anything. Given how important this component is to most non-humanoid avatars, this seems like an unintentional error. The workaround of including an entire humanoid-skeleton is poor for both optimization and user-friendliness.

Current behavior: When a self global collider is in contact with a Physbone where Self Collision is allowed, disabling Self Collision will still allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should not collide with the Physbones when disabling Self Collision. Current behavior: When a self global collider is in contact with a Physbone where Self Collision is not allowed, enabling Self Collision won't allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should collide with the Physbones when enabling Self Collision. Here's the avatar ID for testing: avtr_d34c9e59-4083-4433-bfa4-02a337132cd0

Recent changes have removed the ability to use custom or animator-driven scaling methods that many users relied on. These methods were not just workarounds—they provided functionality that the current in-game scaler does not support. The current scaling system has several limitations: No numeric input for exact values Poor precision when using sliders No way to reproduce a specific scale consistently No ability to save or reuse scale presets Previously, users could create consistent, repeatable scale presets. This is no longer possible. Existing alternatives have significant downsides: Manual scaling is limited, imprecise and cannot be reliably reproduced Duplicating avatars for different sizes: clutters the avatar list (9 outfits times 5 scale presets = 45 avatars) wastes storage (9 avatars times 3 platforms times 5 scale presets = 135 avatars) Reduce cache efficiency, leading to more frequent re-downloads, longer load times, and increased bandwidth usage Additionally, there is currently no way to control avatar scaling externally or programmatically. This prevents integration with external tools and advanced setups. Request: It is time to stop relying on the community to use workarounds to provide the scaling options you should provide. Preferably this should be done before breaking the current external scalers. Please add official support for: Direct numeric input for avatar scale Saveable and reusable scale presets per avatar Fine adjustment controls (e.g., small increment buttons) An OSC input channel for avatar scale control An SDK-accessible method for setting and reading avatar scale Measurement modes (eye height, top of head including kemomimi, top of head excluding kemomimi, direct scale input) This would replace the lost functionality in a supported way and significantly improve usability for both casual users and avatar creators.

Most VRC Avatar Components (Contacts, Constraints, Physbones, Etc.) have a root transform or target transform field, allowing the component to be placed on one gameobject and the functions of the component to originate from or act on another gameobject. It would be nice for the Raycast component to maintain consistency with the other commonly used components and have the root/target transform field.

If feasible, the hue slider feature would be very useful on Standard Lite. Currently, mobile-content-creators must compromise between a hue slider and PBR materials.

When a PhysBone component has a root with multiple children and is set to Multi Child Type = Ignore, the root bone is counted is a physbone affected bone. This makes it more difficult to split a skirt, hair setup, or similar dynamic system into multiple sections for collision optimization, because the common root transform is effectively duplicated in the count. Having an extra physbone component seems cheap in comparison to collision checks that could be saved. ## Expected Behavior If a transform is not affected by a physbone it should not be counted as a transform affected by a physbone. ## Minimal Reproduction Use the simplest possible hierarchy: * BoneParent * BoneChild1 * BoneChild2 Setup: * Add one PhysBone component to BoneParent with BoneChild1 as ignored. * Add a second PhysBone component to BoneParent with BoneChild2 as ignored. * Set multiChildType to Ignore on both components ## Expected Result PhysBones Affected Transforms should be 2 ## Actual Result PhysBones Affected Transforms is reported as 4 There are not even 4 bones to transform in this setup. ## Why This Matters Splitting large dynamic systems into multiple PhysBones can reduce collision complexity. However, the current counting method discourages this optimization because shared transforms are effectively penalized multiple times (and you get one more physbone component on top of that). ## Suggested Improvement If the root of a PhysBone has multiple children and multiChildType is set to Ignore , the root transform itself should not be counted as a PhysBone affected transform. In that configuration, the root is acting only as an organizer transform and is not part of the active simulated chain. This would: * Produce the expected result in minimal hierarchies * Avoid double-counting shared parent transforms * Better match how creators expect Ignore mode to behave ## Minimum viable fix psedocode this.affectedTransforms -= this.root.childCount > 1 && this.multiChildType == Enum:Ignore

It would be really useful to be able to build avatar systems based on your current status. I would love to add an indicator to my avatar which describes if I'm Blue/Green vs Orange/Red. This would also allow avatar creators to make some safety systems, such as having a minimum amount of clothing enabled when the user is Blue or Green. I can imagine this as a simple Int which is then readable by the avatar's animators.

Add something to the SDK to select the blendshapes to use for selfie expression (Like we can for the visemes and blinking) , or add a parameter in the Built-in Parameters for selfie expression. Using the webcam in VRChat is a really cool feature and a cheap way for people use their avatars more expressively, but currently there's little to no documentation about what blendshapes are being used. You also can't use a custom blink animation if you want to have the option to use selfie expression since it's trying to use the blendshape specified in the avatar descriptor.