Box2D+ (Behaviours)

Hello again.

Thanks for the capx - it has helped me pin point a bug (or unexpected behavior) - here is a capx to demonstrate (based on your Assimilate demo):https://1drv.ms/u/s!Aup_NDH7UAIvgrY-Uhp8nrL-Ac5ruw.

To see the problem simply press the "-" key while the objects are assimilated, it breaks the object completely and it is them impossible to re-assimilate the sprites.

The work around is to make sure the sprite is un-assimilated before destroying it, so I suspect your behavior needs an explicit un-assimilate before a destroy sprite, assuming that is possible?

Cheers,

RR

Hello,

Afraid I have spotted another one - here is the link : https://1drv.ms/u/s!Aup_NDH7UAIvgrZAt6XHUt-KeMcHqA

Pressing LMB spawns a new object based on the position and angle of the previous one. Every few sprites you should get one that seems to be fixed in position (although the debug panel shows considerable downward velocity).

This does not occur if A) the angle is always zero or B) the object has Box2D+ disabled initially.

So.... Lots of things to keep you busy.

RR.

Hello,

Afraid I have spotted another one - here is the link : https://1drv.ms/u/s!Aup_NDH7UAIvgrZAt6XHUt-KeMcHqA

Pressing LMB spawns a new object based on the position and angle of the previous one. Every few sprites you should get one that seems to be fixed in position (although the debug panel shows considerable downward velocity).

This does not occur if A) the angle is always zero or B) the object has Box2D+ disabled initially.

So.... Lots of things to keep you busy.

RR.

Hello again.

Thanks for the capx - it has helped me pin point a bug (or unexpected behavior) - here is a capx to demonstrate (based on your Assimilate demo):https://1drv.ms/u/s!Aup_NDH7UAIvgrY-Uhp8nrL-Ac5ruw.

To see the problem simply press the "-" key while the objects are assimilated, it breaks the object completely and it is them impossible to re-assimilate the sprites.

The work around is to make sure the sprite is un-assimilated before destroying it, so I suspect your behavior needs an explicit un-assimilate before a destroy sprite, assuming that is possible?

Cheers,

RR

Hi. Thanks for the bug report. This is caused because one of the assimilated bodies is destroyed whilst it is assimilated, causing the behavior to contain references to objects that no longer exist. I can modify the plugin to prevent this from happening.

Hello,

Afraid I have spotted another one - here is the link : https://1drv.ms/u/s!Aup_NDH7UAIvgrZAt6XHUt-KeMcHqA

Pressing LMB spawns a new object based on the position and angle of the previous one. Every few sprites you should get one that seems to be fixed in position (although the debug panel shows considerable downward velocity).

This does not occur if A) the angle is always zero or B) the object has Box2D+ disabled initially.

So.... Lots of things to keep you busy.

RR.

Hi. Thanks for this bug report - it's a good one, but not really a bug and more of a limitation...

It is a limitation of the Box2D library I used and I am not sure that it will be a simple problem to work-around within the plugin - it's something you'll have to be aware of when using it in c2. The problem occurs when you set the object angle after the body is created and before the box2d+ library has had a chance to run the box2d world. Thus the object's body hasn't interacted with the world when you change its angle, and that causes the problem - and that is why it works ok if the behavior is disabled before the angle is set.

To avoid this issue, if you're going to create objects and change their angles upon spawn, it's best to set the behavior disabled and only enable it after the object has been rotated.

Dammit, it's hard to post replies at the moment...!

[quote:104pcoru]Dammit, it's hard to post replies at the moment...!

Darn right, something very dodgy with the scirra server just now. That`s how you got the double post earlier.

[quote:104pcoru]To avoid this issue, if you're going to create objects and change their angles upon spawn, it's best to set the behavior disabled and only enable it after the object has been rotated.

Yup, that`s what I have done, and will continue to do. I imagine you`ll want to add a note about this in the instructions.

[quote:104pcoru]Hi. Thanks for the bug report. This is caused because one of the assimilated bodies is destroyed whilst it is assimilated, causing the behavior to contain references to objects that no longer exist. I can modify the plugin to prevent this from happening.

Thanks, I`ll continue to un-assimilate before dropping the sprite anyway, it`s probably good practice.

I noticed an update today, thanks.

Hi - Here`s a more complicated one to do with joints, sprite animations and destroying sprites - https://1drv.ms/u/s!Aup_NDH7UAIvgrZWmsOorNgLI0bzgw

Press LMB to spawn new sprites, all fine until you start to press the RMB which destroys the oldest remaining sprite, after a few presses you should get a java exception which seems to indicate some issue with the weld joint.

Issue does not occur if there are no joints or the animation frame is not changed.

Not actually a problem for me, I fully intend to use one, invisible, sprite for physics and another for visuals, this just showed up during prototyping.

Cheers,

RR

RattyRat,

I'm not sure if that's a bug with the library or with the implementation in my behavior; I should have a better idea by the end of the weekend. I'll see if I can make the joint recreation algorithm more robust - in the meantime, as you suggest, the best course of action is to avoid animations on physics objects because the bodies and, therefore, the joints all need to be destroyed and then recreated each time an animation frame changes.

One more for the weekend - This one you can see in your Joints example capx.

In the prismatic example the Angle of the second object in the joint (prismat2 in this case) always gets set to whatever the first objects angle is.

Not sure if this is intentional, rather limiting if it is.

Cheers,

RR

v2.05 submitted for approval in the store. Thanks RattyRat for the spot on this one.

Bugfix: added missing reference angle to prismatic joints. Now the two bodies maintain their relative angles when the joint is formed.

Thanks Colludium, rapid response much appreciated!

v2.06 submitted to the store for approval.

Bugfix: Minify export was broken and is now fixed (closure compiler didn't like the use of a cr.ObjectSet forEach method).

Hello again,

Not sure if I`m doing something vey wrong here (just press up arrow):

https://www.dropbox.com/s/91yk1ky6qpvil70/ForceAddsSpin.capx?dl=0

I thought adding force to an object should just make it move in that direction, instead it seems to add considerable spin and very little motion.

Any help much appreciated.

Cheers,

RR

RattyRat - the object was spinning because the force was not being applied to the center of mass (it was being applied at layout position (0,0)) so when the force was applied it also applied a torque. Here's a fixed capx that demonstrates how to apply forces but not cause spinning.