World/Udon Bugs & Feature Requests

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.

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.

Goal: Make it accessible for VRChat Group Owners to adjust portal placement ability in their instances in order to combat a sense of griefing or bad manners seen in many Group Public/+/Instances. How: Add a VRC Group World Option "Require Group Membership for Portal Placement" and a User Permission node "Restrict Portal Placement in Group Instances" to VRChat Groups: Require Group Membership for Portal Placement: Would be required to be enabled for the Permission Node to be usable. By default, this option would be off, but for VRC Group owners that want to keep their instance more orderly, they can require users be a part of their group to place portals in their world. * This would affect Group Instances, and not players individually, so I'm not sure on the desire and ability to implement this. Restrict Portal Placement in Group Instances: (If the option above is not valid, my suggestion would be to make it so that portal placement in Group instances is just disabled by default.) This Permission Node would have two states: Allowed, which acknowledges the world author's choice for allowing or denying portal placement, which would be the default option. Denied, which disables the dropping of portals. This would be an invaluable permission to grant to "New Members" and would aid in prevention of people joining an "open to the public" group, and immediately dropping portals to be disruptive. If the Group World Option "Require Group Membership for Portal Placement" would need to be avoided, then this option would need to be reversed to "Allow Portal Placement in Group Instances" and would need to deny portal placement permission for anyone who DOES NOT have this option enabled. Context: I run the Sunset Bar, so I get Portal feedback almost on the daily. I would absolutely enjoy the ability for VRChat Groups to have the power to prevent portal placement as it feels very disruptive to drop portals in the middle of an instance. Of course, when you have different groups trying to be the one on top and someone drops a portal inside of their instance, it can eat away at member count. Users who want to fill their instances end up finding the want to ban people who place portals in their instance, but we don't want to prevent portals wholesale either. Thanks for your consideration to this issue!

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.

Currently, when a user enters the interaction range an interactive game object in a world, VRChat displays a blue halo around it. Udon can control this highlight with InputManager.EnableObjectHighlight , though it's unreliable and undocumented. It turns the highlight on and off, but the game object loses or regains its highlight if the user enters the interaction range. Worlds can work around this by calling EnableObjectHighlight every Update. Udon should be able to control an object's highlight state to a greater extent.

With the recent SDK update to Unity 2022, the Navigation feature that was previously built into Unity has been deprecated and is now introduced through an official package. Settings like Navigation Static and OffMeshLinkGeneration have become non-selectable by default due to the change from Static settings. This has made setting up NavMesh in the Unity 2022 environment more challenging. I would like VRChat to support the new method of Navigation setup, which is the NavMeshSurface.

Having only 5 tags to a world makes it fairly hard to properly tag a world, especially if you have certain prefab systems like audiolink and such that you would like to be searchable. I dont really see the reason tags have to be limited to such a small ammount, so seeing this changed would be fantastic for world searchability

We're working on various improvements to VRChat's implementation of TextMeshPro. This will complete a variety of other Canny requests. 🥳 We're adding new wrapper components to the Worlds SDK. TextMeshProUGUI TextMeshPro TMP Dropdown TMP InputField For security reasons, wrappers are required to access TMP components (except TextMeshProUGUI, which did not require a wrapper before).

This community is very creative and no matter how many resources you put towards building cool tools, you will always lag behind the community's ideas. As such I think having some type of experimental area where world builders can extend the Node Graph without being blacklisted during upload seems like a great way to me to propose new features. Simple text and screenshots in the canny don't seem adequate for me here because you can't test your code, nor can you really illustrate properly what the benefits are. For example, what if you wish to build a PA / microphone system leveraging runtime modifications of the spatial audio parameters? This requires that you test with other players to get it right. And the best way to present the results would be through a demo. Now imagine someone could build a custom node for the Node Graph along the lines of: Set Audio Parameters Audio source Min range Max range ... And you're able to reference player voices as the audio source here, perhaps through a trigger of sorts.

Now that we're on Unity 2022, it supports the Unity UI Toolkit which is a framework and toolkit to create UI documents that can run in the editor and in-game. The benefit mostly here is that people can utilize the UI builder for the toolkit to generate UXML documents and programmers can craft UXML documents as well. In basic terms, people can build a UI that can be displayed in-game without having to craft hundreds of game objects to make a functional UI. Learn more at https://docs.unity3d.com/Manual/UIElements.html