koobas.hobune.stream
addforce seems inconsistant
new user here. I've been working on the game mechanics for a simple 2d platformer, not unlike super mario. Anyway, I've been using addforce as a way to launch my char(a simple rigidbody cube) into the air when the jump button is pressed.
The problem: if the char is standing on a single platform(collider), then addforce propells the char a certain number of units into the air(as expected), however, if the char is resting on multiple platforms(half on this, half on that) then the same addforce code has a diminished effect(char is propelled considerably less)
The question: is this normal behavior or some overlooked problem with the physics engine? Is there a workaround? Has anyone else noticed this behavior?
The behavior is simple to reproduce. Simply create 2 cubes and scale them long in the x axis. Now place them next to each other on the x axis at equal height. Now we have 2 platforms adjacent to each other. Place a third cube(char cube) ontop of the platforms and add a rigidbody for physics. Now apply an addforce in the vector3.up direction using a power of 300 and note the altitude of the jump. Try this experiment while touching both platforms and while touching only one. When I do this, there is a significant difference in the altitude of the jump.
Any thoughts?
This should be an example to all new members. This guy is new and yet he asks a near perfect question ins$$anonymous$$d of just "y no wrok?", while having a original question +1 for that my man. Good luck.
I was having this problem. I was processing all related button presses and calculations in FixedUpdate. Simply moving all the input collection and value processes into Update and triggering the force application from FixedUpdate fixed the problem. It was very simple just to have a Boolean activate once ready to apply forces.
Example:
UPDATE
Get button press
Calculate values
Set boolean (applyForce) to true.
FIXEDUPDATE
If boolean (applyForce == true) rb.addforce
Set boolean (applyForce) to false.
Pretty simple. Just put the actual physics stuff in FixedUpdate and calculate everything else in Update and apply Time.deltaTime to the things applying physics over several frames (i.e. not impulse but force).
I don't know exactly what is causing this, but I suspect you will have best results setting the rigidbody.velocity instead - something like this:
if (Input.GetButtonDown("Jump")){
rigidbody.velocity.y = jumpSpeed;
}
The results are way more predictable - AddForce is affected by the rigidbody mass, the previous velocity and the time during which the force is applied.
Also do the jump in Update, not in FixedUpdate - Input.GetButtonDown may return true in two or more FixedUpdates if the frame rate is below 50 fps (the default physics rate), with could double or even triple the jumping speed.
I'll give setting the velocity a try, thx.
Yeah, I've already discovered that grabbing inputs inside fixedupdate is a bad idea. Thoug theh docs say addforce should be applied there. I got around that by grabbing my input in update, and applying the force in fixedupdate, while at the same time only allowing a single jump until the last one has been executed. This gives me reliable results, except while standing on two platforms. (Which I still don't understand.)
Also new to Unity and am experiencing the same problem. Did you every discover what was happening?
That's happening with me too. $$anonymous$$oved all the inputs to update(). Previously they were inside fixedUpdate and were making AddForce unpredictable and inconsistent. $$anonymous$$oving inputs like GetAxis to update solved the issue.
All code write in FixedUpdate and AddForce forceMode.Force the result will be accurate
