Bug Reports

Using the VRC Avatar Parameter Drive to copy an animated parameter in an animator to a VRC Parameter does not work. Tested copying VRC parameter to another VRC Parameter, and that works. Tested copying an animated parameter to VRC Parameter in Unity editor using gesture manager and that works too. Tested on an otherwise empty avatar without any VRCFury or other addons modifying the upload process. To create a test, follow these instructions: * Create a VRC Parameter component with the following 3 parameters and add to an empty avatar. VRC_Input (Float), VRC_Output (Float), VRC_InRadial (Bool). * Create a VRC Menu component and add two radials. Name one Input, and set parameter to VRC_InRadial, and rotation to VRC_Input. Name the other Output and set rotation to VRC_Output * Create a Unity animator with all 3 VRC parameters as well as a new "Animated Property" float parameter. * Create an animation animating the "Animated Property" from 0 to 1. Have this animation as the only animation in its own layer in the animator, and set the Motion Time to VRC_Input (Thus the Input Radial in our menu will animate the "Animated Property" parameter). * Create another layer with two states, name one "In Radial" and the other "Outside of Radial". * Create a transition from "In Radial" to "Outside of Radial" and set the condition to VRC_InRadial == False. Then create another transition back to "In Radial" with the condition VRC_InRadial == True. * Finally add a VRC Avatar Parameter Driver to the "Outside of Radial" state, set the type to Copy, the Source to Animated Property, and the Destination to VRC_Output. Upload and test. Expected behavior: Adjusting the Input radial will update the animated property, and when exiting the input radial, the animated property is copied onto the Output parameter and thus visible on the output radial menu item. Actual behavior: The VRC_Output parameter is not updated when exiting the Input radial. Adjusting the VRC Avatar Parameter Driver on "Outside of Radial" state to copy from VRC_Input instead of Animated Property, then re-uploading the avatar, shows that copying from VRC parameters works. NOTE: It may appear that the Animated Property is not being adjusted by VRC_Input if you view the Debug Menu ingame. However, creating a third layer with an animation that animates anything visible on the avatar (lets say the scale of a cube or color of a material) and then setting the motion time on that animation to Animated Property proves that the value is still updated. This strange behavior might point to the cause of this bug.

Self explanatory. I've spent a long time looking for friends at events only to realize they have a warp effect and are a nameplate-less diamond.

I thought i was going insane for the longest time but after checking thinking that my centering was off but I realized it wasn't my fault in the end. The grid itself is off. (Attached file for middle section compared to top and bottom) (Middle row is shorter than top row by 3 pixels) (Middle row is same size with bottom row) (Right column is wider than Left column by 5 pixels) (Left column is wider than Middle column by 1 pixel) Also the overlay is clipping into the dark outer border of the camera by about one pixel.

In VRChat Avatar SDK 3.10.X and below, it is possible to run a simple exploit that bypasses the Poor rank. What does bypassing Poor mean? Normally, as soon as an avatar has one light source, the avatar is classified as Poor. If a user blocks Poor and Very Poor avatars, that avatar should be blocked. However, with this exploit, the SDK can be tricked into reporting the avatar as Good. Symptoms The avatar shows the Good rank in the Test SDK build The avatar shows the Poor rank once uploaded as a normal avatar The Poor avatar still behaves as Good even when labeled as Poor Steps to reproduce Create a Good avatar Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Increase the light count to 20 or even 1000 Upload the avatar as Test using Build and Test Result The Test SDK avatar is shown as Good Upload the avatar normally Result The avatar is shown as Poor and reports only one light source Now the absurd part Use the Poor avatar that was just uploaded Ask a second player to block Very Poor and Poor avatars Result The avatar is still visible even with Poor and Very Poor avatars blocked Affected Platforms: PC, PCVR, Quest How Curcial is this Exploit: I did a test in a private black cat instance. 25 Players did block my avatar. I was able to crash 18 persons by using this. Video showcasing the issue with the test avatar; https://files.catbox.moe/nv2h2c.mp4 Expected Result: VRChat should count every single Light Source no matter if its inside a particle system or outside a particle system. it should also be blocked on Quest (like it does on mobile)

After the latest avatar SDK update, the root of the avatar jitters in 3-point tracking. This is affecting all the objects outside the humanoid armature. The jitter goes away if the avatar goes to the crouch mode, or if "Use Auto-Footsteps for 3 and 4 point tracking" is disabled in the VRC Avatar Descriptor. I tried to capture the behaviour using a fresh unity project (created with VCC) and the default pilot avatar, with a cube in the root as a place holder. https://drive.google.com/file/d/14VpjrsixiTsqfLtDAZFJlDIM4FOj7ZBf/view?usp=sharing

Ever since the chatbox "Send Text Automatically" live typing feature came out, I feel like I've been rated limited much more often just trying to chat normally. The chatbox stops working for maybe a minute, and the worst part is there's no indication that you've been rate limited, or when it's fine again.

Even if people don’t have permission to create group instances, they can still access them. If someone has a link to an instance, they can use it to invite themselves through the vrchat website. This action will create a new group instance, regardless of their permissions. For example, anyone with the following link can create a public group instance for my group: https://vrchat.com/home/launch?worldId=wrld_72b30439-62a0-4c0d-a0e6-b3eb7292d355&instanceId=VRCPLSFIXPERMS~group(grp_2b910dc4-e984-4fd5-813c-877edcea29d2)~groupAccessType(public)~region(us)

I am reporting that the issue described in the previous Canny post steam-audio-open-beta#1662 has not been sufficiently resolved. ( https://feedback.vrchat.com/steam-audio-open-beta/p/1662-steam-audio-beta-audio-sources-close-to-head-not-panned-hard-enough ) Specifically, the panning and spatialization of audio sources located in very close proximity to the head remain too weak. The separation between the left and right channels is not distinct enough when the source is near the ear. This lack of accurate spatialization critically impacts immersion, particularly for ASMR content or intimate social interactions where close-range audio positioning is essential. Below is a comparison demonstrating that the issue persists in the current build compared to earlier versions. Reference Videos: Live Build (2025-03-04) - Reference: https://youtu.be/8UoSqduh9Y0 Live Build (2025-12-07) - Current Behavior: https://youtu.be/j3RVQOdXbNo

I have a racing world where AI cars are navmesh agents for the person starting a race, and synced objects for other players. There are no scripts running on them for other players, it is just their position that is being synced. When they are close to other players, they will appear to stutter back and forth. The more players in the world, the more they will stutter. When in the distance, they do not stutter at all. This is a new problem, it was not happening in prior builds of VRC. See attached movie (sorry for the dual audio, I have 2 clients open to test) https://drive.google.com/file/d/11qZxBNN0RVzjA9Z0uStS0s3DAFjuin9m/view?usp=sharing *UPDATE This appears to be tied to framerate. If I lock my FPS to 60, I do not see the problem, but if I uncap it and hit FPS much higher (120+ etc), the stuttering occurs. It appears that the objects being synced are only reporting their position at 60fps with no interpolation to account for users running at higher framerates. It is probably not noticeable when things move at slower speeds, but in instances like my racing world, the difference between 60 and 120+ will be obviously cause a stutter when objects have a velocity close to 100 and you also do while moving right next to them! *UPDATE 2 This only happens if I use my monitor with a 60Hz refresh rate, then uncap the the framerate. If I use my Valve Index at 120 or 144Hz with an uncapped framerate, I will not get any stuttering on objects that I do not own that are moving using ObjectSync as my FPS will rarely get higher than the refresh rate of my headset. So ObjectSync is tied to the Hz that your display is when the game launches, or probably FixedUpdate in some way? This is why I see stuttering when running my world FPS uncapped on my display at 60Hz.

Open VRChat, Join a world with an Index controller user Have them make a series of hand gestures and see if they are able to properly articulate their fingers individually or if the quest handshapes are shown. I've noticed over the past few weeks, alongside a few other friends, that the hand IK is having some issues when displaying handshapes to other users. It seems to primarily be affecting Index controllers. Locally I will see what I am doing fine, but others report that I am doing a different gesture. I have seen this issue happen with other users as well. An example I have from a Helping Hands class for VRASL: the teacher was showing a sign which I knew was done with another hand shape, but I saw the teacher using a "C" hand, which is the sort of cupped hand shape that Quest controllers usually have. I knew the teacher used Index controllers so I was confused and tried hiding his avatar and showing it, fixing the issue in this instance. Hiding and showing seems to fix the issue in most instances but having to do that every time is a huge hassle, if you can even identify that the bug is occurring. This issue is a big detriment to clarity in communication between people in the sign language community, as it's very difficult to tell if the issue is occurring until you've communicated for a while and realize that what they're saying makes no sense. It is also frustrating for users to have differences between what they're seeing and what others are seeing in general.