World/Udon Bugs & Feature Requests

Post about current World or Udon bugs feature requests. One item per post!
Non-constructive and off-topic posts will be moved or deleted.
UdonSharpBehaviour throws ArgumentNullException during PrefabStage autosave when Unity pseudo-null object is serialized
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.
1
·
Bug Reports
·
tracked
Collider edge gravity riding bug
Try it out in this world: https://vrchat.com/home/world/wrld_0d5aae29-9ff4-4230-9697-cea19a896b79 When standing at the edge of a Box Collider (I have not tested other types of Colliders), .InPlayerGrounded() remains false incorrectly, while the player is still being held up by the Collider. The resulting chain of effects: Player retains velocity as if in mid air, thus creating a sliding effect along the direction the player was moving. While in this state, player cannot jump, just like in mid air. While in this state, player can move and change direction of the sliding (again, as if in a pseudo state of free falling mid air). While in this state, player is also continually being affected by gravity therefore can accumulate an infinite amount of downward velocity (minus Y) while in this sliding state or "gravity riding" state. When the player eventually exits this state (when his capsule is no longer being held up by the collider, or if he steps onto the collider properly), the massive downward velocity will snap the player to whatever floor surface is below the player in an instant, rather than the expected effect of start free falling with an initial zero downward velocity and slowly becoming faster like you would stepping off a high platform. Further testing or related bugs: The player capsule behaves differently while walking into different types of Colliders (e.g. Box Collider, Capsule Collider, Mesh Collider etc) so this effect might or might not appear with other colliders. But it certainly does with Box Colliders (test it in the above world).
1
·
tracked
Load More