World/Udon Bugs & Feature Requests

Post about current World or Udon bugs feature requests. One item per post!
Non-constructive and off-topic posts will be moved or deleted.
Pivot back to WebAssembly-based Udon 2
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.
30
[1539] Later-Joiner's `OnVariableChanged` can be fired before `Start()` if the object owner syncs variables frequently
On Later-Joiner's client, OnVariableChanged can be fired without OnDeserialization() before OnEnable() and Start() . It will be happened especially if the object owner uses RequestSerialization() frequently (such as per second interval synchronization). It can be critical problem because it makes OnEnable() and Start() are not guaranteed before synced variable changes: firing OnVariableChanged before Start() can breaks Udons that implementing initialization at Start() . This bug seems the reoccurrence of following this Canny: https://feedback.vrchat.com/udon/p/1259-synced-variables-can-be-changed-from-owners-requestserialization-before-lat Build: 1539 ---- I've made the new testing world to check event orders: https://vrchat.com/home/world/wrld_c357c8f1-1d22-4e91-bfdc-e72c04097fe1/info . (Sample screenshot is attached below) Reproduction steps: Make the instance of the world (Player A), join the instance then enable interval sync from "Toggle Sync Interval" buton. (It starts 0.25s interval of synced int increment using manual sync) Join another player to its instance (Player B). See the console UI in the world at Player B. Expected Results: At Player B console UI, "SyncInt change" console message should only be occured before "OnEnable". Actual Results: At Player B console UI, there is small chance to occur "SyncInt change" console message before "OnEnable". - It may sometimes not be occurred, so try re-joining several times.
0
Give UDON & U# access to Instance Information & Group Information
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.
7
Load More