Udon's FixedUpdate() runs multiple times before any Unity physics simulation is done.
Sacchan
This world measures how many times by adding a force every frame and checking if Rigidbody.GetAccumulatedForce() is larger than one frames worth.
My result with one client is 28-32.
My result with two clients:
Master: 28-150~
Nonmaster: 180-300~
The numbers are going to be much higher in more complicated worlds that take longer to load and have more networked/physics objects.
This is problem for anyone working with physics, because applied forces will add up and cause the object to suddenly spring away with all the accumulated force once the simulation starts actually running.
Personally, it caused the suspension forces on my cars to build up and cause them to shoot in the air and explode.
The number of frames is much greater if two players join a new instance at the same time, leading to confusing problems for developers.
The number of frames seems to be directly related to how long the loading screen is shown for, in the case where two players join a new instance at the same time, the loading screen is shown for much longer.
Solution:
It might actually be quite complicated because this delay way probably added for a good reason.
I don't think it's as simple as not running FixedUpdate() until the delay is over, because Update() etc is also already running.
Maybe delay all Udon activation until this time? There's no way for me to know without knowing VRC's code.
A workaround fix could be to add a PhysicsReady() event for when physics actually activates.
Log In
|KitKat|
Delaying all Udon wouldn't be good, since it would break existing things that rely on Udon running early.
I like the
PhysicsReady()
event idea.