Strange order FixedUpdate and OncollisionEnter

In my scene I am logging the motion of objects (ball and baseball bat) in order to replay this after the action. I also log if the ball collides with the bat and log this as a special entry.

Now when I replay the log entry by entry I notice that at the time of contact there are two entries that have the same position of the ball and the bat. One is marked as contact entry, the other is a regular entry. I want to correct this, but there is something I don’t understand.

The strange thing is that the contact entry is logged before the regular entry. The regular entries are logged in FixedUpdate, the contact entry is logged in OnCollisionEnter. According to the execution order (Unity - Manual: Order of execution for event functions), FixedUpdate is called before OnCollisionEnter, so my expectation is that the regular entry would come before the contact entry.

This would make it easy to fix, just change the type of the last created entry. But since the order is the other way around, it will be harder to fix. I can not set a boolean in OnCollisionEnter to prevent creating the entry in FixedUpdate, because it will not be called anymore in this cycle. And it would create a terrible dependency; the logging script is a base class that is used in multiple places, I don’t want to create a dependency to a specific script.

The calls are in separate scripts, but I have not set any preferred script execution order. Could it be that OnCollisionEnter of one script is called before FixedUpdate on another script? Or are all FixedUpdate calls handled before OnCollisionEnter calls in the same cycle?


[Edit] even with a specific script execution order, I set the script that detects the collision to +50, still the contact entry comes before the regular entry.

I think I have this figured out. If you notice in the execution order, FixedUpdate() happens before the internal physics update and OnCollisionXXX is called after the internal physics update. That means that the following happens in sequence:

  1. A physics update happens, causing the objects to come into contact.
  2. OnCollisionEnter() is called.
  3. We loop back around to the next fixed time delta and FixedUpdate() is called again.

Thus, from the time the collision “happens” (in the internal phsyics update), OnCollisionEnter() is actually called before FixedUpdate() even though FixedUpdate() is earlier in the execution loop. It’s the relationship between the two function calls and the internal physics update that matter, not the actual position of the function calls in Unity’s update loop.