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

## 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.

Since we can only get remote players' bone data at the moment, it's essentially impossible to create many different systems reliably (the most significant to me being any sort of reliable custom VRCObjectSync alternative optimized for any given world's specific needs) without some pretty significant compromises. You can either follow bones exactly without any offset, leading to awkward/incorrect visuals, or you can calculate local offsets before syncing data which leads to inconsistencies, or you can add arbitrary predefined offsets which also lead to inconsistencies, all while dealing with inconsistent latency offsets that can sometimes lead to wild discrepancies in position & rotation between the holder and remote users (syncing TrackingData on a manual behavior currently sends the data WAY too early, and there isn't really a way to verify it's still valid anyway since so many bone data points are just discarded to the point where creators can't reliably predict what will happen when a behaviour inevitably receives TrackingData too early). This is especially critical if the rotation of a synced object MUST be perfectly accurate at all times for any given use case; achieving behavior like this while also significantly reducing overall network usage and allowing creators to put manually-synced scripts on pickups (while also syncing their positions/rotations manually), is currently impossible without significant unnecessary sacrifice. This has other implications as well; if a creator needs to reliably put something above a remote user's head, rotated a certain way, they can't. Because "what if the remote user's avatar has their head rotated in an unconventional way?" "What if the rotation of a synced object is critical, but the remote player's avatar is culled, thus preventing Udon from getting accurate bone data?" "What if someone hides a remote player's avatar, thus likely changing all of their bone orientations while they're being tracked?" There are tons of reasons why only providing bone data just isn't sufficient at all for really anything that needs to be 100% reliable like TrackingData would be. Every player-tracking idea I can think of is always thwarted by "but what if a player has an unconventional avatar"? or "but what if a player's avatar is culled/hidden?" As a result, please allow GetTrackingData() to return remote users' actual TrackingData, not just bone data, in the same update/network timing as each player's bone data is sent, so that creators can create systems that reliably line up remote user TrackingData with their visible body movements; systems that will significantly reduce your servers' overall network usage fundamentally across the platform, while tangibly improving player experience. If this functionality needs to be opted-into so as to keep the default behavior performant by not calculating/syncing TrackingData all the time, that's fine; maybe have a synced boolean flag on VRCPlayerApi that reliably enables/disables the calculation/syncing per-user at manual sync timing with "OnTrackingDataSyncToggled()" callbacks. Or if you're already syncing this value alongside bone data, just expose it to us. Or if not, maybe you can calculate certain offsets for each possible avatar a user could present to a remote user at any given time (including while culled and while changing avatars, please make this available and accurate under those conditions as well), and save those offsets locally to be used whenever GetTrackingData() is queried. Even a compressed version of TrackingData that's localized to each player's playspace origin (or some other position that's consistently very close to the player, while also being the same for each player in the instance regardless of avatars or culling settings) that would cut the required networking data down to less than half using shorts/bytes (any Quaternion can be synced using 6 bytes, and the same can be said about any local-space short-distance Vector3) sent as needed, with a "remote user TrackingData may not be perfectly accurate to a tenth of a micrometer" disclaimer to creators, would be sufficient. Whatever the required/optimal solution may be, I'm sure the creator community AND the player community AND the VRChat server rack community, would all greatly appreciate this feature and the creations it would enable.

As the PlayerData API doesn't support any¹ array types most creators resort to storing all their array elements as individual keys in PlayerData. This means most of the already strict data limit gets consumed by unnecessary and avoidable header. Please add all the UdonSync supported types to the PlayerData API. And for the love of all that is holy bitpack the bool array type before writing it to persistence. ¹ The only array type PlayerData currently supports is byte[] . The fact that we at least have this is great for experienced creators! But it leaves everyone else (who can't write their own serializer) in the dust. It's completely unreasonable to expect the average graph creator to "just" make their own serializer when they hit the currently claustrophobic persistence limits.

VRChat is working on an improvement to Udon, VRChat's scripting system. Currently, World creators can write code in two different ways: Udon Graph UdonSharp VRChat is introducing a third way: Soba Creators can write Soba scripts in C#, similar to UdonSharp. Soba scripts are compiled to Microsoft's Common Intermediate Language (CIL). This allows Soba to use a variety of features that are not available in the Udon Graph or UdonSharp.

Players and world creators would appreciate a new character controller for VRChat worlds. It should work mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going upstairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controller. ... And more!

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).

Currently, when a user enters the interaction range an interactive game object in a world, VRChat displays a blue halo around it. Udon can control this highlight with InputManager.EnableObjectHighlight , though it's unreliable and undocumented. It turns the highlight on and off, but the game object loses or regains its highlight if the user enters the interaction range. Worlds can work around this by calling EnableObjectHighlight every Update. Udon should be able to control an object's highlight state to a greater extent.

With the implementation of the Trampolines I've noticed it seems to be the straw that broke the camel's back. Items are being disabled for worlds. Both paid and free assets are being disabled. I think classifying a item as small or large would allow for smaller props to stay while large ones like the pool, trees and trampolines can be toggled off.

At the moment Udon doesn't have this library exposed to Udon. Considering how easy is to tamper with String Loading (DNS poisoning and you are gucci), having this exposed to validate response signatures is required.