Udon Bugs & Feature Requests

Replication Have something listening to OnInputMethodChanged use vrchat with a controller pull up the gesture wheel with RB and select something with the joystick OnInputMethodChanged will be called as f you used a keyboard Build: 1442 SDK 3.5.2

Right now OnInputMethodChanged only get called if well input method changed, but I think I would make sense to have it called once to let the world figure out the user input and switch any logic without having to manually do it with GetLastUsedInputMethod()

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.

Animator Parameters provide Tracking Type Parameter to determine player’s body tracking status (3-point, FBT, etc…)( https://creators.vrchat.com/avatars/animator-parameters/#trackingtype-parameter ). It would be very helpful if I could get this via Udon. This enables creators to provide fine-tuned user experience depending on the type of body tracking. Japanese: Animator Parametersにはプレイヤーのボディトラッキング種別(3点、フルトラ等)の判定に使えるTracking Type Parameterが存在します。 これをUdonから取得できたら、大変助かります。 これにより、プレイヤーのトラッキング種別に応じてより細かなユーザー体験を提供できるようになります。

There are many camera settings that would be really nice to have access to after runtime. An interface could be provided for this via some proxy in the VRCGraphics class. (and maybe one for the hand camera as well!) Ideally this proxy would contain everything the normal Camera class has that doesn't pose a security risk. Some examples of very handy use cases for this: Change farclip dynamically to minimize perf overhead from unnecessarily drawing distant avatars/objects Safe access to culling masks for user-created layers to make a lot of common visibility tricks much easier Set depth texture to be generated without needing a shadow-casting dir light Get FOV to use for unique world mechanics Access to a lot of useful camera matrices like cameraToWorldMatrix, worldToCameraMatrix, projectionMatrix, etc... Access to stereo separation for more advanced world features ...and more I'm probably not thinking of!

[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.

Note: This request is an excerpt of this document which contains some additional context and suggestions for a implementation. With the introduction of VRCGraphics.Blit and asynchronous readback feature, we are closer than ever before to having compute-shader-like capabilities in VRChat. However, we are still missing a critical component: Random writes! Random writes are the ability to write to any location in a block of memory, represented as an unordered access view (UAV) - in our case, these UAVs concretely are just RenderTextures. Random writes are hugely useful for making compute-shader-like code performant, and for many of the things that people tend to use real compute shaders for, they are downright required. This is due in part to the fact that they enable the use of atomic operations (example), which open up the doors to a bunch of algorithms that are infeasible or very tricky to implement without. We could get very close to approximating compute shaders today with the addition of one single piece of API: Graphics.SetRandomWriteTarget . With this API, you can do random writes in fragment shaders, which brings them much closer to compute shaders (see the initial link for example code). Here are some examples of possible use cases: Persistent data storage in a shader without jank. No need for GrabPass abuse, Custom Render Textures, or Camera loops. Just bind a RenderTexture and you are good to go. Communication between shaders without jank. Simply bind your render texture, and any fragment shader can now access it with both read and write access. Custom realtime GI systems. I implemented a system that places and integrates light probes dynamically based on camera depth using this piece of API. Better fluid simulations. In general, pretty much any kind of shader-based simulation can benefit from this. Either by being made simpler to implement, faster, or becoming feasible in the first place. Potentially speedup for AudioLink's DFT algorithm? Fast reduce-style operations such as summing or maxing over a domain. GPU based sorting.

It is currently not possible to construct VRCUrl at runtime. This makes it difficult to generate video URLs that require dynamic input to function, such as playing a video based on an arbitrary search query, or generating video URLs that utilize token based access or are limited by other conditions. Data leakage concerns are already mitigated with the Allow Untrusted URLs option.

World persistency would increase usability since old in-world settings could load automatically when the user re-visits the same world later. As worlds get more and more complex, this is no longer a "nice to have" feature - it is now absolutely needed to make a more complex world playable (such as playing a long story through like "The Devouring" for people who don't stay 4+ hours in a single world in VR or in case VRChat crashes while playing it). But it is also needed for grinding mechanics and worlds where you can build something and farm resources - something we are currently working on. Tl;dr, either VRChat gives us a [StoreToDisk] string datatype (without a weird character limit) that saves to disk when it changes and loads again when the user joins the same world or we'll have to implement our own open-source solution reading debug log files and a third-party application running on people's PCs to send Ctrl+V to the window handle (as other world creators have already done it). But either way, we definitely can't go on without a solution here and the current "ask a VR user to copy+paste a string" is not a good way to do it - especially since it's not crash-safe, so users lose all progress when VRChat disconnects the user randomly. But also since we still don't have a "Copy to clipboard"/"Paste from clipboard" function next to a TextInput field for whatever reason, something that would be extremely useful for VR users in general anyway. Ideally, an instance could also specify to only load the progress from whoever created it, since it's not possible right now to know who's the instance creator in Udon, but that's only a minor follow-up issue.

Proposing an Udon wrapper around the Discord API for world creators to create more immersive worlds. https://discord.com/developers/docs/reference Discord already has an extensive API to interact with their services, poll servers for users, grab their groups, post messages to channels, retrieve messages from channels, etc.. The amount of new and exciting things creators could do in their worlds if they had this ability is almost endless. I feel like this is an especially important and needed feature of the game, especially since crafting URL's at runtime is still being artificially disabled. The entire Discord API does not need to be exposed from the get go, not that it would be very difficult to do. Errors are already returned in JSON format which means they can easily be parsed in Udon without any additional development required from VRC devs. Interacting with the API is a simple HTTP/REST library requiring you to formulate your request inside of a JSON object, so again, not much is needed from VRC devs to expose the ability for us to start interacting with the Discord API. Essentially we just need https://discord.com/api whitelisted and an object that cant post and receive a JSON 'payload' to/from the URL. Thank you for your consideration, I know this will be a widely appreciated feature for world creators and players.