World/Udon Bugs & Feature Requests

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?

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.

My vehicles relied on OnOwnershipTransferred() running before OnPlayerLeft() to turn the engines off when a player left the game while piloting. The way it worked was: If the master takes ownership while Occupied=true (set false in OnPlayerLeft()) they would know to turn the engine off This used to be reliable, but now it seems to be random (Only working sometimes), I can find a workaround, but I think this should be consistant, one way or the other. Suggested fix: Ownership of all a player's objects should be transferred either before or after the OnPlayerLeft() event is run. I prefer before, because it lets me know what they were doing when they left. Additionally, me using OnPlayerLeft() in the first place was a workaround for OnStationExited() not firing when a player leaves while in a station. canny here: https://feedback.vrchat.com/bug-reports/p/772-vrcstations-onremoteplayerexitstation-does-not-fire-if-the-seated-player-lea WORLD FOR TESTING: wrld_c98d4f48-afb4-4f80-ac86-3f746bc0dcae

Checking the equality/inequality of a system-defined enum with equality/inequality operators ( == / != ) will fail. As a result, this example codes in the document don't work as expected: https://creators.vrchat.com/platforms/android/android-best-practices/#2-detect-mobile-players-in-your-world-automatically public override void OnInputMethodChanged(VRCInputMethod inputMethod) { if (inputMethod == VRCInputMethod.Touch) { // Run code for touch input } else { // Run code for non-touch input } } (The UdonGraph version (attached image) also has an identical issue.) Workaround Cast to underlying values and compare them. if ((int)inputMethod == (int)VRCInputMethod.Touch) Analysis UdonSharp compiles the expression inputMethod == VRCInputMethod.Touch into EXTERN, "SystemObject.__Equals__SystemObject__SystemBoolean" Although Object.Equals(Object) is overridden by Enum.Equals(Object) , which the inputMethod may have, with comparing underlying value, this EXTERN seems to call the Object.Equals directly (maybe via reflection API), and it returns the unexpected result (by only comparing the referencing instances). The EXTERN, "SystemObject.__Equals__ comes from here https://github.com/vrchat-community/UdonSharp/blob/22307065bd408dfd163fe46b0b8b701a4efcbc00/Packages/com.vrchat.UdonSharp/Editor/Compiler/Binder/BoundNodes/BoundInvocationExpression.cs#L420 And replacing the System_Object of this line with System_Enum doesn't work because the Enum.Equals is not exposed. Suggestions Temporary, rewrite the example codes using cast operator Expose System.Enum.Equals And replace the EXTERN with System.Enum.Equals

There are some VRC Components and TMP Components that don't have specified generic T types in an internal dictionary preventing the usage of GetComponent<TMP_InputField>() . For those reading this and needing an alternative in UdonSharp you can use the other two: GetComponent("TMP_InputField") or GetComponent(nameof(TMP_InputField)) and GetComponent(typeof(TMP_InputField)) . UdonGraph variants of this issue are shown in the provided images.

When in worlds with a large amount of synced udon behaviours, some of the synced behaviours occasionally don't have their late join OnDeserialization fire when the player is joining the world.

Log the bool "value" argument for InputUse. Click your mouse and release. Expected: receive "True" once, receive "False" once Actual:

The VRChat documentation ( https://creators.vrchat.com/worlds/layers/#stickers ) suggests those layers to make a surface non-stickerable : TransparentFX IgnoreRaycast Interactive Player PlayerLocal StereoLeft StereoRight But I noticed today that it is also not possible to drop portals on those layers, the raycast goes through the floor, which could be problematic if we do not want the floor to be stickerable. I don't think it's a huge issue that's we can't drop portals on some of those layers, I actually think it's nice, but I feel like it should be possible to drop portals on at least some of them.

Name of the VRCSDK package you have imported. VRCSDK3-2020.03.21.12.04 Name of the Udon SDK package you have imported. UDONSDK-2020.03.21.12.24 Version/build of VRChat you’re using to test, if necessary. Latest open beta. (906) A general description of the bug you’re encountering. Attempting to send a long string, like "Trip,Bond,Diamond,Cap,Copper,Canada,Ray,Circle,Centaur,Deck,Dwarf,Wind,Arm,Seal,Pipe,Pyramid,Nail,Amazon,Queen,Theater,Screen,Jupiter,Dress,Game,Whale," over the network via synced vars will return the following error: 2020.03.21 21:33:39 Error - [FlatBufferNetworkSerializer] Caught ArgumentOutOfRangeException: Non-negative number required. Parameter name: count at System.Text.UTF8Encoding.GetString (System.Byte[] bytes, System.Int32 index, System.Int32 count) [0x00000] in <00000000000000000000000000000000>:0 at DŽDžDžDŽDžDžDŽDžDŽDŽDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDžDžDŽDŽDžDžDžDŽDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDžDžDž.DŽDžDŽDžDŽDŽDŽDžDžDžDžDžDžDžDžDžDŽDžDžDžDžDŽDŽDŽDžDŽDžDŽDŽDžDžDžDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDžDŽDŽ (System.Int32 DžDžDžDŽDŽDžDžDŽDžDžDžDŽDŽDžDŽDžDŽDŽDŽDžDžDŽDŽDŽDžDžDžDžDžDžDŽDŽDŽDžDŽDŽDžDŽDžDŽDžDžDŽDžDŽDžDŽ, System.Int32 DŽDŽDžDŽDŽDžDžDŽDžDŽDžDŽDžDŽDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDžDŽDŽDžDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.UdonSync.DŽDŽDžDŽDŽDžDžDžDŽDžDŽDŽDžDžDžDžDžDŽDžDžDŽDŽDŽDŽDžDžDŽDŽDŽDžDžDŽDžDŽDžDžDžDŽDŽDžDžDžDŽDžDŽDŽDž (DžDŽDŽDŽDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDŽDžDžDžDžDžDžDžDžDžDŽDŽDžDžDžDžDžDžDŽDŽDŽDžDžDžDŽDžDžDŽDžDžDžDŽ DŽDŽDžDžDŽDžDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDŽDžDžDžDžDžDžDŽDŽDžDŽDŽDŽDžDŽDŽDŽDžDžDŽDžDžDŽDžDŽDŽ, System.Int32 DŽDžDžDŽDžDŽDŽDŽDžDžDžDžDŽDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDžDžDŽDžDŽDŽDŽDŽDžDž, System.Type DžDŽDŽDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDžDŽDŽDŽDŽDžDžDžDŽDžDžDžDžDŽDžDžDžDŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.UdonSync.DžDŽDŽDžDŽDŽDžDŽDžDžDŽDžDŽDŽDŽDŽDžDŽDžDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDŽDžDŽDžDŽDŽDžDŽDŽDŽDžDžDŽDŽ (DžDžDŽDžDžDžDžDŽDŽDŽDŽDŽDŽDžDžDŽDŽDžDŽDŽDŽDŽDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDžDžDŽDžDŽDžDŽDžDžDŽDžDžDŽ DŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDŽDŽDŽDŽDŽDŽ, System.Int32 DžDŽDŽDŽDŽDŽDŽDžDŽDžDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDŽDžDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDŽDŽDŽDž, System.Single DžDžDŽDžDŽDžDŽDžDŽDŽDžDŽDŽDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDŽDž) [0x00000] in <00000000000000000000000000000000>:0 at VRC.Networking.FlatBufferNetworkSerializer.DŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDŽDŽDžDŽDžDŽDž (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at NetworkManager.DŽDžDŽDŽDžDžDžDžDŽDžDŽDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDŽDŽDžDŽDžDŽDž (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at UnityEngine.AudioClip+PCMReaderCallback.Invoke (System.Single[] data) [0x00000] in <00000000000000000000000000000000>:0 at DŽDŽDžDžDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDŽDŽDŽDžDžDžDŽDŽDŽDŽDŽDŽDŽDžDŽDžDžDžDžDžDžDŽDžDžDžDžDŽDž.OnEvent (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at DŽDžDžDŽDŽDŽDŽDžDŽDŽDžDŽDžDŽDžDŽDŽDžDŽDžDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDŽDŽDžDŽDžDŽ.OnEvent (ExitGames.Client.Photon.EventData DŽDŽDŽDžDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDŽDžDžDŽDžDŽDžDžDžDžDžDžDžDŽDžDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.PeerBase.DeserializeMessageAndCallback (ExitGames.Client.Photon.StreamBuffer stream) [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.EnetPeer.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at ExitGames.Client.Photon.PhotonPeer.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at DŽDŽDŽDžDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDŽDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDžDžDžDŽDžDŽDŽDžDŽDŽ.DispatchIncomingCommands () [0x00000] in <00000000000000000000000000000000>:0 at Photon.Pun.PhotonHandler.FixedUpdate () [0x00000] in <00000000000000000000000000000000>:0 Sending a shorter string, like "Trip,Bond,Diamond,Cap,Copper," works without issue on the same world. Step by step guide how to replicate the bug. Will get this if needed. --- This could just be a limitation of syncing strings - if there's a hardware limit, can we have an error letting us know that the string is too long to be sent?