Feature Requests

Please check out the following guidelines before suggesting a feature! Off-topic posts will be deleted.
Allow worlds/Udon to officially control the local listening position and orientation (consistent on Desktop and VR)
Current problem: Some worlds use an AudioListener-based workaround to simulate moving the user's ears to another point in the world, for example for dummy-head ASMR style effects. However, on Desktop, when the listening position is moved this way, distance and volume appear to follow the moved listening point, while directional localization (left/right directionality) still remains tied to the player's original viewpoint. As a result, the gimmick does not work correctly on Desktop. The same gimmick works as intended in VR. I have also confirmed a difference in PPC° between VR and Desktop in the Audio Sources Debug View. I can provide screenshots and other supporting material if needed. Use cases ASMR / dummy-head style "ear-level" audio presentation using a listening point placed in the world Observer camera / special viewpoint gimmicks where the visual viewpoint and listening point should be separated Audio-driven experiences where distance and direction should be designed around a specific in-world ear position Requested change Instead of relying on unsupported AudioListener-based workarounds, I would like an official and safe way for worlds/Udon to control the local user's listening position and orientation (listener transform). Requirements: It should work consistently on both Desktop and VR Directional localization should update correctly, not just distance attenuation / volume It only needs to affect the local user Network synchronization is not required Why the current workaround is insufficient AudioListener is not part of the allowlisted world components, so it is not an officially supported component for worlds Because of that, platform differences (such as Desktop vs VR) and future breakage are difficult to avoid VRChat already has official functionality such as Audio from Camera, which changes where audio is heard from For that reason, it would be very helpful to have a similarly official and safe way for worlds to specify a local listening point Scope / non-goals This is not a request to bypass normal audible range, occlusion, or existing voice distance rules This is not a request to force other players' listening positions to change A local-only solution is sufficient This is not intended for eavesdropping or expanding what a player is allowed to hear beyond normal rules Possible safety constraints would be fine, for example: Explicit per-world opt-in Local-only behavior Existing distance attenuation and audibility rules remain unchanged Minimal repro Minimal repro world: https://vrchat.com/home/world/wrld_c84d1e3b-d5bb-410d-b407-064b49fb56db Repro steps: Join in VR → the gimmick works as intended, with both distance and direction matching the moved ear/listening position Join on Desktop → distance / volume follows the moved listening position, but directional localization still remains based on the original player viewpoint If needed, I can also provide the following on request: A VR vs Desktop comparison video Debug View screenshots (Audio Sources: PPC°, Dist, lG/rG dB, d) VRChat version / build number
0
Reboot development of Udon UI
Recently, the number of sophisticated world gimmicks has increased, along with the increasing number of controls and settings. This has forced world creators to design their own UI menus and implement unique methods for accessing them. Especially in large worlds, users need to be able to access the UI menu from anywhere. For example, in VR, they can double-click the trigger, hold down the right stick, or use a gesture. On desktop, they can press the E or Esc keys. These methods can even interfere with the controls of the VRChat client, which has seen an increase in functionality in recent years. For example, pressing up on the right stick causes Vive Wand players to jump. Pressing the E key interferes with camera control. (One reason for this is that Udon cannot receive menu button inputs.) Meanwhile, users often become confused by or even fail to notice the different ways to access UI menus in each world. World creators must always provide guidance on how to access the UI menu. I know that in the past, development of a Udon UI accessible from QM was underway, but that work was suspended. https://ask.vrchat.com/t/developer-update-16-february-2023/16474#p-33374-udon-ui-in-the-quick-menu-14 https://ask.vrchat.com/t/developer-update-16-march-2023/16950#p-34625-update-on-udon-ui-9 https://ask.vrchat.com/t/vrchat-sdk-roadmap-may-2024/24243 From my perspective, a significant factor in this was the amount of time spent supporting smartphone platforms. Smartphone platforms have already been released for both Android and iOS. Now is the time to reboot development of Udon UI! --------------------原文-------------------- 最近、更に高機能なワールドギミックが増えて、その操作や設定も増える傾向にあります。そのため、ワールド作者はUIメニューを独自に設計し、独特な手段で呼び出す実装を強いられています。特に広域なワールドでは、ユーザーはどこからでもUIメニューを召喚できる必要があります。例えば、VRならトリガーをダブルクリックであったり、右スティックを下に長押ししたり、あるいはジェスチャーをしたり…デスクトップならEキーを押したりEscキーを押したり… これらは、近年機能の増えたVRChatクライアントの操作と干渉することさえあります。例えば、右スティックの上入力ではVive Wandのプレイヤーはジャンプしてしまいます。Eキーではカメラを操作しようとする時に干渉します。(理由の一端に、メニューボタン入力を Udon から取得できないのもあります) 一方でユーザーは、ワールドごとに呼び出し方の違うUIメニューに戸惑い、あるいは気付かない事もしばしば起こっています。ワールド作者は、常にUIメニューの呼び出し方を案内する必要があります。 私は、過去にQMからアクセスできるUdon UIを開発していて、しかし中断している事を知っています。 私の認識では、スマートフォンプラットフォームの対応に工数が取られていた事も重要な一因です。既にスマートフォンプラットフォームはAndroid, iOS共にリリースされています。今こそUdon UIの開発をリブートする時です!
0
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)
12
Load More