SDK Bug & Feature Requests

Currently, upon reviewing the request headers, there does not seem to be any way to differentiate between string and image loading requests for the same URL. With the limitations of VRCUrl, it would be very nice to have a way to tell them apart. Some potential solutions include specifying a value for the Accept header, extending the User-Agent header, or adding a new VRChat-specific header. I believe the last option would be the least likely to break any existing worlds, but there are various pros and cons of each. An example use-case would be a system to download a mesh (binary data, string loading) and its texture (image loading) using a single URL. The server could use the headers to determine which content it should respond with. This would also be useful for decreasing the size of VRCUrl pools as used in YTS and other worlds. We are already using useragent-dependent responses between video player and string loading useragents, but we'd like to do the same with image loading too.

Adding the Parse Logs from File option allows world creators to take log files (like from another user) and quickly have the UdonSharp log watcher parse them, including useful in-line errors. This is helpful for creators when getting in the common situation of needing to comb through someone else's large log file from a long session to look for an error, and then figure out where that error may take place in an UdonSharp script. This modifies only one file and adds one editor script. PR: https://github.com/MerlinVR/UdonSharp/pull/141

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.

Within a render callback such as OnWillRenderObject, it's useful to be able to check which camera is rendering. Unity has "Camera.current" for this, but it's not exposed to Udon. The new camera API is awesome, but without a property like that, I still can't make my UdonPortals prefab render correctly in the hand-held camera because there's no way to tell which camera is currently triggering OnWillRenderObject. I'd like a property to tell which camera is responsible for the render. A really simple implementation would be a new read-only property like: VRCCameraSettings.CurrentCameraType: An enum consisting of the values "ScreenCamera" or "PhotoCamera". However, I think this API could be extended further to be even more useful. In particular, if a Camera that was created by the world (and so is already accessible to Udon) is rendering, it would be great to be able to access the actual Camera object! Just like Unity's "Camera.current", but only limited to world-created Cameras. An API might look like this: VRCCameraSettings.CurrentCameraType: Enum consisting of the values "ScreenCamera", "PhotoCamera", "WorldCamera", or "Other". "WorldCamera" would be any camera created by the current world, i.e. a Camera that's accessible to Udon. "Other" would be anything else that isn't (yet!) accessible to Udon, e.g. avatar cameras or the screenshot camera. VRCCameraSettings.CurrentCamera: A reference to the current Camera object, just like Unity's Camera.current, except it's only set when CurrentCameraType is "WorldCamera". Otherwise, it's null.

The Network ID Utility can have massive performance issues when working with more than a couple dozens of objects. This can be painful for larger projects especially since now we must retain Network IDs for persistence to function properly. Solution 1: Make a paging system so we can navigate the whole list chunks at a time. Older websites did this to prevent server and web performance issues. We could be given options to view 10/20/25/50/100 or a custom number of objects per page. Solution 2: Change the backend of how objects are listed to only display the ones that could be visible from that window. This would allow infinite scrolling with no pages like Google search or Youtube but can take a bit to get working correctly with a Scroll View. Solution 3: Like solution 2 but using UI Toolkit to have a load time for initialization but is steady after load. I would appreciate if it did not regenerate after clicking an option that changes the data, causing you to wait the full load time again to see the updated list.

An Error or Warning should be shown in the SDK build window when a spawn transform is found to be at or below the respawn height y value. This can be done on accident and isn't something that would be obvious to end users (even with the new respawn plane handle). Especially since it causes the Quick Menu to close, meaning you practically soft lock the client if all respawn transforms are underneath the respawn height. I imagine quite a few creators would not be able to make the connection that their player being locked with no access to the Quick Menu means they are being respawned constantly.

If I have a lobby area in my map, and I want people spawning in to not all start out clipping through each other, then I have to manually set out a dozen empty gameobjects in a grid and add them all to the VRCWorld in random spawn mode. This approach is fine if you really want specific starting points, like totally separate rooms, or doors, or something; but I feel like most maps would benefit from just being able to say "spawn people randomly within this big circle/rectangle". It could just be a radius value (or width/depth value) for each spawn point in the list. It's only a convenience for the world creator (over making a scattering of points in that space manually) but it seems handy and easy to implement.

In UnityEditor, VRCConstraint component inspectors have "Activate" and "Zero" buttons, which calculate rest value and offset value internally. When it comes to adding them from C# script, we have to calculate offset value manually since the "Activate" method is not public in API. The calculation process is not obvious and a bit complicated, so providing existing implementation may be helpful. Is it possible to expose the procedure as a public method like “ActivateAndPreserveOffset”?

I would love a checkbox somewhere in the SDK that would allow me to "pause" the evaluation of all VRC Constraint components when not in play mode. If this interferes with setting up constraints, then perhaps the individual constraint should also be un-paused when the constraint is open in the inspector. Working with constraints gets very messy when working with prefabs because of all the transform overrides generated by the constraints. It's bad to have unnecessary transform overrides inside prefabs not only because its messy but also because it prevents modifications to those transform in the source files from propagating through the prefab inheritance. This is made worse by VRC Constraints because they always mark new overrides, even if the last ones are applied (unlike Unity Constraints). Personally I would basically always have this "pause" enabled, but it should be default off so that people don't unknowingly think their constraints are broken.

I want to be able to see the respawn height and do fine-tuned adjustments of it based on my scene geometry without having to "guess-visualize" it. Just a flat plane gizmo with a single Y axis move handle would do.