World/Udon Bugs & Feature Requests

There is an undocumented limit on Network IDs. If you assign a Network ID beyond 10 000 to a PlayerObject its persistence features will break while the UdonBehaviour itself still functions and syncs. ClientSim throws the following error: ran out of player persistence view ids In-game testing results in Removed some Player Persistence metadata that had invalid IDs. errors. Apparently there is a limit of 100 000 for Network IDs in general, its way less likely to hit this, but this also seems undocumented. The difference in limit for PlayerObjects and standard UdonBehaviour objects is confusing and the provided errors don't accurately explain how to solve this issue. The Network ID Utility also does not seem to take this limit for Player Objects into account and does not warn or ensure a lower ID is assigned to the persistent objects. Furthermore, the Network ID Utility crashes on projects with this many Network IDs, but this was already documented here: https://feedback.vrchat.com/sdk-bug-reports/p/network-id-utility-has-massive-performance-issues

If an exception is thrown by a call made by a Udon program, the instigating event should be terminated with a clean error message, rather than permanently crashing the entire behaviour. In addition, an OnException(error) event which contains the exception object thrown for handling when things explode would be extremely handy.

It is currently not possible to construct VRCUrl at runtime. This makes it difficult to generate video URLs that require dynamic input to function, such as playing a video based on an arbitrary search query, or generating video URLs that utilize token based access or are limited by other conditions. Data leakage concerns are already mitigated with the Allow Untrusted URLs option.

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.

When adding [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] to an udon# class, It will just continue using the last setting. For example if you add [UdonBehaviourSyncMode(BehaviourSyncMode.Continuous)] and then compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again, you get the expected behavior, and calling SendCustomNetworkEvent() works. If you then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.None)] and compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again It will continue to behave exactly as if it's still set to None. SendCustomNetworkEvent() does not work. This is on an object that doesn't have any other scripts on it. I haven't tested the case with other scripts. You can look at the debug inspector to confirm that this is what is happening. From the documentation: "NoVariableSync: Enforces that there are no synced variables on the behaviour, hides the sync mode selection dropdown, and allows you to use the behaviours on GameObjects that use either Manual or Continuous sync." It seems like the case where a script using NoVariableSync being used on an object that doesn't have another script on it may have been overlooked. Since I'm updating a script in a prefab I'm releasing from None to NoVariableSync because I want to use network events now, it's not going to work for anyone updating to the new version. I am forced to set it to Continuous. Does anyone know if it makes any difference to bandwidth usage?

I noticed this bug when I tried to set a value that could not be represented as a float. Shader.SetGlobalInt() is cast to float internally, so Shader.SetGlobalInteger() needs to be used.

The error can't be reproduced with 100% guarantee, nor have I found anything that seems to cause it, though I think it happens most often with The Black Cat? It seems to happen with both public and private worlds, empty and busy worlds, if the portal has a custom name or not doesn't seem to matter, etc. However, I can get it to happen most often from this test world, which may suggest that the world the portal is in has some affect on whether it will break or not: https://vrchat.com/home/world/wrld_a077bb01-5d07-44db-a1fc-cdc95eca2a16/info Sometimes the error pops up but then it loads you into the world anyway. But if it doesn't load, the portal is then "frozen" and can't be entered anymore unless you rejoin the instance. Reproduction steps: Join test world Walk into portal. if the error doesn't pop up, let it load the world, then join it again and try again until it happens (Yes, it HAS to be the Black Cat because I think it happens most often with this world) Output log is attached, with the relevant error at 2025.01.23 03:59:10. In this session I booted into a new instance directly using the VRC Quick Launcher. Walked into the portal, loaded into the Black Cat, pressed Go Home to go back to my home world, then made a new instance of the test world, joined it, and walked into the portal. This time it gave the error and didn't send me to The Black Cat.

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.

The current SDK is able to track players' heads and hands using TrackingData, but not their legs. GetBonePosition can do this but it's less reliable between avatars since it relies on bones rather than controllers. It'd be nice if TrackingData could also access left/right feet and waist/hip.

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.