So you can now have a python script do all the motion without needing an extra brick to connect it to, it also should allow for things like properties controlling motion.
Here’s the functions in full form in the pydoc part of the submitted code (functions in bold, you can kind of find how to use them in this code)
@return: The game object’s rotation matrix @note: When using this matrix with Blender.Mathutils.Matrix() types, it will need to be transposed.
“”"
def applyMovement(movement, local = 0):
"""
Sets the game object's movement.
@type movement: 3d vector.
@param movement: movement vector.
@type local: boolean
@param local: - False: you get the "global" movement ie: relative to world orientation (default).
- True: you get the "local" movement ie: relative to object orientation.
"""
def applyRotation(movement, local = 0):
"""
Sets the game object's rotation.
@type rotation: 3d vector.
@param rotation: rotation vector.
@type local: boolean
@param local: - False: you get the "global" rotation ie: relative to world orientation (default).
- True: you get the "local" rotation ie: relative to object orientation.
"""
def applyForce(force, local = 0):
"""
Sets the game object's force.
This requires a dynamic object.
@type force: 3d vector.
@param force: force vector.
@type local: boolean
@param local: - False: you get the "global" force ie: relative to world orientation (default).
- True: you get the "local" force ie: relative to object orientation.
"""
def applyTorque(torque, local = 0): + “”"
Sets the game object's torque.
This requires a dynamic object.
@type torque: 3d vector.
@param torque: torque vector.
@type local: boolean
@param local: - False: you get the "global" torque ie: relative to world orientation (default).
- True: you get the "local" torque ie: relative to object orientation.
"""
def getLinearVelocity(local = 0):
“”"
Gets the game object’s linear velocity.
@@ -143,6 +187,8 @@
This method sets game object’s velocity through it’s centre of mass,
ie no angular velocity component.
This requires a dynamic object.
@type velocity: 3d vector.
@param velocity: linear velocity vector.
@type local: boolean
@@ -163,6 +209,8 @@
“”"
Sets the game object’s angular velocity.
You don’t need a motion actuator though . Also, the linear and angular velocity ones have been there. In fact, those four functions are already in 2.48 . Here is some example code:
#--The following code is equivalent to having a motion actuator
#--with the force set to 10 on the local y axis.
obj = GameLogic.getCurrentController().getOwner()
obj.applyForce([0, 10, 0], 1)
I’ll still be using applyImpulse (teh same as applyForce, I believe, even though in physics impulse and force are slightly different)- you get much more control over what happens, and it’s been around for forever. I stopped using motion actuators almost completely several versions ago…
I don’t want to undermine the utility of these new API functions but you have to keep in mind that you must call them on every frame if you want to do the same as the motion actuator: the velocity, force, torke, displacement and rotation are only valid for one frame.
The advantage of the motion actuators is that they run at C++ speed, much faster than a python script. In addition the servo motion actuator performs complex calculations that can’t be done so efficiently in python.
Captain Oblivion: applyForce is always applied at the center of mass and does not create rotation while applyImpulse can generate a rotation if the force is not applied at the center of mass.
Heh, that’s amusing, especially when considering that the overall utility of the brick system has been in question for quite some time now.
But anyway…
The advantage of the motion actuators is that they run at C++ speed, much faster than a python script. In addition the servo motion actuator performs complex calculations that can’t be done so efficiently in python.
Well then, this is obviously not the implementation that we have been asking for. We don’t want to do complex calculations in native python, nor do we want the new function set to do that; what we want is simply the ability to assign logic brick functionality (still running compiled C++) directly via python, rather than having to make static/inflexible/restrictive assignments through the logic brick UI.
Just to make it perfectly clear: I love the functionality offered by sensors/actuators -> it’s the way in which that functionality is managed (through the brick UI) that annoys/limits me. Python is a much more versatile tool to manage that functionality.
Even if the first attempts have efficiency/speed issues, this is a welcome change, because controlling complexity and shortening development time are some of the most essential components in game development, and in that sense, anything that can help to further separate us from the convoluted brick juggle is definitely worth the effort.
I still wouldn’t say I support this particular implementation (if what ben said is true; that it’s all python under the hood), but I don’t oppose it either.
but you have to keep in mind that you must call them on every frame if you want to do the same as the motion actuator: the velocity, force, torke, displacement and rotation are only valid for one frame
But this is still useful if otherwise you would need a crudload of motion actuators and now you can just do all of that in a single script.
So you have a single python controllers instead of 10 motion actuators if it ever came to a situation like that.
All of the BGE’s python modules are written in C++ and then exposed to Python. Which means, it isn’t all Python, just the call being made in the script. So, it’s only as slow as the script being run. But ben is right in the fact that it needs to be set every frame. Which, isn’t much different than GameLogic.addActiveActuator().
Once I get some free time, Tuesday-Thursday next week I think, I’ll see if I can refresh my C++ skills and take a look at it. If it seems not to hard I’ll try to allocate some more time. Do you got any examples how you did the part of the clean up that is done? or some kind of guidelines?
. Also, the linear and angular velocity ones have been there. In fact, those four functions are already in 2.48