World/Udon Bugs & Feature Requests

Tested with VRChat client build 1896. I would like to report an issue with VRCJson.TryDeserializeFromJson. There appear to be cases where valid JSON fails to deserialize when an object is nested two or more levels deep and a string inside the nested object contains a brace character ( { or } ). The exact behavior appears to depend on the nesting depth and the brace character. It is not the case that every brace inside every nested object fails. For example, a closing brace ( } ) inside a string at the third nesting level can deserialize successfully. Braces inside JSON strings should always be treated as ordinary string characters and should not affect the surrounding object structure. The following valid JSON objects fail to deserialize: { "x": { "y": "{" } } { "x": { "y": "}" } } { "x": { "y": { "z": "{" } } } Reproduction code: string json1 = @"{ ""x"": { ""y"": ""{"" } }"; bool success1 = VRCJson.TryDeserializeFromJson(json1, out DataToken result1); Debug.Log(success1); Debug.Log(result1.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found end of string before finishing object string json2 = @"{ ""x"": { ""y"": ""}"" } }"; bool success2 = VRCJson.TryDeserializeFromJson(json2, out DataToken result2); Debug.Log(success2); Debug.Log(result2.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found unexpected character '"' while looking for character ',' string json3 = @"{ ""x"": { ""y"": { ""z"": ""{"" } } }"; bool success3 = VRCJson.TryDeserializeFromJson(json3, out DataToken result3); Debug.Log(success3); Debug.Log(result3.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found end of string before finishing object // Control case: this valid JSON deserializes successfully. string control = @"{ ""x"": { ""y"": { ""z"": ""}"" } } }"; bool controlSuccess = VRCJson.TryDeserializeFromJson(control, out DataToken controlResult); Debug.Log(controlSuccess); Debug.Log(controlResult.ToString()); // Expected: true // Actual: true This may be related to the previously reported issue: "VRCJson.TryDeserializeFromJson may still incorrectly parse arrays when strings contain brackets" ( https://feedback.vrchat.com/udon/p/vrcjsontrydeserializefromjson-may-still-incorrectly-parse-arrays-when-strings-co ) That report is marked complete, but similar parsing failures remain reproducible with braces inside string values in nested JSON objects in client build 1896.

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 the player is respawned by the world while they have the quick menu open, the quick menu will be forced closed. While not an issue in most cases, there's a couple I know of that can result in a softlock requiring the player to restart the client to escape. The respawn point being below or too close to the respawn height Y. The world code constantly respawning the player, intentionally or unintentionally. In both cases the player is unable to move or open the menu since it instantly closes upon being respawned. Because the menu can't be used, it's impossible to switch worlds at this point resulting in a softlock. Example world: https://vrchat.com/home/world/wrld_4d579d61-3c5e-4033-9afc-bda5fe0bb326 The respawn height y in this world is set to 0 which is the same as the spawn point. This will result in an immediate softlock upon entering the world. A solution to this is to not close the quick menu unless the player explicitly closes it themself or manually respawns. This would allow the player to either rejoin or switch to a different world preventing a softlock.

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)

This will be another key step in deprecating the VRCStation by completely modularizing its functions. Step 1: Expose player transform parenting, so that a player can be attached to an object. And so there is no need to exploit a station frame by frame to simulate walking on a moving object. Step 2: Expose player avatar animator parameters, so that Udon can make a player do the sitting animation. (optional) Step 3: Expose player avatar animator, so that their animations can be customized with an Animator Override Controller, so there is no need to exploit some undocumented and unintended station animator bug for e.g. MMD. (optional) Step 4: Expose player visibility, so there is no need to exploit a desync station to achieve this effect with a roundabout jank.

Same justification as allowing parenting to the player bones. Rather than having to move positions to VRCCameraSettings.ScreenCamera.Position in Update() , allow parenting to it.

https://github.com/KyryloKuzyk/PrimeTween/discussions/10 More performant than DOTween (which VRCTween is based on), and allocation-free so no need to worry about reusing handles or staggering or killing tweens for performance. Seems like a no-brainer.

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

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

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