Bug Reports

World tags should not be case sensitive. There is no reason why "chill" and "Chill" should be considered two different tags.

if I get any EAC error. It will make so I can't join the instance I was before I got the EAC error. It ends up in either a black screen or 3 load screen before getting me to the same world in a friend instance alone that was freshly created for me. Clearing the content cache didn't help. it lets me join instances of the same world and any other instance except the ones where I got the EAC error. Workaround is basically creating a new instance of the same world and inviting everyone there. There are 2 EAC errors that are confirmed to get the issue (see attachments). One happened on a group+, the other in a public instance. The world content data itself doesn't seem to be related to the issue (it could in theory happen on any world).

The Frosted Scribe has a mysterious bug where, after drawing the intended line, it automatically adds another shorter line—making it extremely difficult to use. Whether writing text or drawing diagrams, this unnecessary line constantly interferes, becoming incredibly frustrating. I've never experienced such poor writing performance with any of the VRChat-standard avatar trail pens. Because of this flaw, I'm reluctant to buy it—I think they should address this issue. Frosted Scribeは意図した線を書いた後にもう一本短い線が引かれる謎のバグ（？）があり、きわめて書きづらい。 字を書くにも図を書くにもこの余計な線が邪魔すぎてうんざりする。 VRChat一般に普及しているアバター用トレイルペンではこのような書き味の悪さを感じたことはない。 これがあるせいで購入を躊躇するので直した方が良いと思います。

Starting with the 28th of March, I'm receiving very frequent reports of users that YouTube videos fail to load in my world. After some testing I concluded that it's other worlds too. To quantify this problem I ran some data and visualized it. Since the 28th, the Error rate of videos in my world increased to around 20%, meaning every 5th video fails to load. This also exactly lines up with when VRChat had the yt-dlp resolver updated for the last time.

If a Contact Sender is already present in the instance, a Contact Receiver may fail to respond to it for the first time after the avatar is loaded. Behavior when the issue occurs: ・ The Receiver fails to react to a Contact Sender that already exists in the world. Even if a Sender is already active, the Receiver will not respond even if a third party's Sender becomes active afterward. ・ Toggling the Contact Sender off and then on again resolves the issue and makes the Receiver respond. ・ This occurs for both Remote and Local avatars. The reproduction rate is over 90 percent, but the specific trigger conditions remain unclear. We tested this across multiple clients and found that results vary depending on the specific client; interestingly, some clients never experienced this issue regardless of the pattern. During our experiments, all safety settings were disabled, and Show Avatar was enabled for all participants. The avatar used for testing is as follows. Since it has a very complex structure, please feel free to ask if you have any questions regarding its setup. Avatar ID: avtr_6257db3f-b32e-4ecb-9468-2e17e5a8c76c Testing Method: *This test is for verifying the Receiver on a Remote Player only. Two players wear this avatar. After the avatar loads, go to the ExMenu and enable SecretTalkSystem -> SecretTalkSystem Active. If a blue sphere appears above the avatar's head, the Receiver is correctly detecting the Sender. After confirming this, one player should switch to a different avatar and then switch back to this one, then repeat the same operation. Technical Note: ・The Receiver is designed to be always active as long as the Animator is loaded. ・The Sender is enabled via "SecretTalkSystem Active" when the avatar is in the PlayerLocal state.

VRChat sometimes crashes completely in VRDancing when multiple videoplayers are used simultaneously. In a recent patch for VRD I added a video preview feature and an additional TV that plays our livestream. Ever since that patch we sometimes have users crash to desktop, this has overall been very rare so its been difficult to pinpoint. It seems that when multiple instances of yt-dlp are used, sometimes VRChat will just crash completely. Which makes me believe this is a bug in VRChat itself. At most it should just, not play the video or crash some udonbehaviour. Not crash the entire game. Reproducing the bug is tricky, but we have about a 10-20% success rate by: Opening an instance of this build: https://vrchat.com/home/world/wrld_6434966b-411b-4c5e-b00b-c9390c9a7207/ Queueing and playing songs repeatedly as quickly as possible (Click "ADD" and then "SKIP") If the crash does not occur after 3 songs, create a new instance and repeat until the crash occurs. I wish I had more specifics, I tried to create more consistent reproduction steps but couldn't find any. The first frame is visible before right before VRChat closes. Nothing is displayed in logs besides the usual messaging that youtube-dlp/AVPro is loading the video. There are three VideoPlayers in the world, all of them use AVPro. Two of the videoplayers use my own custom wrapper, one of the videoplayers uses code originally based upon USharpVideo but heavily modified into its own thing at this point.

VRChat malicious client users have found ways to modify the transform VRChat emojis spawn in at to be near or at the Inf/NaN range for mobile GPU processors, which appears to initialize a GPU Driver timeout/crash. (This also applies to audio data!) Open VRChat on Android (Quest 2 (or 3), for this case) Have another VRChat user, warp 1e40 units away from spawn, then spawn a VRChat emoji, or conversely, spawn a VRChat emoji 1e40 units away from spawn using developer tools. If the previous step did not work, attempt at 1e20 or 1e30 units away. The Android user's client should crash, or, at the very least, freeze for the duration of the emoji. Note: This may affect more platforms than just Android Quest 2 (or 3), this is the only one I witnessed it occur on secondhand. As it requires client modification, I do not have means to reproduce this on my own without breaking the Terms of Service.

When Steam Audio was pushed to Live from Beta, (but not during beta,) many avatar sounds like those used in horror roleplay communities became much quieter or much louder, even dangerously so. Many of us adjusted our volume levels up and down to compensate, but I did way too much testing and found: Using default VRC_SpatialAudioSource settings, my test audio (with a lot of reverb and sudden attack) is overly compressed to nearly inaudible levels, sometimes as low as 20% - - This also caused creators to pump their volume up to compensate because we don't know what's really going on Using ANY of the advanced settings (near, volumetric radius, disabling spatialization, or using the audiosource volume curve) makes sounds play as as they do in Unity PLUS applying gain, making them LOUDER than they are outside of the game with the default Gain 10. - - Both Near and Volumetric Radius, separately, have volume at 100%+gain volume until you reach the end of their radius, then they sharply become very quiet or nearly inaudible until you reach the Far radius. - - This ends up allowing sounds that are dangerously loud, often unintentionally! I'm a bit crazy and wrote up a really detailed report here as I tested to understand what audio components were doing https://docs.google.com/document/d/14cukaZ_TlIyYHkErtD6E_z0QlCjDdVI58N1JkRAw_vI/edit?tab=t.0 ⚠️⚠️WARNING⚠️⚠️ the attached video is LOUD. I used earmuffs to visualize distance only. It shows 4 different audio sources with different settings on each: Default settings, which is Gain 10, Far 40, Near 0, Volumetric Radius 0, disabled Use Audiosource Volume Curve Default settings + Near 10 Default settings + Volumetric Radius 10 Default settings + Use AudioSource Volume Curve with 40 Max Distance on a Linear Rolloff Avatar for testing: (again, ⚠️ sounds are loud ) https://vrchat.com/home/avatar/avtr_f3133502-fdb8-4ea4-b612-6389767038a0

I was reading through Vrchat docs and found this launch option --disable-amd-stutter-workaround https://docs.vrchat.com/docs/launch-options After disabling it with launch option quest pro over steam link or virtual desktop is no longer stuck on 45fps all the time. This on an 7800x3d and rx 7900 xtx. It hits 90fps very much more often. Streamed headsets with HMD side reprojection should not need to go half refresh rate unlike displayport to have a good reprojection and i always found it strange it kept getting stuck on 45. I believe AMD have patches this in drivers since long ago. And this workaround is redundant and now leads to performance loss rather then fixing an issue. It should have been fixed for so long now that not allot people are on that old drivers anymore. I also did not find any stability issues enabled hardware video decoding with modern drivers. so you can give that a try aswell if you want to offload some cpu load --enable-hw-video-decoding

YouTube URLs seem to no longer work in most worlds and has been like this for almost every player lately.