World/Udon Bugs & Feature Requests

There should be an option to set the world to 18+ by default and restrict it to only that. Any other instance, whether its a group, invite only, etc will be defaulted to 18+ This is an option that could be toggled by the creator in the SDK or WebGUI that no one else can change

Starting with Build 1878 (Open Beta) and Build 1885 (Live), there's a change to pickup highlighting which relates to VRC_Pickup with SkinnedMeshRenderer. It is written that "We feel that the amount of content this affects is extraordinarily small", but I have some worlds which are affected by this change. Some of them are SDK2 worlds and it would be a lot of work for me to fix all of them. I guess that some world creators (including me) assumed that SkinnedMeshRenderers are completely ignored by pickup highlighting, and I used this property to control pickup highlighting: Shader-based gimmicks often change the appearance of the mesh. In SDK2, use of SkinnedMeshRenderer is convenient for hiding its internal mesh shape and expanding mesh bounds. To select the highlighting mesh of pickups containing multiple child renderers, sometimes I change some renderers to use SkinnedMeshRenderer. Also, I preferred using the (fallback) collider outline for pickup highlighting. In this SDK3 era, I basically agree with the changes because there's a correct way to fix the issues. But I guess some worlds may still use this old technique. I want to say: Some world creators really care about the shape of pickup highlights. If the highlighting reveals the strange internal shape, players' immersion will be broken. Please keep existing behaviour as it is. I feel component versioning (e.g. VRC_Pickup Ver 1.1) is a very good idea, and it should be used more! I propose increasing the VRC_Pickup version number and keeping the old highlighting algorithm for older versions. I'm really sorry for not checking or reporting during Open Beta. I've attached some screenshots of my worlds which show how the new highlighting unintentionally reveals the internal mesh. (To be honest, I might be the one who uses this bad trick the most, though...)

Writing a U# program like so, will fail with: Method is not exposed to Udon: 'texture.SetPixelData(d, 0, 0)'. Even though it is exposed as UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D U# Code: var texture = new Texture2D( 2, 2, TextureFormat.RGBA32, false ); uint[] d = new uint[2 * 2 * 4]; texture.SetPixelData(d, 0, 0); However it will compile in udon graph, but the data input will be a Object[], and will crash with anything passed to it. Manually writing some udon assembly will compile again, but will also crash at runtime udon assembly: .data_start .export tex .export arr .export num0 .export num1 .export f .export tex_format tex: %UnityEngineTexture2D, null arr: %SystemSingleArray, null num0: %SystemInt32, null num1: %SystemInt32, null f: %SystemBoolean, null tex_format: %UnityEngineTextureFormat, null .data_end .code_start .export Test Test: PUSH, num1 PUSH, num1 PUSH, tex_format PUSH, f PUSH, tex EXTERN, "UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D" PUSH, tex PUSH, arr PUSH, num0 PUSH, num0 EXTERN, "UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid" JUMP, 0xFFFFFFFC .code_end udon assembly crash: VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'. Parameter Addresses: 0x00000000, 0x00000001, 0x00000002, 0x00000002 Cannot retrieve heap variable of type 'Single[]' as type 'Object[]' ---------------------- Program Counter was at: 80 ---------------------- Stack Dump: ---------------------- Heap Dump: 0x00000000: (UnityEngine.Texture2D) 0x00000001: System.Single[] 0x00000002: 0 0x00000003: 1 0x00000004: False 0x00000005: RGBAFloat 0x00000006: UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D 0x00000007: UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid ---------------------- Inner Exception: ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'.

As a world creator, you may have found yourself in need of a way to make an object always face the local player, sometimes called Billboarding. Doing this with transforms requires update loops in Udon, which are expensive. We’re adding native support for this to make it easier and more performant to implement! Three new methods will be available! (Note: always subject to change until release!) VRCBillboard.Register(Transform target); // upright, tracks yaw only (side-to-side) VRCBillboard.Register(Transform target, bool allowTilt); // allows up-and-down pitch changes as well VRCBillboard.Unregister(Transform target); // cleanup is automatic but can be triggered manually

If I want to pass a parameter when sending custom events with delay, and i want to be able to send many of them with varying results without having to add 200 specific events or variables attached. I think it will be useful and user friendly if parameter passing can be written directly in sender side SendCustomEvent node and receiver side CustomEvent node as a kind of syntax sugar. I copied part of the previous canny about this, as only the Networked event was covered and left us completely unable to make this sort of thing happen entirely locally despite the canny being marked as complete

When OSC was added for avatars a long time ago, it was promised to also add it for worlds, but world creators are still waiting for it to be added. Just like with Physbones, this hasn't happened yet and I'm afraid that world creators won't get OSC support because the focus seems to be fully on avatars. Is this still on the roadmap? OSC for worlds / Udon would allow concepts like speeach recognition, tracking world objects / pickups with Steam trackers (e.g. an IRL broom in a world where you can fly on a broom), DMX / light controllers in DJ worlds etc. MIDI is all we have in worlds right now and it's too limited and hard to implement for anything other than a music instrument.

Since bone transforms aren't exposed, we can't parent objects to players and need to use expensive and complicated update loops for such a basic task, which also results in ugly/janky object movements and low performance. Please give us a simple function like .SetParent(Transform t, Boolean b) for .GetTrackingData(VRCPlayerApi.TrackingDataType.x) and .GetBonePosition(HumanBodyBones.x) and for VRCPlayerApi.GetPosition

Allow world creators to choose where portals can and can't be dropped. This would help prevent "trolling" in public instances where someone might be forced into a portal against their will, some game worlds may have the player flying forward for example so they are unable to react fast enough or unable to act if a 2nd user places a portal in their path. Right now the only options we have is entire world allows a portal or the entire world prevents portal dropping. A middle ground between these 2 extremes would be appreciated where a creator could have a designated area where portals can be dropped. Outside that and it would function the same as "too close to spawn". As a world creator I don't want to remove the players choice of dropping portals but I would like some control over it to prevent unpleasant experiences for users visiting the world, as too many occurences like this can have a detrimental effect on public perception of a world.

After importing a dolly via Udon, the "Speed" value set in VRC Camera Dolly Point does not get translated correctly when the "Copy to Camera" button on the point gets used in-client. Anything set with speeds 1 or greater gets applied as 15.0 in-game (clamped limit) and 0.1 gets applied as 0.2 (clamped limit). Editor values tried: 0.15 editor -> 0.4 client 0.2 editor -> 0.5 client 0.25 editor -> 0.8 client 0.4 editor -> 3.0 client 0.6 editor -> 5.1 client 0.9 editor -> 11.5 client

Summary I found a reproducible Udon networking issue where a Manual-sync UdonBehaviour begins serialization without any user-code call to RequestSerialization(). The behaviour repeatedly receives: OnPreSerialization() OnPostSerialization(success = false, byteCount = 0) while the RequestSerialization call count remains 0. The issue depends on the composition/cardinality of UdonBehaviours attached to the same GameObject. Moving the additional UdonBehaviours to separate GameObjects prevents the issue in my isolated tests. Observed Behaviour With a Manual-sync Authority UdonBehaviour and certain additional UdonBehaviours on the same GameObject: RequestSerialization calls: 0 OnPreSerialization: repeatedly called OnPostSerialization: repeatedly called SerializationResult.success: false SerializationResult.byteCount: 0 I instrumented the first unsolicited serialization attempt. At FIRST OnPreSerialization: RequestSerialization count = 0 Networking.IsClogged = false Networking.IsNetworkSettled = true Networking.IsObjectReady = true local player is owner Authority SyncMethod = Manual Therefore the first observed serialization attempt was not preceded by an instrumented RequestSerialization call and did not begin while IsClogged was true. Minimal Cardinality Reproduction Using the same Authority behaviour and repeated copies of the SAME additional ProgramAsset on the SAME GameObject produced this pattern: Additional sibling UdonBehaviours: 0 -> QUIET 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop 5 -> QUIET 6 -> unsolicited serialization loop 7 -> QUIET The positive cases repeatedly produced: Req = 0 Pre > 0 Post > 0 success = false byteCount = 0 This was not specific to one ProgramAsset. I reproduced the same cardinality pattern with another Udon ProgramAsset: 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop I also reproduced it using distinct sibling ProgramAssets: 1 sibling -> QUIET 2 siblings -> unsolicited serialization loop 3 siblings -> QUIET 4 siblings -> unsolicited serialization loop I am NOT claiming that all even numbers of UdonBehaviours are generally broken. This is only the reproducible pattern observed under this isolated fixture configuration. Same-GameObject Isolation I then tested the registration/layout layer. Same GameObject: Authority + two relevant siblings -> unsolicited serialization loop Split GameObjects: Authority on GO-A Sibling 1 on GO-B Sibling 2 on GO-C -> QUIET Partial split: Authority + one sibling on GO-A second sibling on GO-B -> QUIET This suggests that same-GameObject Udon registration/composition is involved. Additional Cause-Layer Tests The problem was NOT reproduced simply by creating arbitrary zero-field behaviours. Controlled variants using inert zero-field Manual / Continuous behaviours remained QUIET in my tests. Changing between zero and one synced field also did not independently reproduce the issue. Therefore I currently classify this as a multifactor same-GameObject registration/composition issue rather than a bug in one specific script, NoVariableSync alone, synced-field count alone, or Manual sync alone. Expected Behaviour For a Manual-sync UdonBehaviour: If user code never calls RequestSerialization(), the owner should not enter a continuous OnPreSerialization / OnPostSerialization failure loop. In particular, I would not expect the addition/removal or placement of sibling UdonBehaviours on the same GameObject to cause unsolicited Manual serialization. Actual Behaviour Under the affected same-GameObject composition: RequestSerialization count remains 0, but serialization begins anyway. The first observed attempt occurs while: IsClogged = false IsNetworkSettled = true IsObjectReady = true It then repeatedly calls: OnPreSerialization() OnPostSerialization(false, 0) Important distinction VRChat documentation states that failed Manual serialization may be cached and retried when networking is clogged. That could explain repeated attempts AFTER a failed serialization event. However, in this reproduction the FIRST observed serialization attempt occurs with: RequestSerialization count = 0 IsClogged = false So the unresolved issue is what creates the initial Manual serialization event. Possible Related Existing Reports https://feedback.vrchat.com/persistence/p/persistence-does-not-restore-synced-variables-in-udon-components-other-than-the https://feedback.vrchat.com/bug-reports/p/pickup-events-may-not-be-called-when-multiple-udon-components-are-attached There are existing tracked reports involving multiple Udon components on the same GameObject, including: Persistence only restoring synced variables from the first Udon component Pickup events not reliably reaching multiple Udon components Those reports may or may not share the same underlying cause. This report describes a different failure mode involving the Manual serialization lifecycle. Impact This is particularly difficult to diagnose because: gameplay code does not call RequestSerialization the affected behaviour is Manual sync the behaviour may work or fail depending on same-GameObject composition changing hierarchy/component composition can make the issue disappear the resulting failed serialization loop can continue at a high rate In a modular Udon system, adding/removing otherwise unrelated sibling UdonBehaviours can therefore change networking behaviour unexpectedly. Workaround Separating the networking Authority UdonBehaviour and the additional UdonBehaviours onto different GameObjects prevents the reproduction in my isolated test. I consider this a workaround, not an explanation of the underlying behaviour. Reproduction Evidence I have retained: isolated minimal fixtures cardinality matrices ProgramAsset identities runtime SyncMethod fingerprints first-unsolicited-event instrumentation prefab/scene hashes for tested builds repeated runtime observations I can provide a stripped minimal Unity/VRChat reproduction project if useful.