Bug Reports

  • No off-topic posts
  • Don't report more than 1 issue at once
  • For isolated issues or customer support visit help.vrchat.com
Thanks for your bug report!
Guests queueing early to skip queue
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.
2
·
tracked
Scaling Worlds (and Avatars) cause eyes to go crosseyed
Now that Scalers are possible through OSC (essentially using the same system that Scaling worlds use), this is a bug that's been bugging me ever since the scaling world features came out. Whenever you scale past 20 meters, it is exceptionally noticeable. 1) Go to any World scaler (Jet-Dog's Prefab world is a good place to look at it. Otherwise Little Big Town) 2) Scale up to 100 meters 3) Check your Personal Mirror (or camera), move your head around and watch your eyes go cross-eyed. What is happening (As I understand it): Avatars have a fake-gaze target that the eyes will point at when no face tracking is available. When you scale to larger and larger sizes, that Fake-gaze position gets closer and closer to the avatar. The distance to that fake gaze target stays the same distance, but the avatar itself is larger. Meaning that the fake-gaze target does not scale along with an avatar. To put what's happening into words for example: At 2 Meters -> Fake gaze target is 4 meters away (Not sure if this is the actual number but it's just for example's sake) At 5 meters -> Fake gaze target is 4 meters away At 10 meters -> Fake gaze target is 4 meters away (unnoticeable) - This is equivalent to something being about 80 centimeters away At 20 meters -> Fake gaze target is 4 meters away (Barely unnoticeable) - this is equivalent to something being 40 centimeters away from your face At 50+ meters -> Fake gaze target is 4 meters away (VERY noticable) - this is equivalent to something 20 centimeters away from your face up to looking at your nose and being crosseyed. Very annoying and long-standing bug, I wish it were fixed. (Cannot confirm or deny if this happens on Quest, I only play on an Index and see it on PC)
1
·
tracked
Request for Video Player Maintenance and Improvements
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.
10
·
tracked
Load More