ScrollTrigger snap inertia

[iDad5]

After I humiliated myself last time I'm actually reluctant to as another dumb question, but I can't help myself... 
(I will build a CodePen if necessary, but my question should be understandable without one I think.)

 

• I have a scrollTrigger that snaps to labels.
• It is created at its starting position (scroll() = 0)
• I want to scroll it to a position of one of the labels (lets say 500px);
• when I do this with scrollTrigger.scroll(500) the scrollTrigger runs through all label to the end of time(line)

 

Reason: inertia (defaults to true, and setting scroll to 500 in zero seconds accounts for a great amount of inertia - I guess)

 

When I create the scrollTrigger with snap{inertia:false} the scrollTrigger scrolls to 500 and stops. BINGO

 

BUT: I would prefer the behavior for the user scrolling with inertia - feels a lot better most of the times.

 

QUESTION: Is there a way to change the snap - inertia value after creation of a scrollTrigger? (I cannot find it in the docs)

[OSUblake]

No, there isn't a way to change inertia after creation. If you want it to immediately snap, you can get the snap tween and set its progress to 1.

 

https://greensock.com/docs/v3/Plugins/ScrollTrigger/getTween()

 

snap: {
  onStart(self) {
    self.getTween(true).progress(1);
  },
  ...
}

 

[iDad5]

Thank you @OSUblake, I tired that, but within a scrollTrigger with inertia enabled it does not make a difference.  When I call ScrollTrigger.scroll(500) it still overshoots to the end. 

 

I also tried to simply set the timelines position to the appropriate label  without setting the scrollTriggers scroll, that showed the panel I wanted, but when I started scrolling it jumped to the start... 

Edit: I also tried moving the timeline to the label I wanted before the creation  of the scrollTrigger, in the hope the a scrollTrigger created with an already existing animation would set its' scroll-position according to the timeline position, but that didn't work either.

 

I guess I have to do more testing and I will build a CodePen as soon as I can find the time. 

 

I do think that in the case of a scrollTrigger with snaping and inertia enabled, scrollTrigger.scroll() should, if somehow possible for once ignore inertia, as I don't see any use in the function under those circumstances - or am I missing something here?

[iDad5]

I think I'm going crazy....

 

here is my simplified example:

 

See the Pen rNzrqmV?editors=1111 by mdrei (@mdrei) on CodePen

 

It works as expected with inertia and without.

 

I recreated all relevant things exactly as I do in my project. In my project however the setup results in overshooting as soon as scrollTrigger->snap-> inertia is enabled, is works as expected if I disable inertia. (which I'd prefer not to do)

 

Of course in my project I do the whole thing after resizing but as i rebuild more or less everything at a resize, it should not make a big difference, I will have to make my pen a somewhat more complex to be sure...

 

 

 

 

[GreenSock]

@iDad5 you're saying you are not able to reproduce it outside your project, right? The CodePen works as expected? 

[iDad5]

I might not go totally bonkers..
here is my CodePen, that is reproducing the issue...

 

See the Pen bGoVpgE?editors=1111 by mdrei (@mdrei) on CodePen

 

How to reproduce:

Scroll to any panes other than 0.

Resize

See the situation being restored to the right panel.

 

In line 69 comment out "inertia=false"

try again, and you will see the drop to the end of time(line)

[iDad5]

@GreenSock well now I have been able to reproduce the issue. The pen is a bit more complex, as I had to integrate the resizing stuff I do in my original project  but I hope it can shed some light on the issue. 

 

 

[GreenSock]

Is there a reason you don't want to set inertia: false? 

 

I assume the behavior is due to the fact that resizing would cause the scroll progress to be at a very different value quickly, thus inertia would pick that up as moving fast. I've been toying with the idea of just eliminating inertia altogether because in practical usage I don't think it's terribly helpful since it must wait until scrolling stops anyway before kicking in the snapping. 

[iDad5]

to be honest, it just 'felt' somehow better, but  no real reason. Thank you for caring.