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

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

When using the ATOK IME (Input Method Editor) for Japanese input in VRChat, the Easy Anti-Cheat (EAC) system blocks the "ATOK35DE.DLL" file, making it impossible to type in Japanese. This issue occurs consistently and prevents users from communicating in Japanese within the game. Switching to another IME, such as Microsoft IME, may resolve the issue temporarily, but ATOK users face significant inconvenience due to this incompatibility. an IME is software commonly used in non-English speaking regions to input complex characters like kanji, hiragana, or katakana. In Japan, ATOK is a widely used alternative to Microsoft IME. However, EAC appears to misidentify certain DLLs associated with ATOK as potentially harmful or unapproved, leading to this problem. Please investigate whether this is a false positive by EAC and consider allowing ATOK's DLLs to function properly within VRChat. This would enable Japanese users to communicate effectively without switching IMEs or encountering errors. If additional details are needed, feel free to ask!

When searching for groups there are lots of groups with "no image found" banners and icons, and many of these are owned by deleted users. These groups are just littering the search results and should all be deleted in my opinion. Mainly because they're junk, but also arguably a moderation concern I figure. Groups with no owners should not exist. I think most of us expect that our account should be completely deleted, along with any and all content and information connected to it - avatars, worlds, groups, images, everything. In the case of self-deletes (not bans), even security information like IP and user agent data should be removed to respect the user's wish for privacy. The only thing that should remain of a self-deleted user is the reservation of the user ID and absolutely nothing else. You guys have been adding a lot of features over the years. I think maybe you should make sure these newer features are properly handled by the deletion process. Make sure newer stuff like groups, images, icons, stickers, emojis, age verification, and so on are being deleted when people delete their accounts. I say this because I feel like it's something that is easily overlooked, and I imagine that people who delete their accounts usually don't stick around to file tickets and canny reports about stuff that didn't get deleted. Only a weirdo like me does that. Of course I make this post because I had an alt account that I deleted and I noticed the groups associated with it continue to exist without an owner. I may need to file a support ticket to get them deleted I suppose. It's not really a big deal, they were meme groups and it's not like they violated any rules, but I just prefer to be thorough. PS - I wasn't sure to file this as a bug report or a feature request. On the one hand, I feel like this surely isn't intended behavior, so it should be a bug report. On the other hand, I can't assume to know the intent of the makers, so perhaps it is a feature request. Also, not sure what platforms to select because this isn't platform-specific. Either way, here it is, re-categorize it if needed. Thanks.

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.