Bug Reports

Using the VRC Avatar Parameter Drive to copy an animated parameter in an animator to a VRC Parameter does not work. Tested copying VRC parameter to another VRC Parameter, and that works. Tested copying an animated parameter to VRC Parameter in Unity editor using gesture manager and that works too. Tested on an otherwise empty avatar without any VRCFury or other addons modifying the upload process. To create a test, follow these instructions: * Create a VRC Parameter component with the following 3 parameters and add to an empty avatar. VRC_Input (Float), VRC_Output (Float), VRC_InRadial (Bool). * Create a VRC Menu component and add two radials. Name one Input, and set parameter to VRC_InRadial, and rotation to VRC_Input. Name the other Output and set rotation to VRC_Output * Create a Unity animator with all 3 VRC parameters as well as a new "Animated Property" float parameter. * Create an animation animating the "Animated Property" from 0 to 1. Have this animation as the only animation in its own layer in the animator, and set the Motion Time to VRC_Input (Thus the Input Radial in our menu will animate the "Animated Property" parameter). * Create another layer with two states, name one "In Radial" and the other "Outside of Radial". * Create a transition from "In Radial" to "Outside of Radial" and set the condition to VRC_InRadial == False. Then create another transition back to "In Radial" with the condition VRC_InRadial == True. * Finally add a VRC Avatar Parameter Driver to the "Outside of Radial" state, set the type to Copy, the Source to Animated Property, and the Destination to VRC_Output. Upload and test. Expected behavior: Adjusting the Input radial will update the animated property, and when exiting the input radial, the animated property is copied onto the Output parameter and thus visible on the output radial menu item. Actual behavior: The VRC_Output parameter is not updated when exiting the Input radial. Adjusting the VRC Avatar Parameter Driver on "Outside of Radial" state to copy from VRC_Input instead of Animated Property, then re-uploading the avatar, shows that copying from VRC parameters works. NOTE: It may appear that the Animated Property is not being adjusted by VRC_Input if you view the Debug Menu ingame. However, creating a third layer with an animation that animates anything visible on the avatar (lets say the scale of a cube or color of a material) and then setting the motion time on that animation to Animated Property proves that the value is still updated. This strange behavior might point to the cause of this bug.

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.

Since a recent update, Shadow users can no longer launch VRChat. It feels like we’ve been banned.

Self explanatory. I've spent a long time looking for friends at events only to realize they have a warp effect and are a nameplate-less diamond.

I discovered two avatar audio bugs in worlds from Udon that have a gimmick for changing the player's avatar audio. https://creators.vrchat.com/worlds/udon/players/player-audio/#avatar Executing SetAvatarAudioCustomCurve(false) makes the avatar audio for 3D settings for the local player extremely quiet. 3D settings mean that Enable Spatialization is checked for VRCSpatialAudioSource. This occurs regardless of the state of Use Audio Source Volume Curve. Executing SetAvatarAudioCustomCurve(false) for a remote player does not seem to affect the volume. Executing SetAvatarAudioCustomCurve(true) did not affect the volume for the local player, either. Executing SetAvatarAudioForceSpatial(true) makes 2D avatar audio noisy, regardless of whether the player is local or remote. 2D settings mean that Enable Spatialization of VRCSpatialAudioSource is unchecked and Spatial Blend of AudioSource is set to 0 (2D side).

Note: The behavior described below was tested using Meta Quest Pro and an iPhone (Live Link Face). I have integrated a system into my avatar that combines face tracking intended for “VRCFaceTracking(5.4.1.0)” with the Eye Tracking feature in the AvatarDescriptor. Recently, I noticed that the same avatar—which previously worked perfectly—no longer applies Eye Tracking, while the rest of the system behaves as expected. (By “Eye Tracking works,” I mean that the data read from the hardware is correctly reflected on the avatar.) After investigating in detail, I found that the likely cause is the “v2/EyeX” and “v2/EyeY” parameters, which are used by VRCFaceTracking. (Although I use AvatarDescriptor Eye Tracking, I was also using “v2/EyeX” and “v2/EyeY” for tongue movement with Meta Quest Pro.) As a test, I removed both “v2/EyeX” and “v2/EyeY” from VRCExpressionParameters, and AvatarDescriptor Eye Tracking started working again. To further isolate the cause, I tested with a standard avatar setup that does not include face tracking (an avatar with AvatarDescriptor Eye Look configured). After confirming that my gaze was being reflected using an iPhone and “VRCFaceTracking,” I added “v2/EyeX” to the VRCExpressionParameters. At that point, Eye Tracking stopped working. This seems like a minor issue, and I’m not sure whether the root cause is VRChat, “VRCFaceTracking,” a bug, or an intended behavior. However, since this behavior appears to have changed compared to how it worked previously, I would like to report it. ~Original Japanese (for reference)~ 「VRCFaceTracking」とAvatarDescriptorのEyeTrackingを併用するとEyeTrackingが動作しなくなる。（BN:1769） ※以下の説明の動作確認はMetaQuestProとiPhone（LiveLinkFace）で行っています。 私はアバターに「VRCFaceTracking（5.4.1.0）」を想定したFaceTrackingと、AvatarDescriptorのEyeTrackingを併用したシステムを組み込んでいます。 先日、以前は完全に動作していた上記のアバターが、EyeTrackingだけ動作していないことに気がつきました。 （EyeTrackingが動作するとは、ハードウェアで読み取った情報がアバターに反映されることを指しています。） 詳しく調べてみると、どうやら「VRCFaceTracking」用のパラメーターである「v2/EyeX」と「v2/EyeY」が原因であることが分かりました。 （AvatarDescriptorのEyeTrackingを使用しているのに、「v2/EyeX」と「v2/EyeY」を使用している理由ですが、MetaQuestProで動かせない舌を動かすためにこのパラメーターを使用していました。） 試しにVRCExpressionParametersから「v2/EyeX」と「v2/EyeY」を両方削除することでAvatarDescriptorのEyeTrackingが動作するようになりました。 また、問題の原因を明確にするために、FaceTrackingを組み込んでいない一般的なセットアップがされたアバター（AvatarDescriptorのEyeLookが設定されているアバター）で動作を検証してみました。 iPhoneと「VRCFaceTracking」を使用して自分の視線が反映されていることを確認したのち、VRCExpressionParametersに「v2/EyeX」を追加してみたところEyeTrackingが動作しなくなりました。 マイナーな問題で、原因がVRCなのか「VRCFaceTracking」なのか、また、バグなのか仕様なのか判断が付きませんが以前の挙動から変化があったため報告させていただきます。

I thought i was going insane for the longest time but after checking thinking that my centering was off but I realized it wasn't my fault in the end. The grid itself is off. (Attached file for middle section compared to top and bottom) (Middle row is shorter than top row by 3 pixels) (Middle row is same size with bottom row) (Right column is wider than Left column by 5 pixels) (Left column is wider than Middle column by 1 pixel) Also the overlay is clipping into the dark outer border of the camera by about one pixel.

Even when I switch the input method to one with an editing function (Japanese or Chinese) during gameplay, the editing function does not work. In the attached video, VRChat is launched with the English keyboard set as the input method. After opening an input field, type "English Input" with English Keyboard Input, and the input method is switched to Japanese IME. Then, "にほんごにゅうりょく (ni hon go nyu u ryo ku)" is typed, and an attempt is made to convert it to "日本語入力 (Japanese input)" which uses kanji. As a result, the Japanese IME conversion system does not work properly, and no text is entered. As a temporary workaround, switching to the Japanese IME and launching VRChat will enable Japanese input. However, if you switch to another input method with conversion functions (such as Chinese IME) in this state and attempt input using the conversion function, it will not work properly.

Currently in the VRChat SDK when uploading a world, it recommends an image resolution of 1200x900px. However as far as I can tell in practice, VRChat only seems to use 800x600px images, which is 2/3rds the recommended size, resulting in aliasing. So far in my testing this seems to apply to: 1) The website 2) The world image returned by the API 3) The world image as seen in the game client UI (all platforms) 4) Portals dropped in-game (all platforms) While often subtle, it becomes quite noticeable when an image has pixel art, which renders as blurry. The discrepancy between the stated and actual ideal resolutions results in world images looking less sharp than they otherwise could, and without clarification makes it uncertain which resolution to target for design and upload. Attached to this post are 5 images from my world VRCanvas to show the effect of the issue, in the following order (pay particular attention to the sharpness of the text): 1) Uploaded 1200x900 image 2) 1200x900 image as downscaled to 800x600 and displayed by VRChat 3) Uploaded 800x600 image (VRChat displays as-is) 4) Image #1/2 as it appears in a portal 5) Image #3 as it appears in a portal The ideal solution I'm requesting would be to fix the API/client to display in the native recommended resolution of 1200x900, since this is higher quality, and most worlds are already uploaded in this resolution per the VRCSDK's recommendation. If for whatever reason this is undesirable to VRChat (perhaps texture memory or bandwidth reasons?), then the VRCSDK recommendation should be changed to 800x600 to match what's actually the ideal resolution. If this is a texture memory concern, then a third option could be move to a new resolution of 1024x768, since this would still fall within the same power of 2 as 800x600 while still 4:3 aspect ratio and higher resolution.

In VRChat Avatar SDK 3.10.X and below, it is possible to run a simple exploit that bypasses the Poor rank. What does bypassing Poor mean? Normally, as soon as an avatar has one light source, the avatar is classified as Poor. If a user blocks Poor and Very Poor avatars, that avatar should be blocked. However, with this exploit, the SDK can be tricked into reporting the avatar as Good. Symptoms The avatar shows the Good rank in the Test SDK build The avatar shows the Poor rank once uploaded as a normal avatar The Poor avatar still behaves as Good even when labeled as Poor Steps to reproduce Create a Good avatar Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Increase the light count to 20 or even 1000 Upload the avatar as Test using Build and Test Result The Test SDK avatar is shown as Good Upload the avatar normally Result The avatar is shown as Poor and reports only one light source Now the absurd part Use the Poor avatar that was just uploaded Ask a second player to block Very Poor and Poor avatars Result The avatar is still visible even with Poor and Very Poor avatars blocked Affected Platforms: PC, PCVR, Quest How Curcial is this Exploit: I did a test in a private black cat instance. 25 Players did block my avatar. I was able to crash 18 persons by using this. Video showcasing the issue with the test avatar; https://files.catbox.moe/nv2h2c.mp4 Expected Result: VRChat should count every single Light Source no matter if its inside a particle system or outside a particle system. it should also be blocked on Quest (like it does on mobile)