Adjusting the transmission frequency of Udon Synced Variables
The object owner always appears to be sending a value of Udon Synced. This makes it unstable when there are many objects. I want the option to adjust the sync frequency or send only when it changes.
Add OnAvatarChanged() event
Most functions that rely on avatar bones and player height need to update their calibration values when the user loads a different avatar, after the new avatar has fully loaded. This can currently only be done with expensive update loops and a lot of bone checks / measurements and therefor CPU spikes while consumes unnecessary ressources. An event/function for that would greatly improve performance and user experience at the same time and the world can be instantly adjusted to the new avatar (height of buttons, dealing with limited amount of finger bones etc.) A function like OnAvatarChanged() or OnAvatarLoaded() should be called when an avatar of LocalPlayer finished loading, also on map start and each time the avatar changed.
Colliders that are not on the MirrorReflection Layer will stop the "Hand Raycasts"
This is a big problem when putting colliders on your hands to do interactive triggers. Without putting the colliders on the MirrorReflection layer they will prevent you from interact (clicking) on objects, pickup objects and everything else that requires the "Hand Raycasts". The "MirrorReflection trick" is not well known, unintuitve and restricts you from customising the collision matrix in this regard. No idea what the best solution would be, but this needs to be adressed at some point imo.
Improve runtime performance for arrays
Currently, Udon makes "security checks" on runtime, but instead of checking an array once, it checks each element of an array whenever you access _one_ element in that array, causing exponential execution times for even the smallest arrays. This causes huge permance issues whenever you use arrays, forcing you to write super ugly code that works without them whenever possible. But: This UdonVM behaviour makes no sense from a security perspective. When I _create_ and _fill_ an array in Udon on runtime of a known/whitelisted type (e.g. a Vector3), there is no need to check whether or not this array is still secure when I read from it again. UdonVM needs to check an UdonBehaviour _once_ for secure/whitelisted content, not every time it is run. The whole overhead of runtime security checks shouldn't exist in a VM that only supports a set of whitelisted components. Right now, making more complex things in Udon that rely on running in Update() is especially frustrating because it always runs fine in the editor (as it should) while it runs on 1 fps in vrchat. And this is only because you need to loop once through a few local arrays of whitelisted components with 30 elements each. The only workaround right now is to use hundreds of class variables instead of arrays to get your frametime back. The code is unreadable at this point and coding for VRChat becomes a pain.
Expose Player Transform in Udon
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.
If we're smart enough to write scripts for worlds, we're smart enough to drag a slider from 1 to 0.
Allow parenting objects to player bones, player position and player tracking data
Since bone transforms aren't exposed, we can't parent objects to players and need to use expensive and complicated update loops for such a basic task, which also results in ugly/janky object movements and low performance. Please give us a simple function like .SetParent(Transform t, Boolean b) for .GetTrackingData(VRCPlayerApi.TrackingDataType.x) and .GetBonePosition(HumanBodyBones.x) and for VRCPlayerApi.GetPosition
Add a 'Force Nameplates Off' feature to the Player API
An official/supported way to do this would be much better than the workarounds already implemented on some maps.
Add Plane.GetDistanceToPoint() function
Plane objects are currently not supported in Udon, and so is the function Plane.GetDistanceToPoint() not supported as well. Please add those, would make creating "physics" UI elements way easier. Easily getting the Plane Normal would be great as well.
VRChat Udon Web API
Add a UnityWebRequest (HTTP GET) equivalent function set tl;dr: Persistence and web connectivity IS going to happen whether these Udon functions are added or not, but it would be better to have a controlled, standardized, and built-in solution than the SDK2 style hacks that creators will standardize themselves. For a long time world creators have done without web panels and have had to use VRC_Panoramas and shaders to squeeze out the smallest possible web functionality available (see Maki's clock prefab) in VRChat worlds. With Udon's full programming power, world creators are finally able to make web based features for worlds - the main one being persistent values/settings across the whole platform. Web connections can currently (almost) be done with SDK2-style workarounds instead of built-in Udon HTTP functions - which by all means SHOULD exist. Creators have already altered the VRC_Panorama server system to return data directly through images, which can then be processed through Texture2D functions in Udon. Creators have even set up video player based streaming servers that return similar data, in case a VRC_Panorama equivalent never resurfaces. I've even personally planned for an external program that reads the game's output log, makes web requests through signals in the log, and returns data through OSC to make Udon web connectivity possible (though this is a sketchy and insecure solution, it would work better than other methods). The point here is that web connectivity IS going to happen whether these Udon functions are added or not, but it would be better to have a standardized built-in solution than the SDK2 style hacks that creators will standardize themselves. There are 3 main arguments I've heard from VRChat staff against web functionality in Udon: sandbox security, user identity/IP protection, and the desire for an in-house persistence solution without the need for web connectivity. The security of the Udon sandbox is not something that should keep this functionality from existing. Simple HTTP requests do not allow for XSS style attacks, and there's no way simple data from an external server could harm the Udon VM, if the VM itself is secure. Even if there were vulnerabilities in the Udon VM, they would be attack vectors that that don't even require web connectivity. Plus, its already been established that people are going to make their own web request solutions. If anything it would be LESS secure to not make HTTP requests available through Udon so security flaws could be easily patched in the future without breaking content. Player IP protection is something that cannot be done. As Tupper has mentioned in a previous canny post, "IPs are not expected to be private information. ... If you want to keep your IP truly safe, we encourage the use of a VPN." (https://vrchat.canny.io/bug-reports/p/eu-gdpr-compliant-serious-post-ip-grabbing) Completely protecting players' IP addresses would mean completely locking the game out from the outside world and removing features like video players and VRC_Panorama entirely. Even now, you can go into a public world with a video player, drop in a link to your web server, and get the IP address of all users in the room. Unless web based media is completely removed from the game, IP addresses are not going to be protected. An in-house data storage/persistence solution for VRChat worlds is no real argument for limiting web connectivity at all. Not everything people want to do with HTTP requests involves world persistence. One use case might involve streaming in realtime data from a website to visualize in a VRChat world - something that's already done with VRC_Panorama except in image form. A simplified persistence service provided VRChat could exist in the future for less technically inclined world creators, but it is by no means equivalent to full web connectivity. Again, web requests are going to happen whether the VRChat team approves of its methods or not. With the fine-grained level of control Udon provides, web requests will happen through inane workarounds that then go on to become established standards. Please take control of this situation while you can and add an Udon Web API.