Feature Requests

Please check out the following guidelines before suggesting a feature! Off-topic posts will be deleted.
Please do not favor the world based on the management's judgment.
Recently, a certain world has been featured on the VRChat menu banner. I've also heard that colliders have been disabled as a special measure for that world. Why is there such extreme favoritism toward a particular world? Is this world advertising based on money or a contract, like Sanrio VFES or VKET? This world is being treated exceptionally and preferentially, and as the world creator, I find this extremely unfortunate. I have two suggestions. Implement this as a permanent feature, rather than an exception for a specific world. Banners in the VRChat menu should be displayed based on fair and appropriate selection criteria. I am particularly critical of banner 2. This banner space is accessible to all VRChat users, and as a world creator, I find it extremely infuriating that the management is arbitrarily and favorably promoting a world in this space. Since it is a public area, fair selection criteria should be established. Here is an example. Sponsoring companies, organizations and companies that pay advertising fees, creators, etc. This is an area where a typical monetized platform would clearly charge money. It's incomprehensible that VRChat, which supposedly has no cash, doesn't do this. They should consider selling it as an advertising banner. Weekly or monthly world recommendations selected based on fair selection criteria I think popular worlds, with a few exceptions, will change over time. Why not use this as a place to highlight them? This would set certain criteria, such as having a certain number of visitors within a certain period of time and not having been selected before. I think this is a great measure that encourages a very fair and diverse range of worlds to be explored. At the very least, it's far removed from the current management's ego-driven selection process. I hope for fair management. 日本語 最近とあるワールドがVRChatメニューのバナーを飾っています。また、最近そのワールドへ向けて特別対応としてコライダーの無効化を行ったことを聞いております。 特定のワールドを極端に贔屓するのはなぜでしょうか。今回のワールド広告はサンリオvfesやvketの用に金銭や契約が交わされているものなのでしょうか?極端にそのワールドに対して非常に例外的で優遇的な対応が取られており、ワールド作者としては大変遺憾に思います。 私から提案するのは2点になります。 特定のワールドの為の例外対応ではなく、恒久的な機能として実装してください。 VRChatメニューのバナーは公平で適切な選定基準を元に掲載してください。 とくに、2のバナーに関しては強く批判します。このバナースペースはVRChatユーザー全員が触れる領域であり、このスペースを運営の独断で贔屓でワールド宣伝するのはワールド作者として非常に憤りを感じます。公共のエリアなので、公平な選定基準を設けてください。例を挙げます。 ・協賛企業や有償広告費を払った団体や企業、作者など 通常のマネタイズされたプラットフォームであれば明らかにお金を取るはずの領域です。お金が無いはずのVRChatがそれをしないのは理解不能です。広告バナーとして売り出すことを検討すべきです ・公平な選定基準を元に選ばれた週替りまたは月替りのワールドおすすめ 人気のワールドは一部のワールドを除き入れ替わっていくものだと思います。それらをピックアップする場とするのはいかがでしょう?これは一定の基準を設けて、一定の期間内に一定の来場者があって過去に選定されたことがない、などです。非常に公平で多様なワールドへの回遊を誘導できる素晴らしい処置だと思います。少なくとも現在の運営によるエゴによる選定とは遠いものです。 公平な運営を望みます。
5
Create a new version of VRCStation
VRCStation needs an alternative for many reasons. Here are some: Too many issues with the introduction of every new feature. Too many undocumented behaviors which seem to change from (client) update to update. Full of difficult-to-reproduce, obscure bugs that are much too time-consuming to debug for more casual creators. Excessively sensitive to implementation and usage factors to the point of total absurdity (Try putting an Udon behavior on the same object as a Station and writing to another Udon behavior's variable.) Changes behavior based on the number of people in a world. (I've seen this several times and it breaks the game.) It doesn't even know which player is sitting in it. Solutions to some Station issues are already in the SDK but not implemented apparently such as the animator fix for full body tracking which exists in the Avatar SDK but is missing in the World SDK. In practice, UDON Solutions and workarounds to VRCStation issues can work less effectively over time, demanding constant maintenance and causing worlds to stop working entirely. PROPOSAL: Because numerous existing worlds currently make (hard fought) use of VRCStation's quirks for actual features, you can't simply get rid of it, as this would break a huge number of very cool worlds. Instead of re-engineering the existing VRCStation (nobody wants that!), Create a brand new VRCStation alternative and creators may choose between the two (an extremely worthwhile choice to present compared to the alternative of not fixing anything). This new VRCStation2 should have the following: The Player must never be misplaced or "thrown" because of playspace origin or other factors separate from and totally irrelevant to the transform of their head. Players must always be positioned where they are expected to be at all costs even if it hits the frames a little to correct it (because the UDON acrobatics we have to do to make this happen without this assurance are going to hit frames harder anyway. Nothing is being saved by doing this quickly but incorrectly. I cannot stress enough how important this is.) The Station must have a public variable or method by which to get the VRCPlayerApi object of the player seated. The Station must be movable by any mechanism by which a GameObject can be moved (Animation, RigidBody, updating the value of the transform position/rotation), with no exceptions or conditions. Usage of this must be as simple as possible with no hidden/undocumented behaviors. The Station must not immobilize the arms of a player by default. In practice, players are expected to be able to interact with things with their arms when seated so it would never make sense for this to happen without the world dev explicitly specifying it. The Station must have a facility for player exit by calling a method on it/sending an event. This is imperative for ergonomics and feature-rich worlds. The Station must have the ability to NOT restrict FBT movement, as this is widely used by many players and there are entire forms of emergent gameplay and experiences which depend on this. There is currently a community workaround for this, don't break it. Stations should be able to sync their positions relative to their host GameObject. If a player is adjusting their seat, their position should be synced because without it, players don't know where each others heads are and this interferes with social interaction. It is unreasonable to require a world dev to have to crack into Networking in order to sync the position of seats because Networking is among the most difficult parts of UDON and most world creators will just skip it if this syncing isn't included in the component (and you can't really blame them, some people just want to casually make a room with a couch or something and don't have time to learn Networking). Stations should orient the player to match the Up direction of the Station's local transform, and NOT the Up direction of the world. The current implementation which orients to world's up creates a huge amount of nauseating misalignments where players end up sideways in a seat because it's on a vehicle, if the vehicle isn't completely flat, and in-practice it is absurd to ask players to only enter a vehicle when it's on flat ground. This might be a lot of things, and in general with some exceptions, it matches the functionality of VRCStation, but the key is that the new one needs to prioritize expected behaviors and cannot have the entropic "decay" in reliability exhibited by the current one. I have spent many hours trying to drag VRCStation into doing exactly what it's supposed to do, entirely because I needed to get events from it or any myriad of other various ways it can find a reason not to work right. This component's vagaries have even evaded the skills of friends that are far better at this kind of thing than I am. This component is a disaster and it's only getting worse with time. Surely, I can't be the only one who is at the end of their patience and resources in dealing with VRCStation. So please, for the sake of future world development and the health of the platform, please consider creating an alternative to the existing VRCStation component. Thank you.
18
EAC Blocks VMs Conflicting With VRChat's Statements Not Caring If People Use VMs
To be clear this is not asking for support, this is asking to configure EAC to not run it's VM detection at all. EAC can still run the same as it has and the security it provides is not changed. This will remove the Epic VM whitelist/exclusive special sauce for allowed VMs (to my knowledge only GeforceNow), and allow VM users such as ShadowPC and regular end-users to play in a VM without workaround s or custom patches to VM host software or guest software. This is not new but since EAC has been deployed it has been configured to block execution from within a VM. The current workarounds in the wiki do not presently work as of around the middle of January this year, and even at the time prove that EAC was attempting to block VMs, as it was looking for common VM smbios values to block the execution in conflict with VRChat's previous statements that they do not care if an end-user runs a VM or not. How it presently is trying to detect a VM I do not know exactly but I can tell that the methods to get VRChat to work solely with VM config tweaks do reduce performance and are windows guest exclusive: 1)Run with the hypervisor CPU extension disabled. (small performance loss) 2)run windows with the hyper-v platform enabled after ensuring the vendor virtualization cpu extension (SVM AMD/ VMX INTEL) is enabled. (massive performance loss) It is possible to configure EAC to not block VMs, all Fromsoft titles I have (Armored Core, Elden Ring, Nightreign) that include EAC run in a VM fine with no workarounds on both Windows and Linux. Tupper Promised to read this at a minimum :) (please and thank you)
17
Improve World Creator Tools for Handling Avatar Flight and Mechanics
Giving world creators the option to disable flight in their world can be useful for certain gameplay experiences. However, relying primarily on a global disable tag creates an architectural incentive that may unintentionally encourage restrictive world design. When the easiest solution available to world creators is a global toggle that disables avatar mechanics, many worlds will naturally default to using it rather than designing systems that work alongside avatar capabilities. Over time this can encourage a pattern where mechanics like flight, vertical movement, lighting utilities, and other avatar side tools are simply blocked instead of being integrated into world design. VRChat is a platform built around expressive avatars and user generated worlds. Historically it has succeeded because creators and users have a high degree of freedom in how they build experiences together. Avatar capabilities are an important part of that ecosystem. Many communities rely on mechanics like flight for legitimate purposes such as: • filming and cinematic capture • assisting other players • accessibility or mobility needs • immersive avatar identities (birds, dragons, flying species) • creative social experiences • event hosting and moderation These uses are not edge cases; they are part of how the platform’s social ecosystem functions. Gameplay-focused worlds should absolutely have the tools needed to protect their mechanics; the goal is to provide flexible systems that allow those protections without requiring avatar capabilities to be broadly disabled. The architectural challenge is that a simple global toggle solves an immediate gameplay problem for a world, but it does so by disabling capability from avatars rather than allowing creators to manage it contextually. Feature Suggestion Consider expanding world creator tools so that avatar mechanics like flight can be managed through contextual world rules rather than primarily through a global disable tag. One useful addition would be a platform-level spectator mode for instances that world creators can leverage through the SDK. This would allow worlds to shift users into spectator mode when appropriate while preserving avatar capabilities. For example, the platform could provide Unity-accessible systems that allow world creators to: • detect avatar states such as flight or large vertical displacement • disable gameplay progression or scoring while flight is active • allow users to manually enter spectator mode • automatically shift flying users into spectator mode when appropriate • optionally hide spectators in flight from active players or gameplay systems • prevent flying avatars from entering specific gameplay zones • provide triggers that allow creators to define custom interaction rules between avatar mechanics and gameplay objectives Instance hosts or moderator roles could also be given optional controls to enable or disable certain mechanics (such as flight or spectator mode) for their instance. This would provide session-level flexibility without requiring world creators to globally disable avatar capabilities. These types of tools would allow creators to protect gameplay mechanics while still preserving avatar expression and supporting diverse avatar designs. Design Consideration In a platform centered around user generated worlds, capability control tends to work best when it follows a layered model: • Avatar layer - defines what an avatar is capable of • World layer - defines how those capabilities interact with the world • Instance layer - manages behavior within a live session Providing richer world level interaction tools for avatar mechanics would help maintain this balance while supporting both gameplay focused worlds and social experiences.
0
Load More