World/Udon Bugs & Feature Requests

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

My world has a layered camera setup and requires for the reference (main) camera of the world to be set to render with Clear Flags set to Depth only and only render from players eyes up to 1000 meters in order to maximize performance. Secondary camera of the world is set to render only a low quality copy of the terrain and surrounding mountains in the horizon from 1000 meters all the way up to 4000 meters before the main camera of the world renders the scene. Despite the player's POV looking perfectly normal on desktop and in VR, the in-game camera, steadycam and personal mirror all break because they inherit all applicable properties of the reference camera and don't properly clear the render, resulting in unacceptable ghosting in the sky. I'm asking for the VRCSDK to include an option to set the camera properties of VRChat's in-game user cameras independently from the reference camera, e.g. fields for Clear Flags, Near Clip, Far Clip on the VRCSceneDescriptor so they can still keep functioning without the world author having to provide a completely custom camera solution from the ground up in order to mitigate this issue. If exposing the properties in the SDK is too big of an ask, at least ensure that the in-game cameras do not have their Clear Flags set to Depth Only or Don't Clear. Thank you. P.S. This issue could also be fixed by allowing the world to set the Clear Flags of the player's main camera during runtime with Udon, related post: https://feedback.vrchat.com/udon/p/give-us-an-interface-to-the-main-camera-via-the-vrcgraphics-class

If you use VRCPlayerApi.SetVoiceDistanceFar() or VRCPlayerApi.SetVoiceDistanceNear() The the value seems to get clamped to a maximum of 10000. I would like the maximum range to be as high as possible for stuff like aircraft radios.

Name of the VRCSDK package you have imported. VRCSDK3-2020.03.21.12.04 Name of the Udon SDK package you have imported. UDONSDK-2020.03.21.12.24 Version/build of VRChat you’re using to test, if necessary. Latest open beta. (906) A general description of the bug you’re encountering. Attempting to send a long string, like "Trip,Bond,Diamond,Cap,Copper,Canada,Ray,Circle,Centaur,Deck,Dwarf,Wind,Arm,Seal,Pipe,Pyramid,Nail,Amazon,Queen,Theater,Screen,Jupiter,Dress,Game,Whale," over the network via synced vars will return the following error: 2020.03.21 21:33:39 Error - [FlatBufferNetworkSerializer] Caught ArgumentOutOfRangeException: Non-negative number required. Parameter name: count at System.Text.UTF8Encoding.GetString (System.Byte[] bytes, System.Int32 index, System.Int32 count) [0x00000] in <00000000000000000000000000000000>:0 at DŽDžDžDŽDžDžDŽDžDŽDŽDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDžDžDŽDŽDžDžDžDŽDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDžDžDž.DŽDžDŽDžDŽDŽDŽDžDžDžDžDžDžDžDžDžDŽDžDžDžDžDŽDŽDŽDžDŽDžDŽDŽDžDžDžDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDžDŽDŽ (System.Int32 DžDžDžDŽDŽDžDžDŽDžDžDžDŽDŽDžDŽDžDŽDŽDŽDžDžDŽDŽDŽDžDžDžDžDžDžDŽDŽDŽDžDŽDŽDžDŽDžDŽDžDžDŽDžDŽDžDŽ, System.Int32 DŽDŽDžDŽDŽDžDžDŽDžDŽDžDŽDžDŽDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDžDŽDŽDžDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.UdonSync.DŽDŽDžDŽDŽDžDžDžDŽDžDŽDŽDžDžDžDžDžDŽDžDžDŽDŽDŽDŽDžDžDŽDŽDŽDžDžDŽDžDŽDžDžDžDŽDŽDžDžDžDŽDžDŽDŽDž (DžDŽDŽDŽDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDŽDžDžDžDžDžDžDžDžDžDŽDŽDžDžDžDžDžDžDŽDŽDŽDžDžDžDŽDžDžDŽDžDžDžDŽ DŽDŽDžDžDŽDžDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDŽDžDžDžDžDžDžDŽDŽDžDŽDŽDŽDžDŽDŽDŽDžDžDŽDžDžDŽDžDŽDŽ, System.Int32 DŽDžDžDŽDžDŽDŽDŽDžDžDžDžDŽDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDžDžDŽDžDŽDŽDŽDŽDžDž, System.Type DžDŽDŽDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDžDŽDŽDŽDŽDžDžDžDŽDžDžDžDžDŽDžDžDžDŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.UdonSync.DžDŽDŽDžDŽDŽDžDŽDžDžDŽDžDŽDŽDŽDŽDžDŽDžDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDŽDžDŽDžDŽDŽDžDŽDŽDŽDžDžDŽDŽ (DžDžDŽDžDžDžDžDŽDŽDŽDŽDŽDŽDžDžDŽDŽDžDŽDŽDŽDŽDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDžDžDŽDžDŽDžDŽDžDžDŽDžDžDŽ DŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDŽDŽDŽDŽDŽDŽ, System.Int32 DžDŽDŽDŽDŽDŽDŽDžDŽDžDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDŽDžDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDŽDŽDŽDž, System.Single DžDžDŽDžDŽDžDŽDžDŽDŽDžDŽDŽDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDŽDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.FlatBufferNetworkSerializer.DŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDŽDŽDžDŽDžDŽDž (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at NetworkManager.DŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDŽDŽDžDŽDžDŽDž (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at UnityEngine.AudioClip+PCMReaderCallback.Invoke (System.Single[] data) [0x00000] in <00000000000000000000000000000000>:0 at DŽDŽDžDžDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDŽDžDžDžDŽDŽDŽDŽDŽDŽDŽDžDŽDžDžDžDžDžDžDŽDžDžDžDžDŽDž.OnEvent (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at DŽDžDžDŽDŽDŽDŽDžDŽDŽDžDŽDžDŽDžDŽDŽDžDŽDžDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDŽDŽDžDŽDžDŽ.OnEvent (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.PeerBase.DeserializeMessageAndCallback (ExitGames.Client.Photon.StreamBuffer stream) [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.EnetPeer.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.PhotonPeer.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at DŽDŽDŽDžDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDŽDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDžDžDžDŽDžDŽDŽDžDŽDŽ.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at Photon.Pun.PhotonHandler.FixedUpdate () [0x00000] in <00000000000000000000000000000000>:0 Sending a shorter string, like "Trip,Bond,Diamond,Cap,Copper," works without issue on the same world. Step by step guide how to replicate the bug. Will get this if needed. --- This could just be a limitation of syncing strings - if there's a hardware limit, can we have an error letting us know that the string is too long to be sent?

VRCSDK3-WORLD-2021.06.03.14.57_Public

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)

Description: If an interactive object is cloned with VRCInstantiate, both the cloned object and the original object will lose interactivity. Reproduction: This can be reproduced by creating a 3d cube gameobject on layer 8/Interactive with a Udon script that has an Interact event in it. Then, in a separate gameobject, create a Udon script that uses VRCInstantiate on the gameobject (through public variables) after the Start event. In the images below, the graphs ordered by when they were mentioned. The graph in the first image should be set to a gameobject #1 and the one in the second image should be set to gameobject #2. Then, the variable should be set to gameobject #1. Gameobject #1 should be a 3D cube (this is not necessary), and #2 should be an Empty (again, not necessary). Other info: This error only occurs on live worlds. Local testing works as expected (both objects are interactable). This can create very confusing errors and broken worlds. Tested Version: VRCSDK3+UDON-2020.04.01.10.20.

When a player leaves the instance or enters a station, OnPlayerTriggerExit does not fire for any trigger colliders that they were in. This will break any system trying to count the players in an area. It is known that Unity will not fire OnTriggerExit when either deleting the collider or disabling colliders, but you must move the collider out of the area. Example world: wrld_d3e81903-54d6-4562-a968-2223c368906e World has a blue trigger area and will display when a player enters or exits. There is also a chair in the area. Test case 1: Have two or more players in the room. Have one player enter the area Have that player leave the instance. Note that a player exit trigger message is never displayed. Expected result would be that OnPlayerTriggerExit fires, which would then display the message Test case 2: Have one player enter the blue area. Have that player sit in the chair. Notice that player exit area does not fire. Have the player exit the chair. Notice that player enter does fire and the count is now off by one. Expected result would be that on entering a station (which disables the player collider), Player trigger exit fires.

If you name your GameObject PlayerManager , then execution of SendCustomNetworkEvent is blocked. This behavior newly started from build 944 or 946 without any notice. I made a world for reproduction: https://vrchat.com/home/world/wrld_f17d2b37-2f60-47d2-b280-e4489ba29368 --- I use identical Udon program for two GameObjects. You'll see logs for the failure case (named PlayerManager ) like this ("naqtn" is my user name): [Network Processing] RPC called PlayerManager:UdonSyncRunProgramAsRPC:All and 10 bytes [VRC_EventDispatcherRFC] SendRPC/AlwaysUnbuffered on PlayerManager blocked for naqtn (local master owner) --- On the other hand, the log success case (named Foo ) is like this: [Network Processing] RPC called Foo:UdonSyncRunProgramAsRPC:All and 10 bytes [VRC_EventDispatcherRFC] Will execute SendRPC/AlwaysUnbuffered on Foo (UnityEngine.GameObject) for naqtn: S: "UdonSyncRunProgramAsRPC" I: 0 F: 0 B: Unused (local master owner) [Network Processing] RPC invoked UdonSyncRunProgramAsRPC on Foo for naqtn [UdonSync] Foo executing echo at the behest of naqtn --- I guess "real" PlayerManager exists somewhere (perhaps in hidden player object) and the system wants to block malicious incoming messages. It might reach with adjusted network id. But I think blocking by the name is not reliable and is not good way to do that. Because VRC_EventDispatcherRFC must be able to get the object reference of real PlayerManager internally. I'm not sure this is a bug or intended feature. If this is a feature, please describe in the document and announce to Udon creators.

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