Open Beta

In the latest Open Beta build, clicking the menu button twice opens the Main Menu. However, I feel this has increased the frequency of accidentally opening the Main Menu, which especially disrupts my in-game movement during critical moments. Requiring a double tap of both hand menu buttons simultaneously would be more intuitive, in my opinion.

In flight worlds it is very common to open your Quick Menu while flying due to the typically large distances between players. Previously, you were able to keep control of your plane while having your menu open because Saccflight constantly pulled the Input data for controlling the plane. However, in the beta build 1452 the Udon Input APIs were changed to not report any active inputs while VRChat menus are open. Because of the change, the player now immediately loses control of the plane when the Quick Menu is opened. This results in an overall worse experience for new and experienced players is worlds like Test Pilots. I am unsure what the reason behind this change is, but the easiest fix for this problem would be to simply revert the change. As an alternative, an option/toggle could be provided to world creators or users to choose what behavior is preferred.

Please revert the change with remote users' camera shutter sounds being controlled by "World" volume instead of "UI" volume. At least, this shouldn't be done without providing an option to mute or control remote camera shutter sounds separately There are different reasons why users might disable the camera sound, but mine is that it's really disruptive in large event instances where people are taking a lot of photos, and all you hear is *shutter shutter shutter*. Muting UI sounds before was more like an ok workaround since UI sounds aren't essential. But now that it's tied to world volume, it's pretty much impractical to turn off, especially in music focused event worlds See also this highly voted past canny: https://feedback.vrchat.com/feature-requests/p/be-quieter-the-camera-shutter-sound

There doesn't currently seem to be a way to access the spritesheet of an animated emoji once it's been created/uploaded. I find it odd that once you've taken photos for an animated emoji in-game and it's been turned into a spritesheet there's no way to properly recover the spritesheet, whether it be for safekeeping or editing the timing of the frames. I would really appreciate if there were a way (perhaps on the website) to access the spritesheet from an animated emoji.

It'd be great if there were an option for letting animated emojis loop by playing the animation backwards and bouncing back and forth rather than just the default behaviour of starting from the beginning. This would allow for a lot more interesting flexibility in how emoji could be animated using the in-game camera.

It would be nice if a float that matched the current avatar scale was exposed to avatar animators. Being able to adjust things on the fly based on the current scale would be wonderful. EG: Head proportion. When I make a taller version of my avatar I usually bump the head scale down to 90% to make it feel proportional. Some constraints with offsets will also break when scaled and this could be alleviated by letting us manual adjustment them based on the current scale.

Clicking on the clock in the QM should have it toggle between 12 and 24 hour time.

Previously the SDK used to display the version of your avatar. That functionality didn't "do a lot" but it was convenient to have as it sometimes helped with deciding what avatar you were uploading to. (If you have a dozen of the same looking avatar uploaded in parallel with very similar names, usually knowing "which one is the one with the BIG version number" makes it easier to figure out what ID youre currently uploading to. It was also just neat to see"You've uploaded this avatar 10 billion times"

In previous SDK, we can workaround avatar validation by calling VRC_SdkBuilder.ExportAndUploadAvatarBlueprint which was marked [PublicAPI] . I really need to call that to avoid false-positive Avatar Validation Errors. There are many false positive avatar validations errors: For Avatar Validation, EditorOnly can be skipped. Materials with pc shaders under EditorOnly may cause false-positive avatar validation errors. When we reduce some PhysBones with IVRCSDKPreprocessAvatarCallbacks, quest PhysBone hard limit error is false-positive. When we replace shaders with IVRCSDKPreprocessAvatarCallbacks, PC Shader errors are false-positive. Of cource, I think it's not good to skip validation, but pre-build validation can cause tons of false-positive. So, for Control Panel, I think it's OK to disallowing clicking "Build and Publish" button if there are Avatar Validation errors. However, for calling Build or BuildAndUpload by tools, please defer Avatar Validation after IVRCSDKPreprocessAvatarCallbacks . See Also: Canny about pre-building performance rank with Preprocess Callbacks Canny about post ProcessCallback Performance Ranks on build

Lots of world already exist that may not be actively maintained (either to enable scaling, or to add Udon limits) Such worlds would also have had to deal with avatars naturally very small/big It would however make sense to default disable scaling for worlds tagged as games, with all other worlds defaulting on