koobas.hobune.stream
Player-controlled rigidbody ball sometimes slowing down for no reason
Hi there,
I've got a rigidbody sphere that is controlled by the player. I've finally perfected the movement, but occasionally (every other minute) the ball is moving slower for 10-20sec and I can't figure out why. I monitor the rigidbody's velocity (not angular) and it drops to maybe 2/3 of the normal speed. That is a huge problem, because a lot of the traps in my game can only be passed with the right timing and full speed. I'm multiplying the applied force by Time.deltaTime. There don't seem to be any framerate issues though, it runs at a constant 60fps. Things/parameters I've experimented with without success:
the sphere's rigidbody parameters (mass, damping, extrapolation, ...)
global physic parameters (max angular velocity, ...)
physics material applied to sphere (friction, bouncyness, ...)
AddForce vs AddTorque (I think I did not see the problem with addTorque, but I can't get the ball rolling fast enough with this method only and maybe it was just a coincidence)
Update() vs FixedUpdate()
Even with a default rigidbody sphere and standard movement script (addforce based on horizontal/vertical input axis) I'm getting this. Has anybody got any idea why this happens? Thanks!
Probably would need a simple demonstration script in order to figure things out. You can hack in a solution by directly manipulating Rigidbody.velocity.
In what direction do you add the force? maybe the direction is changing downwards and therefore decreasing the velocity?
Thanks, I'll try to directly modify the velocity vector. Somehow I always thought that one should not be messed with... :D First tests seem to work, although it is harder to get the perfect controls here (either the acceleration is too fast or too slow). I'll report back.
The force direction does not change, I checked it.
Does the surface has any angle? are the values changing from some reason?
Nope, clean surface and completely random. I think I've fixed it by manually adjusting the velocity vector and limiting it at length 4. I hope it stays that way, because random bugs are evil.
This randomness even extended to the OnTrigger methods that check for collision with the ball. Sometimes they are simply called more frequently than normal (which results in ground traps draining much more damage than intended). $$anonymous$$y workaround is a ray from the ball downwards to check if it is above a ground trap ins$$anonymous$$d of using the triggers. This at least seems to work all the time (and maybe is the better solution anyway).
