World/Udon Bugs & Feature Requests

Since bone transforms aren't exposed, we can't parent objects to players and need to use expensive and complicated update loops for such a basic task, which also results in ugly/janky object movements and low performance. Please give us a simple function like .SetParent(Transform t, Boolean b) for .GetTrackingData(VRCPlayerApi.TrackingDataType.x) and .GetBonePosition(HumanBodyBones.x) and for VRCPlayerApi.GetPosition

If U# scripts with BehaviorSyncMode.Manual (or Continuous) and None set exist in the same object, an error will occur as shown in the attached image. (When SC2 Input Manager is None and SC2 Seat Adjuster is Manual) When combining Manual (or Continuous) and None, it would be nice if U# scripts behaved as synchronization objects without displaying any error-like messages. In fact, this combination works as Manual Sync. Looking at the archive logs below, it seems that this implementation is already in place, and the error message is just being displayed extra. https://feedback.vrchat.com/udon/p/syncmode-none-should-be-weaker-than-other-sync-modes

Same with: https://feedback.vrchat.com/udon/p/expose-staticbatchingutilitycombine Open new one since last update was 2 years+ ago. Expose this API will also allow world creators who create a world with a floating origin system to optimize their world with static batching. (Which cannot be done in editor since StaticBatching in Editor won't allow move the batching object, but StaticBatchingUtility.Combine will allow move the batching root)

## Problem Media files can contain multiple audio tracks (for example Spanish, English and Japanese), but worlds using VRCAVProVideoPlayer cannot enumerate or select those tracks from Udon. The player chooses one track and world authors have no supported way to change it. This prevents proper multilingual cinema, anime, karaoke, event and accessibility experiences. Current workarounds require duplicating the full video, transcoding variants on a server, or running a second audio player and fighting synchronization. AVPro itself has audio-track APIs, but the VRChat wrapper does not expose equivalent functionality to Udon: https://www.renderheads.com/content/docs/AVProVideo-v3/api/RenderHeads.Media.AVProVideo.VideoPlayer_AVPro.html VRChat video-player documentation: https://creators.vrchat.com/worlds/udon/video-players/ ## Requested API Please expose a small, local API on VRCAVProVideoPlayer, with names similar to: int GetAudioTrackCount() string GetAudioTrackLanguage(int trackIndex) string GetAudioTrackName(int trackIndex) int GetSelectedAudioTrack() bool SetAudioTrack(int trackIndex) An event indicating that track metadata is available would also be useful. The exact API names are not important. The important requirements are that Udon can enumerate the available tracks, show their language/name, and select one. ## Behaviour Audio-track selection should be local by default, so different users in the same instance can listen to different languages while watching the same synchronized video. Changing track should not change the shared URL, playback state or time for other users. Switching during playback should preserve the current playback position. If the backend must pause or reopen the media, the SDK could handle that internally or document the required sequence. A capability check is acceptable when a platform or media backend does not support track switching. PC-only support initially would still be useful if cross-platform parity is not immediately possible. ## Acceptance example A world plays one media URL containing Spanish, English and Japanese audio tracks. Two users watch the same synchronized video at the same timestamp. User A selects Spanish locally. User B selects Japanese locally. The video remains synchronized and neither user's choice changes the other user's audio. This would enable true multilingual playback without storing or streaming duplicate copies of the video.

Similar to this request: https://feedback.vrchat.com/android/p/a-way-to-raycast-from-touch-position-on-mobile We can use VRCCameraSettings.ScreenCamera.Position and VRCCameraSettings.ScreenCamera.Forward to construct a ray that corresponds to a desktop user's reticle, but there's seemingly no way to keep this up for a user's cursor when they're in free mouse mode (Tab).

It was announced on yesterday's developer update that Udon 2 had been scrapped for "Soba". Based on the information we have been given, they're making the equivalent to Udon 1.1. In the words of the VRChat team, specifically Fax: Soba will have comparable or worse performance than current UdonSharp at launch with "promised" improvements in the future. But as we know, VRChat is unreliable with promises, so I'm hesitant to believe that. Soba will lack generics support at launch (no List<T> or Dictionary<T>, among others) Soba will not have everything promised in Udon 2 This is extremely dissapointing for me, and many other VRChat creators. Udon 2 was supposed to be the superfast feature-rich improvement over current Udon To see that they have opted to make a custom VM which, based on the facts we have right now, will not achieve Udon 2's speeds or feature parity is a disappointment to the community and a testament to how easier > better in VRChat's eyes. The reasons for this change are also abysmal. They said that Udon 2 "would have distracted us from adding feature requests that the community had been asking for". This shows how deaf VRChat is around community feedback, since Udon 2 was one of the most exciting features for me and many other creators, plus, this wasn't an issue when you were waving your dick about making stickers, boops and other features nobody asked for. Alongside this, based on VRChat's technical reasoning, it appears that WebAssembly was scrapped because the new engineer(s) working on Soba didn't bother to debug Udon 2, it appears some benchmarks were done, issues were found, and they didn't bother to try and debug it, or just made up some excuse, instead opting for yet another sloppy custom VM. I apologise for my irritated language, but it is growing rather agitating that VRChat cannot competently deliver on a highly anticipated feature without taking years and having a 50/50 chance of scrapping it. Udon 2 was the better choice objectively, so I implore you to rethink this decision and bring back WebAssembly based Udon 2.

StaticBatchingUtility.Combine sets up static batching for several objects at runtime. It offers the following advantages over marking objects as batching static in the editor: -Allows the performance advantages of static batching to be applied to objects generated at runtime. Since such objects don't exist in the editor, it's not possible to mark them as batching static. -Objects setup to be statically batched in this way can be moved by adjusting the transform of their associated staticBatchingRoot gameobject. This is useful for sets of objects that move together as a whole. For these reasons exposing StaticBatchingUtility.Combine would provide world creators with a useful tool for optimizing their worlds. https://docs.unity3d.com/2019.4/Documentation/ScriptReference/StaticBatchingUtility.html

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

When increasing player voice distances, being close to that players makes their voice sound very loud, even at 0 gain. In attempts to make a player's voice global, it will always be louder than expected. Having a way to lower the volume of players would make better experiences in these situations.

SetVoiceGain sets player voice BOOST gain. Not voice gain. I want to add a volume slider to my player voice radio system. This is currently only possible by abusing the existing API. At the moment I have to do this for every single player on the radio EVERY FRAME: Measure the distance from the local player to the other player. This has to be approximate since there is no native way to get the exact position of a remote player's head, only their head bone. Somehow adjust the voice distance near and far based on the distance to that player in an attempt to use the falloff curve to indirectly set each player's voice volume. This is extremely silly. I propose adding "SetVoiceVolume(float value)" where value is in the range 0 - 1. This would function exactly like a volume slider in the quick menu. There's already a similar canny, but it has a lot of requests in one, so I made this one. The canny in question: https://feedback.vrchat.com/feature-requests/p/more-player-voice-udonu-functions