- Home /
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 = Vector3.zero;
rb.angularVelocity = Vector3.zero;
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?
Answer by RabidCabbage · May 16, 2015 at 02:42 PM
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. :)
Answer by Baste · May 16, 2015 at 01:20 PM
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.
Thank you for your response. I had suspected there would be a way to do it with a path, but haven't looked into that yet. I will try all the "physics" things you have suggested and return with my findings, but if you have any pointers for an anim curve noob, they will be greatly appreciated, though if adequate training material exists anywhere, I will find it :)
again, Thanks!
First, I removed the ramp completely, raising the collider's position & aim. that didn't work, then I made the ball teleport 10 units above the collider before the force was applied, again, no change. then I switched out the AddForce
for the Velocity
method:
rb.velocity = boostPadCollider.transform.forward * boostPadSpeed;
still it retains the collider entrance inertia.
So it was solved (explanation in accepted answer)
Thanks for your valuable feedback, it highlighted other things I hadn't considered.
Edit: Upvoted :)