VRChat IK 2.0

It would be cool to add Unity.ComputeShader support to Udon The feature is really great, so I can give tasks to the GPU that would run much slower on the CPU, so to speak, divide the tasks better according to skills. Due to the design of GPUs, in Unity, I was able to generate worlds on the fly, much faster which is also possible with the CPU, but is extremely slow. More info: https://docs.unity3d.com/2019.4/Documentation/ScriptReference/ComputeShader.htm and thx for voting

I think it would be a neat feature to allow Udon to have some interaction with groups. For example, you could have a user click a button in your map, and be sent a group invite or be brought to a group's page. This would be easier than having a sign with your group's join link/code. It would also be interesting to allow Udon to check if a player is a member/staff of a specific group. (However, this might be somewhat exploitable? Could lead to a 'join X group to enter the world/room' type thing.) Another idea could be a button to give the player a role in a specific group, such as a "completionist" role for completing a long map? (For security, maybe the world owner would need to be a staff or owner of the group?) All of these are just ideas, but I think it would be really interesting to see some kind of Udon and Group interaction.

Having worlds be able to run udon code for certain instances I think would be great. If you create a friends+ and have certain udon code work like get rid of the certain things for public lobbies or keep toxic users out of public lobbies but still allowing them in friends+ lobbies.

So, I've had the idea for awhile. We have this nice radial menu for doing things with our avatars, but there's no nice interface for interacting with worlds. What this is proposing is an additional menu for SDK3 worlds that can allow players to change settings in the world with their radial menu rather than inputting things from UI panels or buttons in the world. Master/Owner of the world could have their own options to adjust and so fourth.

Currently, Udon only functions on a single thread, which limits what users can create. Upgrading to a multithreaded version of Udon that evenly distributes functions over all available cores in a user's system can increase performance, and avoid bogging down a single core, leading to higher framerates, and faster processes in VRChat across all worlds and games. Some worlds use 100% of a single core, leaving the game running sluggish. If Udon utilized ALL threads, this problem would be much less extreme. Udon appears to run mainly on thread CPU 2, and if there's a lot of Udon functions in the world, such as in Murder 4, Prison Escape, or other Udon heavy games, the framerate tends to suffer as a result. Please consider making Udon utilize more, or all cores.

A single specially coded UdonBehavior that is responsible for managing the world in general. Can easily be referred to by other UdonBehaviors that are attached to objects and avoids the need to use GameObject.Find() and its varients. It can be applied on to a variable in the inspector of the World Descriptor. Most likely this would only be on the world instance owner's side since its the "server" managing its clients. Can be programmed to assist on syncing behaviors between clients reliably rather than a web of object references waiting on each other to update value. (Would from benefit events with parameters if it does get added later on) But maybe there can be a use for client side singletons too that I haven't thought of. Great for game-mode like worlds that need to track player/team score or the world's current state. Speaking of "world's current state", this can probably open up to having a "status like" indicator for worlds similar to user status but more custom and optional. But maybe this is a completely different suggestion.

Proposing an Udon wrapper around the Discord API for world creators to create more immersive worlds. https://discord.com/developers/docs/reference Discord already has an extensive API to interact with their services, poll servers for users, grab their groups, post messages to channels, retrieve messages from channels, etc.. The amount of new and exciting things creators could do in their worlds if they had this ability is almost endless. I feel like this is an especially important and needed feature of the game, especially since crafting URL's at runtime is still being artificially disabled. The entire Discord API does not need to be exposed from the get go, not that it would be very difficult to do. Errors are already returned in JSON format which means they can easily be parsed in Udon without any additional development required from VRC devs. Interacting with the API is a simple HTTP/REST library requiring you to formulate your request inside of a JSON object, so again, not much is needed from VRC devs to expose the ability for us to start interacting with the Discord API. Essentially we just need https://discord.com/api whitelisted and an object that cant post and receive a JSON 'payload' to/from the URL. Thank you for your consideration, I know this will be a widely appreciated feature for world creators and players.

Back then in 2020 to early 2021, we were able to monitor which gameobjects/UdonBehaviour are eating the most resources while testing in the editor by inspecting it through profiler window, going into raw hierarchy and it will show which behaviours are eating the most. Nowadays, all we see are percentages, time ms and gc allocs; We're unable to see which related gameobjects nor scripts that eat up most of the resources. I know in UdonSharp's discord, they've provided a way to determine the usage but it only displays the overall cpu usage in ms for all of the UdonBehaviours in total. It's a workaround but it's hard for us to pinpoint which is which. I'm just asking if it's possible to bring back that feature; or something equivalent. Thank you!

So, the recent EAC update hit and mods kinda went under the bus, completely fine with that honestly, but that got me thinking "what could be a good substitute to modding?" Cause while the bigger features (like the accessibility features currently in beta) will get probably implemented, there are going to be a ton of little things that only an handful of people would be interested in, and definitely not worth the development time. Well, world were in a similar spot before udon, and now we have udon, soo... why not extend it? The idea would be to have client wide udon scripts that a user can load locally, and these client udon scripts can have access to stuff in the client side like the local ik, client settings, menu tabs etc, all within the safeguards of the udon sandbox. There should be 2 modes to a client udon script: one where the only allowed playground is your own player object and local client settings (anything regarding menus and such), so a "don't touch the others" mode, and one where udon has access to all players objects, so that the user could change stuff on the other players,like hiding them or parts of their avatars, mute them etc (of course these changes would be only on the local client). This second mode should be set so that people can see if a user is using it (with an icon in their nameplate for example), cause i would like to know if someone is doing something on their side with my avatar, so that i can point that out if they then come to me saying that my avatar is broken. A rollout of a feature like this would of course be on steps, to see what can be opened up to use (just like udon when it first came out), but it could be a decent middle ground solution to let people personalise their experience in VRChat with safeguards that mods definitely did not have.

It would be nice to be able to get the rank of an avatar via Udon to allow for world creators to filter out players above a certain threshold. (e.g. You load into a room and have to click a door handle to teleport out, the door handle doesn't work if your rank is "Very Poor") This would make managing high-capacity worlds a bit easier and reduce the need to manually check everyone who enters.