World/Udon Bugs & Feature Requests

Imposters are amazing, but they can clash with many creative and interesting effects world creators can use within VRC. Projectors and camera effects show them as opaque, or invisible. Often times imposters generate impossibly huge, ruining experiences for everyone in the space when their outside bounds are visible. Please give us the freedom to disable them per-world, or even per-instance. Giving this option to world creators would expand creativity, and would not complicate the end-user experience any further. Alternatively, give imposters their own unity layer so they can be rendered separately.

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!

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.

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.

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.

Since we can only get remote players' bone data at the moment, it's essentially impossible to create many different systems reliably (the most significant to me being any sort of reliable custom VRCObjectSync alternative optimized for any given world's specific needs) without some pretty significant compromises. You can either follow bones exactly without any offset, leading to awkward/incorrect visuals, or you can calculate local offsets before syncing data which leads to inconsistencies, or you can add arbitrary predefined offsets which also lead to inconsistencies, all while dealing with inconsistent latency offsets that can sometimes lead to wild discrepancies in position & rotation between the holder and remote users (syncing TrackingData on a manual behavior currently sends the data WAY too early, and there isn't really a way to verify it's still valid anyway since so many bone data points are just discarded to the point where creators can't reliably predict what will happen when a behaviour inevitably receives TrackingData too early). This is especially critical if the rotation of a synced object MUST be perfectly accurate at all times for any given use case; achieving behavior like this while also significantly reducing overall network usage and allowing creators to put manually-synced scripts on pickups (while also syncing their positions/rotations manually), is currently impossible without significant unnecessary sacrifice. This has other implications as well; if a creator needs to reliably put something above a remote user's head, rotated a certain way, they can't. Because "what if the remote user's avatar has their head rotated in an unconventional way?" "What if the rotation of a synced object is critical, but the remote player's avatar is culled, thus preventing Udon from getting accurate bone data?" "What if someone hides a remote player's avatar, thus likely changing all of their bone orientations while they're being tracked?" There are tons of reasons why only providing bone data just isn't sufficient at all for really anything that needs to be 100% reliable like TrackingData would be. Every player-tracking idea I can think of is always thwarted by "but what if a player has an unconventional avatar"? or "but what if a player's avatar is culled/hidden?" As a result, please allow GetTrackingData() to return remote users' actual TrackingData, not just bone data, in the same update/network timing as each player's bone data is sent, so that creators can create systems that reliably line up remote user TrackingData with their visible body movements; systems that will significantly reduce your servers' overall network usage fundamentally across the platform, while tangibly improving player experience. If this functionality needs to be opted-into so as to keep the default behavior performant by not calculating/syncing TrackingData all the time, that's fine; maybe have a synced boolean flag on VRCPlayerApi that reliably enables/disables the calculation/syncing per-user at manual sync timing with "OnTrackingDataSyncToggled()" callbacks. Or if you're already syncing this value alongside bone data, just expose it to us. Or if not, maybe you can calculate certain offsets for each possible avatar a user could present to a remote user at any given time (including while culled and while changing avatars, please make this available and accurate under those conditions as well), and save those offsets locally to be used whenever GetTrackingData() is queried. Even a compressed version of TrackingData that's localized to each player's playspace origin (or some other position that's consistently very close to the player, while also being the same for each player in the instance regardless of avatars or culling settings) that would cut the required networking data down to less than half using shorts/bytes (any Quaternion can be synced using 6 bytes, and the same can be said about any local-space short-distance Vector3) sent as needed, with a "remote user TrackingData may not be perfectly accurate to a tenth of a micrometer" disclaimer to creators, would be sufficient. Whatever the required/optimal solution may be, I'm sure the creator community AND the player community AND the VRChat server rack community, would all greatly appreciate this feature and the creations it would enable.

As has been laid bare with the recent issues in the VR Poker world by Nex and now the recently released Fish! by Godfall, hackers are able to manipulate persistent user data. Either resetting it maliciously or giving themselves advantages. This has also been a problem in B Clubs for some time with hackers giving themselves instance permissions. It is impossible to prevent this because all world data is run on player machines. No matter how encrypted or however many anti-cheating checks a world creator can come up with, they are easily defeated when someone becomes the world host. There has been a lot of discussion lately on allowing world creators to ban specific users. But that doesn't solve the problem. There should be an option for world creators to use a true server/client architecture so that these kinds of hacks become impossible.

Was sort of surprised to find out that they aren't already there since full body tracking is officially supported