Feature Requests

Translated with DeepL.com (free version) In the current VRChat IK system, If there is a tracking point on the elbow And shoulder tracking is enabled If either condition is not met, the shoulder height when the arm is lowered will reference the minimum value of the shoulder's vertical range of motion set in Muscle. In this case, some avatars may experience an issue where the shoulders appear to drop lower than intended. To resolve this, one might adjust the Muscle values in the FBX rig settings, but doing so could potentially cause inconsistencies in the behavior of some animations. To address this issue, we would like to request the addition of a slider to adjust the “minimum shoulder height” within the IK settings in the VRChat client. Specifically, an ideal solution would be a slider ranging from “-100% to 0% to 100%”. Each setting should correspond to the “minimum value to 0 to maximum value” of the shoulder's vertical range of motion within the Muscle parameter, preventing the shoulders from dropping below the value set here. 現在のVRChatのIKシステムでは、 ・肘にトラッキングポイントがある ・肩のトラッキングが有効である いずれかの条件を満たしていなければ、腕を下におろしている際の肩の高さはMuscleで設定されている肩の上下の可動範囲の最低値を参照します。この場合、一部のアバターでは肩が想定以上に下がって見えてしまうような問題が発生します。 これを解消するには、たとえばFBXのRig設定でMuscleの値を調整する必要がありますが、これを実行してしまうと一部のアニメーションの挙動に齟齬が生まれてしまう可能性もあります。 この問題を解決するため、VRChatクライアント内のIKの設定項目に「肩の高さの最低値」を調整するスライダーを追加してほしいと考えています。 具体的には「-100％～0%～100%」のスライダーを用意して、それぞれをMuscleにおける肩の上下の可動範囲の「最低値～0～最大値」を参照するようにして、ここで設定した値よりも肩が下がらないようにできるのが理想的です。

VRAM usage is difficult to manage, and failure to manage it effectively results in disruptive app crashes. An option to sort the list of players in an instance by highest VRAM usage would present already-available info in a more usable way. Players could quickly choose avatars to hide to save VRAM.

Please add a feature to VRCSDK that shows the generated impostor right after appearing an avatar. Many users don't realize that their impostor is broken (for example, supposedly nude or with only a head) and also don't know that it can be checked in the avatar preview. To avoid this, I suggest considering an impostor check step into the avatar upload process. I would like the function to display the imposter generated after uploading the avatar will be added to the VRC SDK. Many users don't notice that their imposter is completely naked or that it's strange that it's just their head, and they don't know that they can check the imposter on the avatar confirmation screen. Then I think it would be constructive to incorporate a structure that can be checked during the process of uploading an avatar.

In some group setups, you might want a group of people to be able to invite to the group without being able to see or action group join requests, or cancel existing group invites Currently, the only permission is a merged Manage Group Invites "Allows role to create/cancel invites, as well as accept/decline/block join requests." It would be beneficial to have a permission to invite to the group, then a broader "Manage Group Invites" permission that does the same functionality as the old permission, and requires the new one

Allow users to follow creators so they see when they have released a new world or avatars. It may work best with just worlds for now. So for example if I upload a world and someone likes that world and wishes to see more from me they can follow me and when I upload a new map it will show up under a playlist. Similar to favourites etc.. Lets say you allow users to follow up to 3 creators so they get to see their worlds under 3 seperate playlists. Or you could have 1 playlist which is just called Following and only shows worlds from creators you follow.

We don't need more avatar slots, we need more world slots. Especially for those of us who like to explore.

Recently, in video recording, you can now switch the Audio Listener's position between viewpoint-based and camera-based in both the camera's stream mode and the VRC Drone's FPV mode. Please enable Udon to also retrieve the current location of the player's Audio Listener. This will ensure that world audio sources, which were previously controlled based on the player's ear position, will now be heard accurately even in stream mode.

Had 2 options when selecting to vote kick. Reason 1 - Nuisance Reason 2 - AFK Nuisance reason will be a bad strike on safety system. AFK reason will not effect the status of the player. Simply allows to kick someone who has either gone extended AFK or Sleep.

The English text is given below the Japanese text. I need a function to hide the specified world. There are many wonderful worlds, and unfortunately there are a small number of inappropriate worlds. Also, even though it is a world that should be evaluated by many people, there are also worlds that remind me of things that are painful for me. (Being able to experience the horror of disasters on this platform is meaningful, but for those who have actually experienced it, it may be something they still don't want to see.) Additionally, it has now been confirmed that there is a world where clients crash just by putting a portal into view. https://x.com/bell_kani/status/1691093178395570176?s=61&t=BFJrOw7ac7mgcpOjgX_VwA (I haven't been able to confirm this myself yet.) If you can spend your time without looking at these worlds, vrchat will be even more comfortable and fun to play! --- We need the feature to hide hidden worlds. Many Wonderful Worlds There Are a Few Worlds There are also some worlds that should be gratified to many people, but which reminds some people of worthwhile things. (Catching the horror of a disaster on this platform makes sense, but for those who have actually caused it, it may still be something they do not want to see.) In addition to this, there are currently confirmed worlds where the client appeared just by considering the portal into view. https://x.com/bell_kani/status/1691093178395570176?s=61&t=BFJrOw7ac7mgcpOjgX_VwA ( note I have not yet been able to confirm this myself). If these worlds could be kept out of view, vrchat would be even more pleasant and enjoyable!

Currently, the EVENT CALENDAR ONLY SHOWS EVENTS FROM GROUPS YOU HAVE JOINED. However, even with VRC+, the limit is only 200 groups, so if you want to join many events, you'll quickly hit that cap. This is especially true if you are also in groups that don't host events, such as communities or groups attend to a stance. The discussions of groups have proposed due to the event calendar (it can provide a reason for events that were not hosted by groups to move into groups). If the group join limit is not likely, it will no longer reflect the actual situation. Currently, the event calendar only shows events for groups that you have joined. However, even with VRC+, the maximum limit is only 200 groups, and if you want to participate in many events, you'll quickly reach the limit. This is especially true if you belong to a community that doesn't host events or a group that represents your claim. The importance of groups has increased dramatically due to the event calendar (events that have not been held in groups until now may be the reason for transitioning to groups), and if the upper limit on the number of group members is not increased, I think it will not match the actual situation.