i wonder how in BGE, i could move a cube over 17 meters or so.
And then (by python) have an option to do the 17 meters in x seconds,
if i press A and do the same distance in 7 sec ,
or press B and do it in 23 sec
or press C and add 5 sec to some value and get variable time
So the point here to adjust speed not by simple velocity doubling or tripling, but by some math that takes into account the ticks of the bge engine (thinking as 60 ticks p sec ? or is that FPS ticks ??), not sure if ticks are fixed time.
import bge
def main():
cont = bge.logic.getCurrentController()
sens = cont.sensors['Keyboard']
own = cont.owner
distance = 20
time = 1
if sens.positive:
velocity = distance/time
own.localLinearVelocity[0] = velocity
own['timer'] = 0
if own['timer'] >= time:
own.localLinearVelocity[0] = 0
main()
Connect it with a keyboard and an always sensor with TRUE level triggering. It would work better if keyboard sensor has TAP on.
Also add a timer property named “timer”. It will move the object on x-axis for the distance specified in time specified.
The object must not be static.
applyMovement and worldPosition modifications are tick-dependent. Setting the velocity is time dependent. Use obj.worldLinearVelocity (or local, whatever). Determine the velocity as displacement/time
@wisaam
i got that script working but … as you said it wont work with static objects, is there a workaround possible ?.
Because i dont want it to fall down by gravity and neither add extra floor objects.
I need it to be be static and not be troubled by other objects hitting it.
Hi, I made this: http://www.pasteall.org/blend/42300 but I don’t know if it answers your question…
oops the 2 objects share the same material. We see that movement with velocity is not accurate…
import bge
def main():
cont = bge.logic.getCurrentController()
own = cont.owner
Move = cont.sensors['Move']
Rot = cont.sensors['Rot']
End = cont.sensors['End']
if own.parent and own['Spiral']==True:
own.worldPosition.z+=own.parent['Rate']
if End.positive and own.getDistanceTo(End.hitObject)<.1:
own.worldPosition = End.hitObject.worldPosition
own.removeParent()
own['Spiral']=False
if Move.positive:
if not own.parent:
own.worldPosition+=(Move.hitObject.worldOrientation.col[1]*own['Speed'])
if Rot.positive:
if not own.parent:
if own.getDistanceTo(Rot.hitObject)<.1:
own.worldPosition=Rot.hitObject.worldPosition
own.setParent(own.scene.objects[Rot.hitObject['CentralOb']],0,1)
own['Spiral']=True
main()
Wow that thats a complex one,… i’m trying to understand the spirals in it, cause i want to control speed of such a spiral;
without altering the spindle size, or length of the spiral, (so they can go faster or slower).
But first i need to find out how those spirals work
A bit complex wish i was better in this scripting thing… but i learn from this.
Okay, that works, btw lowering the gravity to 2.9 or so made it more realistic not sure why it isnt 9.8 (30Fps ? ea 3x 2.9)
I also made a little bit of progress with my other one, its not easily to config different speeds for it.
But cubes behaves more correct, … not sure yet what i’m going to use (yours is a lot easer to set speed and heigths.
But then i cant make use of slowdown ramps, hmm.
Press A to set speed of the belt (currently spawn object doesnt spawn faster when running in faster mode BELTS.blend (463 KB)
This solution is well basically not the speed control i was after (headline topic), but all physics keeps working.
i edited the gravity value in the script wasnt mentioning worlg gravity (as with my machine they droped verry fast).
I’m still in doubts what i will be using.
belt.blend plus is that the cubes have real physics
plus i can have sliding blocks, think that will be an important item in the game. (a way to queue)
Plus (big one) some variation in speed working now (be it not as i had hoped, but i can have 3 speeds or so assigned to keys).
cons it gets slower with multiple spirals (might make their parts taller).
cons hard to setup, speed, height, rotation; get complex with multiple speeds
bleuprintrandom version plus much easier setup of rotation ends, and heigths.
plus probaply can handle more moving cubes
cons no speed variation (but i think thats possible with it, just rotate cube faster, and some more scripting tweaks.but might be complex as well. cons cubes dont colide to eachother needed to make queues, so no sliding ramp possible.
plus a lot easier to make levels…