Rope Joint and Transition.to Is this a limitation or a bug?

Solar2D General Questions/Discussion
#1

So I have this heavy object dangling and attached to my “ship” via a Rope Joint.  It works perfectly; wherever the Ship goes the object dangles along like a wrecking ball.  The ship hovers and moves about by applyForce() or  applyLinearImpulse()  or simply drops with gravity.  

Now, for some situations in the game I have to move the Ship using a transition.to().    This is where the weirdness happens.  The dangling object doesn’t follow the ship anymore and falls by itself with gravity.  The “rope” however, is seemingly still active, connecting the ship and the object but it is stretched waaay beyond it’s maximum length.  This happens all throughout the duration of the transition.to.  When it (transition) completes, the rope joint goes back to normal (the ship, which is lighter than the object as its load, is pulled toward the object like in a spring to resume the rope max length).  

There is a caveat though.   If I change the object’s density back to a smaller value (eg 1-5), this problem doesn’t happen but i loose the desired effect.    In order to make the feel and movement realistic, and to make the load very heavy, I had to use a density anywhere from 15-20 for the dangling object.  

I cannot find enough documentation with the Rope joint, so I suppose this is a limitation?  Can’t say it’s a bug, thought it felt like it…  Any input on this?

To illustrate the mechanics of what I’m trying to achive, pls see this this video:

https://www.youtube.com/watch?v=R3f7VVhd-3o 

Santi

#2

Hi mate, 

Dont take my words for it but i saw recently a post somehwere here that transition.to doesnt work well with objects where physics apply.

The explanation was that there is a difference in how the physics engine handle object placements in code vs the transition library.

I guess (underline guess) that you would see a similar error if you change x/y coordingated manually as well on a physics object.

So in that regard its an incompatibility and you should stick to one or the other.

Perhaps the people knowing more about this could fill me in / correct me.

#3

Looks like a cool game btw!  :smiley:

#4

The physics.* library and transition.* library are both separate.  

This means, while both can and do update the position of objects in the world, they do not communicate.

Additionally, when transition.* moves objects, the intermediate part of that move is missed by the physics system.  From the point of view of the physics system, the object essentially ‘teleported’.

Having said that, you can still use transition.* with physics.* and you can improve behavior as follows.  Apply these changes one at time to see which helps :

First, for object(s) being moved directly or indirectly with transition.*

  1. Use kinematic bodies not static bodies.

  2. Add body to object, then set ‘isSleepingAllowed’ to false.

  3. Add body to object then set ‘isBullet’ attribute.

Second, consider modifying the way the physics.* engine operates via:

Tip: The above tweaks to the physics.* engine don’t need to be set for the whole game, just the part with your transitions.

If none of this helps, consider making a small demo and sharing it with us.  Some of us may have the time and ability to further tweak this.

#5

BTW - Your game is looking great.

#6

Another idea is this (totally untested, just a theoretical concept):

  1. Start running the transition on the ship.

  2. Also start running a Runtime position listener on the ship, and gather the “delta” changes over the course of the transition.

  3. Apply any delta x/y changes to the dangling object, not as a direct screen position, but as relative shifts in the object’s position.

  4. When transition completes, stop the Runtime listener.

Brent

#7

Thank you guys!   

I will try your suggestions and hopefully at least one of them works.   If not, one very easy fix is to just drop that portion of the game.  It’s not a show-stopper anyway, but I just thought it’s something nice to have, a very simple cut-scene if you will.

Santi

#8

@Brent,

Thanks for the suggestion.  This solution technically works, but visually it looks awkward and too rigid.  As expected, I loose the ‘pendulum swing’ effect as the ship moves. 

@roaminggamer,

None of the suggested solutions worked.  However, I got another solution that worked!   Instead of using transition to move the ship, with SSK2, I used actions.movep.forward()  along with  actions.face().   That did the thing sweetly!!    

Your SSK2 library is awesome and a great help in this project.  

The code looks something like this:

-- set a dummy coordinate where the ship should tween to local dummy = display.newCircle( mothership.x, mothership.y - 150, 10) local function shipFinalize( self ) ignoreList( {"enterFrame"}, self ) end local function shipDockingListener( self ) actions.face( self, { target=dummy, rate=40 } ) actions.movep.forward( self, {rate = 120} ) if ssk.math2d.isWithinDistance(dummy.x, dummy.y, self.x, self.y, 5) then -- player has docked ! -- do the necessary end end player.enterFrame = shipDockingListener player.finalize = shipFinalize listen("enterFrame", player) player:addEventListener("finalize")

So for anyone having the same problem, you can natively use delta and any physics-based forces to move an object,  but I recommend using ssk2 for ease of coding  ;)  

Santi

#9

Ive said this many times… If you want to directly affect physics bodies you should either weld them to a static sensor or use a touch joint. I like to have a display group which, when moved, updates the target location of a touch joint.

#10

Btw, @santiagoluib3 the game does look really good!  :slight_smile:

#11

@horacebury, Thank you!   

I only have 4 days left until the CoronaDefoldJam deadline, so I guess I will upload the APK with only 10 levels.   I would really appreciate if you guys (those with Android devices) can give feedback on the game on any aspect of it.  I would love to hear the negatives  ;)  

#12

Hi mate, 

Dont take my words for it but i saw recently a post somehwere here that transition.to doesnt work well with objects where physics apply.

The explanation was that there is a difference in how the physics engine handle object placements in code vs the transition library.

I guess (underline guess) that you would see a similar error if you change x/y coordingated manually as well on a physics object.

So in that regard its an incompatibility and you should stick to one or the other.

Perhaps the people knowing more about this could fill me in / correct me.

#13

Looks like a cool game btw!  :smiley:

#14

The physics.* library and transition.* library are both separate.  

This means, while both can and do update the position of objects in the world, they do not communicate.

Additionally, when transition.* moves objects, the intermediate part of that move is missed by the physics system.  From the point of view of the physics system, the object essentially ‘teleported’.

Having said that, you can still use transition.* with physics.* and you can improve behavior as follows.  Apply these changes one at time to see which helps :

First, for object(s) being moved directly or indirectly with transition.*

  1. Use kinematic bodies not static bodies.

  2. Add body to object, then set ‘isSleepingAllowed’ to false.

  3. Add body to object then set ‘isBullet’ attribute.

Second, consider modifying the way the physics.* engine operates via:

Tip: The above tweaks to the physics.* engine don’t need to be set for the whole game, just the part with your transitions.

If none of this helps, consider making a small demo and sharing it with us.  Some of us may have the time and ability to further tweak this.

#15

BTW - Your game is looking great.

#16

Another idea is this (totally untested, just a theoretical concept):

  1. Start running the transition on the ship.

  2. Also start running a Runtime position listener on the ship, and gather the “delta” changes over the course of the transition.

  3. Apply any delta x/y changes to the dangling object, not as a direct screen position, but as relative shifts in the object’s position.

  4. When transition completes, stop the Runtime listener.

Brent

#17

Thank you guys!   

I will try your suggestions and hopefully at least one of them works.   If not, one very easy fix is to just drop that portion of the game.  It’s not a show-stopper anyway, but I just thought it’s something nice to have, a very simple cut-scene if you will.

Santi

#18

@Brent,

Thanks for the suggestion.  This solution technically works, but visually it looks awkward and too rigid.  As expected, I loose the ‘pendulum swing’ effect as the ship moves. 

@roaminggamer,

None of the suggested solutions worked.  However, I got another solution that worked!   Instead of using transition to move the ship, with SSK2, I used actions.movep.forward()  along with  actions.face().   That did the thing sweetly!!    

Your SSK2 library is awesome and a great help in this project.  

The code looks something like this:

-- set a dummy coordinate where the ship should tween to local dummy = display.newCircle( mothership.x, mothership.y - 150, 10) local function shipFinalize( self ) ignoreList( {"enterFrame"}, self ) end local function shipDockingListener( self ) actions.face( self, { target=dummy, rate=40 } ) actions.movep.forward( self, {rate = 120} ) if ssk.math2d.isWithinDistance(dummy.x, dummy.y, self.x, self.y, 5) then -- player has docked ! -- do the necessary end end player.enterFrame = shipDockingListener player.finalize = shipFinalize listen("enterFrame", player) player:addEventListener("finalize")

So for anyone having the same problem, you can natively use delta and any physics-based forces to move an object,  but I recommend using ssk2 for ease of coding  ;)  

Santi

#19

Ive said this many times… If you want to directly affect physics bodies you should either weld them to a static sensor or use a touch joint. I like to have a display group which, when moved, updates the target location of a touch joint.

#20

Btw, @santiagoluib3 the game does look really good!  :slight_smile: