World/Udon Bugs & Feature Requests

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.

Physbones is really cool. In particular it has a performant set of tools that allow for avatar-avatar interaction. Please port the Physbones code so we can use it in Worlds too! It would make making many Worlds things far easier, like buttons and levers.

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.

It was announced on yesterday's developer update that Udon 2 had been scrapped for "Soba". Based on the information we have been given, they're making the equivalent to Udon 1.1. In the words of the VRChat team, specifically Fax: Soba will have comparable or worse performance than current UdonSharp at launch with "promised" improvements in the future. But as we know, VRChat is unreliable with promises, so I'm hesitant to believe that. Soba will lack generics support at launch (no List<T> or Dictionary<T>, among others) Soba will not have everything promised in Udon 2 This is extremely dissapointing for me, and many other VRChat creators. Udon 2 was supposed to be the superfast feature-rich improvement over current Udon To see that they have opted to make a custom VM which, based on the facts we have right now, will not achieve Udon 2's speeds or feature parity is a disappointment to the community and a testament to how easier > better in VRChat's eyes. The reasons for this change are also abysmal. They said that Udon 2 "would have distracted us from adding feature requests that the community had been asking for". This shows how deaf VRChat is around community feedback, since Udon 2 was one of the most exciting features for me and many other creators, plus, this wasn't an issue when you were waving your dick about making stickers, boops and other features nobody asked for. Alongside this, based on VRChat's technical reasoning, it appears that WebAssembly was scrapped because the new engineer(s) working on Soba didn't bother to debug Udon 2, it appears some benchmarks were done, issues were found, and they didn't bother to try and debug it, or just made up some excuse, instead opting for yet another sloppy custom VM. I apologise for my irritated language, but it is growing rather agitating that VRChat cannot competently deliver on a highly anticipated feature without taking years and having a 50/50 chance of scrapping it. Udon 2 was the better choice objectively, so I implore you to rethink this decision and bring back WebAssembly based Udon 2.

https://docs.unity3d.com/2022.3/Documentation/ScriptReference/Keyframe.html Udon is extremely slow and many creators heavily rely on AnimationCurves to optimize their programs, allowing them to evaluate complex curves with very minimal performance impact instead of writing the mathematical equations manually, resulting in orders of magnitude more instructions in the UdonAssembly. AnimationCurve class has already been fully exposed to Udon (thank you!) and they can be constructed from a Keyframe array, but none of the Keyframe properties or the Keyframe[] Get/Set methods are exposed to Udon, something that is needed to actually manipulate the keyframes of an AnimationCurve . Allowing the modification of individual keyframes unlocks many use cases, such as adjusting a car engine's torque curve as a result of aftermarket modifications or adjusting input lookup tables to allow users to fine tune thumbstick input sensitivity to match their preferences, not only that, developing a complete director mode for worlds would become trivial, something that would allow users to create complex timelines for recording videos. There are some possible workarounds using AnimationCurve.AddKey(Single, Single) , but it is very inconvenient and severely limits more specific solutions where singular keyframes must be modified based on their original properties and we don't have a way of accessing the original time value of a keyframe before replacing it. I have attached images of several examples where AnimationCurves are being used and I would like to be able to modify the individual keyframes of.

Being able to receive direct callbacks about UdonBehaviour exceptions with the relevant information included telling us which behaviour has crashed and what the exception message was would help us inform the players in the world immediately that something has catastrophically failed and they should rejoin the world or create a new instance. Not only that, we could also format useful error messages for users to copy from an InputField to include in their bug report without having to look through thousands of lines of logs. When an exception occurs during Udon execution (the UdonBehaviour "crashes"), the component will get disabled and nothing in the Udon program will execute afterwards. As of now there is no way to access information within the world via Udon about what has happened apart from repeatedly checking the enabled state, which only tells us that something has gone wrong, but even then some programs utilize the enabled state by design for optimization and thus it becomes an extremely unreliable method of checking for halted UdonBehaviours. Large worlds in VRChat can easily have over a thousand UdonBehaviours and repeatedly checking their enabled state to make sure everything is running as intended is not optimal and in most cases the only problem is the rare edge cases where a client/SDK update results in a regression or a player uses an avatar with an unsupported/unstable configuration which affects the world's stability. ...Yes, you could just keep adding more null checks like you're normally supposed to, but Udon suffers from severe performance limitations and in large frameworks every microsecond counts and iterating through behaviours is not a suitable solution. Many players either never turn on their client logging for performance reasons or they don't even know about the existence of such, so not only would this help alleviate the process of handling user bug reports as they've already been clearly informed by the world about what has happened, it would also improve the general user experience as the features in the world don't just suddenly go unresponsive without any form of feedback. One of the most frustrating experiences as a world creator is seeing someone encounter an UdonVMException in the middle of an 80 player event, resulting in a central world feature becoming unusable, and nobody involved had their logging enabled due to performance reasons or they didn't know how to enable it. As a final note to clarify, I'm not asking for the implementation of C# exceptions into Udon, just an Udon callback informing about the VM encountering one. I'm completely okay with UdonBehaviours becoming permanently halted, but as VRChat is becoming more complex by the day with all of the new features, more opportunities for edge cases open up and being able to catch them in realtime without the end user having to even understand how to access logs on the platform would significantly improve not only the players' experience in worlds, but also the world creator's experience with creating content for the platform. I've also attached examples of error messages targeted at end users that I've implemented across my products at the additional cost of Udon performance as a result of continuous scanning to ensure that UdonBehaviours critical to world's operation are still enabled.

Hello VRChat Devs and World Creators, For a better formatted & More In Depth Version of this Feature Request that includes Images and Descriptions of each node, please go to my post on the Dev Forum: https://ask.vrchat.com/t/feature-request-give-udon-u-access-to-instance-information-group-information/27923 Due to the character limits on canny, I cannot put the full post here, Again, Please refer to the dev forum post linked above I propose adding the following Nodes: InstanceInfo IsUserInGroup DoesUserHaveRole GetGroupRules GetGroupDescription GetGroupBanner Now let’s go over some examples for how these nodes will benefit world creators. Determining the Instance Type is super useful as world creators can choose to enable/disable certain features of a world depending on the instance type. For example: In a Public instance I would make sure the permissions system is disabled and all staff objects will be disabled, While in a Group Public instance we would enable all the permission systems and enable staff objects. A notification could appear in front of the player when joining any Group Instance, informing them that they have joined a group instance and Groups can set their own rules. Using the “GetGroupDescription” and “GetGroupRules” Nodes, we can put the rules and description inside the world to make it easier for people to see the rules (cause lets be honest, nobody reads group rules before joining a group public) The “OnInstanceClosed” Event can be used to turn off an open sign at the entrance of a store or bar. The “IsUserInGroup” and “DoesUserHaveRole” Nodes can save world creators and group owners a huge amount of time and hassle, because groups can assign roles to players in the group and have those roles affect what abilities they have within the worlds, eliminating the need for world creators to create super convoluted permission systems for manually assigning roles to players. It can also be useful for things like Patreon/Paid Perks in a world, A lot of people still don’t use/don’t have access to the Creator Economy, or they simply use both. World creators need to set up an external GitHub.io site or a pastebin containing the usernames of paid supporters, and keeping track of people changing usernames and what not is very annoying, Remote string loading also poses the risk of people spoofing URLS to include their name in the list (and yes even though UDON Code Signing has been released, this is still an issue). Being able to access a Main Group for the world and checking if the player has a specific role will eliminate all these issues: * It doesn’t matter if a player changes their username as we won’t be comparing usernames from a list anymore. * Bad actors cannot spoof URLS since we are no longer loading URLS anymore. * Skilled Programmers can set up API applications to automatically add & remove players from roles depending on certain factors (like if they subscribed/unsubscribed) * Since we aren’t relying on external services like GitHub or pastebin anymore, we don’t need to worry about services going down or some people not having Untrusted URLS enabled. This is why I have included the “GroupID” Variable in the GroupAPI nodes, as having access to external groups would make that possible. Quick note: I have thought about people potentially abusing the GroupAPI to spy on players and see what groups they are in, but the amount of time this would take as well as the fact that the player actually has to be IN the world for the GroupAPI to check makes me think that people won’t go through all this trouble. Besides, you can see what groups people are in by simply visiting their profile. If you are really worried about it, you could just make it so if the user has the group hidden from everyone on their profile, it will not show them in the GroupsAPI. GetGroupBanner can be used for automatic decoration of a group instance, like changing a banner above the entrance to the group’s banner. Getting the GroupID of the group hosting an instance is crucial not only for the rest of the nodes but also having verification, What I would do is have a list of group ID’s that correspond to groups I know follow the guidelines set in place by us, and that they follow the VRChat TOS. If the current group ID is on the list then I can show a little “Trusted Group” Icon somewhere to inform new users that they can trust the group.

This will allow maps to have a day night toggle (or change the lighting in other ways) while still using backed lighting.

My user data was reset when the world changed to season 2 Reset My User Data. Please give it back. I can't get the special aura again.

[Steps to reproduce] Lay out many (about 50 or more) MonoBehaviour and VRC_Pickup objects in the scene. Enter the world with 3 or more people. All player pick up and move some objects. Join a new player. The coordinates of some objects are not synced correctly to the new player. [Cause] Maybe, ownership information is not correctly transmitted to new player. In the new player, owner of some objects will appear to be the master. But the owner is actually a different player. So the coordinates by the true owner send to be ignored, the new player will see the object appear to be stationary from its initial position. Also, if an object is picked up by the true owner of that one, SetOwner is not called. So new players will continue to recognize that the master is the owner. [Interim measures] Always the master keep to hold all ownership of objects.