TweenMax repeat behavior

[thomas_b]

I am tweening a custom property with a repeat delay and when I trace into the function it gets called with the final tween value (o in my example below) multiple times until the delay has expired.

 

Is this intended behavior?

 

here are the details somhow cleaned up (get / set are the traces in the corresponding functions):

 

tween: ... {"customProp":0, "repeat":-1, "repeatDelay":3, "ease":"Linear.easeIn"} ..

 

customProp get: 10 -- start of tween -

 

customProp set: 10 -- start of first cycle

.......

customProp set: 0 -- first cycle done

 

customProp set: 0 -- delay phase - I see a delay time dependent number of calls - if delay == 0 I see none

...

customProp set: 0 -- delay time finished

 

customProp set: 10 -- second cycle starts

....

customProp set: 0 -- end of second cycle ....

 

thanks - thomas

[Carl]

Hi Thomas,

 

Interesting observation. I hadn't ever considered that behavior but a simple test confirms that yes the property is being set constantly during the repeatDelay.

 

I can't address whether or not it is the intended behavior, but I have a good idea why it is happening. When a tween encounters a repeatDelay it doesn't really stop advancing and then sit around waiting to start playing again, it is constantly moving forward in time. You stumbled across this behavior with your setter, but also if you put an onUpdate callback on the tween you would see that it fires constantly throughout the repeatDelay time period.

 

var t:TweenMax = TweenMax.to(object, 1, {someProperty:10, delay:1, repeat:1, repeatDelay:2, onUpdate:showTweenProgress});

function showTweenProgress(){
trace("tween firing ");
}

 

also TweenMax's have a totalProgress prop that is a value between 0 and 1 that depicts the progress of the tween including all repeats and delays, it might be fun to watch that in the trace as well:

function showTweenProgress(){
trace("tween totalProgress " + t.totalProgress);
}

 

I'm quite certain the tween needs to be constantly advancing throughout the delays so that you can easily rewind from any point in time or jump to any point in time in a tween even its the middle of the third repeatDelay. I'm also guessing that it is safest and entails least amount of overhead to have the property constantly set (even if it is the same value) during the delay periods, which again aren't really delays, they are just spans of times during which values aren't seeing any change.

 

I'm sure Jack will jump in here and clear up where ever I have gone astray. I don't know how great of an idea this is, but if you don't want your setter doing any unnecessary work I guess it could check to see whether or not the new value is the same as the current value and respond accordingly.

 

stay tuned.

 

-c

[GreenSock]

Carl is right about the totalTime continuing to progress throughout the tween which is very intentional and protects against some common mistakes that other tweening engines make that end up allowing gaps and time drift, but I'll spare you the boring explanation unless you request it.

 

However, you make a very good point and there's really no reason (that I can think of) why the values need to be updated if the currentTime hasn't changed (during the repeatDelay), so I just uploaded a new version that alters that behavior. Download a fresh batch and you should see that things stay relatively stagnant during the repeatDelay. Please let me know if that works well for you. And thanks for pointing this out.

[thomas_b]

excellent - the new version fixed the behavior I have seen - very cool love it

 

thanks Carl for jumping in - I was reasoning along your lines but by looking at the code it could have gone both ways - I do what you suggested and filter out successive 0 values - by the way I love your site - I always learn & pick up something from it

 

thanks - thomas

[Carl]

you're welcome and thank you!