World/Udon Bugs & Feature Requests

The ability for worlds to have sub-instances to save on performance at the cost of a loading screen. Basically a portal or Udon function pointing to another world ID that creates a child instance, kinda like a linked list. Moving to a child instance should of course have a prompt to avoid world creators using it as a void dimension for people they dislike. (maybe even add a button to return to the parent instance) Rec Room has had a similar feature for a while, it allows for larger worlds without needing to fit everything in one scene. (especially useful for RAM-limited headsets like Quest)

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!

Currently, when a player drops a VRC_Pickup object that has a solid collider and it accidentally lands inside the player's collider (their own or someone else's), the pickup collider becomes “transparent” to that player until it is picked up and dropped again outside the player collider. Instead of disabling the collider indefinitely, implement a check to re-enable it when it is safe to do so.

VRChat finally implemented Steam Audio ! And it's a lot easier to hear other players now.🥳 However, Steam Audio can do a lot more! Here's how Valve describes it on their website: > Go Beyond HRTF > Use fully-featured spatial audio attuned to the physical attributes of your in-game geometry. Combine accurate occlusion, reflection, reverb and HRTF effects for natural sounding immersion. The worlds SDK currently does not yet support Steam Audio, so none of the features above are available in VRChat yet. Please implement Steam Audio into the worlds SDK, or allow users to import it into the worlds SDK.

Many worlds have various small textures that could be higher or lower resolution depending on user preference. If users could opt-into having higher/lower resolution textures, then Quest builds could start out smaller (so as to meet the Quest world size limit), and users would have more control over their performance & experience in any given world. Players could also download new textures related to some optional add-on feature in the world. This can somewhat be achieved with image downloading, however that solution doesn't solve this problem for a couple reasons: The 5-second rate limit means you're incentivized to download large atlases for multiple textures, which is something some worlds can't feasibly do. But even if that were always feasible, if hundreds of textures need to be downloaded, the user would have to wait multiple minutes just for the world to initialize. Downloaded images can't be ASTC compressed, so they can't be as small as compressed local textures can be. If I could just upload one bundle of textures at a different resolution than those in the world to begin with, and set compression parameters to have the textures in the bundle compressed to ASTC, then have users download the entire thing at once for Udon to process at runtime, then all of those issues could be avoided. This would also be beneficial for downloaded text, not just images. You could even open this feature up to file types like audio clips or mesh files to give creators even more freedom/potential to create experiences they otherwise wouldn't have been able to before.

Please provide us a function so we can get the Current avatar ranking of an avatar worn by a player. (e.G could just return an Enum or Int for rating) The Club scene will thank you!

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.

Currently when a world loads, for example all VRCImageDownloader have to redownload their content, with a 5 second period between each. This both puts strain on hosts and also limits what we can do with worlds in a nice way since all non-bundled content has to be redownloaded every time. Not to mention it puts pressure on bandwidth for users. Ideally there should be a parameter on these functions to make a cached download request, at the very least for images/video, so it can be decided on a case-by-case basis (as this would of course not be desired for all cases where a URL is input by a user or is frequently changing on the source server.). If caching is enabled on the request and a local copy exists, you skip sending a request to the server and skip the 5-second cooldown on this downloader type, simply loading it from disk. This avoids the security concerns since no contact is made to the server. ----------------------------------------------------------- The cache could be stored as a sub-folder of a specific world, being shared across instances, which would make sense, and would make cleanup simple. But even more gains could be had from it being a global cache, so if I pasted the same URL in another world, it could instantly load it from my cache and any others who already have it cached, avoiding duplication of data. A simple dictionary file can be maintained and loaded on VRChat load to avoiding having to scan the cached files each time, as the amount of files could definitely grow pretty big. But a global cache like that isn't essential and would gladly give it up if it means implementing this request is more likely. Also, having an option to set the "TTL" (time to live) of the cached file would be a nice benefit too, though not an essential feature to have from the start. But would be pretty simple to add it as a saved property in the cache record data and compare it to the creation date and just do a redownload. (The local data should be encrypted using existing world encryption systems to prevent modifying the files and so there's no concern about illegal/awkward media ending up in a person's cache).

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.

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.