World/Udon Bugs & Feature Requests

Environment: Unity version: 2022.3.22f1 VRChat SDK Worlds: 3.10.3 VRChat SDK Base: 3.10.3 UdonSharp included with SDK Project uses Prefab Mode / PrefabStage with UdonSharpBehaviour components YamaPlayer package present: net.kwxxx.yama-stream 1.5.18 Observed: When opening or editing prefabs containing UdonSharpBehaviour components in Prefab Mode, Unity logs repeated ArgumentNullException errors from OdinSerializer UnitySerializationUtility. Error: ArgumentNullException: Value cannot be null. Parameter name: unityObject VRC.Udon.Serialization.OdinSerializer.UnitySerializationUtility.SerializeUnityObject(...) UdonSharp.UdonSharpBehaviour.UnityEngine.ISerializationCallbackReceiver.OnBeforeSerialize() and similarly: UnitySerializationUtility.DeserializeUnityObject(...) UdonSharp.UdonSharpBehaviour.UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() Trigger: Open a prefab containing UdonSharpBehaviour in Prefab Mode Move a child object or let PrefabStage autosave run Errors repeat, sometimes dozens/hundreds per save Expected: PrefabStage autosave should not throw if a Unity pseudo-null UdonSharpBehaviour or serialized target is encountered. It should skip invalid objects or handle UnityEngine.Object pseudo-null safely. Additional finding: For diagnosis only, I temporarily tested a local guard around the SDK serialization path. The test indicated that the affected object was not a normal C# null reference, but behaved as null through Unity's overloaded UnityEngine.Object null comparison. With that guard in place, the exception stopped. I am not using this as a permanent workaround and do not intend to publish content with a modified SDK. This observation is included only to help identify the likely failure path. Additional observation: I have encountered this issue twice. In both cases, once the issue started occurring in the project, checking out older repository commits did not reliably make the issue disappear. This suggests that the trigger may involve Unity Library/cache/generated SDK state or some project-local serialized state, not only the currently checked out asset files.

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

It appears that there is a threshold that must be met when scrolling the content of a world space ScrollView which is not adjusted based on the size of the scroll view. This makes it impossible to scroll sufficiently small ScrollViews (if there are no scrollbars). In Client Sim, there is no such threshold. In-Game example: https://i.imgur.com/yQ6Fj0c.mp4 Editor example: https://i.imgur.com/Ry1QZk6.mp4

I had a global door that was meant to be 1-sided, but the player collider would still trip the trigger, but only to remote players. It'd still be closed for the local player, but to everyone else it was open.

Occasionally, when attempting to reference synced variables in other scripts when not the owner of that data, it will return the default value rather than the current value. The current workaround for this is to save all synced data as separate local variables and reference those externally, and only use the synced variables in OnPreserialization, OnDeserialization, and OnPostSerialization. This was an issue I first noticed way back in June 2021, but I was never able to consistently have it break until now. In this example world, the Dealer script is attempting to reference the GameActive boolean synced variable from the Controller script in OnDeserialization, returning if false to ensure data is not ran when the table is not active. However, for everyone except the owner of the controller script, the GameActive variable always returns the default false value, rather than the current value. To test, join the table with one user, and with the person in control, set the game type to manual mode and start a match. Provided debug logs in the code will show the GameActive state on every client. https://vrchat.com/home/world/wrld_4f737bcb-05fa-4898-8234-f3d60dad6ef2

Assigning the start time of a AVPro streaming video will assign the latest time loaded in a video if that point assigned is further ahead than what is actually loaded. I have created a demo world that displays that displays this happening. https://vrchat.com/home/launch?worldId=wrld_567771c3-b0eb-4623-a127-867bf1c6db6a&instanceId=65015~hidden(usr_7ec23ebf-254f-4dac-9d62-f90194affd52)~region(us)~nonce(4a058c3a-bd6b-4055-b69f-9852d72ae37d)

After a random period of time, some users send and receive times become exactly the same, with the total network travel time seemingly being 0. In the attached screenshot, all relevant data is on right side. Serialization Time is result.receiveTime - result.sendTime, Send Time directly reads result.sendTime, Receive Time directly reads result.receiveTime, and Time since startup reads Time.realtimeSinceStartup Here is the world where the issue was discovered: https://vrchat.com/home/world/wrld_7fd1ba0f-4d07-4a6f-b984-e48a6d6cc7ad When entering the world, enable debug panel and hit start, and over time keep track of other players serialization data.

The following script will break a script's networking: [UdonSynced] private MyUdonSharpBehaviour foo; And causes the following error: 2022.10.20 02:49:28 Error - [Behaviour] Caught ArgumentNullException: Value cannot be null. Parameter name: Received a null value when encoding a UdonBehaviour [...] The error can only be found in VRChat's log file and was difficult to identify.

Gravity and Kinematic flags on VRCObjectSync components don't sync correctly right now and also cannot be set correctly while holding the pickup. To set gravity or kinematic flags, VRChat added two new methods for us: https://udonsharp.docs.vrchat.com/vrchat-api/#vrcobjectsync (they are supposed to behave like a synced variable) There are two bugs related to this: ~ Bug 1: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component with an external button after claiming ownership. Then you let different people in the world pick up the pickup and drop it (to show their own local state). In my tests, this resulted in a pickup where the gravity flag is wildly different on each client and only syncs occasionally or not at all. They would see the pickup drop on my end, but when they pick it up it has no gravity for them. ~ Bug 2: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component in OnPickupUseDown() . In my tests, this resulted in a pickup where the gravity stays enabled after the first OnPickupUseDown() and I am unable to turn gravity off again. To check gravity, the pickup is dropped. You can also just test it out here: Right setup: Bug 1 / Left setup: Bug 2 https://vrchat.com/home/world/wrld_9cefd5ec-4492-43c5-8cd3-05036c494556 Additional note: Since we only got a setter and not a getter method, we are left in the dark here when it comes to analyzing the problem. Reading out the local rigidbody state doesn't give us access to the real synced state. A getter method should be added.

VRCSDK3-WORLD-2021.06.03.14.57_Public