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.

In any world that has a chair that you are able to pick up when another player is sitting on it, it is laggy and out of sync, it used to always be perfectly synced between every player, but is now broken after maybe the unity 6 update? (edit: it is any VRC station) The following attached video is what it looks like Edit: Big apologies I was not aware multiple people have already reported this already, since i was looking in the wrong places

repro world: https://vrchat.com/home/world/wrld_685838b2-dc34-47c7-8adf-92d5016075dc repro procedure: Join two clients. Watch bandwidth (debug menu 4) usage on master. On live it's around 3 k/s, on danly-perf it's over 10 k/s (sometimes ending up with a persistent death run which degrades IK fidelity) Debug 8 will show BW 0.00b/s for tiles not moving on live, but around 40-80 on danly-perf Images are perf branch and (a slightly old) live branch screenshot of debug 4 and 8 showing the bandwidth usage difference.

Writing a U# program like so, will fail with: Method is not exposed to Udon: 'texture.SetPixelData(d, 0, 0)'. Even though it is exposed as UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D U# Code: var texture = new Texture2D( 2, 2, TextureFormat.RGBA32, false ); uint[] d = new uint[2 * 2 * 4]; texture.SetPixelData(d, 0, 0); However it will compile in udon graph, but the data input will be a Object[], and will crash with anything passed to it. Manually writing some udon assembly will compile again, but will also crash at runtime udon assembly: .data_start .export tex .export arr .export num0 .export num1 .export f .export tex_format tex: %UnityEngineTexture2D, null arr: %SystemSingleArray, null num0: %SystemInt32, null num1: %SystemInt32, null f: %SystemBoolean, null tex_format: %UnityEngineTextureFormat, null .data_end .code_start .export Test Test: PUSH, num1 PUSH, num1 PUSH, tex_format PUSH, f PUSH, tex EXTERN, "UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D" PUSH, tex PUSH, arr PUSH, num0 PUSH, num0 EXTERN, "UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid" JUMP, 0xFFFFFFFC .code_end udon assembly crash: VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'. Parameter Addresses: 0x00000000, 0x00000001, 0x00000002, 0x00000002 Cannot retrieve heap variable of type 'Single[]' as type 'Object[]' ---------------------- Program Counter was at: 80 ---------------------- Stack Dump: ---------------------- Heap Dump: 0x00000000: (UnityEngine.Texture2D) 0x00000001: System.Single[] 0x00000002: 0 0x00000003: 1 0x00000004: False 0x00000005: RGBAFloat 0x00000006: UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D 0x00000007: UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid ---------------------- Inner Exception: ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'.

SDK 3.10.5 See below code, it outputs "false, true, true" (and vice versa) which is obviously wrong. However if the property is public it outputs "true, true, true" as expected. using UdonSharp; using UnityEngine; [UdonBehaviourSyncMode(BehaviourSyncMode.None)] public class WhyPropertyNoWork : UdonSharpBehaviour { private int state; private const int TestState = 3; private bool IsTestState { get { return state == TestState; } set { } } private WhyPropertyNoWork _whyThis; private void Start() { state = TestState; _whyThis = this; } public override void Interact() { Debug.Log( $"TESTTEST, _whyThis.IsTestState={_whyThis.IsTestState}, IsTestState={IsTestState}, _whyThis.IsTestState={_whyThis.IsTestState}"); if (state == 3) state = 0; else state = TestState; } }

If a person were to go into a Station that has disableStationExit enabled, then you set disableStationExit to false, the player in that chair does not get the update and are unable to leave the chair, same in reverse. As well, calling ExitStation on that chair while disableStationExit is true does nothing, which would be my only way around the previous issue.

In VRChat SDK 3.10.5, a NoVariableSync UdonSharp behaviour appears to cause other behaviours on the same GameObject to switch from Manual to Continuous synchronization. We encountered this issue in our world, “すーはー式ごいた”. The issue is now resolved in our world by explicitly setting all affected behaviours to Manual. This is a world-side workaround; we have not confirmed a fix in the SDK itself. The current version of our world therefore no longer reproduces the original issue. Affected setup Each game piece had three UdonSharp behaviours on the same GameObject: KomaScript : Manual ManualSync_suuhar : Manual UdonImageOwnerSpriteRenderer : NoVariableSync We observed piece object positions rolling back and a drop in FPS due to excessively frequent 'OnDeserialization()' calls. Diagnostic findings During approximately four minutes of testing, our logs recorded: Over 40,000 deserialization callbacks, including identical to the previous reception. Increasing send timestamps on all duplicate receptions. 62 explicit RequestSerialization() calls, but 1,856 OnPreSerialization() callbacks and 1,856 successful OnPostSerialization() callbacks. For one piece, two explicit serialization requests resulted in 58 serialization callbacks over approximately 14 seconds, with a median interval of 0.239 seconds. Changing UdonImageOwnerSpriteRenderer from NoVariableSync to Manual , so that all three behaviours explicitly use Manual, resolved the reported issue in our testing. Suggested reproduction Add a Manual-synced UdonSharp behaviour with synced variables to a GameObject. Add another UdonSharp behaviour marked NoVariableSync . A NoVariableSync behaviour should remain compatible with Manual behaviours on the same GameObject without switching them to Continuous. Environment World: すーはー式ごいた ( https://vrchat.com/home/world/wrld_a68a2924-fb2c-4860-adef-d687853e4b79/info ) Unity: 2022.3.22f1 VRChat Worlds SDK: 3.10.5 VRChat Build Number 1903 Currently, resolved in the world using SyncMode.Any

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.

ClientSim gathers the "PlayerPersistenceObjects" in ClientSimPlayer.cs before ClientSim removes objects that are tagged EditorOnly. This breaks the ClientSim initialization process, resulting in "_stackedCameraReady" never being set to true. This results in the menu's "ToggleMenu" function failing to close the menu, causing the user being unable to test their scene under this scenario.

After importing a dolly via Udon, the "Speed" value set in VRC Camera Dolly Point does not get translated correctly when the "Copy to Camera" button on the point gets used in-client. Anything set with speeds 1 or greater gets applied as 15.0 in-game (clamped limit) and 0.1 gets applied as 0.2 (clamped limit). Editor values tried: 0.15 editor -> 0.4 client 0.2 editor -> 0.5 client 0.25 editor -> 0.8 client 0.4 editor -> 3.0 client 0.6 editor -> 5.1 client 0.9 editor -> 11.5 client