World/Udon Bugs & Feature Requests

When serializing in VRCJson with JsonExportType set to Minify, the output contains unnecessary whitespace. To save data size, it would be better if no whitespace was included when Minify is specified. var j = new DataDictionary(); j["e1"] = 1; j["e2"] = 2; if (VRCJson.TrySerializeToJson(j, JsonExportType.Minify, out var res)) { Debug.Log(res); } Result: {"e1": 1, "e2": 2}

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

It would be so useful if we could have the component VRC contacts work for world building and not just avatars. having to do scripts works but as this component already exist i see no reason as to why it doesn't work in world building. Thank you for reading

Physbones is really cool. In particular it has a performant set of tools that allow for avatar-avatar interaction. Please port the Physbones code so we can use it in Worlds too! It would make making many Worlds things far easier, like buttons and levers.

Recently, in video recording, we can now switch the Audio Listener's position between viewpoint-based and camera-based in both the camera's stream mode and the VRC Drone's FPV mode. Please enable access to obtain the player's audio listener position from Udon. This will ensure that world audio sources, which were previously controlled solely based on the player's head position, will now be heard accurately even in stream mode. This post has been reposted from the following post, which is more appropriately categorized here: https://feedback.vrchat.com/feature-requests/p/determine-whether-the-players-audio-listener-is-viewpoint-based-or-camera-based

This was reported as fixed in 2024.4.1p3 but it looks like the problem crept back in and exists in SDK 3.8.2 / 2025.3.1 (haven't tested any other versions). Since the previous canny was closed out as complete, thought I'd open a new one. Prior bug report on this issue: https://feedback.vrchat.com/udon/p/braces-inside-strings-in-vrcjson-can-fail-to-deserialize // This works if(VRCJson.TryDeserializeFromJson("\"{\"data\":\"test\"}", out DataToken token2)) Debug.LogError("Failed to deserialize JSON"); else Debug.Log("Successfully deserialized JSON"); // This fails. Only difference is the braces after the word test in the JSON string. Number of braces or their configuration doesn't seem to make a difference. if(VRCJson.TryDeserializeFromJson("{\"data\":\"test{}\"}", out DataToken token1)) Debug.LogError("Failed to deserialize JSON"); else Debug.Log("Successfully deserialized JSON"); Thanks! -Tea

For UDON admin interfaces or whitelisted areas etc. it would be great to have GetUserID or something like that exposed, It's been a real struggle with people with special characters in their display name, UserIDs would make the process so much cleaner, and more reliable

Allow worlds to apply camera dolly animations to the user's camera. This would allow worlds to create pre-defined camera paths around points of interest, such as stages, race tracks, or dance floors.

Since the avatar scaling update, I've been having problems with stations, and using the events for them. One thing I've nailed down, is that players are kicked from a station for a bit when they change avatar ( https://youtube.com/shorts/JHKDN4W7edE?feature=share ), and this causes the events 'onStationEnter' and 'onStationExited' to play; which messes up any logic that resets the station on leave. To fix this, I've had to add delay to the stations logic in my 'go kart zombie tag' world, but it's far from perfect, and would be really hard for a newcomer to udon. Also, the 'onStationExited' event gets called for both local and global players, which means the delayed enter and exit is unpredictable, as it is just whenever they see them load in. This can be seen in this clip, though there was a patch a couple of days later that fixed the event being called for the loading avatar as well ( https://youtu.be/1iNC3906fn8 ). For the record, this is a showcase of the avatar loading problem that has seems to be fixed now, where the kart would respawn, but then snap back to the sync script's location; as the player didn't actually leave the kart ( https://youtube.com/shorts/kX_9dtadUCc?feature=share ) Other than that, Something I can't fix is that I'm also having massive desyncing problems between quest and pc users; where sometimes pc users don't see a quest user enter a kart, and vice versa. This is leading to broken logic of non tag-able karts, and cases of two people in the same kart; with one driving (sorry, I don't have a video to show this)

With the Remote string loading and image loading, we should be able to dynamically construct endpoint url's to cater to different scenarios and offer more flexibility. I know other posts about this do exist, but I feel like VRChat won't really pay attention without there being more volume and input from the end users. Please upvote relevant requests and share your thoughts. I'm using this post to potentially share my feedback and idea, and offer a starting point for us to discuss on. I want to be able to kickoff my project in VRChat and the string loading with dynamic URL's will play a major role in making it a reality. I am assuming this was not possible because of "security" concerns, but let's face it that we offer users to block untrusted URL's as is and give them warnings. VRChat is not only a social platform, but a sandbox for creators in terms of avatar, world, and scripting content. I've developed essential tools on Garry's Mod and other sandbox games, and they had no problem letting scripts make API calls, despite the community having a dangerous and toxic userbase. This allowed me to let my clients configure "roles" and preferences from an external web portal. Are you afraid of data exfiltration? There are ways to do that already. Malicious URL calls? Anything on the internet can be malicious as is. We can't keep having this "Carebear" security mindset and keep it locked tight that severely limits our creativity, but look for accountability and flexibility. The security concern is admired, but now its necessary to send dynamic URL's for search queries when we deal with remote strings or images, otherwise we have no choice but to dump the entire dataset. I will just have to create hundreds of VRCURL's and just do a bunch of if/else's and download the entire "database" instead of feeding search queries to get specific datasets to save bandwidth and filter through the data set on the server side. Maybe to meet in the middle, we can be transparent of the requests to be made. Add a prompt to the end user stating that "This World is requesting permission to let your game send/receive content to and from http://xyz.com " and it would be whitelisted to that user individually. Any new URL's not on the list will prompt another permission request. It would Only apply to the domain name, and Subdomain only. Maybe prevent changing the domain/subdomain of the URL entirely. This can also allow the user to feel more confidence knowing that their "Untrusted URLs" is no longer a wildcard, but can consult a list to see which untrusted URL's they're permitting on their client. With your upcoming "Udon" menu implementation, it could be considered to have VRChat built-in user preferences specific to the worlds, and include the whitelist there of URLs the World has requested to communicate with.