unvs

For anyone following along, it was quite easy to do actually. First I added the `onDragStart` event to the draggable which just called `tl.pause()` to stop autoplaying when we start dragging. Then I hooked into `onThrowComplete` which was currently calling `syncIndex()`. I created my own callback (that first calls syncIndex), then: gsap.set(tl, { timeScale: 0 }) tl.play() gsap.to(tl, { timeScale: 1, ease: 'power2.in', duration: 2 })

Ah, I see. I kind of expected that, since it looked like that in the helper. I'll poke around some more and see if I maybe stumble across something

I'm using the excellent seamlessLoop helper (https://gsap.com/docs/v3/HelperFunctions/helpers/seamlessLoop/) which I run with `paused: false` and `repeat: -1`. I was wondering if there is a way to smoothen out the transition between when you grab and "throw" it (or just scroll it manually) and when it starts rolling by itself again? Now it comes to a complete stop, then starts rolling in its previous tempo again. I'd love if it could either ramp up from 0, or not slow down to 0, but land in the previous speed. Are any of those options possible? Thanks for any advice!

A little update on this: - I've managed to fix the operations with arrows -- it loops as it should finally - I've *ALMOST* figured out the dragging/snapping. There is a bug I'm not sure on how to solve. If you drag from 1 to 6 (backwards), the threshold for snapping is not the same as the other slides. If you only move a couple pixels it still will snap to 6. It is wrong when moving the other way as well -- to make it snap to 1 when sliding from 6, you have to drag all the way to pass the 0 threshold. Does anyone have any ideas on how to solve that? https://codepen.io/unvs/pen/ExyRqgZ

Hah, yes, I'm sorry - there are 2 things I'm unclear on how to solve in this codepen: https://codepen.io/unvs/pen/ExyRqgZ 1. I have an array of snap offsets which won't work on the modified slides. If I click and drag towards the left (to go to 2, 3, 4 etc), it snaps in place until 6, but then it stops (since it doesn't have any more values in the snap offset array, I guess?). I'd like to have it snap to the next 1 and 2 and 3 and so on. Can this be wrapped somehow? 2. Clicking the left and right arrows work fine, but if you click the right arrow several times (until you are well into "loop 2"), and then drag it afterwards, it rolls back and snaps to the last known offset. I suspect this is connected with problem #1?

Thanks for taking a look, I really appreciate it! The examples I found uses absolute positioning on the slides, and a fixed height on the wrapper. I was hoping to avoid that for easier styling, but I forked one of the examples and tried tweaking it to my needs: https://codepen.io/unvs/pen/ExyRqgZ I'm a little unsure of how to operate the arrow buttons though Now the backwards arrow goes forward and vice versa. Also it stops working when it arrives at the wrapping point. Not quite sure how to tackle that?

I have a draggable slider/"panner" that is constructed a little differently due to some demands: - It has to work with percentage widths for the slides / flexbox - It has to work with differing slide widths This has worked all right in my solution, but now I'm trying to "loop" the slider and all examples I can find are using a draggable connected to a tween's progress and I'm not able to see how I can make this work in my situation. Any pointers here? I'd suspect I'd have to do some dom manipulation by moving the first slide to the end etc but I'm not really sure where to start. Any and all advice appreciated!

First of all, thanks for this, it does what I was looking for! I just have one question: Is it possible to make it just a little less "sensitive"? So that it will stop after the first section and require a new input to move to the next? When I scroll with my touchpad, it usually scrolls multiple sections. Maybe due to the scroll inertia of the touchpad?

Yes!! That seems to have done the trick! ? Thank you so much for the fast response, you're the best!

Yes, it seems like a lot when isolated like that, but it is a part of a much bigger system where I need a lot of flexibility. Staggers like those you proposed didn't quite cut it for my usecase unfortunately!

I tried recreating the problem with as little of my code as possible. Here it is running like expected with gsap 3.0.4. Each item fades in, one by one. https://codepen.io/unvs/pen/eYYogpb And with gsap 3.0.5. The first 4 snap in, while the rest enter nicely. https://codepen.io/unvs/pen/zYxjPeE Thanks for any advice that might come to mind, I really appreciate it

Yes, sorry about the rushed post - had to get some stuff ready before the weekend and just wondered if something similar has been reported or if something came to mind :) I will try to put together a proper code pen! Thanks for your time

First of all, thanks so much for this fix @GreenSock! I updated to 3.0.2 and everything worked as previous However, when I upgraded to 3.0.5 the problem started appearing again. Has there been a regression perhaps? A video of 3.0.4 (correct) -- the three horizontal boxes animate after eachother https://www.dropbox.com/s/tv1b5st5ji8ul3m/lett_3.0.4.mp4?dl=0 A video of 3.0.5 (incorrect) -- the three horizontal boxes just flash appear at the same time https://www.dropbox.com/s/tu32dqorb28ctc6/lett_3.0.5.mp4?dl=0

Thank you so much! I'm not sure how to test this (this is the new world of Webpack I guess, not sure how I'd drop in that file to my library), so I'll wait with bated breath for the .0.2 release Thanks again

Yes, the timeline is being checked and updated through an IntersectionObserver observing elements entering the viewport, so checks are right before adding a new tween to the timeline (and right after, depending on the scrolling and elements). Thanks for the demo and investigative work, I really appreciate it .

Hi, and first of all, congrats on GSAP 3! I have some code running in GSAP 2 to calculate where to add in my tweens in a timeline: const startingPoint = tweenDuration - tweenOverlap if (section.timeline.isActive() && section.timeline.recent()) { console.log('timeline is active') if (section.timeline.recent().time() > startingPoint) { /* We're late for this tween if it was supposed to be sequential, so insert at current time in timeline instead */ console.log('late') tweenPosition = () => section.timeline.time() alphaPosition = () => section.timeline.time() } else { console.log('still time') /* Still time, add as normal overlap at the end */ tweenPosition = () => `-=${tweenOverlap}` alphaPosition = () => `-=${tweenDuration}` } } else { console.log('inactive -- add to end of timeline') tweenPosition = () => '+=0' alphaPosition = () => `-=${tweenDuration}` } ``` In GSAP 2 this works just as I want, but when I upgraded to GSAP 3 it acts differently. `isActive` is never true for the timeline, even if I add a bunch of tweens initially. This is probably impossible to debug for you guys, but it's hard to create an example of what I mean. So basically my question is: Are there any changes to the timeline defaults or how it operates that I might look into? All the best, T

It should work The pen I forked does not under certain circumstances, as when you scroll slowly and parts have been revealed with very short intervals and longer delays between tweens, which results in ugly bugs when scrolling erratically through sections with different number of tweens. If Tween1 has a duration of `2.0` then there is a delay of `1.5` and Tween2 is called with a position of `-=1.9` then there is a delay of `1.5` and Tween3 is called with a position of `-=1.9`, the tweens break. My fix works though, so I'm happy - thanks for looking at it anyway

For anyone wondering or finding this later, I solved it by checking the position of the recent() tween if the timeline.isActive() ``` const startingPoint = tweenDuration - tweenOverlap if (section.timeline.isActive() && section.timeline.recent()) { if (section.timeline.recent().time() > startingPoint) { // We're late for this tween if it was supposed to be sequential. // Insert at current time position = () => section.timeline.time() } else { // Still time, add as normal overlap at the end position = () => `-=${overlap}` } } else { position = () => '+=0' } ```

If I remove the delayedCall() and wait for the first 9 boxes to load, then scroll down so 10, 11, 12 are starting to tween, then scroll down to the next rows while 10, 11, 12 are still fading in, the rest of the tweens break. So, is it when I'm adding tweens with a position overlap to an already running timeline? https://codepen.io/unvs/pen/OJLwdGE

Hello, and first of all, thank you so much for this wonderful library! I'm trying to wrap my head around this weird thing I'm seeing in my app, and I feel like my head is about to explode! When I reveal multiple elements with `overlap`, and I delay the call of each tween, the animations get chopped. So if I have 8 boxes split over 2 rows in my app, the first 4 reveal perfectly, but if I scroll slowly the next ones get chopped off. It seems as if the timeline is not active, and I shouldn't use negative overlap, but `isActive()` returns true, and if it didn't, the animations would not overlap. I've tried to reduce it to an easier testcase in the codepen above. When the DELAY_BETWEEN_CALLS is greater than the diff between DURATION and OVERLAP the start of the animations get chopped off. Am I doing it wrong? As I'm understanding it, if I have: - a Tween with a duration of 2 - a delay of 1.5 seconds - a Tween with a duration of 2, with overlap -=1 it should work? Any help at all is much appreciated