Bug Reports

Sit down in VRCStation Use Udon to change VRCStation’s transform Your torso won’t rotate with you and will be dragged along (on desktop, your hands will be too!)

To reproduce, separate the eye look values into left and right, then only set rotation values for one of the eye bones and keep the other eye bone at 0 rotations for all states The other eye bone will copy the Left and Right rotation values of the eye bone that had them set The up and down rotation respects the split values This is a problem for stylized avatars that need different L/R values for looking left and right, and overall unexpected behavior https://imgur.com/a/0inTA8C I tried on two different avatars, one with 0 values on the left eye bone and the other with 0 values on the right eye bone I'm not sure if the problem is on any platforms besides PC, I assume it probably is It happens with Selfie Expression as well

After the most recent update (2026.2.2 Build 1853), many members of my community are unable to join certain worlds, myself included. We attempt to join the world, it loads to 100%, then kicks us back to our home worlds. Preloading the world also stops at around 99%, then just hangs. I've confirmed this issue occurs on Desktop and PCVR. I haven't experienced it on mobile yet, and Quest users seem to be okay, but the issue I briefly mention below happened on Android mobile on a Samsung Galaxy S25 Ultra (again, only after updating to the most recent build). I've attached a log file that a community member provided me, and a couple images showcasing: The portion of my own log that I assume to be most relevant A screenshot from the mobile version of the new update that leads me to assume this issue may be related to the new image compressor that was implemented in the most recent update (though these could be two unrelated issues, I just figured I'd include it in case it's relevant).

Steps: While in PC VR, select a user, and click "gift vrchat+" then with the 1 month option selected, press "purchase gift sub for XXX" Issue: After clicking this it often just spins, and nothing happens. No error messages or feedback on whether it failed or succeeded. Other: VRC is probably losing a lot of potential money from this. This whole process has a lot of unnecessary friction, and could be made better. A simple suggestion is to allow purchasing of VRC+ with VRChat credits to cut out all the third party stuff (steam, paypal, etc) so it can truly be a "1 button press" thing. It's hard to debug since I don't want to hammer at an issue that costs real money, so I don't have more useful info. Sometimes it does succeed and works as intended, but that's rare.

Avatar culling hides avatars but does not unload their PhysBones. This means your CPU is simulating PhysBones for every avatar that has loaded near you, not just the ones you can see. In a populated world this adds up fast. You can confirm this with the PhysBones debug overlay — enable it while culling is active and you can still see PhysBones moving on hidden avatars. Repro: Join a populated world, no avatar limit set Hand Menu → Settings → Culling → Show Nearest X Avatars → set to 0 Radial Menu → Options → Avatar → Avatar Overlay → PhysBones → enable PhysBones are still active on hidden avatars. The debug view has a range cutoff but performance confirms they're running beyond that Hand Menu → Safety → switch to any safety preset to force avatars to fully reload PhysBones are now gone, performance improves Set your avatar limit back to what you want — performance is better, but degrades over time as new avatars load in and their PhysBones never unload Tested on: i9-12900K, RX 7900 XTX, 32GB RAM — public world, 30-40 players. in the instance pictured i went from 100 - 150fps by hiding physbones Dynamic Bones had limiter settings. PhysBones removed them, which wasn't a big deal at launch, but avatars use a lot more PhysBones now than they did back then. The fix needed: PhysBones should unload when an avatar is culled. A user-facing PhysBone simulation limit would also go a long way. Also noticed in this session many many users with physbones active for hidden meshes if some wizard can make these disable when the meshes referenced to the bones hide would also be a great optimization

If you are the first person into an instance, you can't rotate pickups for about 8 seconds. After that, it just starts working. If someone is already in the instance it seems to just work immediately without the short delay. The cube is just a vrc pickup set to kinematic. I've tested this in some worlds. And it seems to be consistent for me. Test world: https://vrchat.com/home/world/wrld_fcec062c-104d-412f-8f14-ebff897e2eb0

When Collision Mode was set to "Hit Players" or "Hit Worlds And Players," my own avatar was hit, but other players' avatars were not. When using "Hit World" or specifying "Pickup" in "Hit Custom Layers," the target was hit correctly. Do other players' avatars also need to be running SDK 3.10.3?

The Video Player has accumulated quite a few small bugs and inconveniences over time. If technically possible, I would greatly appreciate it if these issues could be addressed. --- Black Flickering Issue with AVPro Player This problem started occurring shortly after the switch to Unity2022. The latest versions of iwaSync and YamaPlayer include their own workarounds, but older versions of iwaSync/YamaPlayer (when using AVPro) as well as players without custom fixes such as TopazChat Player still suffer from black flickering. --- Video Stuttering During RTSP Playback in Specific Conditions Especially in crowded instances on lower-spec PCs, When streaming RTSP at 60fps while VRChat is running at around 20fps, the video becomes noticeably choppy. Although switching the RTSP stream to 30fps currently avoids the issue, many users set OBS to 60fps because the TopazChat Player distribution page states that 60fps minimizes audio delay. --- Request to Move Video Player Processing to a Separate Thread Especially in crowded instances on lower-spec PCs, video playback often freezes for a moment due to various other processes. With RTSP streams, these interruptions cause playback delay to accumulate. The main causes include: Loading process when someone joins or when an avatar is changed Photo capture processing Display/hide toggling when culling is enabled Loading of stage effects on world VRChat's current CPU processing relies heavily on specific thread performance. On modern CPUs, specific thread often maxes out at 100% usage while the remaining threads (including E-cores and CCD1) stay underutilized. Separating the Video Player's processing into its own unrelated thread could potentially resolve these stuttering and lag issues. It may also allow better utilization of currently idle CPU cores.

When the in-game sliders for adjusting Look-At-Me Offset are used VRChat sends either the new value for the Horizontal Offset with the address /usercamera/LookAtMeYOffset or the new value for the Vertical Offset with the address /usercamera/LookAtMeXOffset over OSC (whichever has changed), but when VRChat receives a float over OSC on address /usercamera/LookAtMeYOffset it changes the Vertical offset and then loops back the float sent on both /usercamera/LookAtMeYOffset and /usercamera/LookAtMeXOffset. The same also occurs when VRChat receives a float over OSC on address /usercamera/LookAtMeXOffset, it changes the Horizontal offset and then loops back the float sent on both addresses.

I run an event that fills up pretty quickly once we announce that guest doors are open. We open the the instance as a group instance with instance queue enabled. After we get all of the staff into the world for the event, we announce on discord and in group pings that the instance is now open for guests to join. Guests should be joining and starting up a queue at the announced time. What they can currently do is use the "Show Go Button on Load" setting to preload the world and reserve their spot in the instance. We can't tell what guests are doing this because they don't load into the world, we have no idea who hass connected early. They simply join the world with everyone else once the ping has gone out. You can test this easily with 2 other people. 1) Create a group instance with a queue for a world with 2 max slots. Just the two of us works well. 2) Have the instance owner join first and load into the world. 3) Have the person who will use the "Show Go Button on Load" join the instance, but not press the join world button. At this point, the person inside the instance does not see anyone else in the world. The person in the load screen has reserved their spot in the world. 4) Have a third person attempt to join the instance. They will either be placed in queue, or receive an error related to needing to join a queue but it will not place them in a queue. From the perspective of the person inside the instance, no one has joined. The third person cannot join the instance and MAY be able to queue. The second person that is waiting to join can join freely at any time. I do not know how long this instance slot reservation lasts, but it is causing significant issues with group instances with queues.