Collisions not registering when you move a character via Transition.to?

Solar2D General Questions/Discussion
#1

I just finished reading this from the blog

http://coronalabs.com/blog/2014/09/16/tutorial-swiping-an-object-to-fixed-points/

To Rob,

Thanks for the write up, it’s useful in some way to what I’m currently working on.

And this I wanted to ask others,

I have a question or concern to address however.

I noticed that with the transition.to physics objects aren’t as responsive to collisions, for example lets say there are two objects.

Let’s call the first object player and the second object candy.

Both player and candy are physics objects that are suppose to collide, and after a collision the candy disappears and the user receives a point.

So the player starts at the left edge and if you swipe, it’ll transition.to the player over to the right edge, and let’s say for example that the goal is to swipe as the candy falls from the top of the screen, so just before the candy passes the same y position as the player, you swipe and the player seems to just pass through the candy without a collision detected.

I have my objects set as physics, both of them dynamic, the candy isSensor is true, and the player isBullet is true too.

I set physics.setScale(60)

It is like 1/3 times where the collision will actually register, and the rest of the time it goes through like it’s a ghost.

Does anyone know where I might of made a mistake in my assumptions?

#2

There’s no mistake, but the fact that box2D is a little world by itself.

What I mean is that it can run at different intervals than what transition.to does, and that it keeps its own calculations and stuff to do what it does.

When you move a box2D object with .x/.y or transitions, you’re actually skipping all the calculations that box2D would do if you moved it with setLinearVelocity and similar functions. For example, when objects are about to collide, box2D starts calculating when it’ll happen (to adjust for example, the last step before a dynamic object hits a static object, avoiding it to pass through). If you move with transition.to, all those “under the hood” calculations will be way more unreliable, as you’re basically changing up what box2D would expect from that object.

#3

HI RagdogStudios,

I understand what you mean there, so it’s not going to happen if I use the transition.to in order to cause a collision.

Thank you for helping me figure this out, time to figure out another way to make this happen.

Sincerely,

Harry Tran

#4

Hi Ragdog Studios, 

I just had a quick question, does the same irregularity occur if you move an object via a translate?

#5

Yeah. It’s the same principle

#6

thank you

#7

There’s no mistake, but the fact that box2D is a little world by itself.

What I mean is that it can run at different intervals than what transition.to does, and that it keeps its own calculations and stuff to do what it does.

When you move a box2D object with .x/.y or transitions, you’re actually skipping all the calculations that box2D would do if you moved it with setLinearVelocity and similar functions. For example, when objects are about to collide, box2D starts calculating when it’ll happen (to adjust for example, the last step before a dynamic object hits a static object, avoiding it to pass through). If you move with transition.to, all those “under the hood” calculations will be way more unreliable, as you’re basically changing up what box2D would expect from that object.

#8

HI RagdogStudios,

I understand what you mean there, so it’s not going to happen if I use the transition.to in order to cause a collision.

Thank you for helping me figure this out, time to figure out another way to make this happen.

Sincerely,

Harry Tran

#9

Hi Ragdog Studios, 

I just had a quick question, does the same irregularity occur if you move an object via a translate?

#10

Yeah. It’s the same principle

#11

thank you