Bug: Revolute joint accuracy on animation change

This is a an effect which has got significantly worse since r79. It happened a little on r77 but was manageable.

I'm creating a pendulum beneath a spaceship using revolutes

The capx is here:-

dl.dropbox.com/u/15786086/RevoluteTest.capx

Use the mouse to get the ship to move around. The animation has to change when the ship reverses to make sure it stays up the right way. When the frame changes, the revolute origin (connection point) moves slowly away from where is should be with each change.

Also getting "stretching" if the object connected is too dense and this could be the physics catching up, but the weird moving of the origin is definitely a calculation inaccuracy (a bug) as it wasn't present in r77.

Tried to force the chain back to the origin, but got an epic fail when I tried... As my current game relies on fun with joints would be great to see if this could be fixed. I know the animation change is making it worse, but I have to change frames.

[Using Chrome on 64bit C2]

Huh, that's odd. BTW you can use 'set flipped' to avoid needing another animation frame. I'll look in to this, but in the mean time a good workaround is probably to use an invisible object which does not animate or rotate with the physics behavior, and every tick position the visible Ship on top of that. I think it's to do with the rotation of the Physics object, so if the invisible object does not rotate it should be OK.

Thanks Ashley. I tried the invisible support before, but there were problems with collisions on the sprite 'facade'. Now you've put in the disable collisions function it may work better. Will report back on that.

This is all good though as it's done in the name getting C2 to have rock-solid bullet-proof physics.

One other nice to have... the joints seem to have their own elasticity and stretch if you exert force on them. It would be great if there was an option to 'bolt' the joints so they were not allowed to stretch under any force. Means we can have really wicked fast spinning/moving things.

Right - the support with the new collision suppression works really well now and the joint swings freely now. I've also sussed out how the 'stretchy' joints works. If you increase the density of the main support up to about 10, the joint is rock solid, so it's a function of mass. While this works, it may not always be desirable to have such dense objects, so a 'bolt joint' function would still be nice to have.

I wait to see if you find out where the rotation mucks with joint.

I'm also having this "stretchy" joint problem in r95. I've created a chain with a ball-like object that the player drags around, but at the moment the chain is acting more like an elastic. It is not a function of the damping ratio or spring frequency. Stencyl, which also uses the Box2d engine, has a "stiffness" option for joints � would it be possible to include something similar in the next release? Increasing the density is an undesirable workaround for my particular game. Thank you!

Is anything being done about this Bug? I am getting the exact same effect in R124.

The revolute joint position remains the same on the source object and the point it is attached to on the secondary object will also stay the same until a different frame is chosen on the source object. When that happens the point of attachment on the second object drifts.

It is very frustrating and I would like to avoid adding multiple, unnecessary, blank objects just to get revolute joints to work correctly with animated sprites.

Ta.

I'm not sure why this happens, but it involves a pretty complicated part of the Physics behavior. For changing animation frames to have an effect on the Physics simulation, the only thing Construct 2 can do is destroy the physics body in the simulation then recreate it. If you destroy the body, all its joints are removed as well. C2 is now smart enough to know which joints you had and re-create them after recreating the body, but for some reason the joint drifts ever so slightly, which accumulates if you do this repeatedly.

I don't know why this happens - it might be a Box2D issue - but it really is best just to use an invisible object with no animations that you never resize as the physics object to connect joints to. Then the engine never has to destroy the physics body and recreate the joints, which appears to cause this bug.

In fact since this is an old bug report and there's probably not a good engine solution, I'm going to close this as won't fix. The separate non-animated object is a good workaround and should be perfectly reliable.

Thanks for the swift reply.

Well, okay then. I can understand this might be Box2D behavior, too bad really as it adds a level of complexity to setting up joints and an extra overhead during runtime.

Incidentally a quick search of the bugs forum for revolute turns up some more recent reports of similar behavior.

As it is not going to be fixed perhaps an addition to the manual pages on joints would be in order as it might save some hair pulling for other users.

Having the same trouble on r168.

I am using a ragdoll and I am changing the animation frame of a part when it collides with some other object. The animated part's rev. joint pivot point position moves away in relation to the force applied to it (or velocity).

Just to mention, I 've created the same functionality using ActionScript3 (Flash CS5) and Box2D and everything works flawlessly there.