World/Udon Bugs & Feature Requests

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.

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.

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?

The uGUI events Set{Value}WithoutNotify of Toggle , Slider , ScrollBar and Dropdown were exposed. However, the InputField.SetTextWithoutNotify event isn't possible to invoke since they aren't exposed.

currently only UnityEngine.Random is exposed which is a static class and is globally shared, having System.Random exposed will make it easier since it is instanced and will allow for things like seeded procedural generation easier

It would be nice to have .IsSubclassOf(), .IsInstanceOfType(), .IsSubclassOf(), and .baseType exposed so that we can do type checking at runtime for methods that return generic objects or some base class of a type. At the moment we can only compare types directly, so if we wanted to be completely correct about type checking, we'd need to manually check every potential inherited type which could easily get prohibitively expensive.

I want to make a console panel that display long strings by Udon. That will be useful for player UI and debugging purposes. But adding strings is performance expensive unless I use StringBuilder. Could you expose it for Udon?

Previously exposed TMP methods are not exposed any longer (or maybe never really were). For instance, ForceMeshUpdate was exposed in update 2021.4.1 ( https://docs.vrchat.com/docs/vrchat-202141 ) for both TextMeshPro and TextMeshProUGUI but is unavailable for TextMeshPro . Note the difference that TextMeshProUGUI is for canvases and TextMeshPro for being placed inside the scene. Another issue is being TMP_CharacterInfo[] exposed (via TextMeshProUGUI.characterInfo ) but the type itself, TMP_CharacterInfo , is unexposed. Therefore I request to reiterate over this list and expose what's unexposed: TextMeshPro.textInfo TextMeshPro.meshInfo TextMeshPro.mesh TextMeshPro.enabled TextMeshPro.ForceMeshUpdate TextMeshPro.UpdateGeometry TextMeshProUGUI.textInfo TextMeshProUGUI.meshInfo TextMeshProUGUI.mesh TextMeshProUGUI.enabled TextMeshProUGUI.ForceMeshUpdate TextMeshProUGUI.UpdateGeometry Overall, all methods and fields by these two main types should be evaluated for being exposed, including base members. However without these following types doing anything but basic operations on TMP is pretty much pointless, hence I request these types (not only as array) to be exposed, including their fields and methods: TMP_MeshInfo TMP_TextInfo TMP_CharacterInfo TMP_ColorGradient TMP_Text TMP_Dropdown The first two images in the attachment show how the same method is not exposed for different TMP types. The third image is displaying how a variety of types are exposed as array only. The fourth image showcases how TextMeshPro is also mostly unexposed, the list grows even longer when including base members. In contrast, the fifth image presents TextMeshProUGUI (without base members). It will be amazing if this is being looked into because TMP is a very powerful tool. Thank you for your time!

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.