Jump to content
GreenSock

cerulean

TweenMax.updateTo() and TimelineMax

Recommended Posts

Is there any reason one can't TweenMax.updateTo() a TweenMax nested inside a TimelineMax? I'm sure it's me, but it's driving me crazy. I do this (I have an object being tweened from z:500 to z:0 or something like that, but not on x), thus (simplified):

_obstacleTimeline.add(TweenMax.to(obstacle,OBSTACLE_SPACING-1,{z:obstacle.finalZ}));

and later

$tween.updateTo({x:stage.stageWidth,autoAlpha:0,ease:Quint.easeIn},false);
and the object that's being tweened does what it's supposed to and then goes _back_ a way in z-space and comes forward again from the left. I'm not restarting the tween (updateTo(...,true)). Again, I'm sure it's me, but have been checking this for 1/2 hour and see no errors on my part…
Link to comment
Share on other sites

First, let me point out a note in the docs:

 

If the resetDuration parameter is true and the tween has already started (or finished), updateTo() will restart the tween. Otherwise, the tween's timing will be honored. And if resetDuration is false and the tween is in-progress, the starting values of each property will be adjusted so that the tween appears to seamlessly redirect to the new destination values. This is typically not advisable if you plan to reverse the tween later on or jump to a previous point because the starting values would have been adjusted.

 

The updateTo() functionality is very tricky to pull off logic-wise mid-tween because [unless you set resetDuration to true] the duration and progress of the tween remains unchanged, with all easing intact, but it must adjust things so that there are NEW destination values, so the only variable that can possibly change in that equation is the starting value(s) to compensate and make the motion remain fluid. 

 

In other words, imagine tweening x linearly from 0 to 100 over the course of 10 seconds. Basically 10 pixels per second. Then, halfway through the tween (when x is 50), you do an updateTo() and make x go to 1000 now. Keep in mind that tweens record starting and ending values and then do the interpolation based on the progress of the tween. So now what should happen? We've got to keep the easing intact perfectly (although in this case it's linear, so that's easy) and redirect to a new end value seamlessly. We need to go from x:50 to x:1000 (a change of 950) over the course of 5 seconds. We can't create a new tween because not only would that be wasteful memory-wise, but it would also ruin the easing. Imagine if you were using a Strong.easeOut or Elastic.easeOut - you wouldn't want it to suddenly start that ease over again from this new position. 

 

See the dilemma? 

 

So math-wise, the only way to accomplish this task is to push the starting value back to -900. Imagine if the tween had originally gone from -900 to 1000. When that tween is halfway done, x would be at 50. That's exactly where it overlaps with our existing tween that was going from 0 to 100. That's how we make it seamless moving forward. We project backwards and calculate exactly where the starting value needs to be in order to make the math work. 

 

As indicated in the docs, you should not use updateTo() if you need to ever go backwards. 

 

If you have any better ideas about how to handle this, I'm all ears. 

  • Like 2
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.
×