World/Udon Bugs & Feature Requests

I am working on a world that uses manual sync to store large amounts of data, potentially up to 16mb. This data is spread across 4*16 Behaviours, each syncing a max of ~260kB of data. When a player joins an instance, they will receive any previously synced data on join, all at once. When the amount of data reaches a certain threshold, about 6mb or so, it becomes too much for either the server or the client to handle, and the player is unable to join: Debug - [Behaviour] Holding recovery payload until all bunches are received. ---------- Repeats 4500 times ------ Error - Got DisconnectMessage. Code: -11 Msg: "SendBufferFull". Debug Info: {} Debug - [Behaviour] Holding recovery payload until all bunches are received. ---------- Repeats 500 times ------ Debug - [Behaviour] OnLeftRoom Debug - [Behaviour] Cleaning up held messages Debug - [Behaviour] OnPlayerLeft Roughy~ (usr_826b49cd-2e24-4a54-8435-3344dfe9512d) Debug - Removed player Roughy~ Debug - [Behaviour] OnDisconnected: DisconnectByDisconnectMessage A full log of multiple join attempts is attached. The same problem was experienced by multiple users. Separating the data into smaller objects ( ~64kb per object instead of 260kb ) yields the same results. The "SendBufferFull" error itself appears to originate in Photon, and as the name suggests it's just trying to send too much data too fast. Players already in the instance do not appear to be affected in any way. This effectively means there's a limit of about 5mb of synced data. Is this an intentional limit or a bug?

Ownership can permanently desync between clients in an unexpected way The included script can generate such a desync, please assign a TMP text field to view it, then join with 2 clients --- Of note for anyone experiencing this, I've had some success mitigating it by overriding OnOwnershipRequest and returning true public override bool OnOwnershipRequest(VRCPlayerApi requestingPlayer, VRCPlayerApi requestedOwner) { return true; }

This can be an issue when using stations for vehicles with trigger zones. For example, i have a setup where i want audio to enable and disable based on the player location. This works fine with players, but to make it work with those vehicles i would need a second check for the vehicle.

This used to be not an issue before, but now if you have a Non-trigger Collider (set to a Unity or Custom layer, excluding the Walkthrough layer since it already does what it is supposed to do but that's beside the point) that is set to exclude the Player/PlayerLocal layer, the player will still "collide" with it and be able to "walk" on top of the collider's surface while slowly descending as if they were using a flying avatar. They'll still be able to go through the collider, but the problem here is that they can stand on top of the collider when they shouldn't be.

On Later-Joiner's client, OnVariableChanged can be fired without OnDeserialization() before OnEnable() and Start() . It will be happened especially if the object owner uses RequestSerialization() frequently (such as per second interval synchronization). It can be critical problem because it makes OnEnable() and Start() are not guaranteed before synced variable changes: firing OnVariableChanged before Start() can breaks Udons that implementing initialization at Start() . This bug seems the reoccurrence of following this Canny: https://feedback.vrchat.com/udon/p/1259-synced-variables-can-be-changed-from-owners-requestserialization-before-lat Build: 1539 ---- I've made the new testing world to check event orders: https://vrchat.com/home/world/wrld_c357c8f1-1d22-4e91-bfdc-e72c04097fe1/info . (Sample screenshot is attached below) Reproduction steps: Make the instance of the world (Player A), join the instance then enable interval sync from "Toggle Sync Interval" buton. (It starts 0.25s interval of synced int increment using manual sync) Join another player to its instance (Player B). See the console UI in the world at Player B. Expected Results: At Player B console UI, "SyncInt change" console message should only be occured before "OnEnable". Actual Results: At Player B console UI, there is small chance to occur "SyncInt change" console message before "OnEnable". - It may sometimes not be occurred, so try re-joining several times.

Currently manual sync is significantly faster than object sync and RPCs. This is fine... until you are using manual sync to replicate e.g. a control for a particle effect bound to a held object. We need a way to get these back into sync. Some potential options include: If the object sync latency is fixed, provide a way to obtain this delay so we can apply it to manually synced values. Provide a way to attach synced variables that are transmitted on object synced updates, but do not prevent the object from sleeping when it's not being moved (see https://feedback.vrchat.com/udon-graph-upgrade-closed-testing/p/reliable-sync-feedback-please-add-a-way-to-sleep-a-continuously-synced-object )

If you attempt to create an array of UdonBehaviours by naming the type VRCUdonUdonBehaviourArray, it does not get recognized as a valid Udon type and fails to assemble. The alternate special case type "VRCUdonCommonInterfacesIUdonEventReceiver" that's used in other places that takes the place of UdonBehavior doesn't have an array type of "VRCUdonCommonInterfacesIUdonEventReceiverArray" defined either. So at the moment we need to use arrays of Component to represent arrays of UdonBehaviours. This issue is probably related and seems like a workaround on the graph side or a bug that's hiding the issue: https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/udonbehaviour-variable-compiles-into-unityengineobjectarray-which-is-an-object

Some manually synced objects are more critical to sync quickly than others - you might have some that need to sync a large amount of data (which might tie up a significant portion of the transmitter's bandwidth) but can do so slowly while others you'd like to respond immediately. Currently, the bandwidth limit for manually synced objects seems to be instancewide, so if there's a single bandwidth hog it'll penalize everything. Having a way to set a QoS or priority value on a gameobject would allow the world author to select what suffers and degrade gracefully when bandwidth limits are exceeded; it would also greatly simplify bulk transmissions.

There is an undocumented limit on Network IDs. If you assign a Network ID beyond 10 000 to a PlayerObject its persistence features will break while the UdonBehaviour itself still functions and syncs. ClientSim throws the following error: ran out of player persistence view ids In-game testing results in Removed some Player Persistence metadata that had invalid IDs. errors. Apparently there is a limit of 100 000 for Network IDs in general, its way less likely to hit this, but this also seems undocumented. The difference in limit for PlayerObjects and standard UdonBehaviour objects is confusing and the provided errors don't accurately explain how to solve this issue. The Network ID Utility also does not seem to take this limit for Player Objects into account and does not warn or ensure a lower ID is assigned to the persistent objects. Furthermore, the Network ID Utility crashes on projects with this many Network IDs, but this was already documented here: https://feedback.vrchat.com/sdk-bug-reports/p/network-id-utility-has-massive-performance-issues

When using a Spatial Audio Source component on an audio source, using "PlayOneShot" will occasionally ignore the max distance set for the component, sometimes playing the whole clip while other times cutting off the clip after playing really quickly. I'm personally using this for collision audio for physics objects, so randomly hearing blocks clanking together from across the map is rather obnoxious. I've set up a quick demo for this, simply chuck the objects as far as you can and they'll occasionally make sounds despite being far out of it's max range. https://vrchat.com/i/yahoo-yuniquehorse-88b85