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!
Toggling a VRCPhysbones Enabled Status that has Gravity won't smooth in some worlds.
The Physbone gravity works differently when being toggeled on/off in some worlds- while in some it's perfectly smoothed, in some other it's being delayed by a couple of seconds or it jumps very harshly I can't pinpoint a world related origin of the issue- seems to be both in Live and current Beta Build and the worlds I've tested, were updated pretty closely to each other. TL;DR: It must be gravity set higher than 0- for some reason it won't get smoothed in some worlds. How to reproduce: Create two empty GameObjects and a cube (Remove colliders!). GameObject 1/GameObject 2/Cube (Stretched long for better visuals) Put the cube in Ignore Transforms Put the Physbone on your avatar hand and rotate it until it has the same direction as the index finger. Physbone Settings on GameObject 1: Version 1.1 (1.0 also doesn't work) Integration Type: Simplified Pull: 0.1 Spring: 0.2 Gravity: 0.9 Collision 0.02 No Limits Allow Grabbing: True Allow Posing: False Snap To Hand: True IsAnimated: False ResetWhenDisabled: False Add animations to toggle the active state of VRCPhysbone (I've tested it in WD Off with Physbone being off on start) Go into any of the mentioned worlds and having an animation that toggles the enabled status of the GameObject 1 VRCPhysbone on/off Buggy: LPD Station (Updated 03/11/2025), Just B Club (Updated 03/12/2025) Working: Avatar Testing Chamber (Updated 02/14/2025), Sovren's Chill home (Updated 03/15/2025) Further Tests I've done: With or without Physbone limit doesn't matter It being attached to a parent constraint as an avatar GameObject child or not (parented directly to the hand) is not changing anything IsAnimated and ResetWhenDisabled doesn't matter whether it's on/off It must be gravity set higher than 0- for some reason it won't get smoothed in some worlds.
1
·

tracked

Connecting to a Discord Voice Chat Can Sometimes Cause a Disconnect.
This is a bug that is difficult to reproduce, and doesn't occur consistently at all, but I've observed it for the past couple of years at least, and felt like finally writing something about it. I will note that this has occurred across entirely different installs of Windows. Upon joining a Discord voice chat, it can sometimes cause VRC to immediately disconnect, like down to the millisecond that you joined it. This normally throws the error: "Your connection to VRChat was interrupted. Verify connection and try again." Looking at the logs, the only bit that looks relevant is: > Connection lost. OnStatusChanged to SendError. Client state was: Joined. SCS v0 UDP SocketErrorCode: 10055 AppOutOfFocus WinSock Not sure what's causing it, but yeah just some weird behavior that I've observed for years and just thought I'd mention it. I notice that it usually tends to happen when it's the first time I've joined a Discord VC in a while, it seems to not happen again for a days afterwards. It seems most likely to happen if you reboot entirely, load into VRC first, then load up Discord and join a VC, it might happen that first time but then never happen again for the rest of the day. If anyone else has experieced this, and might know more, please leave a comment. I have a feeling this might be one of those strange bugs that are weirdly specific and difficult to diagnose. (IE: https://feedback.vrchat.com/bug-reports/p/25gbe-lan-causes-jitterting-problems-exclusive-to-vrc ). For all I know this could be specific to my machine or my network for some reason, so some confirmation from others would be nice. Thanks.
6
·

tracked

yt-dlp eats multivariant HLS playlists - proposed solution included
Open a multivariant playlist in avpro in-game - most playlists from https://hlsjs.video-dev.org/demo/ will work. https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s-fmp4/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8 for example. Notice you have no audio. What appears to be happening is yt-dlp is always picking the first applicable HLS stream, recursing until it finds something with actual video. As a result, it can result in selecting an m3u8 that is invalid. It is also part of what causes VRChat to be unable to play youtube videos at high quality, thus needing a custom yt-dlp fork. One solution I can suggest is having yt-dlp standard (or a fork still, but closer to standard) be used to construct multiple URLs - --get-url results in multiple lines returned in these cases, still abiding by filters, though -J is likely more ideal here as it will output all info at once, you'll just need to filter in your own logic rather than passing the filter into yt-dlp's command line. For actually playing back - and then constructing a temporary .m3u8 in the format of: #EXTM3U #EXT-X-VERSION:4 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",NAME="audio",AUTOSELECT=YES,URI="<full audio m3u8 url>" #EXT-X-STREAM-INF:BANDWIDTH=<video *max* bandwidth>,AUDIO="audio" <full video m3u8 url> This has been tested on windows and it plays back correctly. For example: #EXTM3U #EXT-X-VERSION:4 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",NAME="audio",AUTOSELECT=YES,URI="https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s-fmp4/f08e80da-bf1d-4e3d-8899-f0f6155f6efa_audio_1_stereo_128000.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=628000,AUDIO="audio" https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s-fmp4/f08e80da-bf1d-4e3d-8899-f0f6155f6efa_video_180_250000.m3u8 Using yt-dlp standard with JSON, the video bitrate can be extracted from the tbr field - it's in kbps, so just multiply by 1000 and make it an integer and HLS will take it. Using AVPro's MediaPlayer::OpenMediaFromBuffer() call can take this HLS playlist directly, which is useful for both security (time-of-use related stuff) and general performance. The proposed HLS playlists are the minimum required to get proper consistent playback. As per spec, BANDWIDTH needs to be set to the maximum bitrate, not the average, to allow buffers to be allocated large enough for smooth playback, and is a required tag to operate - but it'll survive if it's not perfectly accurate, tbr is a good enough value to use.
4
·

tracked

Load More