World/Udon Bugs & Feature Requests

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.

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.

It would be really useful to expose Input.mouseScrollDelta in UDON as it will allow us to build mousewheel controlled experiences. Like controlling the current speed of a spaceship / flight system via scrolling, as desktop has basically no other "relative" input method.

I am in the early process of designing a game show world using Udon. It would be incredibly awesome if Udon exposed Unity's JsonUtility so that I could load metadata for a session of the game simply by pasting a JSON string into Unity.

In SDK3 2021.03.22.18.27, SendCustomNetworkEvent was updated to work in editor, by bypassing the SendCustomNetworkEventHook. In doing this, it allowed networked events to work overall, but does not block events that begin with an underscore as the VRChat client does. Please add an editor only implementation of SendCustomNetworkEventHook instead of removing the code that calls it. This way extensions like CyanEmu can also handle extra details. Example graph tested without CyanEmu: application/vnd.unity.graphview.elements AM2W227bRhCGX8XYay6x54MAXyRyWght0iKOfVMYwi53qLChSIMHu4btJ8tFH6mv0KWoWLKluGrgoAUFAlwOF7P/fP+M/vr85y26cmUPaPLbLcr7snznlvEBnb+fnoW6mtbLZV3Nqg6a3GXQzobFN1dQde8hg+IKmnQ+P4UqTPu2q5fvoLuum0+rgPn8K3tsB31wzQK6+elN28HytGuKajFfP53XRUAJ6uN9ghxl3HrGMKGSYKGFxF4biwlYHYRk0mcsBl/WbdEVdYUmt+gPNKFGptIQQjUx1giuVYJu0ARTpVOmuaaMSsMIp/w+QVUd4Gx20kYlUNxq+F0kKC/r6/XqxRhzPsjVrvTqq6K7+cX/Dll3Pop4i4qq7VyVwewETUjctl0dav0aofvkWz6LSqaDlOmoZboRM91VMzl6Eh4XoGmjLMc0JcOVHE37susbOK6g7xpXJke/9r4ssp/g5kP9CarjKpJw96osvzHfsYLpWNDkaNlmdVMWfpOIODQRr7WTmVTUcgGxinfzkbTVedH9xZDfFrYjeWPIAzwsC8r4nGDHIkEi8IA9MQor5hSnlGaZ5rvwYCNSHuEhwhhmKJMrdqRMB260MlIKZbR8Ss5jZlAQithMZxhoEFgI5bHROcWEWyVNzgzkAb0EWf+Z5GdDqm+qRVHBCfh+ERvCz/WDi8cz7PX0QdLsetqSNKZmraRU01iAsSz0+bJYsFY5BdjmwWGR5QxbrQW2PNaX8Jx7qu7IdzH8U72mdfzgUcd7UOSQLPeASoneQ+rQ5B5pop5H9X8O4VtoW7eAr1n+7DK4Dh6U5HkgNjCOvQSJBVjAjgDgzGkpTKYMML9PSa1SoplQ3BrLpDabeTFIqai0SmmrHyv5xPKMS+KCVzhQ57HgzGLHg8dccuWod0CV27H8M66aVZd9F131I3RRnpP6uprPt17HtWnc6YvFXtd1Ca7aTM4IFc+owCFTQ/PLcux9LmNyVufWcCEC3afEYDMWRyfhWlqtpB6lMLF6RjHBlI7yRNa+P1RbZ03Xh02OthendQNv69CXsAGN/MtJd/nRkV22XjcxrY+bQXJIZXc7lkyVsVZQQdTam/9E1EFV2+lXh/1LekGfr1l7WaP/4Mp2ZfOL+78B

To reproduce: Create a behaviour with ExecutionOrder -100000 Create a child of it with another behaviour with no execution order overrides Create a behaviour with ExecutionOrder -100000 and NO child objects as a control Create a new separate behaviour with ExecutionOrder +100000 Add a log to Start() to keep track of it Expected result: Behaviours with -100000 to log first Behaviours with no override to log second Behaviours with +100000 to log third What actually happens: Behaviours with -100000 and NO children log first Behaviours with no override log second Behaviours with +100000 log third Behaviours with -100000 WITH children log fourth Repro world: https://vrchat.com/home/world/wrld_f43e6a53-97c2-4a6b-88af-60612f4b3cce This also creates another large issue If you also try to disable those -100000 objects (with Default children) via the +100000 Start() method - the -100000 behaviour will enter a broken state where it will never initialize or receive any events no matter what. You can toggle them on and off after - no methods will ever fire I have created a test world that illustrates the above: https://vrchat.com/home/world/wrld_06ab5f32-ffbe-44dd-9930-b3b28074fcfd Checking the logs when loading in - you'll see a bunch of objects logging OnEnable (the ones that report withChild False ), and a bunch of Default objects which are children of other -100000 objects. Then they will all get disabled by the +100000 behaviour. Clicking the sphere enables those -100000 parents, but they never log either Start() or OnEnable

VRChat is working on a new feature for the Worlds SDK titled "Example Central." The feature is not finished yet and may change before the final release. Examples Central gives World creators access to a variety of SDK examples. You can browse the list of examples or use the search. The initial examples focus on Persistence and the Creator Economy. Example Central makes it easier for VRChat to release new examples without updating the SDK. Examples are easy to import into your project. Each example comes with documentation on ask.vrchat.com to learn more or to discuss the example with other creators.

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.

I want to make a remote control that responds to joystick inputs while it's being held -- but it would be confusing if someone picked up the remote in their left hand but had to operate it with their right joystick. I could make it listen to BOTH joysticks, but then they would have none left to navigate with. So, I want to be able to know (in Udon) which hand the pickup is being held in, so that I can decide to respond to only those inputs; it could be either as an argument to OnPickup, or just as a property that an Udon script can look at. Is there any way to do this?

VRChat SDK version 3.2.0 Newtonsoft Json version 2.0.2 VRCJson.TryDeserializeFromJson("{\"key\":{\"nestedKey\":\"{\"}}", out DataToken token) returns false. Braces are valid inside a string value in JSON, so it should return true.