World/Udon Bugs & Feature Requests

In the Udon Graph and Udon Sharp there is currently no documentation. It would be convenient to have direct access to each function's documentation from Unity. Here's an example from UdonSharp, with documentation from https://docs.vrchat.com/docs/player-audio inserted: Current: public void SetVoiceDistanceNear(float near) => VRCPlayerApi._SetVoiceDistanceNear(this, near); Proposed: /// <summary> /// The near radius, in meters, where volume begins to fall off. It is strongly recommended to leave the Near value at zero for realism and effective spatialization for user voices. /// </summary> /// <param name="far">in Meters, Range 0 - 1,000,000</param> public void SetVoiceDistanceFar(float far) => VRCPlayerApi._SetVoiceDistanceFar(this, far); According to the contributors of UdonSharp they cannot add documentation to the libraries themselves (for technical reasons). For completeness sake I've attached an example of what it might look like in the Udon Graph. Though perhaps that should be a separate post.

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?

Seems that the methods OnBecameInvisible, OnBecameVisible Are broken. I tested using a monoscript and they trigger properly, but they don't trigger using Udon. Regular practices were followed in the testing, e.g. -Object has a meshrenderer -Has a standard shader (nothing funky) Scene camera is not messing with the results (closed the tab) No other cameras looking at it. Only camera being tested is the main camera Set normal callbacks as usual (using UdonSharp) Exact same code, except using Monoscript, works properly OnWillRenderObject DOES work however. -> Using Udon 2020.06.16.20.53_Public.

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

VRCSDK3-WORLD-2021.06.03.14.57_Public

It should be possible to set a variable on an animator controller that is assigned to a station. This way, a character could for example procedurally change the pose on a vehicle using blend trees or we could switch between different poses on demand while the player is in the station. This would also be very useful to circumvent a lot of restrictions that make the use of stations very limited right now, like rotating an avatar on a station without rotating the viewpoint to deliver a motionsickness-free experience. Those are the functions that should be available on a VRCStation: VRCStation.SetAnimatorFloat("floatVariableName",floatValue); VRCStation.SetBool("boolVariableName",boolValue); VRCStation.SetTrigger("triggerName");

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.

Running 3+ clients and reloading them through a period of time yields me with a "Failed to authenticate with realtime servers: Too many requests" error leading me to be blocked from testing for a long period of time (sometimes hours). This is really hindering on my ability to test networking conditions when there are multiple players at play. Like testing an unstable network connection or slow network initialization for late joiners due to differing conditions. Especially with Super VR Ball, it's almost impossible for me to network test for longer than 20 minutes before being kicked for this reason. Proposed Solution: Allow me to turn off specific requests during Build & Tests, like getting group info and social information, so I produce less requests overall. Or a light version of the client with a default avatar and minimal menus similar to ClientSim in functionality. Other Solutions: Allow more requests to be ran during Build & Test. (Simplest but not fun for security!) Allow a local realtime server that I can host with the main client. (Understandably difficult for many reasons.) Allow me to slowdown/step through networking events so I can test how the network handles network clogging or unstable connections. Related Canny Whitelist my account for a higher request limit/unlimited requests. (This would be easiest but there's got to be a better solution :P)

Please allow us to directly manipulate transform of the local player and of his playspace transform in Udon. Abusing teleport for this is not only misleading, but also not very efficient. The coolest stuff that people do with Udon uses teleport in every update and there are lots of performance issues doing that. We want to create flying-scripts, locomotion-scripts and better "chairs" for vehicles, doing this with teleport is inefficient. Also reading and manipulating the playspace transform is important for us as well, e.g. to know where the player is relative to his playspace.

This would potentially be able to reproduce the Combat System in Udon and make it obsolete. Also would be pretty cool in general :^)