It seems making basic First Person Shooter movement is nearly impossible in bullet physics.
Force cannot be used, because there are friction problems in bullet (slides in wrong direction).
DLoc cannot be used, because it is extremely easy for DLoc movement to pass through collision enabled faces, and players walking through walls is something I do not want.
Linear Velocity cannot be used because gravity stops when the player starts moving with LinV.
The main problem is the Force. I would love to use Bullet in my game, but until such a basic issue like friction is fixed, it seems useless.
Perhaps I am just missing something? Is there some strange hidden setting like “Screw Up Friction” that is enabled? Let me know if I am just being a n00b and don’t get something.
I’d rather like it if there were better character physics incorporated, but since there aren’t, I had to improvise.
Essentially, I used a script that got the velocity and rotation, and when the player pressed a button (say, fwd) it would take the rotation of the character, multiply the appropriate global vector by the speed, plug that into global linV, and then add gravity. Thus, all motion is handled by one script and one global LinV actuator. it works fine, except for the ground detection; I still haven’t found a reliable method for this (I’m using a ray currently, but ledges and slopes defeat this).
Thanks for the help. It’s too bad that doing such a seemingly simple thing that we all take for granted is so much more difficult then it should be. The problem with slopes and ledges sounds like a big problem for my game.
I’m leaning towards using sumo, but I love the uh… not character physics part of bullet.
if you’re willing to put a little extra work into your level making, and keep the player off of objects that can roll, there are better methods of floor detection, but all the methods I know of have the same problems in both sumo and bullet (they’re logic issues, not physics)
for more reliable ground detection, separate all floors, give them the property ‘floor’, and use a collision sensor on the player. This only has problems with objects that roll (think dynamic boxes) because the whole object would have to have this property and if the player was touching the side of the object, it would trigger the floor sensing.
also, as far as I know, in the newer versions of blender sumo is nearly unusable, so you’d have to step back a few versions. I have less than fond memories of my characters popping through floors at random moments (there were pretty bad bounds issues, I believe), so I’m sticking to bullet, thank you very much. I still appreciate the work done on sumo though- I’m hard pressed to make a 2d physics engine with pre-made functions, making a 3d one from scratch is just mind boggling for me. but that’s unrelated to this thread, so I’ll cut myself off here.
Steering in air?? You mean as far as turning while in air, or do you mean actually steering??
If your talking about Steering in air I have a sloution. Jump off the roof of your house and turn around and guide yourself through the bottom floor window…
when you do, the code for it will go into your mind automatically…
Use Dloc, but use a ray sensor that goes in front and behind the player, when the ray sensor hits a wall, slow down his movement significantly.
Since you can’t really go through walls when using Dloc on a really slow speed, and you’d only be able to move fast when the ray sensors don’t hit the wall, you should be fine. It works for me.
Thanks for the help. It’s too bad that doing such a seemingly simple thing that we all take for granted is so much more difficult then it should be. The problem with slopes and ledges sounds like a big problem for my game.