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.

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)

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.

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.

When using a Spatial Audio Source component on an audio source, using "PlayOneShot" will occasionally ignore the max distance set for the component, sometimes playing the whole clip while other times cutting off the clip after playing really quickly. I'm personally using this for collision audio for physics objects, so randomly hearing blocks clanking together from across the map is rather obnoxious. I've set up a quick demo for this, simply chuck the objects as far as you can and they'll occasionally make sounds despite being far out of it's max range. https://vrchat.com/i/yahoo-yuniquehorse-88b85

If I want to pass a parameter to custom event receiver, even now, I could it by using public program variable and executing SetProgramVariable before SendCustomEvent. Comparing that, for example, OnCollisionEnter event uses implicitly defined variable "onCollisionEnterOther". 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.

We're working on a new character controller for VRChat worlds. It works mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going up stairs 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 controler. ... And more! This feature is still in development and subject to change.