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.

Since a recent update, Shadow users can no longer launch VRChat. It feels like we’ve been banned.

I discovered two avatar audio bugs in worlds from Udon that have a gimmick for changing the player's avatar audio. https://creators.vrchat.com/worlds/udon/players/player-audio/#avatar Executing SetAvatarAudioCustomCurve(false) makes the avatar audio for 3D settings for the local player extremely quiet. 3D settings mean that Enable Spatialization is checked for VRCSpatialAudioSource. This occurs regardless of the state of Use Audio Source Volume Curve. Executing SetAvatarAudioCustomCurve(false) for a remote player does not seem to affect the volume. Executing SetAvatarAudioCustomCurve(true) did not affect the volume for the local player, either. Executing SetAvatarAudioForceSpatial(true) makes 2D avatar audio noisy, regardless of whether the player is local or remote. 2D settings mean that Enable Spatialization of VRCSpatialAudioSource is unchecked and Spatial Blend of AudioSource is set to 0 (2D side).

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.

Currently in the VRChat SDK when uploading a world, it recommends an image resolution of 1200x900px. However as far as I can tell in practice, VRChat only seems to use 800x600px images, which is 2/3rds the recommended size, resulting in aliasing. So far in my testing this seems to apply to: 1) The website 2) The world image returned by the API 3) The world image as seen in the game client UI (all platforms) 4) Portals dropped in-game (all platforms) While often subtle, it becomes quite noticeable when an image has pixel art, which renders as blurry. The discrepancy between the stated and actual ideal resolutions results in world images looking less sharp than they otherwise could, and without clarification makes it uncertain which resolution to target for design and upload. Attached to this post are 5 images from my world VRCanvas to show the effect of the issue, in the following order (pay particular attention to the sharpness of the text): 1) Uploaded 1200x900 image 2) 1200x900 image as downscaled to 800x600 and displayed by VRChat 3) Uploaded 800x600 image (VRChat displays as-is) 4) Image #1/2 as it appears in a portal 5) Image #3 as it appears in a portal The ideal solution I'm requesting would be to fix the API/client to display in the native recommended resolution of 1200x900, since this is higher quality, and most worlds are already uploaded in this resolution per the VRCSDK's recommendation. If for whatever reason this is undesirable to VRChat (perhaps texture memory or bandwidth reasons?), then the VRCSDK recommendation should be changed to 800x600 to match what's actually the ideal resolution. If this is a texture memory concern, then a third option could be move to a new resolution of 1024x768, since this would still fall within the same power of 2 as 800x600 while still 4:3 aspect ratio and higher resolution.

After the last Patch in vrchat on steam after i close the game in the main menu or using the close button it just stays in the background processes in my task manager until i restart my pc closing down steam or pressing the stop button doesn't work Basically the procress is stuck and won't close

My assumption is that avatar animations still play when culling which is extremely unnecessary in my opinion. Maybe there is some technical difficulties preventing this but this could potentially be a big performance hog if that's the case. Network and frametime wise.

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

Hi. I host Disney-themed balls in VRChat, and I've had two balls where I had given roles with queue priority out to performers, and then when they crashed and tried to join back, they were pushed to the back of the queue instead of to the front of it. This first happened for my Disney Nature's Dance on August 9th. There was like a queue of I think 20-30 people. I was lucky I had my performer in on time for their song. But when I had my Disney Villain's Gala on October 18th, it seemed to be fixed, so I didn't say anything. But it came back again for my Disney Christmas Ball this past weekend. I want to make sure it's fixed for my next ball, as one time, we had a queue of 40-60 people, and it took people like 1-2 hours to get in. I so far have only had performers on Windows, so I don't know whether quest users are affected.

Roughly since a month (maybe a bit longer, shortly before the 3p open beta build was introduced i think) we saw a massive decline in performance stability. Not the average performance (at least not that i can tell) is affected here. Anytime something happens, random things, onscreen effects from games, toggles, switches, anything really, there doesn't seem to be any pattern behind it (that i could notice) VRChat will completely freeze, not just hitch for a moment but completely lock up entirely, up to several seconds sometimes. I can see in the Steam Overlay that Steam (and everything else) continues to work just fine with no hitches at all. I cannot determine why exactly it has been happening though i noticed that turning down (to Errors Only) or entirely off Debugging does help a bit, it does not fix the constant freezes however. Several many people i know have reported this degrade in performance so i'm confident it isn't just me. I've tested the live build (since a month), the open beta and the third person beta. All of them have this issue and it makes playing quite frankly almost impossible. Things that can cause these massive freezes: Turning off lights (Blackout, Murder, Prison Escape, Among Us) Some avatar effects (Scaling bones + playing a short sound + toggling physbones) Practically any new onscreen effect (text or effects popping up on screen, fade-to-backs when dying) Turning around for a bit and then turning back to face the same avatars Opening any menu that loads a couple images (Groups, Friendlist and several others) Spawning some very light items in some worlds (Pens, Objects, Furniture) The usual (Avatars loading in, lights toggling etc) are amplified (although weirdly enough not as bad as everything else) I would have suspected an issue with logging (though when turning logging off it still happens) and/or the way the strings are gathered and printed but that seemed only part of the issue. Game lobbies are nigh unplayable with the constant freezes. It's not an issue with firewall, defender or antivirus (tested all of them, turned all of them off). The effect is similar as to when you've been logged out of the API while still being online (API calls causing massive stalls of up to 10 seconds). I honestly don't know what to point to other than it wasn't happening ~2 months ago. Its happening everywhere with as little as a single other player in the instance, its hard to miss it. Hardware has not changed, drivers and software has not changed, its repeatedly reported by many people with hardware reaching into the high-end bracket. My only wild guess i have at this point is that the avatar optimization (single pass shaders) is getting reapplied aggressively after a short while. Usually when something requires shaders to switch to two passes (thus undoing the optimization), such as being lit by a realtime light, it stays unoptimized until (presumably) being reloaded (or possibly only after switching/rejoining worlds). My guess is that the switch back to single pass is being reapplied very aggressively here, which (if the previously compiled single pass or two pass shaders aren't cached) would cause a massive freeze as shaders are getting recompiled live. This would explain most if not all the cases in which these freezes seem to happen.