GreenSock

Very sorry about the confusion there, @shaderbytes! That was indeed a regression in 3.11.5 and it has been fixed in 3.12.0 which was just released a few minutes ago Upgrade and you should be all set. ✅

Sorry to hear about the headaches, @johnrnagle. I'm not aware of any issues like that, but we can't really troubleshoot live sites for free in these forums - there are way too many variables/factors. Plus you'd need to be much more specific about what exactly you mean by "conflicts that lead to unexpected behavior, broken animations, or even site crashes". What unexpected behavior? What exactly breaks about the animations and how can it be reproduced? Same for site crashes. You'll have the best chance of getting a solid answer here if you can provide an isolated minimal demo, like in CodePen or Stackblitz. Or if you'd like to explore paid consulting options, you can contact us directly for that. In terms of conflicts, I would definitely recommend checking to make sure you don't have any CSS transitions/animations applied to the same elements that you're trying to animate with GSAP. And obviously I'd recommend just loading the latest version of GSAP whenever possible.

Version will be 3.12.0. Private message sent. ✅

Ha! Looks like you signed up as I was typing that. Nice! 🥳 I'll send you access info via private message.

The new release will be pushed out very soon. I don't see a Club GreenSock membership on your account - do you mind me asking how you're getting access to members-only plugins like ScrollSmoother? If you're a member, I can get you early access to a .tgz file that you can npm install.

Can you elaborate a bit on what you mean by "it's glitchy with opacity"? And what does it mean to be "stacked on top of each other a bit more"? It sure looks close to the image your shared, but I'm sure I'm missing something.

I'm not sure if this will help, but here's a video from @Carl that covers some of the concepts:

You might want to check out @Carl's excellent training resources, like this video that he released recently: There's a lot more when you sign up at https://www.creativecodingclub.com/courses/FreeGSAP3Express?ref=44f484 (it's an outstanding value)

Are you looking for something like this?: https://codepen.io/GreenSock/pen/RwqbzeZ?editors=0010 You're welcome to use regular CSS snapping if you prefer.

Sorry about any confusion there, @pixelsandthings. You stumbled across an edge case where a particular aspect ratio could cause a problem in the algorithm, but I believe that's fixed in the upcoming release which I've pushed up to CodePen: https://codepen.io/GreenSock/pen/NWEKZpY?editors=0010 Better?

I certainly wouldn't recommend assigning the same ID to multiple instances. It'll return the first one it finds as it searches through the active animations (not necessarily the most recent one).

I read your question 4 times and I'm still not quite sure what you mean. You can figure out the animations' order by comparing their .startTime(). It should be quite straightforward. You can get their current progress() anytime, like animation.progress(). You can use onComplete/onReverseComplete wherever you'd like.

Here's proof: let t1 = gsap.timeline({id: "wrong"}); t1 = gsap.timeline({ id: "right", onComplete: log, onCompleteParams: [t1] }); t1.to({}, {duration: 0.5}) function log(timeline) { console.log(timeline.vars.id); // "wrong"! } https://codepen.io/GreenSock/pen/ZEmzMwe?editors=0010 I think there may be a fundamental misunderstanding about how timing and timelines work. This code tipped me off: if (animation.progress()==0) {maintl.add(animation.timeScale(1).restart(true, false))} if (animation.progress()==1) {maintl.add(animation.progress(1).timeScale(-4))} if (animation.progress()>0 && animation.progress()<1 ) {maintl.add(animation.resume())} if (animation.progress()>1) {maintl.add(animation.timeScale(1).restart(true, false))} Think of a timeline like a container for other animations. Each child animation must have a startTime. The parent timeline's playhead sweeps across its children and updates their playheads, so they're all synchronized. Let's say you add a 4-second tween to an empty parent timeline, thus its startTime is 0. But then you immediately set the CHILD animation to progress(0.5). So the parent timeline's playhead is at 0 but you want the child animation to act as if it's halfway done already...that would require that the child's startTime get set to -2 so that its playhead is properly aligned. When you enable smoothChildTiming: true, that's what it allows (shifting around of child animations' startTimes to keep things aligned). But if you allow a negative startTime in a parent timeline, it would mess up other things like the timeline's duration and playhead bounds. For example, what would you expect to happen if you tried rewinding the parent timeline to its start, like parent.time(0) or parent.progress(0)? Wouldn't it be super weird if that child animation could NEVER get back to its very start because it's a negative value? That's why GSAP automatically senses when there's a negative startTime in a child, and it adjusts things accordingly so that the bounds shift appropriately. Here's some simple code that illustrates the concept: let tl = gsap.timeline({smoothChildTiming: true}), tween1 = gsap.to(".box-1", {duration: 4, ease: "none", x: 500}), tween2 = gsap.to(".box-2", {duration: 4, ease: "none", x: 500}); tl.add(tween1); tl.add(tween2, 0); // aligned at start tween1.progress(0.5); // now tween1's playhead should be in its middle, but at what was 0 on the parent timeline, shifting it BACKWARD by 2 seconds console.log(tl.duration(), tl.progress(), tween1.startTime()); // 6, 0.3333, 0 Again, this is all essential so that things work logically. Notice the parent timeline's duration went from 4 to 6. And tween1's startTime would have to get pushed back by 2 seconds to keep its playhead aligned with its parent (smooth timing). But it can't be negative, so the parent timeline actually adjusted its own startTime backwards 2 seconds so that it still encompasses all of its children. It's a trickle-down effect that corrects everything to keep it all lined up. It looks like maybe you were expecting that maintl.add(animation.resume()) would add that animation such that its playhead would be adjusted backwards. For example, if it's a 4-second animation and its playhead was currently at 3.5 seconds (only had 0.5 seconds left to play), it would insert it into the parent at a startTime of -3.5. That's NOT how it works. The default position parameter is at the end of the timeline (in this case, your timeline is empty so it gets inserted at a time of 0). So that child tween would play in its entirety. You can, of course, do whatever you want with the timing. GSAP gives you full control of things. So if you want to insert it into the timeline such that it continues playing from its current position, you could do: tl.add(tween1, -tween1.time()) I hope that helps clear things up. If you need more help, I think you could greatly simplify things and isolate it down to just a timeline and a tween or two without all the complicated callbacks, setTimeouts, various function calls, Arrays that track numbers of times things play, meta objects, DOM manipulation, utility function calls, etc. Good luck!

I'm super short on time, but I'll mention a few quick things: You're still making that same mistake I mentioned earlier, but now you're doing it twice (t1 and t2). This looks very odd to me: animation.timeScale(4).reverse(0, false) Maybe you meant to just do animation.progress(1).timeScale(-4)? I don't really understand at this point why you're nesting things like this, especially since you keep clearing the whole timeline and replacing the contents, but keep in mind that by default timelines have smoothChildTiming set to false, so children don't shift around when you do things like altering their timeScale, reversing, etc. Typically that's the behavior people want, but it looks to me like maybe you're trying to do things that would necessitate altering the children's startTime (that's what smoothChildTiming does). Maybe you should set smoothChildTiming: true on your parent timeline. See the docs: https://greensock.com/docs/v3/GSAP/Timeline I find it extremely difficult to follow your code and understand what you're trying to do (and why). Maybe it's because it's very late at night and my brain is shutting down, but you'll GREATLY increase your chances of getting a good answer here if you simplify things quite a bit more. You really shouldn't need all that code to illustrate the core issue. Maybe just use one timeline, one child, and say "after the first iteration, I expected the duration to log out as 2 but it's actually 3...why?" (just as an example)

It always seems to happen that way, right? (starts working right after you post). 🙄 Thanks for sharing your experience and what helped on your end. No need to delete the post(s).