Okay, so probably the problem here is that I don’t understand the basics. I have a ground and walls set as a static physics type with actor and box type collision bounds applied. As for my character, I don’t know what physics to use in order to properly interact with the environment. I have some near sensors set to look for my character’s armature, so I want my armature to be an actor. I don’t know whether it is more proper to set my physics to my character’s mesh or armature, or both though. Any physics I add to my mesh doesn’t seem to make any influence. Character physics on the armature, I fell halfway through the floor, and stuck there without being able to move. Dynamic physics on the armature I fell halfway through the floor, maintaining control of me model, but was able to walk through walls. Are there some basic presets I should be using? Thanks.
-
The ground and walls should be static, as you have them, but they don’t need a collision bounds type specifically set, as they’ll default to triangle-mesh collision bounds type. It might be that your walls and floor are individual objects, in which case Box collision is alright, though you probably would still rather go with triangle-mesh for the collision bounds (or just de-tick the collision bounds box).
-
Neither the armature, nor the animated mesh should be used for collision / physics. Generally, you should parent the mesh to your armature, as you probably have it, but also parent the armature to a collision bounds object (the actual player), which would be invisible. You would control the collision box, and update and animate the armature as you need it.
-
The collision bounds object (the player) should probably be set to Convex Hull or one of the simple collision modes (box, sphere, etc) as you need it.
Do a search for Monster’s Character tutorial, or wait he’ll probally make it here in about 6 Post.
Edit- Or Solar Lune, heed his good words ^^^^
But first I would say do not have physics on your mesh and armature at the same time. Two objects with physics enabled should not occupy the same space at the same time.
And using a simpler volume that encompasses your mesh and armature is a common practice with predictable results. Just make sure your mesh and armature have no collision enabled.
i used a lot directly the armature instead the box collision, but as design , is better the box .
this way you can keep separate things logic to things graphic .
see this blend , there have a basic char , plus some experiment with physics , that seem promising 
anyway :
you need to 3 obj
mesh box (actor[V] , dynamic (no rigid body) , collision box (or sphere)…box is more easy to setup, but spere is a bit better)
armature -> no collision
mesh character -> no collision
ground -> static , triangle mesh
the flag “actor” put only on the character , basically .
this way you can use near and radar sensor without put the property (but the obj with “actor” have to be few)
PS: the gravity seem low since the character is giant , not change gravity . put instead right size for obj
Attachments
basicChar.blend (192 KB)
anyway using brick to make movement is pretty ugly , (the blend above is done only with brick)
to make jump, also using force , no way , the velocity on other axis change (wrongly).
plus , the character pysics , not have velocity ?
Why should using logic bricks be ugly?
I think using logic bricks is very beautiful and flexible. I really prefer to see what keys the logic is listening to rather then hiding key press in a piece of code. Especially as in most cases the documentation is hidden as well ;).
Finally the real beauty comes from the right mixture of logic bricks and custom code.
i mean , when you put a variable , for example , on linear velocity to make a jump , want add velocity only on Z axis -> [0.0 0.0 10.0]
but it is read as -> X=reset, Y=reset , Z=10.0
strange thing seem happen also using force (but not sure 100% … not should be)
PS: i also prefer see a blend done with brick anyway . (unless the code is short and written very well… python only for my blend 
)
for that i done it withy bricks
If I am understanding your complaint, you are saying that when linear velocity is called to provide lift on the z axis it resets and nullifies x and y motion. This is true and can be what you want sometimes. But what about adding a State that now adds lift on the z axis without negating x or y velocity.
Logic bricks are fantastic when the user grasp the whole concept and flexibility. I wish there was intent on adding more logic bricks that open the BGE up farther to the artist.
In 2.66 the motion actuator has a Character Motion type, which has jump. It handles things like checking if the character is on the ground. For characters, I’d recommend using a capsule physics shape with the character physics type.
Just went into the test build to play with the updated character phsyics. Yeah man, the jump inplementation is sweet and painless. you guys are doing great work for all us thankful and thankless Blender abusers.