World/Udon Bugs & Feature Requests

While local strings allow storing from range \u0000 to \uffff , any synced strings are forcefully encoded with UTF-16, making any characters within range \ud7fff to \udfff be truncated to \ufffd . It seems like internal serializer or deserializer is treating all strings as UTF-16 encoded texts, no matter what their purpose is. I do know strings require terminators like \0 to be memory safe, or for some other features like support for emojis via utilizing surrogate pairs, but in raw memory side, string can be treated just like other containers, and I'm utilizing for maximum productivity and memory&network efficiency. (For example, treating each character as 2 bytes, or even go further, 4 hexadecimal numbers) I see this becomes important, due to VRChat's network bandwidth limitations and Udon's performance compared to normal C# codes. Just like gameboy-era old games did, I need to squeeze out all the possible bytes to make the code both performance and network-efficient. Maybe treat string just like byte[] when serialized? or maybe adding a special attributes like NonEncoded to the string variable so that the variable is treated just like another data container?

Was sort of surprised to find out that they aren't already there since full body tracking is officially supported

In native Unity script, MonoBehaviour.Invoke() can cancel by MonoBehaviour.CancelInvoke(). I wondered why SendCustomEventDelayed/Frames can not.

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.

Now that web connectivity will likely require some form of consent from the user when using Udon, I think it's a reasonable request to ask for an actual unique user ID that we can use to identify users. This could be used to do things like enable a debug console in the world, or when web connectivity is back, save progress or settings in a world. Right now people are using display names as "unique" identifiers which isn't good and already has issues since it's a display name. One issue is https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/onplayerjoined-doesnt-get-full-displayname-for-steam-users Another issue is that "special" characters like "." get replaced in the display name with lookalikes which breaks string comparisons. Relying on display name to "uniquely" identify people will become more prevalent as time goes on and people make commonly used systems that depend on them. You should expose this sooner rather than later to avoid this issue. The potential for abuse is obviously possible, but there's no reason to kneecap the systems and introduce potential issues by leaving only display names visible. Right now I can reasonably target people with just their display names, it's just possible that there will be some more people with the same name that get targeted. Worlds abusing names to harass people is something that should be reported on a world basis.

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.

Allow us to get what type of instance the user is in. This way we can add different behavior for public and private instances.

Suggestion: Option 1: In class VRCPlayerApi, create a bool method SetVisibility(bool) which defaults to true, for toggling the overall visibility of a particular player, which includes their avatar and nameplate and any chat box they may create. Option 2: Alternatively, create multiple toggles to control each element individually, such as SetAvatarVisibility() SetNamePlateVisibility() SetChatBoxVisibility() SetStickerVisibility() SetItemVisibility() etc. In my opinion the second option offer better granularity of control and allows a more creative use. Reason 1: Currently if we need to hide a remote player without changing their actual position, we need to exploit a desync station to achieve this effect. Surely that is not the intended use of a station and is in fact a bug. We should be allowed to modify a remote player's visibility with Udon, directly, without exploiting a bug. Meanwhile, world creators can transition to this method, thus allowing the station bug be fixed without affecting worlds that utilize it. Arguably this feature is a prerequisite of eventually fixing the station. Reason 2: We can already control the audibility of a player, via SetVoiceDistanceFar etc. Combining SetVisibility(false) with SetVoiceDistanceFar(0f) and SetAvatarAudioFarRadius(0f) you can make someone completely disappear. Or, alternatively, make someone invisible but can still be heard.

My understanding is that when using AlignRoomWithSpawnPoint with TeleportTo in VR, the passed position/rotation is the destination playspace Origin position/rotation. It's as if the playspace Origin tracking point is moved to your given position, and the player is moved along relative to the Origin. The new origin might be outside a wall, while the player is inside that wall, but that shouldn't matter. However, I've found that if after teleporting a player in VR using AlignRoomWithSpawnPoint, the new player position after teleporting is separated from the new origin position by a wall, the teleport will usually "break". The player's head /viewpoint will end up at the correct position, but they will be detatched from their avatar, which will be outside the wall. This happens when the wall collider is double-sided, i.e. there is collision between the new origin and new player position which seemingly prevents the player capsule from moving to the correct spot. I have made a (contrived) example scene to demonstrate the issue. There is a box, a button which teleports you into the box using AlignRoomWithSpawnPoint, and two indicators. The green indicator shows your AvatarRoot tracking position/rotation, and the magenta indicator shows your Origin tracking position/rotation. When you click the button, the green indicator animates from its position under you to the target position inside the box. The magenta indicator also moves along relatively to the green indicator. At the end of the animation, the magenta indicator should be the new origin position/rotation after teleporting, and so it is the position/rotation passed to TeleportTo. If AlignRoomWithSpawnPoint behaves correctly, you should be teleported into the box and your green indicator should remain underneath you. In the attached video, you can see the first two teleport attempts work correctly. The 1st teleport I stood at the origin, so everything worked fine. The 2nd attempt, the origin was outside the box, but the teleport still worked, and to be honest I don't know why that time it worked. But the 3rd and 4th attempts both failed: my head was teleported into the box, but my avatar stayed outside the box, and the green indicator was outside the box too. I didn't have to jump over the wall to rejoin my body -- I could just pass right through it. Here is a package containing the example scene: https://drive.proton.me/urls/PDST2A2DTR#GU9EoykqkpEU Of course, the workaround here is to just teleport using Align Player WithSpawnPoint, which uses the AvatarRoot position. That's fine and all, but since I encountered this bug and spent days trying to figure out what the heck was happening, I figured I'd report it! Thanks!

We already have NetworkCalling.CallingPlayer, I think we should also be able to know which script is currently the entry point for a network call. This will enable defensive guarding against network calls in event methods without requiring the _ prefix. Not requesting a legacy change, just an extra data point to handle logic with. Semantically this would probably be more valuable for U# devs, but equally useful for UGraph devs too. This is how I would use it: public void MyNetworkProtectedAPIEvent() { // Guard against being called directly via SendCustomNetworkEvent if (NetworkCalling.InNetworkCall && NetworkCalling.CalledBehaviour == this) return; // beyond this, code continues as normal } This would enable making the method protected against _direct_ network calls, BUT still allows OTHER scripts to call the public API from _within their own network called scripts_. This effectively replicates the _ prefix conditions, but allowing for more proper C# naming convention at the cost of 3-4 additional externs. I imagine there are a few other uses such a data point would enable, but I haven't brainstormed that far just yet.