cont = bge.logic.getCurrentController()
own = cont.owner
W = bge.logic.KX_INPUT_ACTIVE == keyboard.events[bge.events.WKEY]
A = bge.logic.KX_INPUT_ACTIVE == keyboard.events[bge.events.AKEY]
S = bge.logic.KX_INPUT_ACTIVE == keyboard.events[bge.events.SKEY]
D = bge.logic.KX_INPUT_ACTIVE == keyboard.events[bge.events.DKEY]
-defined bge.logic.keyboard
-fixed typos (applyMovment changed to applyMovement)
-indents (they were not correct) (make sure your copy-pasta code is properly formatted )
-changed hard-coded movement values to globals for easy tweaking
-changed from script mode to module mode (since you have it all set up in a method already)
What’s the difference between a python script and a python module?
Do you happen to know why the cube does not rest on the surface, when you play it, the cube jumps up for some reason idk why.
So I should be able to add some linear velocity to this right? Or would using a force value instead be better. I was playing with your script and I can get it to move pretty much how I like i I play with the mass, but it did not really stop moving so well when say W and S were pressed at the same time or A and D.
What’s the difference between a python script and a python module?
A script is the file that you’re currently running. a Module is an external script which is imported (for example, bge is a module). In the big picture, there’s really no difference between the two (if you dig into it, you’ll find a bge.py which is a python script), except for how they are implemented. You can think of the ‘script’ as the active functional code, with the ‘modules’ being outside tools/resources you can call in if/when you need them.
If you’re asking what’s the difference between ‘script’ mode and ‘module’ mode for the logic Controller brick, it is all in how you want the controller to be, controlling, the script.
If we have this script, we’ll call foo.py (because everybody uses foo-bar to do python demonstrations for some reason I don’t understand):
#foo.py
x = 3
y = 'bunny'
print(x,y)
def bar():
a = x + 10
b = y + "foofoo"
print(a,b)
If you run this script in script mode, you should get the output “3 bunny”. If you run it in module mode with foo.bar in the text field, you will get the output of “13 bunnyfoofoo”.
In script mode, it’s just running the first few lines and not bothering with anything under ‘def bar()’. In module mode, it’s running everything under ‘bar()’ (using foo.py as the module), and using the x and y values above it as global variables (if that’s proper pythonese?)
Do you happen to know why the cube does not rest on the surface, when you play it, the cube jumps up for some reason idk why.
Collision detection is not perfect (there is always going to be a small ‘buffer space’ between your object and its colliding surface). Try making the collision margin for your cube slightly larger than that of the surface (ie surface margin of 0.04, cube margin of 0.06). Make sure both objects are set to ‘triangle mesh’ collision bounds for the best (but more expensive) collision detections. Sometimes this just takes tweaking. Sometimes increasing physics sub-steps (found under the World properties tab) helps with these things too.
So I should be able to add some linear velocity to this right? Or would using a force value instead be better. I was playing with your script and I can get it to move pretty much how I like i I play with the mass, but it did not really stop moving so well when say W and S were pressed at the same time or A and D.
Force and linear velocity are two sides of the same coin. Applying force to an object will change its linear velocity. Setting an object’s linear velocity is the application of force.
The difference between the two in applicable terms is that linearVelocity can be set (ie you can bring an object to a dead stop by calling like own.localLinearVelocity *= 0 ), like a throttle on a car. Or you can set one axis of motion (like own.localLinearVelocity.z *= 1.1).
Applying force takes into account things like gravity and mass (applying equal force to a low-mass object will move it ‘more’ than a high-mass object…it takes more force to push something upward under high gravity than it does low…etc etc), like wind pushing a sailing ship. If you want to bring something to a stop with applyForce, you would get the Vector of linearVelocity and apply that as negative force.
Thanks Nines! That’s super crazy helpful information to me!
One thing left
I did what you told me about the collision and it gets to the ground but is constantly jiggling up and down. Another interesting thing I saw while the collider was set to a box was that the collider box was below the mesh itself for… some reason. I discovered that by moving the cube down in edit mode I could get it in the same place as to collider. But why do I need to do that, seems problematic…
Should not the collider appear in line with the mesh???
If you’re using the box collision model (or sphere/cylinder/capsule/etc), it takes its origin from the origin point of your object.
If you want the box collision to line up with the box, the origin of the box needs to be in the box’s center.
(with triangle mesh and convex hull collisions, collision data is taken from the mesh so origin does not need to be taken into account)
The cube on the left has its origin at its center (the default when you create an object). The one on the right has its origin shifted to the center of its bottom face. (the yellow dots are origin points, they are important!). Both cubes have box collision enabled.
As a good rule of thumb (or unless you have a reason to do otherwise), you want to keep the origin of an object at the object’s center. Especially if you’re using physics objects. Try making a rigid body cube with its origin way off center and see the whacky results.
(a quick example of an exception would be if you had a static/no collision cube and you wanted it to neatly sit on top of another surface, you can use the cube on the right and just set its position and not have to take into consideration the height of the cube)
You can select your object(s), shift+ctrl+alt+c, and select Origin to Geometry, to quickly get everything neatly snapped back into place.
If you’re in Object mode, you manipulate objects by their origin points. That is, move an object in object mode, and you’re moving its origin. While in edit mode, you’re manipulating the object’s verts/edges/faces relative to their origin. That is, move an object in edit mode, and the origin point stays still.
I found someone’s else classic Sonic fangame in Blender game engine and it seems creator stopped supporting this project. And I want to know how to make this classic sonic 3d character move in 4 directions,spin jumping,spin dashing and even gravity mechanics similar to Super Mario Galaxy.
)