World/Udon Bugs & Feature Requests

Manual synchronization stops updating synced variables on non-owner clients with certain field configurations, despite the owner reporting successful serialization. In the failing cases, the non-owner receives OnDeserialization, but the synced fields remain at their initial values. ENVIRONMENT ──────────────────────── Unity: 2022.3.22f1 VRChat Worlds SDK: 3.10.4 Tested with actual VRChat clients in the same instance STEPS TO REPRODUCE ──────────────────────── Attach the provided Float20SyncProbe and Double20SyncProbe scripts to separate GameObjects. Assign a separate TMP text display to each script. Upload the world and join the same instance with two players. The owner assigns new values and calls RequestSerialization() every 10 seconds. Compare the owner's values with the non-owner's values on the displays and in the logs. Both scripts use Manual synchronization. Only the owner writes the synced fields. Neither script uses FieldChangeCallback or calls Networking.SetOwner. Despite their filenames, the attached scripts currently contain: Float20SyncProbe: 27 synced floats. Double20SyncProbe: 14 synced doubles and 1 synced int. EXPECTED RESULT ──────────────────────── The non-owner's synced fields should update to match the owner's serialized values. ACTUAL RESULT ──────────────────────── With the failing configurations, the non-owner's fields remain at their initial values. Reducing the number of synced fields restores normal synchronization. TEST RESULTS ──────────────────────── All configurations below were tested without FieldChangeCallback. 2 doubles : Worked 2 floats : Worked 13 doubles : Worked 26 floats : Worked 14 doubles : Worked 27 floats : Failed 14 doubles + 1 int : Failed 20 doubles : Failed Earlier tests also reproduced the issue with 20 doubles using FieldChangeCallback, while 20 floats worked. Removing FieldChangeCallback did not resolve the double20 failure. The results suggest that the amount or layout of synced data may be involved, but the exact cause is unknown. POSSIBLY RELATED REPORTS ──────────────────────── A single UdonSharpBehavior with VRC Enable Persistence cannot store more than 108 bytes of the same variable type https://feedback.vrchat.com/persistence/p/a-single-udonsharpbehavior-with-vrc-enable-persistence-cannot-store-more-than-10 PlayerObject Persistence Fails to Respect Sync Mode https://feedback.vrchat.com/persistence/p/playerobject-persistence-fails-to-respect-sync-mode Those reports concern Persistence restoration. This issue occurs during ordinary owner-to-non-owner synchronization within the same instance. REPRODUCTION MATERIALS ──────────────────────── The attached scripts reproduce the issue independently and display each client's local synced values, receive count, consistency check, and serialization result.

Please add an event for when any player enters a station, including avatar stations. As of right now, OnPlayerTriggerExit is unreliable due to how Unity handles Trigger Exit events when colliders are disabled. Players entering a station will turn off their collider. While creators can handle this (although painfully) with stations in the world, it is impossible to handle it when the station is an avatar station. Related canny: https://vrchat.canny.io/sdk-bug-reports/p/playerlocal-collision-should-remain-on-players-in-stations

There should be an option to set the world to 18+ by default and restrict it to only that. Any other instance, whether its a group, invite only, etc will be defaulted to 18+ This is an option that could be toggled by the creator in the SDK or WebGUI that no one else can change

VRChat is more than a social game. We've been shown that many times, and even more with the recent(ish) launch and popularity explosion of FISH!. This is a community that welcomes dynamic games and activities. We already have access to DownloadString in Udon, which is a undeniably a great tool for creating Dynamic Experiences. Combined with "Allow Untrusted URLs", it has powered popular experiences like "Geolocator", among others, for quite a while now. I believe that API should be extended, providing a proper HTTP Client (including URL interpolation). Being able to dynamically craft URLs and issue POST Requests (with content bodies) would enable creators & technical developers to easily connect to their own backends. This would allow for creator-driven experiences such as global leaderboards, dynamic content, and much more, without creating any extra strain in the VRChat Infrastructure. Furthermore, potentially adding WebSocket capabilities to the client would allow for realtime-intensive games to propagate their information using external infrastructure, reducing or completely removing the strain that they create. Some may argue that in the sense of content/world moderation, such an API would add an extra attack surface for "badly intended" users, however, I would like to state that any I cannot see any form in which this would be riskier than the current API we have. Information like User IP address can already be gathered via DownloadString, and any potentially dangerous hosts can be dynamically blocked via a global blocklist (combine that with a Roslyn analyzer, and creators could even be warned at build-time).

As a world creator, you may have found yourself in need of a way to make an object always face the local player, sometimes called Billboarding. Doing this with transforms requires update loops in Udon, which are expensive. We’re adding native support for this to make it easier and more performant to implement! Three new methods will be available! (Note: always subject to change until release!) VRCBillboard.Register(Transform target); // upright, tracks yaw only (side-to-side) VRCBillboard.Register(Transform target, bool allowTilt); // allows up-and-down pitch changes as well VRCBillboard.Unregister(Transform target); // cleanup is automatic but can be triggered manually

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.

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)

Since bone transforms aren't exposed, we can't parent objects to players and need to use expensive and complicated update loops for such a basic task, which also results in ugly/janky object movements and low performance. Please give us a simple function like .SetParent(Transform t, Boolean b) for .GetTrackingData(VRCPlayerApi.TrackingDataType.x) and .GetBonePosition(HumanBodyBones.x) and for VRCPlayerApi.GetPosition

Please add Udon/UdonSharp API for controlling and reading the mouse cursor in Desktop Mode Currently, interacting with a custom world UI requires holding TAB to free the cursor. This is inconvenient for long interactions such as crafting, waiting for processes to finish, or using an inventory. Ideally, Udon should be able to: Release the mouse cursor from script. Read the cursor position (x, y) while it is being used by the world. For privacy, cursor position could automatically become unavailable whenever the user interacts with a VRChat-owned UI/menu. In that state, Udon would receive no cursor-position data. Once the user returns to the world, access could be restored. This would allow custom desktop UIs to work more like normal game interfaces without requiring the user to hold TAB for the entire duration of an interaction. Receiving the cursor position would also be useful for visualizing drag-and-drop interactions. For example, a world could display an item being dragged by the cursor, show where it will be placed, or provide visual feedback while moving UI elements.

Deprecate VRC Station completely, and expose the atomized functions of a VRCStation. Let UGC handle "making a chair" and the other stuff that are currently "VRCStation janks": Expose player Transform parenting. (Also allows standing on moving platforms etc, rather than exploiting a "chair" and have a janky implementation) Expose player avatar animator parameters in Udon. (Also allows proper MMD functions without exploiting a "chair with hacked SDK .dll") (Optional) Expose player visibility in Udon. (No more desync station bug exploit jank using a "chair" to hide a player) ... have I missed any janks?