Open Beta

Having components that people need to put in the middle to access some APIs on these types as suggested in https://vrc-beta-docs.netlify.app/worlds/components/textmeshpro/#udon-wrappers is pretty unintuitive. It'd be better if they could just have their classes exposed directly. TMP_Dropdown would need some handling for setting options in the list which could be done with extension methods ex:

If you open the Camera tab, the options still show for Photo Camera and Stream Camera. VRChat Plus features include Icon Camera, and Gallery Camera. I expected both, the Photo Camera and the Gallery Camera to double as a Print Camera, or have buttons to switch between them. "Gallery Camera" still seems like confusing lingo for VRChat Plus users, because it's ambiguous on whether it's taking a Photo or Print. These features should be merged, or better yet, be able to switch a Photo Camera with a Print Camera in the camera menu's UI.

I understand the need to promote your subscriptions, but placing an ad in the quick menu feels unnecessary. The quick menu is supposed to be minimalistic and straightforward. You already have plenty of opportunities to advertise VRC+, like in the banner or when clicking the profile icon. There's no need to clutter the quick menu with it. This space would be much better used for important features, like the upcoming Udon Menus!

A simplified version of the keyboard input field has been added in Build 1511. This simplified input field is the default display on mobile, desktop, and Pico platforms. In arguing that copying and pasting functions, such as extracting URLs for videos or images, outsourced world saving data or generated content to the InputField, and copying them, the copy And paste buttons are extremely important. I believe that the advantages of these buttons in the default display are easily usable. Please add copy and paste buttons to the simplified input field, as shown in the attached image. * This was written using a translation tool. ==== The following Japanese text ==== A simplified version of the keyboard input field was added in build 1511. This simple input field is the default display on mobile desktop Pico. The copy and paste buttons are extremely important in gimmicks that use copy and paste, such as inputting URLs for videos, images, etc., or outputting saved data and products from the world to the InputField and copying them. I think the fact that these buttons are hidden in the default display greatly reduces convenience. Please add copy and paste buttons to this simplified input field, as shown in the attached image.

Build 1515 introduced disabled action buttons > Both the "Request Invite/Join" and "Send Invite" buttons in the user details menus will now be disabled instead of disappearing and causing other buttons to shift. This would make well-trained users' muscle memory happy but may also confuse people who are not familiar with the system's behavior. So, I suggest showing a tooltip on disabled action buttons and guiding why it is disabled.

It's currently impossible to swap which hand you're placing a sticker with, unlike portals. I'd expect to be able to hit right trigger for the laser to swap to my right hand despite using my left action menu to select it.

The "Show Additional Information on Nameplates" option seems to have changed behaviour: nameplates now always appear when the quick menu is open regardless of any other settings. Not sure if it's a bug or intended change. It used to be that if nameplates were hidden and that option was disabled, nameplates would not appear even when opening the quick menu. This was great for immersion and allowed for a more natural social experience at times. Now nameplates always appear when opening the quick menu. No combination of settings prevents that (for me, at least. Someone else claimed they got it working somehow? I tried for quite a while with no success) The new behaviour is more consistent with the tooltip description but I miss not having a more immersive mode. A new "Don't show nameplates when opening the quick menu" toggle would be ideal if there's no interest in restoring old behaviour.

While it's convenient to have quick access to the VRC+ settings from the QM, I believe its placement would be more consistent if it were positioned just before or after the Settings tab, aligning it with its placement in the MM.

A user may upgrade constraints on their avatar, thinking they've covered everything, but the VRCSDK would miss upgrading any controllers being merged by VRCFury or other non-destructive merging tools. Please add a public API method that allows us to silently run the upgrader on a given avatar descriptor, so that VRCF can non-destructively ensure the avatar is fully upgraded once any additional controllers have been merged during the upload process.

Opening this again as https://feedback.vrchat.com/open-beta/p/add-a-public-vrcsdk-api-method-for-silently-invoking-the-constraint-upgrader is not the same issue and was probably inappropriately merged with Fuka's post. In 3.7.0-beta.1 there is an auto fix for converting existing constraints to VRC Constraints. This enumerates animation clips in the animator controllers attached to the avatar descriptor, and rewrites their curves to match the new constraints. However, it will not be able to identify animations merged using nondestructive utilities. Thus, when the user runs the auto fix, they'll end up with components converted, but animations left unchanged (or vice versa). While Senky's post is a useful one (we could invoke the converter at build time to help address this issue), being able to invoke the conversion process from our tools does not resolve the issue of the auto fix action, when invoked manually by the end-user from the VRCSDK UI directly, missing animation clips that need adjustment. As such, an API is needed to allow nondestructive tools help the VRCSDK discover any additional animation clips that need to be processed during this manual auto fix invocation. Note also that both VRCFury and Modular Avatar perform animation path rewriting, so your API will need to be amenable to this as well. MA currently only does prefix rewriting, but I have plans to add more advanced forms of path rewriting in the future.