World/Udon Bugs & Feature Requests

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.

This could be a way to speed up string validation in Udon, especially with complex string rules, since Udon is slow.

If we want to have a string in a byte[] form and work in it in the byte[] form for any number of reasons. The current ways we have to encode/decode it are extremely complicated. We especially need Encoding.UTF8.GetString As UTF-8 is size optimized and supports all characters. Also, the main issue is that the current ways have large performance impact. When decoding any Larger texts.