Jump to content
Search Community

tweens not always completing

rhg test
Moderator Tag

Recommended Posts

Hi,

 

Ive been using the Tweenlite and TweenMax for a while now.

 

I notice sometimes (mostly on rotations) where a tween will not fully complete. Here is some example code:

 

TweenLite.to(this.cellArr[0], 0.5, {scaleX:1.1, scaleY:1.1, rotation: 360, delay:0.8});
TweenLite.to(this.cellArr[1], 0.5, {scaleX:1.1, scaleY:1.1, rotation: 360, delay:0.8});
TweenLite.to(this.cellArr[2], 0.5, {scaleX:1.1, scaleY:1.1, rotation: 360, delay:0.8, onComplete: this.animateCellsBack});

private function animateCellsBack():void {
       	TweenLite.to(this.cellArr[0], 0.75, {scaleX:1, scaleY:1, delay:0.75});
       	TweenLite.to(this.cellArr[1], 0.75, {scaleX:1, scaleY:1, delay:0.75});
       	TweenLite.to(this.cellArr[2], 0.75, {scaleX:1, scaleY:1, delay:0.75});
}

 

So as you can tell I want the "cells" to rotate and grow then go back to their original size.

 

What I noticed is that sometimes, and usually with the rotations, the tweens don't fully complete. And by fully complete I mean the onComplete is called fine but the tweening properties don't match what I asked TweenLite/Max to do. In one situation I just recently had the cellArr[1] (the middle cell or second call here) still had about 45 degrees of rotation left, so it was diagonal yet the other ones were perfect. Is there a better way to write this? I notice this when I use both TweenMax and TweenLite actually. I love the libraries too!

 

Thanks

rhg

Link to comment
Share on other sites

I'd be willing to bet there's something else in your code that's causing the problem - there are absolutely no known problems with tweens not actually completing before the onComplete is called. Nobody else has reported anything similar. Could you please post an FLA that demonstrates the issue? I'd also recommend reading up on the overwrite modes at http://blog.greensock.com/overwritemanager/ because maybe you're writing your tweens in a way that's causing them to get overwritten.

Link to comment
Share on other sites

One more thing - I noticed you said that it happens primarily with rotation, so maybe you're misunderstanding how rotation works in Flash (not saying you do - I'm just going to clarify to make sure). Rotating an object to a rotation value of 360 is the same as rotating it to 0. It's a specific orientation of your object and it does NOT make the object travel all the way around in a circle. For example, if your object's current rotation property value is 179 and you rotate to 360, it will only travel 181 degrees (a little more than half of a revolution). If you want your object to travel in a full circle (360 degrees more than whatever its current rotation value is), use a relative tween by casting the value as a String. For example:

 

TweenLite.to(mc, 1, {rotation:"360"});

 

or if you're using a variable, do:

 

TweenLite.to(mc, 1, {rotation:String(myVariable)});

Link to comment
Share on other sites

I have to confirm the problem. It seems to be caused by relatively small numerical errors.

 

I can provide an example code (game, Rubik's Cube, unfortunatelly with polish comments only). TweenMax is used to rotate PaperVision objects, I'm using only

tweens like

if (!rotating) TweenMax.to(wall, 0.8, { shortRotation: { rotationZ:"+90" }, onComplete:setRotatingFalse, immediateRender:true } );

If I'll write in onComplete code that runs another rotation (to make infinite loop), then after some rotations (slower computer, fewer rotations) rotationZ will be something like "89.97".

 

[Accually it could be a Papervision Bug too... It should be easy to check, I'll do that]

Link to comment
Share on other sites

If I'll write in onComplete code that runs another rotation (to make infinite loop), then after some rotations (slower computer, fewer rotations) rotationZ will be something like "89.97".

 

[Accually it could be a Papervision Bug too... It should be easy to check, I'll do that]

 

I'd be willing to bet it's a bug in Papervision then - if you look at the TweenMax code internally, you'll see that it's pretty much impossible for the tween not to get EXACTLY to the end value. In your case, though, you're using a relative value, so if it starts at -0.03 (as reported by PV3D), that'd explain why it ends up at 89.97. Or another explanation would be that if TweenMax sets the rotation value to EXACTLY 90 and then you read it back from the object (trace(object.rotation)) it may incorrectly report 89.97, and again, that'd have nothing to do with TweenMax. If you add a trace() to the rotation property's setter so that you can see precisely what value TweenMax is trying to set it to, I bet it's accurate, but TweenMax cannot control what happens internally in that PV3D code when the value is set. See what I mean?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...