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

This has been broken for a long while, since I can remember, Auto Hold does not work for Oculus, or Index, but does work for Desktop, and (last I checked) Vive.

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?

new GameObject() missing in udon. USharp error: System.Exception: Method is not exposed to Udon: Void .ctor(String), Udon signature: UnityEngineGameObject.__ctor__SystemString__UnityEngineGameObject

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.

TeleportTo instantly moves a player to a position. Normally it makes sense that this would send an RPC in order to update the player's position as fast as possible for other players. The "lerpOnRemote" option for this function should omit the RPC and rely on VRChat's regular player-position sync. However, this isn't the case and seems to send unnecessary RPC's. This function COULD be useful for things such as moving platforms, but due to this oversight repeated calls will result in "unexpected client behaviour" and a disconnect.

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.