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
Implement custom "global" physbone colliders
Currently physbone colliders have a fairly rudimentary implementation that is rather restrictive. Considering that prior to the introduction of EAC dynamic bones had a third party patch to allow cross-avatar interactions, you should finish this feature. Contact system is already there. Right now "global" colliders are only referenced from hands and fingers, as per the documentation, but avatars can have more objects that may need to collide: from anatomy to props and VFX. This is needlessly restrictive, and there exists no viable solution. Thus, here's a draft of requirements: Implement the ability to mark a physbone collider as a global contributor: use a separate property to define global contribution status If current implementation allows for it, implement runtime property updates to allow colliders to be promoted to (and demoted from) global status outside of build process "Global" colliders' permission model should follow that of the ones already implemented in hands and fingers Add a safety option that'd allow users to disable (or limit total count of) custom colliders on a per-user and/or global scales; the feature should be enabled by default, the limit is up to you to decide If count limiter is implemented, also implement a uint8 (single byte) priority property in colliders, which essentially would copy AudioSource's priority's behaviour (same priority objects can be non-deterministic, based on client's stack), starting at 255 (lowest) Add a boolean "{parameter}_Colliding" animator parameter to physbones themselves that is set upon a collision with any collider, global or listed Add a boolean "{parameter}_CollidingWithListed" animator parameter to physbones themselves that is set upon a collision only with colliders listed in the component's collider whitelist
1
·
in progress
Load More