Question Handling physics updates in Coroutine

Up until this point what I've been doing is yield return CoroutineUtility.WaitForFixedUpdate and then doing whatever I need to do. This has been fine until I just came across something unexpected and it had me rethinking the approach.

I have a situation where in OnCollisionEnter I pass the collision as a parameter to a coroutine in order to handle some things. Where I noticed the issue is sometimes this would happen:

Code (CSharp):

1. IEnumerator MyCoroutine(Collider2D collisionDetails)
2. {
3.    yield return CoroutineUtility.WaitForFixedUpdate;
4.    var magnitude = collisionDetails.rigidbody.velocity.magnitude
5. }

I get a null reference exception because the collisionDetails is now a completely different collision object since fixedupdate has run again before accessing the variable. I can easily solve this by caching the values I need before waiting etc., but what if I need to add velocity or something to that rigidbody before the next fixed update?

So I guess I have 3 questions:

1. Is it safe to handle physics updates right in the OnCollision methods?
2. Is it safe to handle the physics immediately in the coroutine before the fixedupdate waiting, or is there no guarantee it will start immediately when I invoke it?
3. Would the best scenario be to just wrap my physics adjustments in an action and put it in a queue to be processed inside FixedUpdate so I can guarantee it runs at the beginning of the next FixedUpdate?

I also have some event listeners that need to be in coroutines because they temporarily ignore collision, wait a set amount of time, and reactivate the collision. I'm currently handling that by:

1. Event handler triggered
2. Wait for Fixed Update
3. Ignore Collision
4. Wait for seconds
5. Wait for Fixed Updated
6. Reactivate Collision

 

Yeah I came to that conclusion about the reuse once I saw the reference was updated in place.

My post was more to get some clarity on the 3 questions I outlined.

1. Can I make physics updates inside OnCollisionxxx?
2. If instead I pass the data onto a coroutine will it start immediately in succession or does Unity decide when to invoke it?
3. Am I better to just queue up physics updates and run them inside the fixedupdate loop instead to guarantee they happen there on the next fixed update since wait for fixed update will actually end up being after the next one instead of before/during?

Thanks

 

Ok, from what I've read it always seems to be stressed that you should only make physics updates inside FixedUpdate.

By "physics updates", yes I mean changing the velocity of a rigidbody, .AddForce, Physics2D.OverlapCircle, Raycast etc.

I have always understood this as do not modify those values/invoke those functions anywhere but inside FixedUpdate, but from what you've written it seems what you are saying is that it doesn't matter where you do these things it's just that modifications won't be applied until the next FixedUpdate.

So regarding the best practice recommendations I've read as stated above, it's more of a question of awareness/predictability regarding your own code as opposed to bugs that could arise within Unity itself from modifying those properties outside the FixedUpdate function. Is that a fair interpretation?

 

Yes fair enough thank you. I think where I'm getting a little tripped up is in my events. When the event listener is invoked, we can't know where in the lifecycle we are, so how best to handle a situation where you have several steps, as opposed to where you have the standard scenario of "have movement variable set in update and apply the value in fixed update".

As an example for context, here is a simple event and how I have handled it:

Code (CSharp):

1. IEnumerator BlockItem()
2. {
3.     var velocity = _rigidBody2d.velocity;
4.     _rigidBody2d.velocity = Vector2.zero;
5.     _rigidBody2d.angularVelocity = 0;
6.     yield return CoroutineUtility.WaitForFixedUpdate;
7.     _rigidBody2d.AddForce(velocity * -.1f, ForceMode2D.Impulse);
8. }

The idea is that the rigidbody has a normal material with bounciness etc. but in this one particular instance I want to override that behaviour, so I:

1. Cache the current velocity in a variable
2. 0 out the current velocity so it doesn't affect things when we add force
   
3. Wait for the fixed update to ensure those values get applied
4. Add the new force to get the desire "bounce" I'm looking for

It works perfectly fine and exactly how I want it to, but with all the talk about doing everything in fixed update it would(seemingly) stand to reason I should queue up that add force call and then fire it in the next fixed update.

However, due to the way the game works I am confident that the rigidbody will not be tampered with before that addforce gets applied, so I'm not really worried about it, which I suppose falls under the "you don't absolutely have to use fixed update if your situation doesn't call for it". This post is more looking to understand best practice in a scenario like this.

I also have noticed you are usually the expert that responds to these posts so I was hoping you would chime in, so thank you.