What's safe to do from Monobehaviour OnX event methods.

Is it run on a fixed interval or varying interval (once per frame)? Is it more like Update or FixedUpdate?

Is it best practice to modify some state from these events (Implementing some form of your own MVC?) and then apply those changes to objects on the next Update or FixedUpdate call? With this in mind do the OnX events happen before the next Update call for the frame (Or the next FixedUpdate call for the interval)? Or would your updates end up happening on the next frame?

Update:

But I think OnX happens every frame, not every fixed physics step.

And the Unity docs also say that you should only manipulate rigid bodies from FixedUpdate during each physics step.

So I think its not correct to modify rigidbodies from OnX this makes OnCollisionX pretty hard to use.

The OnX events are just that; events. They happen once when their corresponding event happens. They can be used just as normal methods in your code, the only difference is that you’re not the one calling them, instead the Unity Engine is. Because of this, there is no need to apply any change made in them in Update, as the changes are already made in the OnX method.

I have not done research on if these can be fired both before and after Update, could be either; could be both. However, I can say any changes made there will take effect immediately when it’s run, because, again, they’re just normal methods in your code.

This system is sort of like events for C#, except Unity does reflection to figure out which classes have the methods, so there is no need to explicitly register to those events.

EDIT: It seems the question was really about rigidbodies and physics.

The docs will tell you:

OnCollisionStay is called once per frame for every collider/rigidbody the collision happens.

OnCollisionEnter and OnCollisionExit are called once on the first and last frame of the collision respectively.

It is ‘safe’ to apply forces to a rigidbody whenever, at least in the sense that it will not break anything codewise. The only reason Unity says to apply forces in FixedUpdate is because any number of frames (with each applying that force) might pass before the next call to FixedUpdate, thus producing unpredictable results in behavior.

The only reason I could think of applying forces to a rigidbody during collision is to either slow it down or speed it up before it hits or leaves; which can be done in OnCollisionEnter or Exit, respectively. PhysX does the rest.

I’ve always considered any OnX methods to be about game logic, not about physics or networking or whatever else there is an OnX method for. OnCollisionStay is more of a conveniance method for any game logic that needs to happen while two objects are colliding. It could easily be replaced by maintaining a bool for each meaningful collision and their state in OnCollisionEnter and Exit.