World/Udon Bugs & Feature Requests

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'.

Starting with Build 1878 (Open Beta) and Build 1885 (Live), there's a change to pickup highlighting which relates to VRC_Pickup with SkinnedMeshRenderer. It is written that "We feel that the amount of content this affects is extraordinarily small", but I have some worlds which are affected by this change. Some of them are SDK2 worlds and it would be a lot of work for me to fix all of them. I guess that some world creators (including me) assumed that SkinnedMeshRenderers are completely ignored by pickup highlighting, and I used this property to control pickup highlighting: Shader-based gimmicks often change the appearance of the mesh. In SDK2, use of SkinnedMeshRenderer is convenient for hiding its internal mesh shape and expanding mesh bounds. To select the highlighting mesh of pickups containing multiple child renderers, sometimes I change some renderers to use SkinnedMeshRenderer. Also, I preferred using the (fallback) collider outline for pickup highlighting. In this SDK3 era, I basically agree with the changes because there's a correct way to fix the issues. But I guess some worlds may still use this old technique. I want to say: Some world creators really care about the shape of pickup highlights. If the highlighting reveals the strange internal shape, players' immersion will be broken. Please keep existing behaviour as it is. I feel component versioning (e.g. VRC_Pickup Ver 1.1) is a very good idea, and it should be used more! I propose increasing the VRC_Pickup version number and keeping the old highlighting algorithm for older versions. I'm really sorry for not checking or reporting during Open Beta. I've attached some screenshots of my worlds which show how the new highlighting unintentionally reveals the internal mesh. (To be honest, I might be the one who uses this bad trick the most, though...)

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

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

Summary I found a reproducible Udon networking issue where a Manual-sync UdonBehaviour begins serialization without any user-code call to RequestSerialization(). The behaviour repeatedly receives: OnPreSerialization() OnPostSerialization(success = false, byteCount = 0) while the RequestSerialization call count remains 0. The issue depends on the composition/cardinality of UdonBehaviours attached to the same GameObject. Moving the additional UdonBehaviours to separate GameObjects prevents the issue in my isolated tests. Observed Behaviour With a Manual-sync Authority UdonBehaviour and certain additional UdonBehaviours on the same GameObject: RequestSerialization calls: 0 OnPreSerialization: repeatedly called OnPostSerialization: repeatedly called SerializationResult.success: false SerializationResult.byteCount: 0 I instrumented the first unsolicited serialization attempt. At FIRST OnPreSerialization: RequestSerialization count = 0 Networking.IsClogged = false Networking.IsNetworkSettled = true Networking.IsObjectReady = true local player is owner Authority SyncMethod = Manual Therefore the first observed serialization attempt was not preceded by an instrumented RequestSerialization call and did not begin while IsClogged was true. Minimal Cardinality Reproduction Using the same Authority behaviour and repeated copies of the SAME additional ProgramAsset on the SAME GameObject produced this pattern: Additional sibling UdonBehaviours: 0 -> QUIET 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop 5 -> QUIET 6 -> unsolicited serialization loop 7 -> QUIET The positive cases repeatedly produced: Req = 0 Pre > 0 Post > 0 success = false byteCount = 0 This was not specific to one ProgramAsset. I reproduced the same cardinality pattern with another Udon ProgramAsset: 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop I also reproduced it using distinct sibling ProgramAssets: 1 sibling -> QUIET 2 siblings -> unsolicited serialization loop 3 siblings -> QUIET 4 siblings -> unsolicited serialization loop I am NOT claiming that all even numbers of UdonBehaviours are generally broken. This is only the reproducible pattern observed under this isolated fixture configuration. Same-GameObject Isolation I then tested the registration/layout layer. Same GameObject: Authority + two relevant siblings -> unsolicited serialization loop Split GameObjects: Authority on GO-A Sibling 1 on GO-B Sibling 2 on GO-C -> QUIET Partial split: Authority + one sibling on GO-A second sibling on GO-B -> QUIET This suggests that same-GameObject Udon registration/composition is involved. Additional Cause-Layer Tests The problem was NOT reproduced simply by creating arbitrary zero-field behaviours. Controlled variants using inert zero-field Manual / Continuous behaviours remained QUIET in my tests. Changing between zero and one synced field also did not independently reproduce the issue. Therefore I currently classify this as a multifactor same-GameObject registration/composition issue rather than a bug in one specific script, NoVariableSync alone, synced-field count alone, or Manual sync alone. Expected Behaviour For a Manual-sync UdonBehaviour: If user code never calls RequestSerialization(), the owner should not enter a continuous OnPreSerialization / OnPostSerialization failure loop. In particular, I would not expect the addition/removal or placement of sibling UdonBehaviours on the same GameObject to cause unsolicited Manual serialization. Actual Behaviour Under the affected same-GameObject composition: RequestSerialization count remains 0, but serialization begins anyway. The first observed attempt occurs while: IsClogged = false IsNetworkSettled = true IsObjectReady = true It then repeatedly calls: OnPreSerialization() OnPostSerialization(false, 0) Important distinction VRChat documentation states that failed Manual serialization may be cached and retried when networking is clogged. That could explain repeated attempts AFTER a failed serialization event. However, in this reproduction the FIRST observed serialization attempt occurs with: RequestSerialization count = 0 IsClogged = false So the unresolved issue is what creates the initial Manual serialization event. Possible Related Existing Reports https://feedback.vrchat.com/persistence/p/persistence-does-not-restore-synced-variables-in-udon-components-other-than-the https://feedback.vrchat.com/bug-reports/p/pickup-events-may-not-be-called-when-multiple-udon-components-are-attached There are existing tracked reports involving multiple Udon components on the same GameObject, including: Persistence only restoring synced variables from the first Udon component Pickup events not reliably reaching multiple Udon components Those reports may or may not share the same underlying cause. This report describes a different failure mode involving the Manual serialization lifecycle. Impact This is particularly difficult to diagnose because: gameplay code does not call RequestSerialization the affected behaviour is Manual sync the behaviour may work or fail depending on same-GameObject composition changing hierarchy/component composition can make the issue disappear the resulting failed serialization loop can continue at a high rate In a modular Udon system, adding/removing otherwise unrelated sibling UdonBehaviours can therefore change networking behaviour unexpectedly. Workaround Separating the networking Authority UdonBehaviour and the additional UdonBehaviours onto different GameObjects prevents the reproduction in my isolated test. I consider this a workaround, not an explanation of the underlying behaviour. Reproduction Evidence I have retained: isolated minimal fixtures cardinality matrices ProgramAsset identities runtime SyncMethod fingerprints first-unsolicited-event instrumentation prefab/scene hashes for tested builds repeated runtime observations I can provide a stripped minimal Unity/VRChat reproduction project if useful.

We cannot check whether a GameObject is destroyed or not. To detect an GameObject is destroyed or not, we normally may use (gameObj != null) or (gameObj != null && gameObj.name != "ToDestroy" ) or ReferenceEquals(gameObj , null) Those codes work perfectly in udonSDK3 unity editor environment. However, the same code will throw exception in-game which cause the script stop running. To investigate, we tried to enable UdonSecureHeap in editor and the editor also throw errors, so we guess that Udon's secure heap is what breaking the in-game behavior. The exception message say 'Your script should either check if it is null or you should not destroy the object.' However what I am doing is actually the null-checking!! The following is the error log. I am destroying a 'Cube' and check the cube's status using 'Tester' by showing the result on UnityEngine.UI.Text, which shows "Object is NOT null" or "Object is null" : [UdonBehaviour]An exception occurred during Udon execution, this UdonBehaviour will be halted. VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'UnityEngineObject.__op_Equality__UnityEngineObject_UnityEngineObject__SystemBoolean'. Parameter Addresses: 0x0000000B, 0x00000004, 0x0000000A The object of type 'GameObject' has been destroyed but you are still trying to access it. Your script should either check if it is null or you should not destroy the object. ---------------------- Program Counter was at: 92 ---------------------- Stack Dump: ---------------------- Heap Dump: 0x00000000: 6459115532197657758 0x00000001: Tester 0x00000002: null 0x00000003: Text (UnityEngine.UI.Text) 0x00000004: null 0x00000005: null 0x00000006: Object is null 0x00000007: Object is NOT null [ 0x00000008: ] 0x00000009: 4294967295 0x0000000A: False 0x0000000B: null 0x0000000C: 241 0x0000000D: Cube (UnityEngine.GameObject) 0x0000000E: Object is NOT null [Cube (UnityEngine.GameObject) 0x0000000F: Object is NOT null [Cube (UnityEngine.GameObject) 0x00000010: Object is NOT null [Cube (UnityEngine.GameObject)] 0x00000011: Object is NOT null [Cube (UnityEngine.GameObject)] 0x00000012: 241 0x00000013: Object is NOT null [Cube (UnityEngine.GameObject)]241 0x00000014: 4294967295 0x00000015: UnityEngineObject.__op_Equality__UnityEngineObject_UnityEngineObject__SystemBoolean 0x00000016: UnityEngineTime.__get_frameCount__SystemInt32 0x00000017: SystemInt32.__ToString__SystemString 0x00000018: SystemString.__op_Addition__SystemString_SystemString__SystemString 0x00000019: UnityEngineUIText.__set_text__SystemString__SystemVoid 0x0000001A: UnityEngineGameObject.__ToString__SystemString ---------------------- Inner Exception: ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'UnityEngineObject.__op_Equality__UnityEngineObject_UnityEngineObject__SystemBoolean'. Parameter Addresses: 0x0000000B, 0x00000004, 0x0000000A ---> UnityEngine.MissingReferenceException: The object of type 'GameObject' has been destroyed but you are still trying to access it. Your script should either check if it is null or you should not destroy the object. at (wrapper managed-to-native) UnityEngine.GameObject.get_transform(UnityEngine.GameObject) at VRC.Udon.Security .UnityEngineObjectSecurityBlacklist.IsBlacklisted[T] (T objectToCheck) [0x0008c] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\Security\Source\UnityEngineObjectSecurityBlacklist.cs:50 at VRC.Udon.ClientBindings.UdonClientInterface.IsBlacklisted[T] (T objectToCheck) [0x00000] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\ClientBindings\Source\UdonClientInterface.cs:83 at VRC.Udon.UdonManager.IsBlacklisted[T] (T objectToCheck) [0x00001] in E:\Unity Project 2018\Test2018World\Assets\Udon\UdonManager.cs:137 at VRC.Udon.Security .UdonSecureHeap.ScanHeapValue[T] (T& heapValue) [0x0005f] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\Security\Source\UdonSecureHeap.cs:142 at VRC.Udon.Security .UdonSecureHeap.GetHeapVariable[T] (System.UInt32 address) [0x0000d] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\Security\Source\UdonSecureHeap.cs:55 at VRC.Udon.Wrapper.Modules.ExternUnityEngineObject.__op_Equality__UnityEngineObject_UnityEngineObject__SystemBoolean (VRC.Udon.Common.Interfaces.IUdonHeap heap, System.UInt32[] parameterAddresses) [0x00000] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\Wrapper\Source\Modules\UnityEngine\ExternUnityEngineObject.cs:89 at VRC.Udon.VM.UdonVM.Interpret () [0x00272] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\VM\Source\UdonVM.cs:281 --- End of inner exception stack trace --- at VRC.Udon.VM.UdonVM.Interpret () [0x00326] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\VM\Source\UdonVM.cs:305 --- End of inner exception stack trace --- at VRC.Udon.VM.UdonVM.Interpret () [0x003f4] in C:\VRChatGit\VRChat-Udon\UdonVM\Udon\VM\Source\UdonVM.cs:346 at VRC.Udon.UdonBehaviour.RunProgram (System.UInt32 entryPoint) [0x0006a] in E:\Unity Project 2018\Test2018World\Assets\Udon\UdonBehaviour.cs:1867 UnityEngine.Debug:LogError(Object, Object) VRC.Core.Logger:LogError(String, Int32, Object) VRC.Udon.UdonBehaviour:RunProgram(UInt32) (at Assets/Udon/UdonBehaviour.cs:1877) VRC.Udon.UdonBehaviour:Update() (at Assets/Udon/UdonBehaviour.cs:762)

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.

I'm aware SDK2 is no longer supported, but I wanted to bring this up as it breaks so many great worlds and seems like it may be a straightforward fix. In SDK2 worlds, OnPlayerTriggerEnter is no longer working for players when entering a trigger collider. This breaks core functionality in many worlds. A good example is this classic, "Fever Dream": https://vrchat.com/home/world/wrld_4137b868-771b-4dd1-ac76-a138d56dbd41/ Steps to reproduce: Enter the first room and turn the corner. The next area no longer turns on when entering the trigger collider.

Currently, it appears that manual syncing has been broken. In at least my world ( https://vrchat.com/home/launch?worldId=wrld_54123524-3329-4091-bdb1-1c43e86451d9 ), I am being spammed with this in the console: 2022.05.27 08:52:56 Error - [Network Transport] Received serialization data for id 109, but we have no serializers for that object. 2022.05.27 08:52:57 Error - [Network Transport] Received serialization data for id 102, but we have no serializers for that object. 2022.05.27 08:52:57 Error - [Network Transport] Received serialization data for id 109, but we have no serializers for that object. 2022.05.27 08:52:57 Error - [Network Transport] Received serialization data for id 101, but we have no serializers for that object. 2022.05.27 08:52:57 Error - [Network Transport] Received serialization data for id 110, but we have no serializers for that object. 2022.05.27 08:52:57 Error - [Network Transport] Received serialization data for id 109, but we have no serializers for that object. ...etc And the objects which deal with manual syncing are not behaving properly on clients who are not the owner, and initially try to sync their position to (0,0,0)

VRCSDK3-WORLD-2021.03.09.13.57_Public Unity 2018.4.20f1 When many Midi Events are received, references outside the buffer range will occur. Log IndexOutOfRangeException: Index was outside the bounds of the array. VRC.SDKBase.Midi.VRCPortMidiInput.Update () (at Assets/VRCSDK/SDK3/Runtime/Midi/VRCPortMidi.cs:71) VRC.SDK3.Midi.VRCMidiHandler.Update () (at <5d3e9f7f72234587a2c25e98f82b4f27>:0)