Hi all!

Another odd question:

I was playing with the motion actuator and started to use the ‘add’ button on the actuator (next to the L). This is great as it allows two or more linear velocities to be mixed together. I’m using this on a ship that can be blown sideways even when moving forward.

Now, I cannot for the life of me find a Python equivalent! In the attached file both green and red cubes are controlled by the same keys (UP and RIGHT cursor). If you press both keys together the green (logic driven) works fine- however, the Python version does not. Is there a secret Python syntax (like AddVelocity?). And why does the green logic cube move faster even though its set to a lower velocity (0.3 compared to 1 on the red cube).

Any input (as always) would be gratefully appreciated.

Paul

### Attachments

Linear.blend (378 KB)

in your blend , you have first to choose the true pulse on the keyboard sensors.

i never can understand how work this impulse … probably the design is make to work in a certain way for the brick
but python not respond well.

for that is ever better put an the best friends of python , the always sensors true, in all cases .
this solve half issue.

the second issue, is add a value to a pre existent value of linear velocity

you can make in this way :

``````

if key :

x,y,z = ow.getLinearVelocity()
ow.setLinearVelocity([0.0, y+0.3, 0.0], True)

``````

which is pretty ugly

or more easy:

``````

if key :

ow.localLinearVelocity[1] += 0.3

``````

Is not sure if this is what you wanted or not but:

### Attachments

Linear.blend (482 KB)

for some reason work better than one friction applied direcctly to the linearVelocity, but!

there something of wrong, if there some collision?? the speed (own[yspeed]) continue to increase… of course

this make a kind of “teletrasporting” (as dLoc)

try to use it in a climb and see…

I’ve usually gone with the getLinearVelocity() route to add velocities together, though for the ‘teleporting’ problem that MarcoIT brings up, you could possibly try getVelocity() instead, as this would probably return the actual movement velocity of the object, not the velocity that it’s moving with. Just an idea.

what have localLinearVelocity which is not good?

to me seem good, also, you can use only one axis instead of set all 3 all time(as setLinearVelocity())

According to the API :

getVelocity(Vector) returns the current velocity at a specific point relative to the game object. It combines the linear (forward motion) and angular (rotational motion) to calculate the motion vector.
If the game object tumbles each point in the object space would have a different velocity vector (e.g. outer points are travelling faster than points closer to the center).
Hint: the point does not needs to be on the surface of the object.

Anyway: getVelocity() returns getLinearVelocity() as at the center the rotation has no effect on the velocity.

Edit:

The “Add” button of the motion actuator switches from “replace the current velocity” to “add the current velocity”.
As Marco suggested you can simply add two vectors.

One vector is the current velocity
One vector is the velocity you wish to add

``````

``````

May I ask why you need to fake actuator behavior with Python?

Thanks for the great replies, everyone!

Marco> Nice stuff, learned some more Python! I guess chicken soup and Python are good for the flu

CrazedQuetzal> Thanks for that, but its not quite what I was after. Will still pick it apart though, always good for learning!

SolarLune> Interesting!

Monster> Makes sense adding the two vectors. I never realised how much the logic blocks do ‘under the hood’.

I’m currently going through a mid-life crisis as far as Blender is concerned. Now that I know the basics of Python, I am falling into the trap of doing everything possible in Python which is really a mistake. I suppose the logic blocks and Python should be seen as each side of the same coin working together, but its tempting to just have a script do it all.

Regardless if you choose Python or logic bricks you should keep separate tasks separate. Otherwise you easily get hard to manage logic (because of its complexity).

See the Python controller as customized Logic Brick. It perfectly fits into the structure of the other Logic bricks. If you keep your Logic Brick simple you can use it at other places without the need to create a new one.

I’m often falling in another trap: complex solutions.

Some things are quite easy to achieve. But you need to know how. Even if it obvious sometimes the easy solution is hidden by a complex idea in my mind ;).

Example:
At my BGE beginnings I was going to let a character work from A to B. Just a straight line.
So I started to calculate angles and distances … ending with a really messy code.

Some one posted here … use a trackTo and move forward - thats it.

Simple as it sounds I didn’t saw it that time.

So my recommendation: Only mix what you can’t achieve otherwise.