Bug Reports

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

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 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一般に普及しているアバター用トレイルペンではこのような書き味の悪さを感じたことはない。 これがあるせいで購入を躊躇するので直した方が良いと思います。

This is a very, very specific issue that I have been wrangling with since at least 2021 or so, and I doubt it's happening for anyone else, or people just don't care enough to notice, but I figured I ought to report it anyway. This occurs both with and without FBT. Switching into any avatar in the game, calibrating my full body, and placing my arms at my side reveals that my arms are not centered about my body. Additionally, my avatar has a very slight lean to it. Currently the problem is solvable, but it requires a trick in SteamVR to basically lie about where my hardware is physically located (OpenVR Input Emulator), adding a ~2cm right offset to my HMD. Since this is not so easy to explain with words, I have recorded my raw VR view and demonstrated the problem and how I fix it for myself: https://youtu.be/jvfrAz4HVL8 And, since it is a very legitimate question that might come off as a bit impolite to ask, I will answer it ahead of time: I did indeed check my real physical self to make sure my spine isn't messed up or something, and I can confirm that I stand up straight as an arrow in person :P Addendum: I have also checked my playspace configuration. This has persisted across several different spaces as I have used different parts of my home for my VR setup. I'm using an Index with 3 Lighthouses.

This issue was mentioned by Franada as the sole reason for the T-pose layer still existing in Gogo Loco. Please ask them for more details because I do not really know much about this other than what they have said. When asked about what the T-pose layer is for: > fix the slight x offset the unity tpose have > that the reason when you bind you feel a little shifted on the side. the tpose fix that ... > but vrc could havea proxy tpose to fix it yes

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.

Any avatar with Marshmellow PB post patch is good example of this local jitter and does not show up in a screen recording using OBS. The issue seems to be tied to frame rate and at 60 fps locked it functions normally, however above that its appearing to jitter extremely fast while locomotion moving. Can only observe this behavior in first person POV. Looks totally fine in a mirror with 0 problems. I did not notice this before but maybe im just crazy. Either way there is a issue.

If pressing "enter" many times after typing stuff in the chatbox, It just bugs it for a few seconds and makes the chatbox impossible to type with, (invisibility of words and letters, can only see if the person is using the chatbox but nothing will appear on the chatbox if you type anything.), And also it's very annoying, It happens to me often and i hate it so much. If it can be fixed, Thank you so much, If no, It's not your fault.