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

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.

This will allow maps to have a day night toggle (or change the lighting in other ways) while still using backed lighting.

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.

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

Players and world creators would appreciate a new character controller for VRChat worlds. It should work mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going upstairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controller. ... And more!

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.

NodeRegistryUtilities.GetNodeDefinitionInfo incorrectly identifies GameObject.SetActive as CTOR_INFO . I have discovered a bug in NodeRegistryUtilities.GetNodeDefinitionInfo . When querying the definition for UnityEngine.GameObject.SetActive , the API returns a DefinitionInfo where the DefinitionType is DefinitionType.CTOR_INFO instead of the expected DefinitionType.METHOD_INFO . It appears that the internal logic fails to match the specific MethodInfo for SetActive and erroneously falls back to a ConstructorInfo that happens to match the parameter signature, disregarding the actual node name. I realize this is not an API that most world creators will use, but since it is a public API, I believe it is appropriate to submit the bug report here. Reproduction: ```csharp using UnityEngine; using UnityEditor; using System.Linq; using VRC.Udon.Graph; using VRC.Udon.Graph.NodeRegistries; public class UdonBugReproduction { [MenuItem("Tools/Verify Udon Bug")] public static void VerifySetActiveBug() { var registry = new RootNodeRegistry(); var definitions = registry.GetNodeDefinitions(); string targetFullName = "UnityEngineGameObject.__SetActive__SystemBoolean__SystemVoid"; var targetDefinition = definitions.FirstOrDefault(d => d.fullName == targetFullName); if (targetDefinition == null) { Debug.LogError($"Didn't find the definition of {targetFullName}"); return; } var info = NodeRegistryUtilities.GetNodeDefinitionInfo(targetDefinition); // Expected: METHOD_INFO // Actual: CTOR_INFO Debug.Log($"Definition type is {info.definitionType}"); Debug.Log($"Info object type is { info.info ?.GetType().Name}"); Debug.Log($"Info content: { info.info }"); } } ``` Result: Expected: info.definitionType should be METHOD_INFO . Actual: info.definitionType is CTOR_INFO , and info.info contains a ConstructorInfo object instead of MethodInfo .