Do I really need to stop Void Update or are collider interactions the Culprit?! I’m Stopping Void Update Too!!

If you’ve been following along, you may know about how I have (or had) trouble stopping movement methods once executed in void update.

By its nature, the method runs any and everything called within it once per frame which will typically average at 60 calls per method in a second, so void update is actually needed for movement methods. In my Space Shooter project, I was able to stop the Boss in its prior phases by making use of Enum States and stopping all coroutines within them.

Unfortunately, in my boiler room project the box can still indeed move after it reaches its end destination. This typically happens once the thinner cans are slotted into their socket interactors.

It may have to do with some obscure collider interactions and/or the box’s movement being dependent on bool variables.

Unfortunately, I can’t demonstrate this in every instance because I can actually get a varied result every time. The details there though don’t exactly matter. The objective is stopping void update at a certain point, or is it?

Let’s see what I have going on in my particular case:

This would be part of the “Move” script attached to the box and this Coroutine is called in an Enum State in void update. First off, being void update causes the object to ‘fight’ with itself especially in ‘if/else’ statements in my experience, it may serve me to simply JUST have an ‘if’ statement here.

Turning the thinner cans on is important but we need to place that event in the next subsequent Enum State.

You see that last ‘if’ statement? I don’t think it’s necessary and neither is the bool variable.

The Coroutine already moves the box. This Enum state gets called when a certain object touches the box in the OnTriggerEnter method.

While the box stopped once it reached its end point, slotting the thinner cans in caused it to move again.

The next few hours would be dedicated to getting to the bottom of this, which I finally did.

Slotting the 2nd, or shall I say ‘right’ thinner can into its socket interactor turns the “Child Collider” objects on.

These are the objects used for the gun gaze interactor.

While I don’t know the specifics, having multiple colliders in one area without physics layer collision restrictions can cause things to get.. kerfluffled. The fact my box would shift to the right at the same speed it used to get to its end point may have something to do with the fact that the box colliders have ‘IsTrigger’ checked.

Resolved by assigning Layer tags and disabling their interactions in Layer Collision Matrix.

And while void update can still generate endless debug.logs, the box ultimately stays in place now.

However, let’s stop void update when the box reaches its end point too!

My research showed that the highlighted command will only kill void update. And it checks out because I tested it multiple times and:

I only got one Debug.Log everytime.

The script still has other public methods which are called after this point. They still work because they’re not a part of void update.