Bug Reports

Once your friend count exceeds 2,000, it takes a very long time to load instances. I’ve been playing VRChat for nearly six years. I look forward to visiting various public instances every day. However, since my friend count increased, I’ve started experiencing a wait time of about 3 to 5 minutes every time I move to a new instance before it loads. I suspect that the system reloads the entire friend list every time the instance list is displayed, so I’d appreciate it if there were a better way to resolve this. Alternatively, I think a feature that allows users to bulk-manage friends they haven’t seen in years or have only met once could help prevent friend counts from growing excessive Translated with DeepL.com (free version)

VRChat using absurd amount of RAM, more likely on longer sessions (around 2-4 hours). I haven't played around with it too much to figure out things that could be causing it, but I have noticed that the longer the play session, the more likely it is to happen. Ends up using all of my available RAM, causing freezing and stuttering which can only be solved by restarting VRChat. Does not reset on world/instance rejoin, or going to a new world. I have noticed that RAM usage will be stable, then at some point, it just starts to pile on more and more. ONLY happens on VRChat, every other VR application and non-VR application doesn't do this. Don't know if the results are different on Desktop. This has been happening for a while now and I first started noticing it with the release of the Lunar New Year items update. Maybe could be something that happened there?

For Deaf users, the chatbox is a primary communication method. Typing text is equivalent to voice chat for hearing users. When typing at a normal conversational speed, the chatbox frequently triggers spam detection and applies a timeout. This occurs during regular back-and-forth conversation, not intentional spam. As a result, Deaf users are temporarily prevented from communicating at all, because our primary communication tool becomes unavailable. This creates an accessibility barrier where none should exist. This is not an improvement, but a big step backward in accessibility for Deaf players. I do not use TTS, so chatbox access is essential. Please excuse my English, as British Sign Language (BSL) is my first language.

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.

this has been an issue starting last year around October December but its only getting worse, so long story short trying to use vrcstations whilst in a saccflight air vehicle while on desktop (likely more things are being broken but this is what i know of at the moment), is causing the camera and player to be yanked from it was calibrated, I'm not entirely sure what is causing this as this wasn't an issue before on previously working worlds as they worked before whatever update from vrc broke the stations, i have updated the worlds that worked before still broken all the saccflight stuff works fine but for some reason it doesnt work anymore in vrchat i am attaching some photos that other users provided to the saccflight discord to help explain this better

When using VRChat's native hand tracking on PCVR, the hand movements that are displayed locally do not correspond accurately to what remote users see. The core issue appears to be that finger curl data is transmitted on a per-finger basis rather than per-joint, similar to the legacy Index-controller finger curl implementation. This leads to incorrect representation of specific hand signs, particularly those that involve fingers being straight but angled. Users employing custom OSC hand tracking do not face this problem, highlighting a discrepancy in how hand tracking data is processed and transmitted in VRChat. Steps to Reproduce: Use VRChat on PCVR with native hand tracking enabled. Perform hand signs that require specific joint-based finger curls (e.g., fingers that are straight but angled). Have a remote user observe the hand signs. Compare the hand movements observed by the remote user with what is displayed locally. Observed Result: Remote users observe incorrect or misaligned hand movements due to finger curl data being transmitted per-finger instead of per-joint. This issue is consistent across different users and instances, regardless of whether VRChat is restarted or even reinstalled. Expected Result: Hand tracking data should be transmitted per-joint rather than per-finger, ensuring that remote users see an accurate representation of the local user’s hand movements. This is essential for the proper execution of Sign Language and other precise hand gestures in VRChat. Frequency: Always Impact: This bug severely impacts users who rely on Sign Language for communication, as it prevents accurate representation of certain hand signs. The lack of precise hand tracking translation compromises the ability to communicate effectively using Sign Language in VRChat. Additional Information: The issue occurs across multiple users, instances, and devices. Users with custom OSC hand tracking do not encounter this issue, suggesting a difference in how tracking data is handled. Accurate transmission of hand movements, down to the individual joint level, is critical for Sign Language and other detailed gestures.

Go to a world with UI Have your friend stand in front of or inside the UI, preventing you pressing buttons Block them Try clicking the UI Nothing can be pressed - the UI cursor does not even appear. Even rejoining the instance does not fix this.

Be in a Group that Creates a Post Post is Deleted Before Reading it In-Game See Permanent Unread Indicator on the Group Posts until a new Post is Created

My profile picture resets to the avatar picture and icon is reset during the day a new vrc+ subscription period starts. This has happened for the past 2 months. I have subscribed via steam.

This is tested with 13 4K PNG textures; normal compression (first image), normal compression + crunch compressed at 50% quality (second image). Contrary to popular belief avatar download size (as suggested in unity) is not significantly reduce for avatar uploads; VRChats LZ4/LZMA compression is already handling the heavy lifting of download size reduction so there is evidently severe diminishing returns to using crunch compression. From my understanding the LZ4/LZMA algorithm is exceptionally good at finding and removing redundancy. Adding Crunch compression on top provides diminishing returns because there's little additional redundancy for LZ4/LZMA to compress. Here is what needs to be addressed immediately: Uncompressed size being drastically reduced in avatar stats when fundamentally this is not what crunch compression does. This in turn is letting people bypass the 500mb uncompressed download size limit. This whole dilemma could be resolved by simply disabling crunch compression for avatar, especially since crunch compression will cause loading textures onto the GPU to be a bit slower for virtually no reason.