World/Udon Bugs & Feature Requests

For UDON admin interfaces or whitelisted areas etc. it would be great to have GetUserID or something like that exposed, It's been a real struggle with people with special characters in their display name, UserIDs would make the process so much cleaner, and more reliable

Fairly simple request. Half of what makes Contacts what they are is currently missing. We can only contact from Avatar to World to trigger something in the World. What we need is the ability to send parameters from World to Avatar to trigger effects on the Avatar. An example of this would be a weather system. You stand inside a contact for rain and it will send a inRain parameter to the Avatar which then can implement something in their animator layer to do something with this, such as enabling shader effects to look rained upon or wet. This could be used for many effects, sandy in the desert, muddy in swamp, wet in rain/water, damaged/bloody in games with health and so on. Allowing communication from the World to an Avatar would open up endlessly more ways to interact with the World in a variety of ways.

VRChat is working on an improvement to Udon, VRChat's scripting system. Currently, World creators can write code in two different ways: Udon Graph UdonSharp VRChat is introducing a third way: Soba Creators can write Soba scripts in C#, similar to UdonSharp. Soba scripts are compiled to Microsoft's Common Intermediate Language (CIL). This allows Soba to use a variety of features that are not available in the Udon Graph or UdonSharp.

Players and world creators would appreciate a new character controller for VRChat worlds. It should work mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going upstairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controller. ... And more!

It would make implementing cryptography algorithms much easier.

Now that web connectivity will likely require some form of consent from the user when using Udon, I think it's a reasonable request to ask for an actual unique user ID that we can use to identify users. This could be used to do things like enable a debug console in the world, or when web connectivity is back, save progress or settings in a world. Right now people are using display names as "unique" identifiers which isn't good and already has issues since it's a display name. One issue is https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/onplayerjoined-doesnt-get-full-displayname-for-steam-users Another issue is that "special" characters like "." get replaced in the display name with lookalikes which breaks string comparisons. Relying on display name to "uniquely" identify people will become more prevalent as time goes on and people make commonly used systems that depend on them. You should expose this sooner rather than later to avoid this issue. The potential for abuse is obviously possible, but there's no reason to kneecap the systems and introduce potential issues by leaving only display names visible. Right now I can reasonably target people with just their display names, it's just possible that there will be some more people with the same name that get targeted. Worlds abusing names to harass people is something that should be reported on a world basis.

Currently, the Texture2D and Texture3D classes are fully exposed, but the Texture2DArray class is not. Exposing this class would allow us to create and manipulate Texture2DArray. For example, being able to work with Texture2DArray would enable us to: Change the resolution of textures in a world that uses Texture2DArray, offering quality options. Efficiently store images downloaded via an image downloader, reducing draw calls. Manipulate mipmaps within the Texture2DArray. Exposing this class would greatly improve workflow and performance options for worlds that rely on advanced texture handling.

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

As it stands, the ability for developers to apply occlusion culling to udon scripts themselves is fairly limited. There are many cases where behaviors, such as those ran in Update / LateUpdate / FixedUpdate , are not necessary when the objects attached are not in view . — Example A developer adds a "scrubber" to a video player, with time display via text on both sides. Once per second (done by collecting the time during each LateUpdate and comparing it to a copy of the time stored during the last update), the udon behavior pulls the current time of the video, the length of the video, applies these to the scrubber, then runs a series of floors and multiplication & division to the time and max time before formatting them into a string for a HH:MM:SS time display. The entirety of this behavior is only necessary when the controls are actively within view of the player, and could be safely culled. Another developer has a game world. They are looking for a way to have an NPC move and act when the viewer is not facing the NPC. By providing the option to register the NPC's visibility, when the player looks away (and no camera is in view) the NPC's specified udon behaviors will engage, until such a time that the player or a camera looks at them again. — Request Add support for the OnBecameInvisible & OnBecameVisible events. — Additional Note In reading, for some there is confusion with these events, as Unity's behavior purportedly includes Editor views, including the Scene view, even when inactive, in determining visibility. If true, documentation should note that for successful testing in-editor, the scene view should be pointed away from the object which behavior is being tested. — Related Feedback OnBecameInvisible, OnBecameVisible, broken

Seems that the methods OnBecameInvisible, OnBecameVisible Are broken. I tested using a monoscript and they trigger properly, but they don't trigger using Udon. Regular practices were followed in the testing, e.g. -Object has a meshrenderer -Has a standard shader (nothing funky) Scene camera is not messing with the results (closed the tab) No other cameras looking at it. Only camera being tested is the main camera Set normal callbacks as usual (using UdonSharp) Exact same code, except using Monoscript, works properly OnWillRenderObject DOES work however. -> Using Udon 2020.06.16.20.53_Public.