Consistent AddForce distance/direction

I am trying to make a Boost Pad that launches the player to a specific spot every time, but no matter what I try, I can’t eliminate the inertia/direction in which the player hits the pad, which sends him in all kinds of random directions.

I searched all over the web trying to find an answer, but none of the suggestions work.

Here is what I have in the Player Controllers FixedUpdate():

movementLocked = true; // controls will only function when this is false (proved working)
rb.rotation = Quaternion.identity;
rb.velocity =;
rb.angularVelocity =;
rb.AddForce(boostPadCollider.transform.forward * boostPadSpeed, ForceMode.Acceleration);

I applied these commands to a hotkey and it stops the ball dead when I hit it. so should be working.

Somebody on the forum suggested using rb.velocity instead, but the same thing. I also tried things like toggling rb.isKinematic or freezing the rigidbody before the jump, but nothing I try seems to make any difference.

I am at a loss, so here is my first ever question on this site.

Why am I still able to control distance/swerve by how fast & what angle I approach the pad?

Is there a required factor like Gravity, Weight, Mass, Drag or Framerate that I’m missing? Is there a workaround?

Your boost pad has a collider, right? I’m pretty sure that what’s happening is that your ball has it’s direction changed by hitting the pad’s collider. If it’s a mesh collider, then you’ll be seeing very different results depending on if you come out in the middle of the pad, or hit one of the sides.

Even if the boost pad is a trigger, you could still be hitting the low wall behind the pad. Depending on your speed, you’ll be closer to or further away from that on the frame where you start boosting, which means that your sphere will hit it in a different way.

The quick and dirty solutions are:

  • Prevent the ball from hitting any of those by turning off collisions between the ball and the pad and edge with Physics.IgnoreCollision
  • Give the ball enough vertical momentum to not hit the pad or walls
  • Move the ball to the end of the pad, and then launch it

All three might work, but I think it’s still suboptimal to use physics for what you’re doing here. You seem to want to move the ball consistently - ie. every time you hit the pad, you land on the same spot. In that case, you should disable the physics on the ball (kinematic rigidbody), define the flight path, and move the ball along that until it’s at it’s target. The best way to define the flight path is probably with an Animation curve - post a comment if you haven’t worked with those to define paths before.

It appears I have solved it, and it was a silly mistake on my part.

Although I stopped further input, I forgot to zero the input var, so the main movement AddForce was still acting upon the last recorded input value.

Baste: I feel like I should have accepted your answer based on what better helps future readers, but really, the answer should be the true answer.

Future readers: Some valid points were brought up by Baste’s answer, and any one of them could have been the problem, so if you aren’t as stupid as me, you may be better off looking there. :slight_smile: