World/Udon Bugs & Feature Requests

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

If you use VRCPlayerApi.SetVoiceDistanceFar() or VRCPlayerApi.SetVoiceDistanceNear() The the value seems to get clamped to a maximum of 10000. I would like the maximum range to be as high as possible for stuff like aircraft radios.

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.

On Later-Joiner's client, OnVariableChanged can be fired without OnDeserialization() before OnEnable() and Start() . It will be happened especially if the object owner uses RequestSerialization() frequently (such as per second interval synchronization). It can be critical problem because it makes OnEnable() and Start() are not guaranteed before synced variable changes: firing OnVariableChanged before Start() can breaks Udons that implementing initialization at Start() . This bug seems the reoccurrence of following this Canny: https://feedback.vrchat.com/udon/p/1259-synced-variables-can-be-changed-from-owners-requestserialization-before-lat Build: 1539 ---- I've made the new testing world to check event orders: https://vrchat.com/home/world/wrld_c357c8f1-1d22-4e91-bfdc-e72c04097fe1/info . (Sample screenshot is attached below) Reproduction steps: Make the instance of the world (Player A), join the instance then enable interval sync from "Toggle Sync Interval" buton. (It starts 0.25s interval of synced int increment using manual sync) Join another player to its instance (Player B). See the console UI in the world at Player B. Expected Results: At Player B console UI, "SyncInt change" console message should only be occured before "OnEnable". Actual Results: At Player B console UI, there is small chance to occur "SyncInt change" console message before "OnEnable". - It may sometimes not be occurred, so try re-joining several times.

The current iteration of prints is fun, but extremely disruptive to events that are being held. I'd like to see the option to mark a zone via a component or something similar to a collider to prevent prints from being brought in or printed in the zone. Something to prevent print spam in specific areas. Once again, I think these are fun, but world creators need to have options to prevent people from just tossing them everywhere.

The ability for worlds to have sub-instances to save on performance at the cost of a loading screen. Basically a portal or Udon function pointing to another world ID that creates a child instance, kinda like a linked list. Moving to a child instance should of course have a prompt to avoid world creators using it as a void dimension for people they dislike. (maybe even add a button to return to the parent instance) Rec Room has had a similar feature for a while, it allows for larger worlds without needing to fit everything in one scene. (especially useful for RAM-limited headsets like Quest)

Checking the equality/inequality of a system-defined enum with equality/inequality operators ( == / != ) will fail. As a result, this example codes in the document don't work as expected: https://creators.vrchat.com/platforms/android/android-best-practices/#2-detect-mobile-players-in-your-world-automatically public override void OnInputMethodChanged(VRCInputMethod inputMethod) { if (inputMethod == VRCInputMethod.Touch) { // Run code for touch input } else { // Run code for non-touch input } } (The UdonGraph version (attached image) also has an identical issue.) Workaround Cast to underlying values and compare them. if ((int)inputMethod == (int)VRCInputMethod.Touch) Analysis UdonSharp compiles the expression inputMethod == VRCInputMethod.Touch into EXTERN, "SystemObject.__Equals__SystemObject__SystemBoolean" Although Object.Equals(Object) is overridden by Enum.Equals(Object) , which the inputMethod may have, with comparing underlying value, this EXTERN seems to call the Object.Equals directly (maybe via reflection API), and it returns the unexpected result (by only comparing the referencing instances). The EXTERN, "SystemObject.__Equals__ comes from here https://github.com/vrchat-community/UdonSharp/blob/22307065bd408dfd163fe46b0b8b701a4efcbc00/Packages/com.vrchat.UdonSharp/Editor/Compiler/Binder/BoundNodes/BoundInvocationExpression.cs#L420 And replacing the System_Object of this line with System_Enum doesn't work because the Enum.Equals is not exposed. Suggestions Temporary, rewrite the example codes using cast operator Expose System.Enum.Equals And replace the EXTERN with System.Enum.Equals

If you have an object with an UdonBehaviour on it that is disabled in the scene by default, the first time you enable it during play it is visible for one frame before OnEnable() runs on it, causing (for example) visual glitches if OnEnable() is used for setting up how it looks (spawned projectiles .. ) Disabling and enabling the object a second time does not have this issue. This can be tested in client sim by creating a simple script that disables a child object in OnEnable(), and enables it in OnDisable(). Disable the main object then run, then hit pause, and enable the main object while paused, you will notice the first time you do it, the child object is visible. In Monobehaviour (or sebsequent enablings) OnEnable() runs instantly even when paused. Update() does not run on this frame (and it shouldn't) This also effects instantiated objects. fix: Run OnEnable() the instant the object is enabled, even the first time.

My Avatar Pedestals were not working and it was missing items under "Interaction" field. Upon checking SDK's InteractToggle.cs and the Udon assembly, i realized the "Interact" in the script getting changed into lowercase "ınteract" in assembly, resulting with a non English character "ı", and thus not working as intended. This issue affects every script that uses capital i (I) character as a modifier when operating system is set to Turkish. I hope VRC team can make changes on how Udon creates assembly, so it can copy the names of modifiers without changing formatting and use 1 to 1 from C# scripts.

This used to be not an issue before, but now if you have a Non-trigger Collider (set to a Unity or Custom layer, excluding the Walkthrough layer since it already does what it is supposed to do but that's beside the point) that is set to exclude the Player/PlayerLocal layer, the player will still "collide" with it and be able to "walk" on top of the collider's surface while slowly descending as if they were using a flying avatar. They'll still be able to go through the collider, but the problem here is that they can stand on top of the collider when they shouldn't be.