Improve VRCPlayerAPI.GetPlayers()
available in future release
MisutaaAsriel
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.
Log In
This post was marked as
available in future release
Dexvoid
marked this post as
tracked
We're looking at adding an allocating version of
GetPlayers()
that takes no parameters.Just to give a quick explanation, the reason
GetPlayers()
currently accepts an array that it populates is to make it possible to avoid allocating memory every time it's called, which can be useful for avoiding garbage collection in contexts where it's used frequently (for example every frame). You're right that it probably isn't a very straightforward interface for newcomers to Udon though.MisutaaAsriel
Dexvoid I know it's marked as available in a future release, but I am morbidly curious now about the ins-and-outs of this, if you'd humor me.
I assumed, on the .NET side, VRChat already
has
an array of players in the world. Was that a wrong assumption?Or do you mean to say that UDON, rather than accessing the internal API's array through a some sort of "interconnect" between UDON & the client, is (or was)
copying the list of player's to the UDON VM's own memory?
Rather than referencing the existing array.Or was it something even more cursed entirely?
Dexvoid
MisutaaAsriel We can't return the internal array by reference because world Udon could then modify the array directly. We either return a copy of the array (the new parameterless call) or populate a pre-existing array owned by the Udon program with the same set of player objects.
MisutaaAsriel
Dexvoid Ah the array wasn't set up for read-only access. That makes sense (and I imagine changing that would've entailed refactoring a lot of client-side code.)
Either way, sounds like y'all found a solution. :)