GSAP .delay()-problems

[akapowl]

Hello there,

 

since I updated to GSAP 3.0, I am struggling to make timelines / timeline-functions run with a delay.

I added a codepen-demo to demonstrate my issue.

 

Am I overseeing something or is this a problem in GSAP 3.0?

 

Cheers,

Paul

See the Pen ad250d8a7253c9547e2f23a36cfe3247 by akapowl (@akapowl) on CodePen

[ZachSaucier]

Hey akapowl and welcome to the GreenSock forums! 

 

I assume the effect that you're wanting is this animation to infinitely repeat, scaling the box up and down? If so, you can simply your code a lot by doing this:

 

var tl = gsap.timeline({repeat: -1, yoyo: true, delay: 5});
	
tl
.from(".element", { duration: 1, scale: 0 })
;

// or use a regular tween if this is all you're doing
var tween = gsap.from(".element", { duration: 1, scale: 0, repeat: -1, yoyo: true, delay: 5 });

 

[akapowl]

Thanks, ZachSaucier.

 

I know, I can declare the delay inside the tween itself.
The codepen demo is just a showcase example for my problem.

I need to make a more complicated timeline run on a delay on exactly one occasion, whereas it is supposed to run without delay on other occasions. So I need the .delay().play() functionality or a delayedCall, which doesn't seem to work as intended, either.

 

 

[Carl]

either of these options will work
 

tween.delay(5).restart(true); //true means the delay will be honored when restart() is called
gsap.delayedCall(5, ()=> tween.play());

 

[akapowl]

Thanks, Carl!

 

Both those solutions work as intended.

 

Still, if I am not mistaken, my approach should have worked too, though - seems like it's buggy in GSAP 3.0.

[ZachSaucier]

17 minutes ago, akapowl said:

Still, if I am not mistaken, my approach should have worked too, though - seems like it's buggy in GSAP 3.0.

What I realized after Carl's comment is that your approach shouldn't work. The reason being that the timeline has already "started", even if it's paused at the start, so the delay (which is supposed to occur before it starts) being changed after it's initialized  won't affect it until the next iteration. Hence why the .restart(true) is necessary as Carl pointed out. 

 

Someone feel free to correct me if I'm wrong here.

[akapowl]

Well, it always worked like this before v3.0, and even in the Docs for 3.0 it says:

 

This method serves as both a getter and setter. Omitting the parameter returns the current value (getter), whereas defining the parameter sets the value (setter) and returns the instance itself for easier chaining, like myAnimation.delay(2).timeScale(0.5).play(1);

 

https://greensock.com/docs/v3/GSAP/Timeline/delay()

[GreenSock]

1 hour ago, akapowl said:

Well, it always worked like this before v3.0

I'm a bit confused - that's not my recollection and I just ported your codepen to 2.1.3 and it has exactly the same behavior, right? 

See the Pen e071d3912c5de0fd91c6e9cacf6b1821?editors=0010 by GreenSock (@GreenSock) on CodePen

 

When someone calls play() on an animation, they typically expect it to...well...play  That's why delay isn't factored in. But as @Carl pointed out, if that's the behavior you want, simply use restart(true) and you should be golden. 

 

Happy tweening!

[akapowl]

On 11/22/2019 at 7:31 PM, GreenSock said:

When someone calls play() on an animation, they typically expect it to...well...play

 

Yup, sounds about right  ...seems like ZachSaucier was right with what he said.

The last version I used before 3.0 was 2.1.2.

In my last project I used 

animationFunction.play().delay(5.0);

instead of

animationFunction.delay(5.0).play();

and it gave me the result that I expected.

Seems, like I was kind of lucky that it worked then.

Made a pen for my 2.1.2 version.

 

See the Pen 5b6fa69a6b0611a4a814fac95e894a1a by akapowl (@akapowl) on CodePen

 

Thanks for your help, everybody.