World/Udon Bugs & Feature Requests

Update is executed for one frame after the script is disabled. Reproduction Procedure: Prepare a U# script that outputs OnEnable(), OnDisable() and each Update() log (see image). Attach this script to the game object and play it in ClientSim. When this script (component) is enabled, it will be disabled after 3 frames and output the log of each event. The log in chronological order shows that each Update() is executed after OnDisable(). (see this video : https://twitter.com/mimyquality/status/1749001703893164421 ) This also happens when switching "enabled" from other U# scripts, etc. or when switching the active game object. It seems to have started occurring since Unity Editor was changed to Unity 2022.3.6f1. Translated with www.DeepL.com/Translator (free version)

Maybe this has been the case since VRChat supported SteamVR Input 2.0. Regarding the OnInputMethodChanged(VRCInputMethod inputMethod) argument, on smartphones and desktop PCs, it has the expected values such as VRCInputMethod.Touch and VRCInputMethod.Keyboard. Touch and VRCInputMethod.Keyboard. On the other hand, many VR controllers seem to have unified to VRCInputMethod.SteamVR2. This means that there is no longer a way to distinguish mainstream Vive Wand/Quest/Pico/INDEX controllers, etc. from Udon. This means that automatic tuning according to the characteristics of each controller is impossible. Are there any plans to fix this?

VRChat Version: VRChat Build 1664, SDK 3.8.2 It occurred at least in the current version. I don't remember when it started occurring. Description of the bug: If the local player loses ownership of an object to which VRCObjectSync and VRCPickup are attached, the position of it may temporarily revert to the position it was in when the local player acquired ownership. This occurs when ownership is transferred when VRCObjectSync is active and not when it is sleeping. It also does not occur without VRCPickup. The position moves from OnOwnershipTransferred to the next OnDeserialization. Steps to reproduce (how did you encounter the bug?): Move an object to which VRCObjectSync and VRCPickup are attached. Pass its ownership to a remote player while VRCObjectSync is active. Any extra files? (output logs, screenshots): I have confirmed this with the Udon below. The log of the run is also attached. https://gist.github.com/llaser/321a9fc3f63c66f3623615b2383a873e

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

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.

ORIGINAL BUG Steps To Observe Behaviour: Create two objects with VRC_ObjectSync components. Add a VRC_Pickup script to one of the objects. Use the new networking debug menu that shows ownership, priority and data transfer per second to check the priority state of the two scripts. Steps to Reproduce Bug: Create an object with an ObjectSync script. Expected Outcome: You should be able to just mark an object sync object as Important without having to attach a dummy pickup script (and the associated dummy rigidbody) Actual Outcome: You're forced to add a pickup script to mark a sync object as high priority. === After Vowgan and I did more testing, we're getting less consistent results. I don't understand the logic for how something is Important - it seems like attaching a pickup script might help? Maybe if the syncer is enabled whilst it's in the player's view? It'd be good to get some information on how Important/Normal priorities work and if the above (attaching a pickup script) actually makes a synced object higher priority as this is quite confusing at the moment. === Some more testing - it seems like ObjectSync is very inconsistent. Attaching a pickup has had the effect of actually totally desyncing the pos/rot of the ObjectSync'ed object in testing after doing a FlagDiscontinuity on the ObjectSync. We're also seeing five-second lag on ObjectSync'ed objects in certain circumstances, generally again after firing FlagDiscontinuity on the ObjectSync. (Apologies for this odd bug report - this is what happens when weird behaviour is observed after observing something in engine...) === We're using my pool test world to explore this behaviour: https://vrchat.com/home/launch?worldId=wrld_7c23c9c3-fa6f-40ed-8f75-776fed2eef4e - I'll add some instructions for how to use the synced pickup system for QA to take a look at if they're interested.

When adding [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] to an udon# class, It will just continue using the last setting. For example if you add [UdonBehaviourSyncMode(BehaviourSyncMode.Continuous)] and then compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again, you get the expected behavior, and calling SendCustomNetworkEvent() works. If you then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.None)] and compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again It will continue to behave exactly as if it's still set to None. SendCustomNetworkEvent() does not work. This is on an object that doesn't have any other scripts on it. I haven't tested the case with other scripts. You can look at the debug inspector to confirm that this is what is happening. From the documentation: "NoVariableSync: Enforces that there are no synced variables on the behaviour, hides the sync mode selection dropdown, and allows you to use the behaviours on GameObjects that use either Manual or Continuous sync." It seems like the case where a script using NoVariableSync being used on an object that doesn't have another script on it may have been overlooked. Since I'm updating a script in a prefab I'm releasing from None to NoVariableSync because I want to use network events now, it's not going to work for anyone updating to the new version. I am forced to set it to Continuous. Does anyone know if it makes any difference to bandwidth usage?

I noticed this bug when I tried to set a value that could not be represented as a float. Shader.SetGlobalInt() is cast to float internally, so Shader.SetGlobalInteger() needs to be used.

I noticed that VRCObjectSync has started to not sync rotation perfectly. I don't know when this started, but it definitely didn't used to happen. The owner of the object will get the exact correct rotation, of course, but others will get rotation that is slightly off. In my testing, when the owner had (0,0,0) rotation, others had (359.89, 359.89, 359.89) rotation. That's enough to cause slight alignment issues in my situation, which is how I noticed it. How to reproduce: Create a world with an object that has VRCObjectSync. It doesn't need to have a pickup component. I've attached a screenshot of my "obj". Make a button somewhere that has a script like this: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; using VRC.SDK3.Components; public class resetpos : UdonSharpBehaviour { public VRCObjectSync obj; public override void Interact() { Networking.SetOwner(Networking.LocalPlayer, obj.gameObject); obj.Respawn(); } void Update() { Debug.Log($"pos: {obj.transform.position} --- rot: {obj.transform.eulerAngles}"); } } And assign the VRCObjectSync object to "obj". I've attached a screenshot of my "resetpos" button. Build and launch two VRChat clients. Have each client click the button a few times and see that when ownership is transferred between players, sometimes the non-owner will get a slightly off rotation value. It doesn't always happen immediately after clicking, and sometimes it takes a few clicks in a row for it to happen. Notice that when the object is misaligned, and you click the button to take ownership, the object does visibly rotate slightly as it goes back to the correct rotation. I've attached a screenshot of my console log showing the pos and rot values logged from the script shown above. In my test, the magenta object is the "obj" and the white post is the button.

This can be an issue when using stations for vehicles with trigger zones. For example, i have a setup where i want audio to enable and disable based on the player location. This works fine with players, but to make it work with those vehicles i would need a second check for the vehicle.