SDK Bug & Feature Requests

Please check out the following rules and use the provided template when posting a bug report! Off-topic posts will be deleted.http://bit.ly/vrchat-bug-reports
Improve vrcPlayerApi.getPlayers ()
Motivation In Udon Sharp, syntactically, the following is nonsensical: var players = new VRCPlayerApi[VRCPlayerApi.GetPlayerCount()]; VRCPlayerApi.GetPlayers(players); Why doesn't GetPlayers() just… return a preconstructed array of players in the instance already? Why do I need to first create an empty array? In Udon Sharp, at least, one can easy replace or initialize an array with something else like so: int[] arrayOfNumbers; void someFunction() { arrayOfNumbers = someClassInstance.AFunctionThatReturnsAnIntArray() } There is no need to preset the size of the array, as the actual array construction is handled by another function. But in the VRCSDK we are required to pass a prebuilt array to this function??? Make it make sense. Solutions One, Update UDON so GetPlayers() no longer requires passing in an empty VRCPlayerAPI[] sized to the number of players when compiled with a newer SDK; The UDON VM would support both the old and the new behavior. This would have the benefit of, at least in UDON Sharp, being syntactically valid, as the initialized VRCPlayerAPI[] would become effectively an optional variable. If passed, it would follow the current behavior. If not passed, the function will create an array sized to the current number of players currently in the instance automatically. Two, create a separate GetPlayerList() , which would return a VRCPlayerAPI[] of the appropriate size (which could then be stored as a variable), and deprecate GetPlayers(VRCPlayerAPI[] players) in favor of the new function. This would have the benefit of easier backwards compatibility and avoid changing default behavior of an existing function.
0
VRC Object Sync - MAJOR Performance Issues With a Real Solution
VRC Object Sync by default is a continuously operating script that pings locations to all players even when objects are at rest or behind the player/occluded by the world. As a result, once the object pool reaches higher numbers, over 200, frame times are permanently hindered as the game waits for all these pings. I'd tested in my world the difference between VRChat's default Object Sync script and MMMaellon's Smart Object Sync on about 212 objects. Performance with default object sync raised frame times to 16.7-17ms. MMMAellon's Smart Object Sync brought framerates down to 2.4-3ms, an overall savings of around 4-5x performance improvement. And this is not on a slow PC - this is on a Ryzen 7 7800x3D with a Noctua NH-12s cooler, an RTX 4070, and 64 GB of RAM. You cannot simply add power to fix the problem. MMMaellon's script does a lot to improve performance, but the core function allows objects at rest to stop pinging unless exerted by an external force. They are also developing a newer version of the script that cuts bandwidth in half. As VRC adds more dynamic global objects through the inventory system, I fear this issue will only become more exasperated the longer global sync gets ignored. I highly recommend enabling higher performance syncing methods by default for newer worlds and enabling the older sync system only when absolutely necessary. As many maps feature QV pens, pool tables, grabbable pillows, coffee and drink prefabs, and other grabbable synced objects, this will have an immediate performance impact across the entire game, and it's something all creators need to be made aware. https://github.com/MMMaellon/SmartObjectSync
2
·

tracked

Load More