Feature Request Does a Destroy()ed rigidbody carry out preloaded instructions?

If a GameObject has a rigidbody component, and in FixedUpdate that component has MovePosition() called on it, and then Destroy(), does the MovePosition() take effect before the Destroy()? My understanding is that it does, based on how my system is behaving, but the documentation says only:

"The object obj is destroyed immediately after the current Update loop"

https://docs.unity3d.com/ScriptReference/Object.Destroy.html

It would be helpful if the documentation were clearer on this issue. "Update loop" is ambiguous, isn't it? Or is that term defined somewhere? Does that mean "the current one of FixedUpdate()/Update()/LateUpdate()"? Or "the next Update()"? When I google (Unity "update loop") I get my first hit on the most likely page to have a definition, perhaps:

https://docs.unity3d.com/Manual/ExecutionOrder.html

but it has a definition only of the "Animation Update Loop". This page:

https://gamedevbeginner.com/how-to-destroy-an-object-in-unity/

suggests that "update loop" might mean "the current one of FixedUpdate()/Update()/LateUpdate()", but even if that's the answer, that still leaves open the question of what exactly "after" means. "After" the user code? Or "after" every part of the *Update() set? Or something else?

I realise this won't usually matter much, but I've now met one case, at least, where it does.

Cheers

 

Instead of pondering the nature of undocumented internals, how about measuring? Throw some

Debug.Log()

wherever you think you need to know. If you ever open up the Profiler, you can zoom into the order in which everything flows to a pretty high degree. You will get a better understanding of the overall loop and structure of the Unity engine's master loop.

The only situation I think the life and death of a Rigidbody vs other parts of the master loop might be in collisions. If the Rigidbody dies mid-collision, it will have to invoke OnCollisionExit behaviours. If you muck with a Rigidbody position, it will only transfer the new position to Transform.position at the end of physics processing.

 

@halley - Thanks, but I'm not asking about internal behaviour, I'm asking about how a GameObject moves under the described condition (MovePosition(), then Destroy(), within the same frame). I can debug to determine a particular case, but I presume there is a general rule that determines when components are destroyed, and that's what I'd like to understand - and see documented. When is destruction actually executed, and do components (including rigidbodies) continue to play their normal roles (such as moving GameObjects) right up until that point. I'm guessing the answer to the latter is yes, in which case the question is just exactly when destruction occurs.

I agree that the profiler gives plenty of insight, but I'm not aware of a way to determine when a particular component is destroyed using it, and I'm sure I couldn't determine if MovePosition() had taken effect using it, and in any case I can't see that it would be straightforward to determine a general rule from this approach, given the number of variables.

Presumably there is a simple enough rule, and it would be helpful (to me, at least) to have a statement of it, is all .

 

That's a great presumption.
I'd also presume that it could be dependent on WHEN you call for it to be destroyed (e.g. in Start() vs in OnPreRender()).
So again: Log it. Easiest & quickest way to find out.