World/Udon Bugs & Feature Requests

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.

There is a component named "OnAudioFilterReadProxy" which will be added automatically when I expose OnAudioFilterRead in my UDON code. Currently, this component is added at the end of the components, but I would like this order to be after UdonBehaviour.

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!

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.

Directly loading media from servers or streaming endpoints is currently delayed by nearly 2 whole seconds due to everything being piped through yt-dlp regardless of whether it needs it or not. This causes unwanted delays when trying to use externally stored audio or video for various world interaction content (this is also why video content loading on Quest was so much faster before it gained the ability to use (or was forced to use) yt-dlp). Please provide a way for video players at the world level to bypass the yt-dlp lookup and just pass the URL directly to the respective video engine.

It would be useful if we could get Terrain methods in Udon. Specifically, methods and properties in https://docs.unity3d.com/ScriptReference/TerrainData.html and https://docs.unity3d.com/ScriptReference/DetailPrototype.html .

Create a legitimate way to enable and disable player spawned portals within a specific radius, trigger or collider of a world, while retaining the ability to have player spawned portals elsewhere in the same world. Currently in VRChat, you cannot place a player spawned portal at a world spawn or next to another player. What if this specific behavior can be a feature used for world building without necessarily needing to disable portals entirely from the project? There is no way to disable player spawned portals in a specified area of a world without placing a bunch of spawn points to act as a restrictor. Stickers and items have layers or colliders where they cannot be placed, but this seems to not work the same way for player portals. If player spawned portals cannot be disabled through a collider or layer like stickers and items, then there should be a way to achieve this through Udon scripting with an 'onPortalSpawnEvent' or other equivalent node. However, if the colliders, layers, as well as Udon options are not possible to implement for player spawned portals, my alternative is to add a toggle within the world instance menu to enable or disable player spawned portals in the currently existing way as emoji, items, stickers, drones, prints, and pedestals. It may seem like a niche use case, I believe this feature can be used for minigames, bars, nightclubs, venues and wherever locations and events that a world creator or instance master may want to specifically disable or re-enable portal spawning as an in-game toggle. Thank you for taking the time to see my suggestion.

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.

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.

Greetings, I'd like to have access to the 'ImageConversion.LoadImage' method from Udon : https://docs.unity3d.com/2022.3/Documentation/ScriptReference/ImageConversion.LoadImage.html The reason is : I'm currently making a 3D Model Loading using Udon#, that interprets GLB/VRM data. https://github.com/vr-voyage/vrchat-glb-loader Not having access to LoadImage forces me to re-encode, in advance, the images (PNG/JPEG/WebM) stored in these files into GPU-ready formats (DXT5/BC7/ETC2). ( https://github.com/vr-voyage/glb-textures-converter-rust ) Re-encoding textures in advance leads to issues due to different systems having different requirements (BC7 for PC, DXT5 for Quest, ETC2 for Android/iOS, ...). So while this is not blocking me, being able to use LoadImage would benefit me greatly, since I'd be able to create one asset for all the different platforms, without having to manipulate the data beforehand. This request is similar to https://feedback.vrchat.com/feature-requests/p/udon-expose-unityengineimageconversion-class-and-methods but, I only need 'LoadImage'. I don't need to encode pictures in-game. I'd like to note that using the ImageLoader instead is not possible. The image data is embedded inside binary data. So while there's an URL for the binary data, which is then downloaded using the StringLoader, there's no direct URL to the embedded images. The ImageLoader cannot convert local data (i.e. I cannot pass it a byte[]), it only converts data it can download from a valid URL.