Good day
Please tell me how to do that using:
transition.moveTo( Popugay, { x=screenW-50, y=Popugay.y, time=2000, tag="popugay\_move\_pravo" } )
object " Popugay" stopped when collision with static objects?
Popugay physics tape “dinamic”
Without the use of " transition" everything works fine - Popugay stops when colliding with static objects
avdsm ,
set the Popugay physics type as kinematic during the transition.
This is what you are supposed to do when moving objects outside of the physics simulation. Then set it back to “dynamic” when you want physics to resume moving the item.
-Assif
I have the opposite need, that time the movement if the path is a static object that Popugay stopped. Now, although the type of “dinamic”, it without stopping moving over static objects.
I’m unclear what you are trying to do.
Is the transitioning object supposed to stop when it hits something or keep moving?
Note: Combining physics and transitions is not a normal practice because the transition system and physics system are ignorant of each other.
Physics objects should really be moved with velocities and forces.
However, if you ignore my advice on this, and if you want the transitioning object to stop moving if it collides with something, then do something like this:
Popugay.collision = function( self, event ) if( event.phase == "began" ) then transition.cancel( self ) end end Popugay:addEventListener( "collision" ) transition.moveTo( Popugay, { x=screenW-50, y=Popugay.y, time=2000, tag="popugay\_move\_pravo" } )That’s what I’m trying to understand.
But " transition"how to move objects, that all the laws of physics took place.
Maybe in my case it is not necessary to use " transition"?
I know there is a language barrier here, sorry. I just don’t understand the question.
But " transition"how to move objects, that all the laws of physics took place.
Again. You should really not use transitions with physics objects. They are separate systems.
Transitions are meant to be used for interface objects and other objects that need movement and other effects.
Physics is meant to be used when you want to make objects that can interact with each other and move as if they are in ‘the real world’.
Followup:
When you use both transition.* and physics.* calls on the same object, they will fight with each other to move it.
Note: If an object is being moved by transition.to(), and you call obj:getLinearVelocity(), you will get <0, 0> because as far as the physics system is concerned the object is not moving, even if transition moved the object.
Because this topic comes up fairly often, I wrote a specific section of a guide to address it, and I post it every time I see this topic come up:
https://docs.coronalabs.com/guide/physics/limitations/index.html#transitions
To be clear, you can use both systems together, and sometimes it’s actually the best way… but you must know what you’re doing and how to handle this practice, otherwise it will get messy quickly.
Best regards,
Brent
Thanks Brent! My “should not use together”, statement wasn’t exactly right, but I wanted to avoid explaining the idiosyncrasies of using them together. I will be posting that link now too!
You rock for putting in the extra time to explain this common issue.
Cheers,
Ed
avdsm ,
set the Popugay physics type as kinematic during the transition.
This is what you are supposed to do when moving objects outside of the physics simulation. Then set it back to “dynamic” when you want physics to resume moving the item.
-Assif
I have the opposite need, that time the movement if the path is a static object that Popugay stopped. Now, although the type of “dinamic”, it without stopping moving over static objects.
I’m unclear what you are trying to do.
Is the transitioning object supposed to stop when it hits something or keep moving?
Note: Combining physics and transitions is not a normal practice because the transition system and physics system are ignorant of each other.
Physics objects should really be moved with velocities and forces.
However, if you ignore my advice on this, and if you want the transitioning object to stop moving if it collides with something, then do something like this:
Popugay.collision = function( self, event ) if( event.phase == "began" ) then transition.cancel( self ) end end Popugay:addEventListener( "collision" ) transition.moveTo( Popugay, { x=screenW-50, y=Popugay.y, time=2000, tag="popugay\_move\_pravo" } )That’s what I’m trying to understand.
But " transition"how to move objects, that all the laws of physics took place.
Maybe in my case it is not necessary to use " transition"?
I know there is a language barrier here, sorry. I just don’t understand the question.
But " transition"how to move objects, that all the laws of physics took place.
Again. You should really not use transitions with physics objects. They are separate systems.
Transitions are meant to be used for interface objects and other objects that need movement and other effects.
Physics is meant to be used when you want to make objects that can interact with each other and move as if they are in ‘the real world’.
Followup:
When you use both transition.* and physics.* calls on the same object, they will fight with each other to move it.
Note: If an object is being moved by transition.to(), and you call obj:getLinearVelocity(), you will get <0, 0> because as far as the physics system is concerned the object is not moving, even if transition moved the object.
Because this topic comes up fairly often, I wrote a specific section of a guide to address it, and I post it every time I see this topic come up:
https://docs.coronalabs.com/guide/physics/limitations/index.html#transitions
To be clear, you can use both systems together, and sometimes it’s actually the best way… but you must know what you’re doing and how to handle this practice, otherwise it will get messy quickly.
Best regards,
Brent
Thanks Brent! My “should not use together”, statement wasn’t exactly right, but I wanted to avoid explaining the idiosyncrasies of using them together. I will be posting that link now too!
You rock for putting in the extra time to explain this common issue.
Cheers,
Ed