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.
Add RenderTexture, Texture, Sprite, Texture2D, Texture2DArray, Texture3D, CustomRenderTexture, Cubemap and CubemapArray nodes
Texture and Sprite variables could be useful. Currently you can use Materials to do stuff with textures / hold references, but this could make it simpler. I do not expect GetPixels or GetNativeTexturePtr. The most useful thing is the ability to hold variables of texture types. However, read or read/write (for *RenderTexture) access to properties such as width, height, depth etc. could be useful.
Add playerapi property for "has menu open"
This would be very useful for disabling ingame functions while the player's menu is open so that it doesn't interfere with using the menu.
Add major C# collection types
List is already requested in https://vrchat.canny.io/vrchat-udon-closed-alpha-feedback/p/request-add-list-type-handling But there are other collections that would be useful like Dictionary, HashSet, Queue, and Stack as well. At least Dictionary and HashSet would be nice because they provide functionality that are not easy/performant to emulate with lists.
Expose VR Input Actions for Udon
Allowing creators access to the the action inputs would allow for users to make more consistent custom controls or actions for their worlds. In example, if you were to add double-jump, you would set it to the space-bar, but getting the appropriate "jump" key for different VR setups at this time is a complicated and tedious process as it is.
strafe speed needs to be added.
In a recent update we can now set player run speed, walk speed, jump impulse, and gravity strength. there is no strafe node.
[Request] JSON Node
I think a node that let's a user get/set a json file for the world would be super handy. it would make things so much better for saving things like a global map currency for example.
Allow setting interaction text for objects using the Interact event
Allow setting interaction text in the Interact event node and with a pair of get/set nodes. Right now only VRC Pickup has interaction text methods.