Bug Reports

In the Avatar tab of the Main Menu, the Change Avatar button sometimes does not work by pressing it once. The message "Avatar changed to..." is printed, and the sound effect for the button plays, but the avatar is not changed. If I press the button multiple times, the avatar will certainly change. This issue often occurs if the menu is closed too quickly after pressing the button, but I am not sure of the exact cause. This issue has been present for several months.

A considerable amount of playback failures in VRChat is reported by players in Japan, within the week. Some claimed to resolve the problem by either disabling IPv6, or using a proxy service e.g. Cloudflare WARP. Essentially people are being banned as a bot using yt-dlp via VRChat. I wonder if VRChat can allow players to pass certain arguements to yt-dlp to provide their cookies (--cookies) or disable IPv6 (-4) Because to my observation, it does not work even if you create yt-dlp.conf in %userprofile% or the same folder with the yt-dlp.exe installation under VRChat.

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.

QM Unfavorite wrong description Open QM Select favorited friend from Wing hover over Unfavorite Button The bottom text says "Add Friend To Favorite"

Many game worlds use tracking of player's head positions to put important indicators or gameplay features, and many people don't realize that their avatars are preventing other people from playing the game properly. This is because to the local player, everything functions correctly. The udon call for 'get local player>tracking position>Head' tracks the actual head tracking of the player. But on other clients, head tracking is based on the avatar. It's a prevalent enough issue that I've had to start adding skeletons to avatars that don't use humanoid animations just so my avatars don't break the game experience for other players, but most people don't realize that this is an issue. A good way to test this is to go into a game like freeze tag, where above each player is supposed to be an indicator of what team you're on. However, if your avatar lacks a humanoid rig (visible or not), the indicator will be stuck at the position 0,0,0 for anyone else's client.

Reopening https://feedback.vrchat.com/bug-reports/p/local-players-dont-cast-shadows-caused-by-lights-in-avatars-on-cameras Expected behavior Objects comprising local players cast shadows in cameras similar to a player's view. Actual behavior Objects comprising local players do not cast shadows on cameras. "Cameras" means both photo camera and Camera components in avatars. Description / How to reproduce 1. Open test world I prepared a world for testing culling behavior: https://vrchat.com/home/world/wrld_8d64c603-280f-4dd9-811e-d1db875676ad This world contains spheres for each layers. (see also: https://feedback.vrchat.com/bug-reports/p/culling-mask-for-lights-in-avatars-modified-unexpectedly ) 2. Switch to the test avatar Switch to the test avatar that has a light with shadow. 3. Check casted shadow In the first-person view, the sphere in PlayerLocal layer is casting shadow. In the camera view, the sphere in MirrorReflection layer should cast shadow but actually not. It is tested with world object for easy observation, but meshes in the local avatar behaves similarly. Environment VRChat build 1392

Steps to produce: Launch Unity with 3.7.6 SDK Load your world Upload Android version Test it works = Works Upload iOS vesion Test it works = Works Join again with Android = World will not load nor pre-load Currently, the workaround is to upload the Android world again. But this happens always if you upload iOS world right after. Edit: World ID in question: wrld_6f12cc23-872d-40f1-8c1a-ad1682b92c97

Under a specific set of circumstances, viewing a player animated by a station through a render texture capture playing at a low fixed framerate, the animation plays significantly lower, but only when the player is not in sight/is culled. Please see below linked unlisted video, notice that the animation on the render texture screen is running at the same speed as the player on the station, but when the player is out of view the animation speed is greatly decreased. Recording of bug: https://www.youtube.com/watch?v=1WiejFIMvOU VRChat world showcasing bug (1 local and 1 remote player required): https://vrchat.com/home/world/wrld_577cf1a1-351a-439a-be79-517df198a9a4/info I discovered this bug originally in NeoWorlds, which is the reason behind the weirdly convoluted setup. You can also see this bug at play in that world(Unless you are very close to remote players they animate slower than you). NeoWorlds: https://vrchat.com/home/launch?worldId=wrld_544e7879-d870-42a2-9c7a-99eb95a8e62f Things required to replicate this bug, all found in provided world: Remote Player being animated by station animation controller Camera viewing that player and outputting to a render texture The camera is being activated by code using Camera.Render(), at a lower fixed framerate (using SendCustomEventDelayedSeconds). This issue does not manifest if the camera is capturing every frame. This is a new bug; I've only encountered it recently (first discovered 2/18), despite not changing the elements at play since I've last seen this working as intended. Have not tested if this bug is also present on quest.

On index controllers the wrists are rotated significantly differently than before the update. Everything attached to the wrists is now off, including any props. Included is a photo showing how the axies differ. The in menu wrist rotation does not fix the issue.

I have a generally slow internet. I have strict safety settings and I show avatars one by one. I've had multiple times where I win the lottery and start downloading a 200mb avatar and suffer. They also add insult to injury by quickly switching between multiple big avatars, all of which I would have to download. Download priority is coming up and that's great but wouldn't solve this particular issue.