Feature Requests

Please check out the following guidelines before suggesting a feature! Off-topic posts will be deleted.
Want to see expanded functionality for events in the instance form
There are a lot of events among Japanese users, and a lot of events are held on VRChat every day, there is a limit to how much human processing can be done, so we would like to see the system expand the functionality for events to be able to handle them. Currently, there are 2 mainstream participation formats. ■First-come-first-served The instance will be set up in the Friend+ format prior to the opening time of the event, and all owners and staff will gather with the status of Ask Me in advance. Then, at the opening time, the instance owner will change the status to Online or Join Me, and those who wish to participate will join the instance owner. 👎️Problems with this format ・The instance fills up in just a few seconds at times, but.., some users (e.g., users with many friends?) are sometimes slow to reflect or do not reflect well the status changes of other users, making it difficult for such users to participate in this form of event. ・Also, if someone is in Online or Join Me status when the staff gathers in advance, non-staff users can enter the instance. ■Pseudo lottery style The instance will be set up in the Invite format prior to the opening time of the event, and owners and staff will gather in advance. Then, at the opening time, those who wish to participate send a Request Invite to the instance owner, the instance owner selects participants at random and sends an Invite. 👎️Problems with this format ・Dozens or hundreds of Request Invites may be sent to the instance owner all at once, but all Request Invites sent in large numbers are not retained, and the oldest ones seem to disappear after a few dozen, and users whose Request Invites disappear are lose their right to participate in the lottery. ・Also, the instance owner manually handles the countless number of Request Invites that are sent, this is a heavy burden for the instance owner, who has to manually handle the countless Request Invites sent to him or her and be careful not to send more Invites than the number of people who are eligible to participate. ★Functions we would like to propose (example) ■Implement Instance Open functionality for Instance Close. ・I want you to be able to re-open an instance that has been closed once. ・Even in the Closed state, we would like you to implement a state that accepts Invite and participation from URLs. ・In the case of Group instances, if they are in Closed state, they can be lined up in Join Queue even if the instance is not full. ・If possible, I would like you to implement a function to automatically open and close at preset times. 👍️Benefits of these implementations ・When a Friend+ instance is built with the status of Closed in advance and the staff gathers together, when a Friend+ instance is built in advance and the staff gathers, even if someone is in Online or Join Me status, users other than the staff will not be able to enter the instance. ・If the instance status is set to “Closed” after all participants have entered, the original participants can return to the instance without new participants entering the vacant slots in the event that a staff member or participant has an equipment failure or other problem. ・In a Group instance, even if all users in the instance have “Ask Me” status, if they have joined the Group, they will be displayed in the Group Activity and any user in the Group can join the instance, However, by creating an instance with the status of Closed in advance, only the staff can gather at the instance first, making it possible to utilize the Group instance more effectively. ・Also, since instance owners do not need to change their status, it may be easier for users whose status changes are not reflected well or are reflected slowly by other users to participate in first-come, first-served format events. ■Implemented a feature in Join Queue that allows users to be randomly selected from the Queue to join an instance, rather than on a first-come, first-served basis. ・(In conjunction with the above “In Group instances, the ability to line up in Join Queue even if the instance is not full if it is in the Closed state”) Please implement a function that allows users to enter the “lottery participation” queue of a closed Group instance, and when the instance is subsequently opened, users in the lottery participation queue are randomly selected from among those in the lottery participation queue, rather than on a first-come, first-served basis. ・Also, it would be very nice to have the ability to set up a winning quota for a pre-determined number of people at a pre-determined time! 👍️Benefits of these implementations ・The need for instance leaders to manually process Request Invites is eliminated, significantly lowering the cost of event management. ・This will ensure that all participants are equally entered into the drawing, since there will be no more users who lose their right to participate in the drawing due to the disappearance of a Request Invite they sent.
0
Different availability statuses for different favorites lists
tl;dr: A separate status for "Online Friends" not in any favorites groups, and separate statuses for each favorites group. The highest level of availability applies to people in multiple favorites groups. This is a suggestion I've heard floating around a lot but haven't seen posted (unless I missed it). It's often repeated nowadays that VRChat isn't as fun as before due to everybody being on orange / unavailable. As somebody who is always on orange myself, I stay on that status for two reasons. The first is that I accept friend requests from kind people I don't necessarily know too well who I wouldn't want to mix with my close friends. The second is to keep some friends groups separate either due to them explicitly stating so or just my own judgement. I would like to instead have a different set of statuses for different people I can set as needed. For instance, if I'm streaming I would be unavailable to most but joinable by a list of people I trust to be in my stream. If I were just hanging out and relaxing I would only be available to join by people I'm very close to. And I could have a different status on a favorites list of people I trust to join me in any situation. I think most people on orange have a lot of friends they would trust to join them in most cases, but their friends list is so full that they have to be selective. I know most people now see orange as unavailable and won't even send the request out of not wanting to be rejected. I think having different statuses for different people / favorites lists would clear a lot of this up and bring some of the fun back. This would be an effective resolution to the "orange status" problem even if it were only applied to one favorites list.
7
Add support for the Unity LOD Group component OR develop an efficient equivalent for avatars
At current, there is no method to use LODs for avatars, which is one of the primary causes of poor performance in populated instances. VRChat has implemented several workarounds to this issue, but not addressed the issue directly; developing functions such as hide by distance. Whilst this is a great feature for lower to mid spec systems, this leaves a gap for users with higher end machines or who prefer visual fidelity and sense of presence over framerate. It is common practice within game development to use LODs on assets such as characters to save on system resources by doing the following: Reducing material complexity, i.e. using simpler / less fancy materials. -> As a practical example, disabling a grab pass on LOD1 and beyond. Reducing armature complexity to reduce the amount of physbone transforms to compute per avatar & disabling collisions. -> Another practical example of this would be a mechanical avatar using VRC constraints and physbones in tandem to obtain a certain stylistic choice could be simplified within certain LOD group ranges to reduce the amount of processing the CPU has to do. Reducing the resolution of textures to reduce VRAM usage. -> Whilst VRChat already has implemented mipmap streaming, this does not reduce the amount of memory being used. An implementation VRChat could use to handle proper texture management would be if an avatar has been in a specific LOD zone for too long, it unloads the streamed mipmap texture from memory and replaces it with a lower resolution texture. The correct high resolution texture could then be put back in its place upon entering a closer zone. There are also multiple ways in which LOD handling could be done: Allowing users to select a faster performing version of their avatar they have uploaded. Allowing multiple LODs to be uploaded into the same avatar, with the client dynamically changing to the necessary avatar. Automatically falling back to imposters when beyond a user-defined limit. -> This option would replace the diamonds we see with distance hiding. ->-> This should not replace the diamonds we see at current, rather being an intermediary step between the full avatar being shown and hiding the avatar entirely. ->-> This would also reduce the requirement of the animator being permanently loaded even if the remote user is multiple hundred meters away. -> This option would more than likely be the simplest to implement.
0
Load More