World/Udon Bugs & Feature Requests

Until now, OnDeserialization() flowed at the timing of synchronization variable changes, even in Continuous With this append, OnDeserialization() is always running, regardless of synchronization variable changes, etc. So even in Contiunous, explicitly Therefore, even with Contiunous, compatibility breakdown occurred in code that explicitly wrote RequestSerialization() and OnDeserialization(). ・In my case, I had set Contiunous to almost Manual in terms of functionality, and it still worked fine, but with this appde It worked fine. In my case, I had it set to Contiuous, which is almost functionally Manual, and it still worked fine. I had set it to "Contiuous" and it still worked fine. ・In my personal opinion, I think the behavior after this update is correct in terms of the name "Contiuous". However, I thought it would be a good idea to inform users of the compatibility breakdown that has occurred.

Ownership can permanently desync between clients in an unexpected way The included script can generate such a desync, please assign a TMP text field to view it, then join with 2 clients --- Of note for anyone experiencing this, I've had some success mitigating it by overriding OnOwnershipRequest and returning true public override bool OnOwnershipRequest(VRCPlayerApi requestingPlayer, VRCPlayerApi requestedOwner) { return true; }

Please let us access the position of the name plate, to let us add world-specific UI icons to it. Currently, we can estimate the position of the name plate from the player's position. @bobystar discovered that: > it may have something to do with the avatar's main bounding box (all bone sizes are 1m): I've attached bobystar's screenshot. So a workaround might be to access the player's avatar bounding box - if we have access to that 🤔

UdonBehaviour has HasError that becomes true if the Udon got an error, but it is not exposed for Udon. Currently checking enabled becomes false is the only way to detect if an Udon has error, but it cannot distinguish enabled = false is by user or by Udon error. Using HasError will helps tracking bugs about user-created Udons, so I thought HasError should be exposed.

Physbones is really cool. In particular it has a performant set of tools that allow for avatar-avatar interaction. Please port the Physbones code so we can use it in Worlds too! It would make making many Worlds things far easier, like buttons and levers.

All flavours of SmoothDamp implementation in Udon Graph are completely broken What Unity SmoothDamp does In Unity source, Mathf.SmoothDamp has a parameter ref float currentVelocity which updates itself every frame. Note the ref . The Udon Graph situation Currently in Udon Graph, the Mathf.SmoothDamp node has a currentVelocity input and output. (Should also apply to similar functions that uses SmoothDamp, like Vector3.SmoothDamp and Mathf.SmoothDampAngle.) You can apparently plug in a variable for the input, and set the same variable with the output. However, because you cannot set more than one variable at the same time, once you have updated the currentVelocity dummy variable, when you try to get the current value float output, it will count as a second calculation using the updated currentVelocity meant for the next frame. So this cannot work. (See image) If you try to set variable of the current value first, and calculate the currentVelocity second, it will calculate using the newly updated current meant for next frame. Again, it cannot work. Trying to manually jiggle variables around for this frame and next frame does not work, the output current will somehow overshoot the target. Looking at the Unity source code again, this should not be possible. Something spooky is happening, and the only thing spooky is what Udon Graph might be doing with a ref parameter. (Idk what is going on) (See image) If the currentVelocity input and output is left unplugged, the node works. However, currentVelocity does not get updated every frame in-game, and will remain 0. The effect is that, the movement becomes hugely framerate dependant in a weird way, when it shouldn't. In Unity's original implementation, the overall time to reach a certain point should be about the same for different framerates, regardless of how many steps it takes. Testing I have confirmed these using some custom python code to simulate the duration to reach 0.95 when going from 0 to 1. Test 1 - measurements using Unity source code (This is what should happen) By simulating various framerates, the overall duration using Unity's original code (and making sure the currentVelocity is updated as it should). Notice it is largely framerate independent, except some small errors probably attributed to step sizes in the last frame: Time to reach 95% of the target at 15 FPS: 0.2667 seconds Time to reach 95% of the target at 30 FPS: 0.2667 seconds Time to reach 95% of the target at 60 FPS: 0.2500 seconds Time to reach 95% of the target at 120 FPS: 0.2417 seconds Time to reach 95% of the target at 150 FPS: 0.2400 seconds Time to reach 95% of the target at 200 FPS: 0.2400 seconds Time to reach 95% of the target at 240 FPS: 0.2417 seconds Time to reach 95% of the target at 280 FPS: 0.2393 seconds Time to reach 95% of the target at 300 FPS: 0.2400 seconds Test 2 - measurements using a modified source matching in-game results (This is what happens in-game if the currentVelocity input and output are left unplugged) Another simulation, this time the currentVelocity is manually sabotaged to not be update. The results matches the in-game obeservations. Simulated results: Time to reach 95% of the target at 15 FPS (without updating velocity): 0.4667 seconds Time to reach 95% of the target at 30 FPS (without updating velocity): 0.6667 seconds Time to reach 95% of the target at 60 FPS (without updating velocity): 1.1000 seconds Time to reach 95% of the target at 90 FPS (without updating velocity): 1.5667 seconds Time to reach 95% of the target at 120 FPS (without updating velocity): 2.0333 seconds Observed results in-game: 15 FPS, ~466 ms 30 FPS, ~666 ms 60 FPS, ~1100 ms 90 FPS, ~1567 ms 120 FPS, ~1.9 seconds Comments In my opinion, if Udon Graph implemented this correctly, currentVelocity should not be exposed (as input and output) at all, but should be run under the hood of Udon Graph, which is out of my hands. I guess , under the hood, Udon Graph just needs to make sure there is a variable put aside for each individual instance of these nodes to be used for saving and reading currentVelocity . But I don't know how it works under the hood so I will let the devs figure this out. I don't know if Udon Sharp has the same problem. References and how to replicate The world I used for testing is here: https://vrchat.com/home/world/wrld_8df1ce44-319d-4c67-b253-90f5bd1894b5 Unity source for reference: https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Math/Mathf.cs I also attached the two pieces of simulator codes, in Python. I ran the codes using Jupyter Notebook: https://jupyter.org/try-jupyter/notebooks/?path=notebooks/Intro.ipynb

I am in the process of adding a prefab that processes string loaded information and adds it to a TMPUGUI object, however I have run into an obstacle where I am unable to dynamically scale the headers due to an inability to access the TextMeshProUGUI.fontSize property. Seeing as this doesn't seem like an overstep in any direction and is just basic TMP support, please add support for us to be able to Get this property! Setting it from Udon would be great as well.

Attach the following script to an object, it sends some timestamps between two clients, measuring the one-way trip times. Observe the results in the debug log with 2 local clients on a live server (or assign a TMPro.TextMeshProUGUI field in the inspector for easier viewing) Comparing packet age times on the local clock compared to server derived times shows discrepancy, this varies even within the same instance upon rejoining (though this cannot be easily tested with the script included, you'd need to remake the instance or rejoin on both clients) Shouldn't measuring player2_receiveUTC - player1_sendUTC be equal to player2_receiveServerTime - player1_sendServerTime if both player1 and player2 are run on the same machine?

Make an Udon graph with your windows system language set to Swedish and place in a float with a decimal, say "0.3". Change your system language to English and open the same graph and it will remove the comma and convert the float to "3". The change is permanent and does not revert if you change the system language back.

There are varying opinions regarding the features such as Stickers and Drones in the Live version, but I understand that this is part of VRChat’s official direction. Layers have been provided to restrict the use of these features, and I believe it is possible to take preventative measures in areas where potential issues may arise. However, I do feel there is a concern regarding the fact that some of these features are limited exclusively to VRCPlus members. The reason being that creators who are not subscribed to VRCPlus are unable to test or verify the functionality of these features in their own worlds before releasing them. Personally, I am a VRCPlus subscriber and therefore not affected by this limitation. However, many of my acquaintances who are also world creators are not subscribed. In light of this, would it be possible to consider implementing a temporary exemption—such as a ‘test Stickers’ mechanism—that allows creators to use these features in their own worlds solely for testing purposes? Thank you very much for your consideration.