Negative timeline progress not working

[Edify Technologies 10 Likes (Newbie)]

I'm pretty sure I was able to set negative progress in gsap2, but it doesn't seem to be working in gsap3. Any thoughts?

See the Pen NWPPVKg by sallf (@sallf) on CodePen

[ZachSaucier 7,152 Likes (Superhero)]

Indeed it was:

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

 

What are you needing a negative progress value for?

[Edify Technologies 10 Likes (Newbie)]

Was that depreciated in gsap3?

 

Similar to my recent post, I'm working on bringing a slider based on OSUBlake's draggable infinity slider up to gsap3.

 

See the Pen veyxyQ by osublake (@osublake) on CodePen

 

In updateProgress() transform.x is usually a negative value, which is what's being passed to animation.progress(...). Looking closer, I didn't realize that progress will always compute to a positive number between 0 and 1. That logic makes sense and means I can just do the progress logic myself (something like const trans = transform.x > 0 ? (1 + transform.x) : transform.x;) before passing it to progress().

 

I think I had a general misunderstanding of the logic there and assumed it might be a bug in gsap3 since it worked that way in gsap2. 

[ZachSaucier 7,152 Likes (Superhero)]

@GreenSock might be able to provide some insight, but I don't think it's necessary for GSAP to support a negative progress value. As you point out it can be worked around. Thanks for bringing it up!

[Edify Technologies 10 Likes (Newbie)]

Ya, I don't think so either now that I understand it better.

 

Also, for anyone following along, I think the actual work around for this situation is something like this (not what I had above):
 

let transPerc = transform.x / wrapWidth;
transPerc = transPerc - Math.floor(transPerc);
const trans = transPerc > 0 ? transPerc + 1 : transPerc;

animation.progress(trans);

 

Thanks for the quick replies!

[GreenSock 18,592 Likes (Superhero)]

Yep, in v2 there was extra code to FORCE the value to be 0-1 but in v3 I eliminated that code for several reasons:

1. To allow things to genuinely go negative, meaning the startTime of the animation could shift in a more flexible way (rather than always forcing the animation to be within range of the parent timeline's playhead)
2. Less code = smaller file, less CPU cycles

And you're absolutely right - it'd be easy to get the behavior you wanted with a little extra code. ?