World/Udon Bugs & Feature Requests

Now that we can sync larger amounts of data, it would be helpful to be able to compress that data to minimize network overhead. However, doing compression in Udon is expensive; I'm sure you already have a zlib binding somewhere that you could expose, which would work much better.

SerializedUdonPrograms end up being thown into a "SerializedUdonPrograms" folder and given a randomized string for a name. This is really annoying when creating prefabs as it's very unclear what assets should be shared. These files don't clutter things too badly. It would make more sense for these serialized programs to be saved next to the asset that generated them. In addition, it should be made easier to see what a serialized udon program was serialized from via a human-readable name, rather than the randomized string they currently use.

World persistency would increase usability since old in-world settings could load automatically when the user re-visits the same world later. As worlds get more and more complex, this is no longer a "nice to have" feature - it is now absolutely needed to make a more complex world playable (such as playing a long story through like "The Devouring" for people who don't stay 4+ hours in a single world in VR or in case VRChat crashes while playing it). But it is also needed for grinding mechanics and worlds where you can build something and farm resources - something we are currently working on. Tl;dr, either VRChat gives us a [StoreToDisk] string datatype (without a weird character limit) that saves to disk when it changes and loads again when the user joins the same world or we'll have to implement our own open-source solution reading debug log files and a third-party application running on people's PCs to send Ctrl+V to the window handle (as other world creators have already done it). But either way, we definitely can't go on without a solution here and the current "ask a VR user to copy+paste a string" is not a good way to do it - especially since it's not crash-safe, so users lose all progress when VRChat disconnects the user randomly. But also since we still don't have a "Copy to clipboard"/"Paste from clipboard" function next to a TextInput field for whatever reason, something that would be extremely useful for VR users in general anyway. Ideally, an instance could also specify to only load the progress from whoever created it, since it's not possible right now to know who's the instance creator in Udon, but that's only a minor follow-up issue.

Get what instance type you are in. Public, Friends, Friends+, Invite+, Invite Single node can return string Multiple nodes for each type can return bool

It is currently not possible to construct VRCUrl at runtime. This makes it difficult to generate video URLs that require dynamic input to function, such as playing a video based on an arbitrary search query, or generating video URLs that utilize token based access or are limited by other conditions. Data leakage concerns are already mitigated with the Allow Untrusted URLs option.

If we're smart enough to write scripts for worlds, we're smart enough to drag a slider from 1 to 0.

It will be nice to be able to use embedded video clips with the new video player system for things like video textures. Currently (on the open beta build 986) we can only load videos from external servers.

There are many camera settings that would be really nice to have access to after runtime. An interface could be provided for this via some proxy in the VRCGraphics class. (and maybe one for the hand camera as well!) Ideally this proxy would contain everything the normal Camera class has that doesn't pose a security risk. Some examples of very handy use cases for this: Change farclip dynamically to minimize perf overhead from unnecessarily drawing distant avatars/objects Safe access to culling masks for user-created layers to make a lot of common visibility tricks much easier Set depth texture to be generated without needing a shadow-casting dir light Get FOV to use for unique world mechanics Access to a lot of useful camera matrices like cameraToWorldMatrix, worldToCameraMatrix, projectionMatrix, etc... Access to stereo separation for more advanced world features ...and more I'm probably not thinking of!

I would like to request the addition of URL redirection functionality for string loading and image loading in VRChat, similar to the existing feature for videos and livestreams. This would allow creators to serve dynamic assets like strings and images from trusted URLs easier, enhancing content flexibility and reducing redundancy. The feature should be restricted to trusted URLs to avoid potential misuse or malicious activities by third parties. Currently, VRChat supports URL redirects for videos and livestreams utilizing YT-DLP, enabling creators to dynamically update content without requiring re-uploads or modifications to assets. Extending this feature to string loading and image loading would provide similar benefits, including: Enhanced Asset Management: This feature enables creators to manage assets like images and strings on the server-side, allowing them to cycle through different versions without needing to overwrite or replace files at the same URL. A common problem is that users are forced to overwrite files ( e.g., /string/whitelist.json ) to apply changes, which can lead to caching issues depending on the service used. By simply pointing requests to /string/whitelist/ to a different file, creators can avoid overwrites and ensure more efficient updates. Consistency Across Media Types: By using URL redirection for both strings and images, the management of different media types in VRChat becomes more streamlined. This reduces the need to overwrite files, minimizing caching issues and providing a smoother workflow for creators working with text, images, and videos. Enabling URL redirects for string loading and image loading in VRChat, restricted to trusted URLs, would provide significant flexibility and efficiency to creators while maintaining security. The current implementation for videos and livestreams has proven successful, and extending the same approach to strings and images would streamline workflows and improve content management, without compromising user safety.

There is no way to resize a texture in Udon currently. We can release (custom) render textures and that's about it. This is quite limiting and can hamper performance by forcing people to use the largest resolution needed when they could have otherwise reduced it as needed. If the issue with allowing resizing ((custom) render) textures is the possibility that they can be used to run the client out of memory, it would be useful to intercept the calls and cap the maximum resolution to something reasonable like 4k or 8k. This should have minimal performance overhead since people should not be resizing and reallocating their textures every frame. If that's the concern, it can be rate limited and just return false to the udon behaviour.