World/Udon Bugs & Feature Requests

There are varying opinions regarding the features such as Stickers and Drones in the Live version, but I understand that this is part of VRChat’s official direction. Layers have been provided to restrict the use of these features, and I believe it is possible to take preventative measures in areas where potential issues may arise. However, I do feel there is a concern regarding the fact that some of these features are limited exclusively to VRCPlus members. The reason being that creators who are not subscribed to VRCPlus are unable to test or verify the functionality of these features in their own worlds before releasing them. Personally, I am a VRCPlus subscriber and therefore not affected by this limitation. However, many of my acquaintances who are also world creators are not subscribed. In light of this, would it be possible to consider implementing a temporary exemption—such as a ‘test Stickers’ mechanism—that allows creators to use these features in their own worlds solely for testing purposes? Thank you very much for your consideration.

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.

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.

I would like a way to mark stations as "local" which prevents stations from doing their own internal "seated" player tracking. This allows us to reuse 1 station for all custom world locomotion systems. Currently stations have their own special handling for making sure that late joiners see a specific person sitting in a station that they were sitting in prior. This handling also prevents you from sitting in a station if your client thinks someone else is already in it. However, if two players enter the same station at the same time, locally they will both be registered as being in the station which means the lock out provided by VRC does not guarantee anything and is essentially useless in practice for much more than a chair that's there for aesthetics since it's trivial to break unintentionally and by extension break any systems that depend on it. Anything involving stations has historically been bug prone and liable to break subtly at the drop of a hat. When issues have been fixed, they have been liable to regress a patch or two later and then get left for months or years. The same goes for the implicit syncing behaviour of stations. Putting aside bugs with station sync aside, even if it worked perfectly 100% of the time, there are many cases where people want to implement their own locomotion in worlds which requires absolute control over the player position and rotation locally. But at the same time does not require a "vehicle" that the player is in and directly attached to. As far as I have heard from VRC staff, stations are the supported way to do this since we cannot control the exact position of the player, only the derivative of it (the velocity), which is janky at best, and we cannot rotate the player on any other axis than Y because the player controller is not made to work correctly with any rotation off the Y axis outside of the context of stations. On the other side, we should also be able to locally assign a remote player to a local station. Many worlds have used this to control the local perception of the location of remote players. Allowing for non-euclidian worlds, worlds where locomotion does not behave exactly the same as VRC where people can stand on walls for instance, or more practically, large "vehicles" where everyone can be located on the vehicle which is "moving" through the world when the world is actually moving around it, but players outside the vehicle see the remote players attached to it properly. This is all possible with how stations are currently synced, but it means that you need to have an object pool for every station in the world which is handled consistently between all clients, and it leaves stations subject to the worryingly common bugs with station sync. I have seen many people try using stations for locomotion and such only to stop because it's way more complex than it should be even though it's the way VRC tells you to do custom locomotion. There are also many worlds that you're leaving to use the jank method of pooling them which is liable to break, and on many of these worlds has broken when the station sync has broken. Despite it being more complex, people will make prefabs, people will make instructions for how to deal with station pooling Because every VRC employee seems to be of the mindset of "man, should we support this basic thing that takes maybe a couple of hours to implement and should be basic to support?" I will reiterate: people already do these things, as time goes on, more people will do these things, you are increasing technical debt by not adding this. And it will only get worse the longer you do not act. When you run a content creation platform, lack of basic things like this pushes technical debt onto your creators, which means they use systems in ways they should not need to be used. This in turn means you need to support these further abstracted systems Stations are the established and supported way to override VRC's built-in locomotion, and they should be able to be treated as such without hacking around to make them kinda work and leaving them subject to sync bugs. Related bug about one of the ways station sync breaks currently: https://feedback.vrchat.com/bug-reports/p/random-user-gets-stuck-in-station-for-new-joiners

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.

Teleporting players with an offset rotation, 180 degrees being the most drastic, will twist and contort players in a very unsettling and horrific manner. Also, when trying to make more seamless (hidden) transitions using player teleporting, physbones completely reset, also giving the transition away. Using quaternion math, teleporting players with offsets for their local view is easy in Udon and would be perfectly immersive and unnoticeable with this capability. Prevent players contorting right as they're teleported. Optionally preserve physbone offsets and velocity between the teleport locations. This kind of teleport would allow for easy: Audio separation between floors of a world's building Manual occlusion of areas and players normally behind animated objects, like doors that may only show the transitioning player and not everything else behind them elevator-esque locations teleporting players immersively between locations Non-euclidean effects to create unique navigation or experiences

It would be useful if we could get Terrain methods in Udon. Specifically, methods and properties in https://docs.unity3d.com/ScriptReference/TerrainData.html and https://docs.unity3d.com/ScriptReference/DetailPrototype.html .

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.

Hello, VRChat team, I hope you're doing well! I'm a big fan of VRChat and appreciate the incredible social experience you created in virtual reality. I'm getting in touch to suggest the possibility of developing a version of VRChat for the PS5 console and the PSVR2 system. With the graphical potential of the PS5 and the improvements in tracking and immersion of the PSVR2, I believe that many players would love to take advantage of the VRChat community and experiences on this new hardware. Additionally, PSVR2 has been gaining a solid user base, which could further expand the VRChat community. I understand that there may be technical challenges or other considerations, but I would like to express my enthusiasm for this idea and my support for expanding the platform to new devices. I thank you for your attention and for all the incredible work you do. Regards, Samuel Dantas de Araújo Medeiros

It would allow worlds to do a lot more if we could Instantiate objects over network to players and have them sync. This would be more efficient and easier to work with than having all possible objects in a object pool.