Make transition react to collsion contact

Solar2D General Questions/Discussion
#1

I have a moving object:

 transition.to( enemy, { time=3000, x=obj.x-50,y=obj.y-50})

I have a bomb/bullet

local bomb=display.newImageRect("bomb\_boost.png",20,20) bomb.x=obj.x bomb.y=obj.y

They both have physic bodies

physics.addBody(enemy,"kinematic",{radius=75,density=0,friction=0,bounce=0.5}) physics.addBody(bomb,"dynamic",{density=1,friction=0,bounce=0,isBullet=true})

To make this simple, the bomb is moved by a transition.

transition.to(bomb,{time=1000,x=enemy.x,y=enemy.y})

When the enemy is still(not moving), the bullet reacts properly(enemy bounces back).

However when the enemy is moving and the bullet is moving, they do not react.

Anyway to make them react when both ibjects are moving.

Thanks bros.

#2

This is the problem of using transition.* or manual changes to <x,y> with physics.

You are essentially bypassing the physics engine.  i.e. It is not made aware (in a reasonable amount of time) of the position changes, so it can’t react correctly.

The ONLY way to properly solve this is to move with velocities and forces.

A hack to try to overcome this is to:

  • set ‘isSleepingAllowed’ on bodies to false.
  • set ‘isBullet’ on moving bodies to true.

This is still a hack, but maybe it will be OK.

HOWEVER, you cannot use transition.* or manual updates to cause one body to push another body.  That won’t work.

#3

The hack didnt work. Trying out to make the enemy follow the previous bomb/bullet instead of obj.

Is there anyway to make a make moving object get pushed by another moving object?

#4

Yes, as I said, use all physics movement.

#5

Is there a guide for that? I looked it up but i am not sure if you mean this:

https://docs.coronalabs.com/api/type/Body/applyLinearImpulse.html

#6

No. Just the physics guideand all the physics docs (1, 2) .  You need to work out what it means to push a thing and then write the correct physics code to do it.  Sorry, but I can’t be more exact that that.

This demo shows one example of pushing and how transition.* does it wrong whereas physics does it right.

Top is transition.*

Bottom is physics.*

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/04/transition_vs_physics.zip

( VIEW FULL SCREEN TO SEE ** DIFFERENCE**)

https://www.youtube.com/watch?v=tY91oSeOJro&feature=youtu.be

#7

THanks I will look into this.

By the way, instead of using transitions, would changing the x and y coordinates work like:

local function move() enemy.x=enemy.x+1 enemy.y=enemy.y+1 end move()

Also would I need a collision listener? I dont have one in the example I gave above.

#8

Dude.  You didn’t read post above. 

No.  It won’t work.  That is you  manually changing <x,y>

You can only achieve correct pushing of physics bodies with forces and velocities.

#9

Sorry for my impatience, but this is such a huge topic, without knowing exactly what you want to do, it is hard to instruct you.

So my only hope is to give you some examples that do something, then let you experiment.

Once you have a firm grasp of the physics.* system and some basic understanding of vector math, making action games in Corona is a snap. 

Until then, it is completely impenetrable and any success is accidental.  You must learn these things and experiment a lot with all the different field settings and functions.  There is no quick path to knowing this stuff.  :frowning:

PS - You may believe your original post is exact, but it raises all kinds of questions:

  • Is there gravity
  • If so, do the objects ignore it or respond to it? Do only some ignore it?
  • How are you going to decide when a body should stop moving?  
  • Does it need to move along a specific path.
  • Is it ballistic.
  • Should some bodies bounce off others or only push?
  • How fast is the object moving.
  • …
#10

I added another example where both objects are moving with transition.* or physics.* to show you how  transitions fail when moving physics objects that interact/touch/collide.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/04/transition_vs_physics2.zip

In a nutshell, transition.* wins over physics.

#11

Right sorry about that.

After reading your code and watching the video, i sort of get it.

In my case, the pusher is the bullet and the enemy is the circle.

Only issue is in my project; the “circle” is moving to the pusher while the pusher to the circle.

So after thinking about it, I realised that the bullet does react to the collision by getting pushed back but the enemy does not.

So what I have to do is to make a collision listener where when the collision ended, the enemy will be pushed back by a transition and when that is done, it will resume transitioning to the enemy.

Only question is…how do i do it?

#12

I don’t agree.  You need to abandon using transition.* as the means of movement.   Otherwise you’re going to spend all your time trying hack around things that don’t work.

If you’re making a shooter you want to user pure physics.

See my second example: 

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/04/transition_vs_physics2.zip

It shows a major issue with transition.* and physics.

#13

Are you trying to make something like ‘Soul Knight’?

#14

No no that was an example for the moving mechanism.

Should i use then setLinearVelocity(  ) instead of transition.to?

And if I do use setLinearVelocity, how can I make it got to a specific point?

#15

This is way too complicated to describe.

I’ll make a small demo of what I think you want, then I’ll share it here.

You can tweak it after that, but my help beyond that will be limited.

#16

I understand completley.

Thank you so much!  :slight_smile:

#17

Warning I will use SSK because I have no time for doing things long-hand.

#18

Heading out.  Example will be posted later tonight.

#19

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/04/shooterMechanics.zip

https://www.youtube.com/watch?v=llV2NdQh9Ls&feature=youtu.be

#20

Be aware.  This is not drop-in friendly.  It is merely a demo of concepts, and then only a few.  There are many  more ways to move objects w/ physics.