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)

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

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.

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

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.

“Hidden” is expected to almost completely hide being a member of that group, but it actually reveals membership to friends who belong to the same group. This is inappropriate behavior for “Hidden,” so I feel it should be changed to behave as expected. If this is the intended specification, the label should rename to something more suitable.

My friend closed VRChat through Meta's Universal Menu Then I closed my game too after ~25 minutes we went back in the group instance then there was the other character of him everyone who rejoined can see it, before they were not able to see it. We are both on separate versions My friends build number is 1629 I have put my build number in the Build number text field below He is the group owner and he can't kick, ban or warn anyone

The number of animation layers heavily affects performance due to unnecessary inverse kinematic calculations. Even blank animation layers with zero weight in the FX layer can trigger this behavior. The offender is seen in the profiler as Animators.IKAndTwistBoneJob. It runs as many times as the currently loaded animation controller with the largest number of layers. Although the individual run time is small, they very quickly add up. Slower CPUs seem to be more adversely affected by this. The time taken by these extraneous calculations quickly grows larger than all normal animator activity. This behavior only happens on animators that have a unity avatar/armature. When that is removed, this behavior goes away and the number of layers ceases to be a significant cause of lag. Most FX layers do not have any interaction with the armature, so it is likely that this behavior can be fixed for almost all FX layers. However from debugging the unity editor in visual studio, it appears the this happens in a native unity function named Animator::UpdateAvatars. It is likely that in most if not all cases, these calculations are completely wasted on FX layers and provide no benefit at all while consuming significant amounts of main thread time. Somehow these calculations need to be only run for layers that require them. Additionally providing a way to get parameters in sub animators would allow logic to be moved out of the main animator completely sidestepping this problem. They would not have a unity avatar associated with them, so this problem would not occur. It would also allow completely disabling animators when not in use. Please attempt to find a way to prevent this behavior or consider convincing your Unity contacts to implement a fix. This seems to be one of the largest contributors to animator lag. I have a full write-up with more profiler images and further explanations. https://docs.google.com/document/d/1SpG7O30O0Cb5tQCEgRro8BixO0lRkrlV2o9Cbq-rzJU

Following up on this completed Canny and developer update from last month , the issue isn't fully resolved. Group members with the "Create Members-Only Group Instances" permission do not see the ability to make group public instances in the VRChat client, but they can still make group public instances and invite themselves by manually crafting a public instance link in the browser. Current mitigation until VRChat resolves the issue: Don't allow group members to open Group instances. Enabling Group+ instance creation does not allow the exploit. The last exploit was left open for over a year. I hope this one won't see the same treatment. I'd really like to allow our group members to create their own group instances without the risk of having unauthorized public instances opened. Thank you to our community member Joakorex for bringing this to our attention. <3