World/Udon Bugs & Feature Requests

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.

We're working on a new character controller for VRChat worlds. It works mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going up stairs 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 controler. ... And more! This feature is still in development and subject to change.

My world has a layered camera setup and requires for the reference (main) camera of the world to be set to render with Clear Flags set to Depth only and only render from players eyes up to 1000 meters in order to maximize performance. Secondary camera of the world is set to render only a low quality copy of the terrain and surrounding mountains in the horizon from 1000 meters all the way up to 4000 meters before the main camera of the world renders the scene. Despite the player's POV looking perfectly normal on desktop and in VR, the in-game camera, steadycam and personal mirror all break because they inherit all applicable properties of the reference camera and don't properly clear the render, resulting in unacceptable ghosting in the sky. I'm asking for the VRCSDK to include an option to set the camera properties of VRChat's in-game user cameras independently from the reference camera, e.g. fields for Clear Flags, Near Clip, Far Clip on the VRCSceneDescriptor so they can still keep functioning without the world author having to provide a completely custom camera solution from the ground up in order to mitigate this issue. If exposing the properties in the SDK is too big of an ask, at least ensure that the in-game cameras do not have their Clear Flags set to Depth Only or Don't Clear. Thank you. P.S. This issue could also be fixed by allowing the world to set the Clear Flags of the player's main camera during runtime with Udon, related post: https://feedback.vrchat.com/udon/p/give-us-an-interface-to-the-main-camera-via-the-vrcgraphics-class

Udon 2 is VRChat's upcoming replacement for Udon. "Udon" is a feature of the VRChat's Worlds SDK. It allows users to write custom scripts with the Udon Graph and UdonSharp. Udon 2 runs WebAssembly instead of UdonAssembly. Programs are compiled into C# script assemblies using Roslyn and run within VRChat using the same runtime as Blazor. This means that... Most C# features are supported, such as Lists, Dictionaries or Actions. Scripts in worlds uploaded with Udon 2 will generally perform better. Existing worlds will continue to work as before. Udon Graph programs are compiled into C# instead of UdonAssembly.

Dropdowns were added as being supported recently, however all you can do with them in udon is either add a option, or clear the entire list. There is currently no way to remove a specific option from the list, without completely rebuilding the dropdown list itself

Hello! About 50-60 days ago, CyanPlayerPool stopped working at random on Quest, breaking my world in the process, however exclusively on Quest (and at random too). I've been trying to fix it for a while but couldn't find the issue until now, it appears the "Owner" variable (assigned by CyanPlayerPool) may never get assigned (I'm assuming VRCPlayerApi is null when the variable is being assigned) This hasn't been an issue in the past and only started occurring recently, I'm suspecting after one of VRChat's memory improvement updates. I've solved the issue by brute-forcing "Owner = localPlayer" over several seconds after "_OnOwnerSet" and using "Networking.IsOwner(gameObject)" rather than "Owner == localPlayer" I'm unsure how many worlds this issue might be affecting, afaik @Faxmashine was having similar issues. I'm only reporting this now as I've just found the cause and solution. Thanks 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.

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!

This is required for multi-material support on TextMeshPro meshes.

This would potentially be able to reproduce the Combat System in Udon and make it obsolete. Also would be pretty cool in general :^)