World/Udon Bugs & Feature Requests

As of SDK v3.7.4 & SDK v3.7.5, Client sim only adds one Client Sim Udon Helper per GameObject. This means that only the first script on said object can function as it does in the VRChat client. The most recent SDK version that works as it should is v3.7.3

On Later-Joiner's client, OnVariableChanged can be fired without OnDeserialization() before OnEnable() and Start() . It will be happened especially if the object owner uses RequestSerialization() frequently (such as per second interval synchronization). It can be critical problem because it makes OnEnable() and Start() are not guaranteed before synced variable changes: firing OnVariableChanged before Start() can breaks Udons that implementing initialization at Start() . This bug seems the reoccurrence of following this Canny: https://feedback.vrchat.com/udon/p/1259-synced-variables-can-be-changed-from-owners-requestserialization-before-lat Build: 1539 ---- I've made the new testing world to check event orders: https://vrchat.com/home/world/wrld_c357c8f1-1d22-4e91-bfdc-e72c04097fe1/info . (Sample screenshot is attached below) Reproduction steps: Make the instance of the world (Player A), join the instance then enable interval sync from "Toggle Sync Interval" buton. (It starts 0.25s interval of synced int increment using manual sync) Join another player to its instance (Player B). See the console UI in the world at Player B. Expected Results: At Player B console UI, "SyncInt change" console message should only be occured before "OnEnable". Actual Results: At Player B console UI, there is small chance to occur "SyncInt change" console message before "OnEnable". - It may sometimes not be occurred, so try re-joining several times.

This used to be not an issue before, but now if you have a Non-trigger Collider (set to a Unity or Custom layer, excluding the Walkthrough layer since it already does what it is supposed to do but that's beside the point) that is set to exclude the Player/PlayerLocal layer, the player will still "collide" with it and be able to "walk" on top of the collider's surface while slowly descending as if they were using a flying avatar. They'll still be able to go through the collider, but the problem here is that they can stand on top of the collider when they shouldn't be.

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?

OnPurchasesLoaded does not get called in build & test

I noticed VRCObjectSync.Respawn() can cause NullReferenceException and halts the udon, if its GameObject is inactive and never activated once. It seems caused by not having it's respawn information, which seems declared at its Start() . ( VRCObjectSync.Respawn() will send the object to the first position the object activated. Moving inactivated object will affect its respawn position.) There is no way to avoid its exception safely. We need to check to use if the object is active, but it means inactive object should not use Respawn() .

[Steps to reproduce] Lay out many (about 50 or more) MonoBehaviour and VRC_Pickup objects in the scene. Enter the world with 3 or more people. All player pick up and move some objects. Join a new player. The coordinates of some objects are not synced correctly to the new player. [Cause] Maybe, ownership information is not correctly transmitted to new player. In the new player, owner of some objects will appear to be the master. But the owner is actually a different player. So the coordinates by the true owner send to be ignored, the new player will see the object appear to be stationary from its initial position. Also, if an object is picked up by the true owner of that one, SetOwner is not called. So new players will continue to recognize that the master is the owner. [Interim measures] Always the master keep to hold all ownership of objects.

VRCObjectPool TryToSpawn command crashes client if pool is empty Steps to recreate: Player A spawns all available objects from pool. 2 Player B tries to take ownership and spawn from empty pool. No crashes observed if player B was an owner of the pool before it was empty. SDK: VRCSDK3-WORLD-2021.11.24.16.19_Public Unity: 2019.4.31f1 Test world: https://vrchat.com/home/world/wrld_d051d186-92bf-485d-9c6b-560092d82c37 Attached unity screenshot with udon and inspectors.

VRCSDK3-WORLD-2021.06.03.14.57_Public

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.