World/Udon Bugs & Feature Requests

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

Get what instance type you are in. Public, Friends, Friends+, Invite+, Invite Single node can return string Multiple nodes for each type can return bool

Now that we can sync larger amounts of data, it would be helpful to be able to compress that data to minimize network overhead. However, doing compression in Udon is expensive; I'm sure you already have a zlib binding somewhere that you could expose, which would work much better.

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.

Gravity and Kinematic flags on VRCObjectSync components don't sync correctly right now and also cannot be set correctly while holding the pickup. To set gravity or kinematic flags, VRChat added two new methods for us: https://udonsharp.docs.vrchat.com/vrchat-api/#vrcobjectsync (they are supposed to behave like a synced variable) There are two bugs related to this: ~ Bug 1: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component with an external button after claiming ownership. Then you let different people in the world pick up the pickup and drop it (to show their own local state). In my tests, this resulted in a pickup where the gravity flag is wildly different on each client and only syncs occasionally or not at all. They would see the pickup drop on my end, but when they pick it up it has no gravity for them. ~ Bug 2: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component in OnPickupUseDown() . In my tests, this resulted in a pickup where the gravity stays enabled after the first OnPickupUseDown() and I am unable to turn gravity off again. To check gravity, the pickup is dropped. You can also just test it out here: Right setup: Bug 1 / Left setup: Bug 2 https://vrchat.com/home/world/wrld_9cefd5ec-4492-43c5-8cd3-05036c494556 Additional note: Since we only got a setter and not a getter method, we are left in the dark here when it comes to analyzing the problem. Reading out the local rigidbody state doesn't give us access to the real synced state. A getter method should be added.

Knowing the Photon ID of an UdonBehaviour would allow us to troubleshoot sync between Quest and PC by providing ingame UI displaying the ID of certain scripts. Non-matching Photon IDs is one of the most painful issues when maintaining Quest support, especially since some Quest worlds rely on a different project/hierarchy which can bring Photon IDs out of sync. Networking doesn't work and it's really hard to debug or find out why.

It'd be helpful for world creators to know how many people are entering their world as well as how often users are coming back.

It will be nice to be able to use embedded video clips with the new video player system for things like video textures. Currently (on the open beta build 986) we can only load videos from external servers.

To reproduce: Create a behaviour with ExecutionOrder -100000 Create a child of it with another behaviour with no execution order overrides Create a behaviour with ExecutionOrder -100000 and NO child objects as a control Create a new separate behaviour with ExecutionOrder +100000 Add a log to Start() to keep track of it Expected result: Behaviours with -100000 to log first Behaviours with no override to log second Behaviours with +100000 to log third What actually happens: Behaviours with -100000 and NO children log first Behaviours with no override log second Behaviours with +100000 log third Behaviours with -100000 WITH children log fourth Repro world: https://vrchat.com/home/world/wrld_f43e6a53-97c2-4a6b-88af-60612f4b3cce This also creates another large issue If you also try to disable those -100000 objects (with Default children) via the +100000 Start() method - the -100000 behaviour will enter a broken state where it will never initialize or receive any events no matter what. You can toggle them on and off after - no methods will ever fire I have created a test world that illustrates the above: https://vrchat.com/home/world/wrld_06ab5f32-ffbe-44dd-9930-b3b28074fcfd Checking the logs when loading in - you'll see a bunch of objects logging OnEnable (the ones that report withChild False ), and a bunch of Default objects which are children of other -100000 objects. Then they will all get disabled by the +100000 behaviour. Clicking the sphere enables those -100000 parents, but they never log either Start() or OnEnable